사례2건
2건 중 1~2번째
IL-0390PostHog 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 테이블로 옮겼다. 엔지니어가 직접 정기적으로 상태를 알렸다.
IL-0334RDS MySQL 의 bookmarks 테이블이 2TB 파일 크기 한도에 닿아 INSERT 가 실패하고 Instapaper 가 31시간 동안 멈췄다Instapaper2017- 증상
2월 9일 수요일 12:30PM PT 부터 Instapaper 사용자가 저장한 글을 담는 MySQL 의 bookmarks 테이블에 새 항목을 넣으면 오류가 나기 시작했다. Instapaper 서비스는 2월 10일 목요일 7:30pm PT 까지 멈췄다.
- 촉발
2월 9일 수요일 12:30PM PT 에 bookmarks 테이블이 2TB 파일 크기 한도를 넘었다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- Pinterest SRE 팀의 안내로 Instapaper 운영 데이터베이스를 i2.8xlarge 인스턴스의 5.5TB RAID-0 디스크에 덤프했다. 첫 시도는 24시간, 병렬로 돌린 두 번째 시도는 10시간이 걸렸다.
- 덤프가 너무 오래 걸리자 아카이브 접근을 제한한 채 동작하는 인스턴스를 약 6시간 만에 만들어, 31시간의 다운타임 끝에 운영에 올렸다.
- 옛 데이터베이스의 Aurora 읽기 복제본을 만들었다. Aurora 는 Instapaper 코드로 충분히 시험해 보지 않아 위험하다고 봤지만 만들기는 쉬웠다. 약 24시간 만에 끝났다.
- 새 MySQL RDS 인스턴스를 만들어 보조 인덱스 없이 데이터를 모두 넣었다. 8시간이 걸렸다. 그 뒤 보조 인덱스 세 개를 하나에 약 16시간씩 만들었다.
- Amazon 엔지니어가 실패한 운영 데이터베이스에 ext4 파일 시스템을 마운트하고 ext3 파일 시스템에서 ext4 파일 시스템으로 rsync 를 약 8시간 돌려, 데이터와 인덱스가 모두 있는 ext4 데이터베이스 인스턴스를 만들었다.
- RDS 엔지니어들이 임시 운영 데이터베이스의 바이너리 로그로 새 ext4 데이터베이스에 행 기반 복제를 걸어 목요일부터 월요일까지의 변경을 맞췄다. 약 3시간이 걸렸다.
- 새 데이터베이스를 마스터로 승격하고 애플리케이션 코드가 새 데이터베이스를 가리키도록 배포했다.
- 후속 조치
- Instapaper 전체 장애가 나면 Pinterest 의 SRE 팀에 바로 에스컬레이션하는 절차를 만든다.
- MySQL 백업 시험 주기를 석 달에 한 번에서 한 달에 한 번으로 늘린다.
- Pinterest 의 SRE 팀과 함께 이런 장애가 다시 나면 복구할 수 있는 절차를 마련한다.
- 교훈
팀이 알지 못했고 볼 수도 없었던 파일 시스템 한도 때문에 운영 데이터베이스뿐 아니라 모든 백업까지 쓸 수 없게 됐다. 호스팅된 인스턴스에는 MySQL 로만 접근할 수 있어서 rsync 같은 파일 시스템 수준의 해결책은 Amazon 엔지니어의 도움 없이는 쓸 수 없었다. 완벽하게 대응했어도 진단부터 데이터베이스 재구축까지 다운타임은 최소 10시간이었을 것이다. 이 문제는 미리 내다보고 막기 어려웠지만, 이런 장애를 위한 재해 복구 계획이 없어 다운타임과 복구 시간이 필요 이상으로 길어졌다. 데이터베이스를 다시 만드는 데 며칠이 걸린다는 것을 알았다면 곧바로 제한된 서비스 복구로 들어가 첫날의 다운타임을 크게 줄일 수 있었다. Pinterest 안에서, 그리고 AWS 팀과 더 잘 소통했다면 쓸 수 있는 자원을 더 잘 활용했을 것이다. 글쓴이는 다른 회사가 호스팅하는 기술이라도 매일 운영에 쓰는 기술의 한도를 이해하는 것이 자신의 책임이라고 밝혔다.
이 2건에서 가장 많이 나오는 구성 요소: 데이터베이스, 데이터베이스 백업과 스냅숏. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.