사례2건
2건 중 1~2번째
- 증상
2022-03-27 3:23 UTC 에 계정, 서버, 플레이어 정보를 담는 주 PostgreSQL 데이터베이스가 쓰기를 받지 않았다. 처음 보인 증상은 사용자가 웹사이트를 불러오지 못하는 것이었다.
- 촉발
플레이어 식별자 테이블의 인덱스가 알 수 없는 이유로 손상돼 vacuum 작업이 모두 오류로 끝났다. 로그로 보아 손상은 약 한 달 전인 2022-02-26 에 생긴 것으로 추정했고, 그동안 트랜잭션 ID 가 계속 쌓여 2022-03-27 에 wraparound 보호가 작동했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
처음 들어온 것은 웹사이트를 불러오지 못한다는 사용자 신고였다. 팀은 30분쯤 전에 작동한 DDoS 방어 탓으로 보았다가, RCON 업데이트와 쿼리가 실패하는 것을 보고 더 살펴본 끝에 주 데이터베이스가 쓰기를 받지 않는 것을 찾았다.
- 조치
- 데이터베이스를 내리고 single-user mode 로 들어가 손상된 인덱스를 지운 뒤 데이터베이스를 다시 올렸다.
- vacuum 을 다시 돌렸고, 이번에는 성공해 데이터베이스가 다시 쓰기를 받았다.
- 지운 플레이어 식별자 인덱스를 약 두 시간에 걸쳐 다시 만들었다.
- 데이터베이스가 돌아온 뒤 쿼리 워커를 모두 멈추고 RCON 업데이트를 우선했다.
- 인덱스가 돌아오자 서비스가 새 Postgres primary 를 가리키게 했다.
- replica 를 더 부트스트랩해 하나 올라올 때마다 primary 부하를 덜었고, 16:30 UTC 에 RCON 업데이트를 따라잡았다.
- RCON 업데이트가 늦어지지 않게 쿼리를 제한해서 다시 돌렸고, 쿼리의 우선순위는 서버의 현재 접속 인원과 순위로 매겼다.
- 후속 조치
- Postgres 로그의 오류를 모니터링한다.
- 트랜잭션 ID 를 모니터링하고 알림을 건다.
- 물리 복제에 더해 논리 replica 를 둔다.
- 장애에서 더 빨리 복구하도록 더 빠른 네트워크를 갖춘다.
- 교훈
BattleMetrics 는 Postgres 의 트랜잭션 ID 크기를 확인하는 헬스 체크를 두지 않은 것을 결정적인 실수로 보았다. 인덱스 손상은 사이트 성능에 영향이 없어 한 달 동안 드러나지 않았고, 그동안 vacuum 이 계속 실패하며 데이터베이스가 wraparound 에 다가갔다. 손상은 replica 에도 복제돼 있어 장애 조치가 소용없었고, 백업 서버와 내려받기용 백업도 같은 손상을 안고 있었다. 오류 문구와 달리 wraparound 보호에 들어간 서버에서도 single-user mode 없이 전체 vacuum 을 돌릴 수 있었다.
- 증상
2020-01-22 오전 9시 45분 PST부터 데이터베이스 지표에서 쓰기 IOPS와 락 경합이 늘었다. 전날 사고와 달리 데이터베이스 CPU는 평소보다 낮았다. 오전 10시에 자동 알림이 왔고, 일부 사용자는 Figma를 불러오지 못했다.
- 촉발
사고가 시작된 바로 그 시각에 테이블 하나의 자동 ANALYZE가 끝나 통계가 바뀌었고, PostgreSQL 9 쿼리 플래너가 ORM이 만든 질의 하나의 행 수를 크게 잘못 추정했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
2020-01-22 오전 10시 PST에 자동 알림을 받고 조사를 시작했다. 데이터베이스 지표의 변화는 9시 45분부터 보였다. 전날 사고도 오전 6시 11분 PST의 오류율 상승 자동 알림으로 알아챘다.
- 조치
- 데이터베이스 부하를 줄이려고 꼭 필요하지 않은 질의 몇 개를 취소하고 할당 IOPS를 늘렸다.
- 가장 큰 테이블들에서 돌던 autovacuum 문을 취소했다. 지표가 잠시 나아졌지만 autovacuum이 다시 시작됐다.
- 공격적인 autovacuum을 완전히 막으려고 autovacuum_freeze_max_age 파라미터를 바꾸고 데이터베이스를 재부팅했다.
- 오후 7시 PST에 서비스를 내려 긴급 유지보수를 하고, 스테이징에서 미리 시험한 PostgreSQL 11로 데이터베이스를 올렸다. 오후 8시 15분 PST에 사이트를 다시 열었다.
- 후속 조치
- 장시간 도는 비싼 질의가 끊기도록 트랜잭션 타임아웃과 한도를 다시 정한다.
- autovacuum, 락, 질의 성능과 관련된 지표, 모니터링, 데이터베이스 설정을 개선한다.
- 쿼리 플래너를 헷갈리게 할 수 있는 불필요하거나 지나친 조인과 하위 질의가 있는지 질의를 점검한다.
- 업그레이드한 PostgreSQL에서 쓸 수 있는 새 성능 분석 도구를 장애 대응 계획에 넣어 문제 질의를 더 빨리 가려낸다.
- PostgreSQL에 들어 있는 데이터 종류별 구조와 접근 방식을 점검하고, 일부 데이터는 접근 방식에 맞는 저장소로 옮기는 것을 검토한다.
- 예정에 없던 유지보수 시간을 앱 안에서 알리는 방식을 개선한다.
- 앞으로 중단 시간이 필요 없는 온라인 데이터베이스 업그레이드로 옮겨 간다.
- 오프라인이 된 뒤 다시 연결되기 전에 브라우저를 닫아도, 이미 열어 둔 파일에서 계속 안전하게 작업할 수 있게 하는 일을 시작한다.
- 교훈
스테이징 데이터베이스를 미리 PostgreSQL 11로 올려 몇 달 시험하고 운영 업그레이드 계획을 써 둔 덕분에 좋지 않은 상황에서도 업그레이드를 결정할 수 있었다. autovacuum을 막은 뒤에도 성능 문제가 남았으므로 autovacuum은 기여 요인이었을 뿐 유일한 원인이 아니었다. 같은 질의의 행 추정이 시점마다 크게 달랐다는 것은 통계 문제의 신호였다.
이 2건에서 가장 많이 나오는 구성 요소: PostgreSQL vacuum, 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.