솔직히 이건 대단한 자랑거리가 아니라고 생각함. 100PB나 되는 로그를 저장하고 있다는 건, 아직 뭘 진짜로 남겨야 하는지 못 찾았다는 증거. 대부분의 핵심 정보는 메트릭과 구조화된 이벤트로 충분히 파악 가능. 나머지는? 아무도 안 읽는 디테일한 트레이스 로그, 정말 장애 터졌을 때나 봄. 더 잘할 수 있는 방법은? 한 번도 알람에 활용되지 않은 로그, 혹은 3개월 동안 검색에도 안 걸린 로그는 자동으로 삭제하는 식의 ‘관심도 기반 저장 정책’ 도입. 이런 식으로 가지 않는 한, 이건 그냥 아주 고급 디지털 쓰레기 더미에 압축만 좀 한 수준
나는 반대로 모든 데이터를 모으고, 필요 없을 때 필터링하는 쪽을 선호함. 디버그 로그는 평소엔 필요 없지만, 필요할 때는 진짜 없어서는 안 되는 존재. 어떤 이벤트가 재현도 안 될 만큼 희귀한 경우엔, 그때서야 데이터를 다시 모을 수 없음. 이미 전부 저장돼 있으면 찾기만 하면 되니까 훨씬 낫다고 생각
여러 회사에서 Datadog을 쓰면서, 갱신 비용이 터무니없게 나오면 메트릭과 제한된 이벤트만 남기고 로그는 줄이자는 압박을 많이 받았던 경험 있음. 문제는, 어떤 일이 터질지 미리 알았으면 진작에 고쳤을 거라는 점. 뭔가 이상하면 도대체 무슨 일이 있었나 찾을 때는 디테일 로그가 매우 필요함. 그런데, 반복적으로 일어나는 상황이 아니면 어떤 로그가 중요한지 알 방법이 없다는 게 현실
‘관심도 기반 저장 정책’ 정말 멋진 아이디어임. 로그 패턴별로 쿼리/알람 접근 횟수만 카운트해도 TTL(저장 기간) 정책 세울 수 있음. 실제로 우리 팀도 이 방식 도입해서 저장 비용 70% 줄이면서, 중요한 데이터는 다 남김
로그 전송 비용도 공짜가 아님. 특히, 크래쉬 원인 파악을 위해 최대한 빨리 디스크에 로그를 쓰는 언어일수록 더 비용이 커짐. 정보가 너무 많으면 진짜 중요한 상관관계 찾기도 힘들고, 해결된 버그의 로그는 가치가 금방 떨어짐. 난 통계 데이터를 선호함. 통계 데이터는 집계 방식이 효율적이고, 특히 GIL 기반 언어에선 OTEL 사용 시 오버헤드가 과도한 경우도 있음
데이터가 이미 저장돼 있다면, 이후 필터링이나 정리는 할 수 있는 문제라고 봄. 데이터를 다 저장해두고 필요할 때 쓰는 게, 필요할 때 없어서 고생하는 것보단 낫다고 생각함. 물론, 이런 대용량 인프라를 운영할 수 있는 리소스가 있다는 전제하에 가능한 얘기
이건 사실 Clickhouse 로그에만 해당되는 내용. 다른 종류 로그에는 별로 연관 없음. 물론 Clickhouse 자체는 아주 마음에 드는 솔루션이긴 하지만
파티에서 엄청 재밌는 타입일 것 같음
주의할 점 하나 언급할게. 서비스가 크래시 루프에 빠지거나 장애로 다운됐을 땐, SysEx로는 필요한 시스템 테이블에 접근 불가라 로그를 수집할 수 없음. 하지만 OpenTelemetry(OTel)는 수동적인 방식이라 서비스가 완전히 정상화되지 않았더라도 stdout, stderr로 나오는 로그를 챙길 수 있음. 이런 식으로 장애 상태에서도 로그를 모아서 근본 원인까지 분석 가능
내가 해온 OTel 프로젝트들은 모두 능동적인 방식이었음. 그래서 저 내용은 딱히 새로운 정보라기보단, 잘못됐거나 불완전한 설명인 것 같음
'와이드 이벤트(wide event)'가 진짜 이렇게나 많은 저장 공간을 잡아먹어야 하는지 의문. 관찰(Observability)이란 건 본질적으로 샘플링 문제임. 최소한의 저장 공간으로, 특정 시점의 상태를 최대한 잘 복원할 수 있으면 됨. 샘플 개수를 줄이거나 압축 효율을 끌어올리면 됨. 그런데, 압축 기술이 아직 한계까지 간 것도 아니라고 봄. 중복 투성이 데이터엔 반드시 엄청난 저차원(low rank) 구조가 있을 거라 생각. 물론 이미 인버티드 인덱스나 각종 트리도 쓰고 있지만, 더 실험적인 저차원 텐서 분해 같은 연구적인 방법에도 희망이 있다고 느낌. 나도 업계 사람은 아니라 뭔가 빠뜨린 게 있을 수도 있음
ClickHouse 정도 스케일은 경험 못 해봤음. 이런 볼륨의 로그는 정말 검색 가능? ElasticSearch는 소규모엔 쿼리가 잘 되는 걸로 알고 있음. 역사적 로그용으로 json 파일 저장하는 방식 대신 ClickHouse를 써야 하는 이유는 뭘까?
이 스케일에서 일하고 있음. 결론부터 말하자면, 가능은 함. 하지만 처리 비용이 상상을 초월할 수 있음. 인덱싱, 정렬, 클러스터링 전략이 엉망이면, "이 문자열이 들어간 레코드" 한 번 검색하는 데 $1~$10도 나옴. 내 경험상 대용량 데이터에선 무조건 "최대한 적은 데이터만, 최대한 적게 만지기"와 "최대한 덜 옮기기" 원칙이 중요. 직렬화/역직렬화 또는 디스크, 네트워크 IO가 한 번만 들어가도 비용이 폭증. 이러면 OTel의 경우, 데이터 수집기(collector) 한 번 더 거치는 게 효율성에 정면 위배될 수 있음. 하지만 페타바이트 스케일에선 이런 작은 최적화를 통해 아낀 돈이, 복잡한 직렬화 코드를 짜는 엔지니어 연봉을 뽑고도 남음
왜 ClickHouse를 json 파일보다 히스토리 로그 용도로 쓰냐고? 이유는 여러 가지. (1) ClickHouse 같은 로그용 DB는 컬럼 단위 압축으로 각 필드별로 따로 압축해서 일반 json 파일(압축된 것 포함)보다 훨씬 작은 저장 공간. (2) 로그 DB는 쿼리 속도가 훨씬 빠름. 1000배 이상 빠른 것도 가능. 이유는 필요 없는 데이터는 아예 안 읽으니까. 관련 링크. (3) 100PB의 json 파일을 grep으로 검색하는 건 현실적으로 불가능. 로그 DB는 저장 노드, 저장 공간만 늘리면 수평 확장으로 가능한 구조
규모와 비용의 문제임. 우리 회사도 로그 볼륨 문제에 부딪침. json을 Splunk로 그냥 넣으면 연간 600만 불 넘게 듦. 그런데 승인된 예산은 5~10%밖에 안 됨. 본문에서 json 로그 처리에 8,000개 CPU가 필요하다고 했는데, 최적화 후엔 90개 CPU만으로 해결된다고 함
2~3년 전엔 ClickHouse가 전문(full text) 검색 성능이 아쉬웠음. 빠르고 ElasticSearch급 대용량 처리도 되긴 하는데, 사용 용도에 따라선 미리 인덱싱 안 하면 ES가 묶음, 그룹핑, FTS엔 훨씬 빠른 편이라고 느낌
관측팔 극단주의는 진짜 신흥 종교 느낌. 그리고 돈도 엄청 많음
알려지지 않은 이상현상까지 파고들려면, 딱히 뾰족한 대안이 없는 상황
재밌는 건, 이런 문제로 고생하라고 만들더니 결국 "월정액만 내면 다 해결" 전략으로 파는 아이러니 상황
본문에서 로그 보존 기간(리텐션)이 얼마인지 얘기가 없었음. 특정 기간 지나면 요약/집계 데이터만 남기고 원본 데이터는 굳이 보유 필요성에 의문
Clickhouse 쓰다가 Postgres로 돌아오면 항상 문화 충격 느낌. 20GB 덤프 임포트하는 데 몇 분씩 걸린다는 게 납득이 안 됨. 이거 몇 초면 하지 않아야 하는 상황 아닌가
Clickhouse 사용할 때마다 너무 힘듦. 물론 Clickhouse가 필요한 쓰임새가 있고, Postgres가 다 대체할 수 있는 건 아니지만, 왠지 Clickhouse는 ‘위험요소’가 많고, 특별히 제한된 목적 아니면 거의 모든 면에서 Postgres가 더 낫다고 느낌
넓은(wide) 이벤트를 쓰라는 압박을 받는 사람들은 로그용 데이터 비용 폭증 이야기를 안 함. 기존 방식(메트릭+트레이스+샘플 기반 로그)이랑 비교하면 확실히 돈 많이 듦. 분명 이득도 있지만, 비용 문제는 항상 빠짐
제대로 설계된 wide event 구조는 오히려 전통적 로그보다 저장 비용을 줄일 수 있음. 한 번의 외부 요청이 하나의 wide event로 남으니까, 이후 디버깅이나 분석에도 필요한 정보가 다 담김. 관련 글 참고 A practitioner's guide to wide events
Clickhouse나 Dynamo와 같은 시스템의 핵심 트릭이 궁금함. 본질적으로 거대한 해시테이블 같은 구조인지?
Clickhouse 등 대용량 DB에 공통된 트릭 두 가지가 있음. 첫째, 디스크에 데이터를 똑똑하게 배치해서 대부분의 데이터를 무시하고 필요한 덩어리만 읽어내는 방식(컬럼 지향 저장 및 LSM 트리류 등). 그리고 저장 데이터를 모두 압축해서 디스크 IO까지 최소화. 둘째, 모든 자원(CPU, RAM, 디스크, 네트워크)을 최대한 활용하게 하는 극한의 튜닝. 예를 들어 Clickhouse는 CPU 코어 하나당 초당 10억 개 이상의 로우를 처리할 수 있고, 코어 수에 맞게 선형적으로 확장됨
Hacker News 의견