사례2건

2건 중 1~2번째

1. IL-0281 PostHog US 리전 Logs 제품의 ClickHouse 클러스터가 S3 에 둔 로그 데이터를 거의 다 지워 3일보다 오래된 로그가 사라졌다

   PostHog2026

   증상

   Logs 클러스터의 노드 하나가 죽었고, 다시 시작하는 중에 찾을 수 없는 데이터가 너무 많아 뜨지 못했다. 엔지니어가 확인해 보니 S3 에 저장된 데이터 대부분이 없었다.

   데이터 유실

   촉발

   인덱스를 materialize 하는 일상적인 mutation 이 끝나면서 ClickHouse 의 zero-copy replication 버그가 터졌고, 복제본 하나가 데이터베이스의 모든 데이터 파트를 더는 아무도 참조하지 않는다고 잘못 판단했다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스데이터베이스 복제오브젝트 스토리지데이터베이스 백업과 스냅숏

   기여 요인

   모니터링 사각지대단일 장애점미검증 백업

   감지

   19:40 UTC 에 클러스터 노드 하나가 죽었고, 재시작하다 없는 데이터가 많아 뜨지 못했다. 엔지니어가 이를 조사하다 S3 에 저장된 데이터 대부분이 없는 것을 발견했다. 그 전 8시간 동안 자동 알람은 하나도 울리지 않았다.

   조치

   • zero-copy replication 을 쓰지 않는 새 테이블로 전환하고 최근 메시지를 따라잡았다.
   • 보존 기간 3일인 Kafka 기록에서 데이터를 새 테이블로 백필했다. 2월 20일 10:05 UTC 에 시작해 12:21 에 끝났다.

   후속 조치

   • 모든 클러스터에서 Zero Copy Replication 을 바로 끈다.
   • Logs ClickHouse 설정 전체를 감사하고 운영 환경에서 실험 기능을 쓰지 않게 한다.
   • 저장소 버킷에 S3 Versioning 을 켜서 데이터베이스가 버그로 파괴적인 명령을 내도 객체를 되살릴 수 있게 한다.
   • 제품을 정식 출시하기 전에 설정과 데이터 무결성 전략을 표본 점검한다. 이 점검으로 단일 장애 지점을 찾아 고친다.

   교훈

   Logs 제품을 따로 떼어 둔 덕분에 다른 제품과 기능은 전혀 영향을 받지 않았고, Kafka 보존 기간 3일 덕분에 최근 데이터는 잃지 않았다. 반면 MVP 와 알파 단계에 쓰려던 실험 설정이 운영 환경까지 그대로 남았다. PostHog 는 들어오는 데이터와 핫 데이터의 상태만 감시해 과거 데이터가 지워지는 것을 보지 못했다. 공유 저장소를 쓰면서 데이터 내구성을 데이터베이스 복제에만 맡겨 단일 장애 지점이 생겼고, S3 Versioning 이 없어 지워진 파일을 되살릴 수 없었다.

   사례 보기
2. IL-0390 PostHog US Cloud 의 Persons Postgres 데이터베이스 쓰기가 크게 느려져 이벤트와 persons 수집이 최대 2일 지연됐다

   PostHog2025

   증상

   2025년 11월 11일 16:02 UTC 부터 PostHog 수집 처리 파이프라인의 성능이 크게 떨어져, US 리전 모든 고객의 이벤트 처리가 지연되기 시작했다. 고객이 최근에 보낸 이벤트가 PostHog 에 보이지 않았다.

   처리량 저하지연 시간 증가

   촉발

   Persons 테이블의 properties 열은 자주 2KB 를 넘어 TOAST 테이블에 따로 저장되는데, 이 값마다 할당하는 32비트 OID 공간이 거의 다 찼다. 그러자 쓰기 한 건마다 비어 있는 OID 를 찾느라 이미 쓴 OID 를 길게 훑어야 했다.

   원인

   용량 한계

   구성 요소

   데이터베이스메시지 브로커

   기여 요인

   한계 미인지모니터링 사각지대런북 부재

   조치

   • 새 TOAST 테이블과 새 OID 공간을 갖는 파티션 Persons 테이블 구조를 새로 만들었다.
   • 실시간 쓰기가 옛 테이블과 새 테이블에 함께 맞춰지도록 데이터베이스 트리거를 넣었다.
   • 백필 스크립트로 기존 Person 데이터를 옛 테이블에서 새 테이블로 복사했다.
   • 새 쓰기는 모두 새 테이블로 가고, 옮기는 동안 읽기는 새 테이블을 먼저 본 뒤 옛 테이블로 넘어가도록 수집과 애플리케이션 로직을 바꿨다.
   • 장애 중 새 문제를 만들 위험이 있어, 웹 앱은 완전 자동 롤아웃 대신 사람이 통제하는 배포로 운영에 내보냈다. 엔지니어 여럿이 주말 내내 교대로 Feature flags API, Error tracking 수집, Django 웹 애플리케이션을 고쳤다.
   • 새 Persons 테이블에서 수집 성능이 돌아온 뒤, 파티션별 지연, 처리량, 자원 사용률을 지켜보며 수집 워커를 늘려 밀린 이벤트를 처리했다.
   • MSK 로컬 디스크 사용률이 약 85% 에 닿자 수집을 잠시 멈췄다.
   • 해당 Kafka 토픽의 로컬 보존 기간을 줄여, S3 로 넘기기 전에 디스크에 두는 데이터를 줄였다.
   • 디스크 여유가 충분한 것을 확인한 뒤 수집을 다시 시작했다.
   • 오래 걸리는 백필 작업을 더 잘 지켜보고 안정적으로 돌리려고 백필 과정을 Dagster 로 옮겼고, 남은 백필과 정리 작업을 주말 동안 Dagster 로 끝냈다.

   후속 조치

   • 쓰기마다 디스크 읽기가 크게 늘어나는 현상에 지표와 알림을 더한다.
   • TOAST 테이블 통계에 지표와 알림을 더한다.
   • 큰 규모에서 문제가 될 수 있는 다른 Postgres 엔진 한계에도 지표와 알림을 더한다.
   • 비슷한 Postgres 엔진 수준 문제의 증상과 진단 방법을 런북으로 정리하고, 옮길지 제자리에서 고칠지 정하는 의사 결정 트리를 분명하게 넣는다.
   • 고객에게 언제 어떻게 알릴지, 누구에게 에스컬레이션할지, 누가 대신 맡을지를 분명히 정한 고객 소통 런북을 새로 만든다.
   • persons 데이터베이스에 다른 데이터 저장소를 쓰는 방안을 계속 검토한다.
   • 새 테이블로 통합하는 작업을 마무리한다.
   • 백필 도구와 Kafka tiered storage 의 안전장치를 개선한다.
   • Person 과 비슷한 테이블을 처음부터 비슷한 한계에 닿지 않게 설계하고 운영한다.

   교훈

   Persons 테이블 하나에 analytics, feature flag, replay 필터, CDP 같은 핵심 기능 다수가 기대고 있어, 이 테이블이 느려지자 제품의 넓은 부분이 영향을 받았다. TOAST 증가, OID 사용량, 쓰기당 디스크 읽기 증폭을 보는 모니터링이 없어 OID 고갈을 원인으로 확정하는 데 하루 반쯤 걸렸다. 처음의 백필 방식은 길고 큰 마이그레이션에 필요한 가시성과 견고함이 모자라 장애 중에 Dagster 로 옮겨야 했다. MSK 디스크가 차오른 일로 tiered storage 설정과 알림이 큰 백로그 상황에 맞춰져 있지 않았다는 것이 드러났다. 평소 고객 소통을 맡는 팀원이 장애 내내 모두 자리에 없어 대신할 사람을 급히 찾아야 했다. PostHog 는 잘된 점으로 네 가지를 꼽았다. 데이터를 잃지 않았다. 여러 팀과 외부 컨설턴트, AWS 엔지니어가 함께 드문 엔진 수준 문제를 진단했다. 시스템을 살려 둔 채 트리거와 백필로 새 Persons 테이블로 옮겼다. 엔지니어가 직접 정기적으로 상태를 알렸다.

   사례 보기

원인별2