사례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-0485 계획된 OS 업그레이드 작업이 운영 중인 데이터베이스 서버를 재설치해 Dropbox 서비스가 멈췄다

   Dropbox2014

   증상

   2014-01-10 금요일 오후 5시 30분 PT에 시작한 계획된 유지보수 중에 Dropbox 서비스가 내려갔다. 약 3시간 뒤 서비스는 다시 올라왔지만, 핵심 서비스가 완전히 돌아온 것은 일요일 오후 4시 40분 PT였다.

   서비스 중단

   촉발

   일부 서버의 OS를 올리는 계획된 유지보수에서 업그레이드 스크립트의 잘 드러나지 않는 버그 때문에 사용 중인 데이터가 있는 서버 몇 대에 재설치 명령이 내려졌다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스데이터베이스 백업과 스냅숏

   기여 요인

   파괴적 변경 보호 장치 부재

   조치

   • 서비스를 빨리 되살리려고 영향을 받은 데이터베이스를 백업에서 복원했다.

   후속 조치

   • 서버가 들어온 명령을 실행하기 전에 자기 상태를 로컬에서 확인하는 검사 단계를 더했다. 중요한 프로세스를 돌리고 있다고 스스로 확인한 서버는 파괴적일 수 있는 작업을 거부한다.
   • 바이너리 로그 재생을 병렬로 처리하는 도구를 만들어 큰 MySQL 백업에서 더 빨리 복원한다.
   • 이 바이너리 로그 병렬 재생 도구를 오픈 소스로 공개할 계획이다.

   교훈

   서버 상태를 원격 스크립트로만 확인하면 스크립트의 버그 하나로 운영 서버에 파괴적인 작업이 실행될 수 있으므로, 서버 스스로도 자기 상태를 확인해야 한다. 복제본을 여러 대 두어도 복제본까지 잃으면 백업에서 복원하는 길뿐이다. 큰 데이터에서는 MySQL 표준 복원 도구가 느리므로 복구를 빠르게 할 수단이 필요하다.

   사례 보기

원인별1