Incident Library

IL-0281 PostHog · 2026-02-19databaseaws

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

PostHog 는 Logs 제품의 데이터를 다른 제품들이 함께 쓰는 주 ClickHouse 클러스터와 분리된 전용 클러스터에 저장했다. 이 클러스터는 ClickHouse 의 S3 디스크를 써서 24시간이 지난 데이터 파트를 자동으로 S3 에 올렸다. 데이터베이스에는 복제본이 둘 있었지만, PostHog 는 프로젝트 초기에 Zero Copy Replication 을 켜 두었다. Zero Copy Replication 은 ClickHouse 가 운영 환경에 권하지 않는 실험 기능이고, 이 기능을 켜면 여러 복제본이 S3 라는 같은 저장소를 함께 쓴다.

2026년 2월 19일 10:54 UTC 에 인덱스를 materialize 하는 mutation 을 돌렸고, 11:02 에 mutation 이 끝나면서 zero-copy replication 버그가 터졌다. 복제본 하나가 모든 데이터 파트를 더는 아무도 참조하지 않는다고 판단해 S3 객체 삭제 명령을 냈다. 복제본들이 저장소를 함께 쓰므로 파일은 클러스터 전체에서 바로 사라졌다. 19:40 까지 복제본들이 데이터베이스 전체의 S3 데이터를 지우는 동안 알람은 울리지 않았다. S3 에 둔 콜드 데이터의 무결성을 보는 모니터링이 없었고, 알림은 수집 지연, 쿼리 지연, 활성 쿼리의 오류율을 보도록 맞춰져 있었기 때문이다.

19:40 에 노드 하나가 죽었고, 재시작하다 없는 데이터 때문에 뜨지 못했다. 엔지니어가 이를 살피다 S3 데이터 대부분이 사라진 것을 찾았다. 21:45 에 데이터를 되살리기 어렵다고 판단해 재해 복구 절차를 시작했고, 22:15 에 새 테이블로 넘어가 보존 기간 3일인 Kafka 에서 데이터를 복원하기로 했다. 23:00 에 zero-copy replication 을 쓰지 않는 새 테이블로 전환해 최근 메시지를 따라잡았다. 2월 20일 10:05 에 시작한 Kafka 기록 백필은 12:21 에 끝났다. 버킷에 S3 Versioning 이 꺼져 있어 지워진 파일을 되살릴 수 없었고, 3일보다 오래된 로그는 잃었다. 다른 PostHog 제품과 데이터는 영향을 받지 않았다.

심각도
–
영향 범위
Logs product: logs collected more than 3 days before the incident were lost; all other PostHog products and data were unaffected
영향 사용자
–
지역
US region
감지까지
8h 38m
복구까지
25h 19m

증상

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

삭제는 노드가 죽기 전 약 8시간 동안 조용히 진행됐다. 데이터는 24시간이 지나야 S3 로 옮겨지고 쿼리 대부분은 최근 데이터를 찾으므로 쿼리 오류가 적었다. 자동 알람은 하나도 울리지 않았다. 애플리케이션 수준의 오류도 나지 않아, 노드 재시작으로 일관성 검사가 돌기 전까지 대시보드는 초록색이었다.

증상 데이터 유실

원인

원인 소프트웨어 결함

구성 요소 데이터베이스데이터베이스 복제오브젝트 스토리지데이터베이스 백업과 스냅숏
기여 요인 모니터링 사각지대단일 장애점미검증 백업
촉발
인덱스를 materialize 하는 일상적인 mutation 이 끝나면서 ClickHouse 의 zero-copy replication 버그가 터졌고, 복제본 하나가 데이터베이스의 모든 데이터 파트를 더는 아무도 참조하지 않는다고 잘못 판단했다.

감지

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

조치

후속 조치

교훈

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

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 데이터베이스 복제, 오브젝트 스토리지. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.