사례7건

7건 중 1~5번째

1. IL-0432 Memorystore for Redis 가 메모리 단편화로 쓰기를 거부해 AutoReserve 예약 알림 일부가 조용히 빠졌다

   Hello Inc.2026

   증상

   레스토랑 예약 서비스 AutoReserve 에서 예약 관련 알림 일부가 도착하지 않는다는 버그 보고가 들어왔다. 여러 종류의 알림 가운데 한 종류만 갔다 안 갔다 했고, 로그에는 정상으로 보이는 Notification already scheduled 가 찍혔다.

   쓰기 거부메모리 압박

   원인

   용량 한계

   구성 요소

   인메모리 캐시

   기여 요인

   모니터링 사각지대안전하지 않은 실패 동작미검증 가정

   감지

   AutoReserve 에서 예약 관련 알림 일부가 도착하지 않는다는 버그 보고가 들어왔다.

   조치

   • 메모리가 부족하다고 보고 Redis 인스턴스를 8GiB 에서 16GiB 로 늘렸지만, 쓰기 거부는 멈추지 않았다.
   • Redis 3.2 를 7.2 로 업그레이드했고, 그때 쓰기 거부가 멈췄다.
   • Redis 가 다시 쓰기를 거부해도 알림이 빠지지 않도록 보낸 상태를 Redis 가 아니라 RDB 에서 관리하게 바꿨다.

   후속 조치

   • 물리 메모리 사용량이 논리 메모리 사용량의 1.3배를 넘기 시작하면, Redis 를 멈추지 않고 단편화를 해소하는 active defrag 를 켜는 것을 검토한다.

   교훈

   보낸 상태를 판정하는 데 중요한 것은 속도가 아니라 값이 사라지지 않는 것과 여러 처리가 동시에 와도 결과가 하나로 정해지는 것이었다. 캐시는 사라져도 되살릴 수 있는 값을 두는 곳이고, 처음부터 쓰기가 실패할 수 있다고 보고 만든 것이다. 그러므로 값의 성질에 맞춰 둘 곳과 다루는 방식을 정해야 한다. 로그와 인스턴스 화면 메트릭처럼 겉으로 보이는 정보만으로는 원인을 잡지 못했고, Redis 안까지 들어가 봐야 했다.

   사례 보기
2. IL-0326 MailPace 의 관리형 Postgres 데이터베이스 디스크가 가득 차 데이터베이스가 두 시간 넘게 내려갔다

   MailPace2023

   증상

   2023-08-11 13:36 BST 에 여러 서비스에서 모든 데이터베이스 트랜잭션이 실패한다는 알림이 들어왔다. 데이터베이스를 다시 시작하려 했지만 공간이 없다며 올라오지 않았다. 메일도 나가지 않았다.

   노드 디스크 가득 참서비스 중단쓰기 거부

   촉발

   13:15 BST 에 cron 인스턴스 메모리를 1gb 에서 8gb 로 늘려 밀려 있던 보존 기간 정리 작업을 돌렸다. destroy_all 이 연결된 레코드까지 한꺼번에 많이 지우면서 데이터베이스 디스크가 빠르게 찼다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   비효율적인 쿼리모니터링 사각지대여유 용량 부재

   감지

   13:00 BST 정기 점검에서 데이터베이스가 평소보다 큰 것을 먼저 봤다. 13:36 에는 여러 서비스에서 모든 데이터베이스 트랜잭션이 실패한다는 알림이 곧바로 들어왔다. 상태 페이지 두 개는 장애를 잡지 못했다. 업스트림 제공자는 저장 공간이 99% 찼을 때 자동으로 알림을 받았다.

   조치

   • Postgres 가 관리형 서비스였으므로 13:37 BST 에 곧바로 업스트림 제공자 지원팀에 연락했다.
   • 13:40 에 Twitter 와 Mastodon 으로 사용자에게 장애를 알렸다. 상태 페이지가 자동으로 바뀔 것으로 생각했지만 바뀌지 않았다.
   • 제공자의 답을 기다리는 동안 13:45 에 전체 장애 복원 절차를 시작해 6시간 전 오프사이트 백업을 새 데이터베이스 인스턴스에 준비했다.
   • 15:50 에 제공자의 이전이 끝나 더 큰 데이터베이스 인스턴스로 옮겨졌고 메일이 다시 나갔다.
   • 백업에서 시험해 고친 쿼리로 운영의 오래된 데이터를 하루 단위로 직접 지웠다. 그동안 메모리, 데이터베이스 크기, 지표를 가까이 지켜봤다.

   후속 조치

   • 매일 도는 정리 작업을 in_batches(of: 50) 로 바꿔 한 번에 50건씩만 지우게 했다. ruby 메모리 요구량과 postgres 부하가 줄었다.
   • 정리 작업을 하루 한 번이 아니라 네 번 돌게 바꿔 한 번 실행의 영향을 줄였다.
   • 성장 여유가 훨씬 많은 더 큰 데이터베이스 인스턴스로 옮겼다.
   • 모든 cron 작업에 cron 모니터링을 적용했다.
   • 상태 페이지가 헬스 체크 엔드포인트 /health 를 보게 바꿨다. 이 엔드포인트는 데이터베이스 접근을 포함해 여러 가지를 확인하고 하나라도 실패하면 500 오류로 응답한다.
   • 자동 장애 조치를 위한 핫 레플리카 데이터베이스를 검토한다.

   교훈

   장애는 여러 원인이 겹쳐 났다. 오래된 데이터를 지우는 cron 작업이 조용히 실패해 데이터가 쌓였다. 이 작업은 평소 하루치 양이었다면 문제없었겠지만 지나치게 단순하게 짜여 있었다. 데이터베이스 요금제는 처음부터 성장 여유가 부족했다. 상태 페이지는 장애를 잡지 못했다. MailPace 는 중요한 서비스마다 제공자를 여럿 두라고 권했다. 또 장애를 감지해 메일을 예비 제공자로 보내는 오픈 소스 아웃바운드 SMTP 프록시 Outgoer 를 만들고 있다고 밝혔다.

   사례 보기
3. IL-0311 주 PostgreSQL 데이터베이스가 트랜잭션 ID wraparound 보호로 읽기 전용이 되어 웹사이트와 백엔드 서비스가 멈췄다

   BattleMetrics2022

   증상

   2022-03-27 3:23 UTC 에 계정, 서버, 플레이어 정보를 담는 주 PostgreSQL 데이터베이스가 쓰기를 받지 않았다. 처음 보인 증상은 사용자가 웹사이트를 불러오지 못하는 것이었다.

   쓰기 거부서비스 중단

   촉발

   플레이어 식별자 테이블의 인덱스가 알 수 없는 이유로 손상돼 vacuum 작업이 모두 오류로 끝났다. 로그로 보아 손상은 약 한 달 전인 2022-02-26 에 생긴 것으로 추정했고, 그동안 트랜잭션 ID 가 계속 쌓여 2022-03-27 에 wraparound 보호가 작동했다.

   원인

   데이터 손상

   구성 요소

   데이터베이스PostgreSQL vacuum데이터베이스 복제데이터베이스 백업과 스냅숏

   기여 요인

   모니터링 사각지대장애 중첩여유 용량 부재

   감지

   처음 들어온 것은 웹사이트를 불러오지 못한다는 사용자 신고였다. 팀은 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 을 돌릴 수 있었다.

   사례 보기
4. IL-0241 데이터베이스 shard 하나가 primary 를 뽑지 못해 Stripe API 요청 대부분이 두 차례 실패했다

   Stripe2019

   증상

   2019년 7월 10일 16:35 UTC 에 데이터베이스 클러스터의 primary 노드가 고장 났고, 1분 뒤 자동 모니터링이 선출 실패를 잡아 알림을 보냈다. Stripe API 요청 대부분이 실패하기 시작했다.

   오류율 상승장애 조치 실패쓰기 거부간헐적 타임아웃노드 CPU 고부하

   촉발

   16:35 UTC 에 데이터베이스 클러스터의 primary 노드가 고장 났다. 그 shard 에는 멈춘 노드가 여럿 있어 석 달 전 마이너 버전 업그레이드로 들어온 장애 조치 결함이 드러났다. 두 번째 장애는 선출 프로토콜을 이전 마이너 버전으로 되돌린 변경 때문에 일어났다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자

   기여 요인

   늦게 드러난 변경모니터링 사각지대과도한 영향 범위수동 조치 악화미검증 가정장애 중첩

   감지

   첫 장애는 자동 모니터링이 1분 안에 선출 실패를 잡았고, 16:36 UTC 에 팀이 알림을 받아 대응을 시작했다. 두 번째 장애는 21:14 UTC 에 클러스터의 shard 몇 개를 사용할 수 없다는 자동 알림으로 알았다.

   조치

   • 17:00 UTC 에 데이터베이스 클러스터의 모든 노드를 재시작해 새 primary 선출을 성공시켰다. 17:02 에 Stripe API 가 완전히 복구됐다.
   • 22:34 UTC 에 운영 설정을 고쳐 새로 배포하고 데이터베이스 클러스터의 노드를 재시작해 영향받은 shard 를 되살렸다.
   • 클러스터가 정상인지 확인한 뒤 사용자가 직접 보낸 API 요청에 필요한 서비스부터 트래픽을 다시 올렸다. 22:47 UTC 에 완전히 복구됐다.

   후속 조치

   • 노드가 복제 지연 지표를 보내지 않으면 알리는 모니터링을 더했다.
   • shard 가 데이터베이스 장애 조치 시스템의 이 선출 결함을 일으킬 수 있는 상태에 들어가면 알리는 모니터링을 더했다.
   • 이 결함을 고치는 수정을 데이터베이스 메인테이너와 함께 만든다.
   • 특정 클러스터로 가는 작업이 실패하면 끊어 내는 서킷 브레이커를 더 넣는다. 이번 사고의 클러스터도 대상이다.
   • shard 하나가 고장 나도 그 영향을 가두는 장애 격리 기법을 더 도입한다.
   • 실패한 요청을 거듭 재시도하는 클라이언트가 쓰는 자원을 제한한다.
   • 장애 대응 중 운영자가 설정을 빠르게 바꿀 때 더 안전하게 할 수 있도록 절차와 도구를 더 만든다.

   사례 보기
5. IL-0211 Mandrill 의 PostgreSQL 샤드 하나가 트랜잭션 ID 랩어라운드를 막으려고 쓰기를 멈춰 약 40시간 동안 메일 발송이 줄었다

   Mailchimp2019

   증상

   2019년 2월 4일 05:35 UTC 부터 Mandrill 이 대기열에 쌓인 메일의 80% 만 보냈다. 첫 예외는 일요일 밤에 로그에 남았지만 다른 시스템의 관계없는 예외에 묻혀 중앙 오류 보고에서 눈에 띄지 않았다.

   쓰기 거부처리량 저하부하 불균형노드 디스크 가득 참

   촉발

   Mandrill 의 키 해시 알고리즘이 shard4 에 쓰기를 더 많이 몰아 이 샤드의 autovacuum 이 밀렸거나 실패했고, 2019년 2월 4일 05:35 UTC 에 XID 가 상한에 닿아 데이터베이스가 안전 종료 모드로 들어갔다.

   원인

   용량 한계

   구성 요소

   데이터베이스PostgreSQL vacuum

   기여 요인

   초기 신호 무시한계 경보 부재잡음에 묻힌 신호재시도 폭주모니터링 사각지대

   감지

   첫 예외는 일요일 밤에 로그에 남았지만 다른 시스템의 관계없는 예외에 묻혀 중앙 오류 보고에서 늦게 발견됐다. 11:58 UTC 에 Mandrill 엔지니어가 조사를 시작했고, shard4 의 부하 급증을 쫓다가 12:56 UTC 에 랩어라운드를 찾았다.

   조치

   • 14:16 UTC 에 shard4 를 단일 사용자 모드로 띄우고 VACUUM 을 시작했다.
   • VACUUM 이 며칠 걸릴 것으로 보여 설정을 바꿔 속도를 높인 뒤 다시 시작했다.
   • VACUUM 이 도는 동안 데이터베이스 덤프와 복원을 시작했고, 속도를 높이려고 TB 단위인 Search 와 Url 테이블을 뺐다.
   • 실패한 작업과 로그로 디스크가 모자라자 Mandrill 앱 서버들의 스토리지 볼륨을 교체했다.
   • shard4 에 있던 작업 대기열 테이블을 살아 있는 다른 샤드로 옮겨 작업이 처리되게 하려 했다.
   • 잠긴 데이터베이스에서 테이블을 비우면 그 XID 가 풀린다는 것을 확인한 뒤 2월 5일 19:12 UTC 에 Search 와 Url 테이블을 비웠고, VACUUM 이 약 한 시간 뒤에 끝났다.
   • 21:36 UTC 에 밀린 메일 발송을 시작했다.
   • 22:40 UTC 에 XID 랩어라운드 알림을 새로 걸었다.

   교훈

   Mailchimp 는 대응을 늦춘 요인으로 다섯 가지를 들었다. Mandrill 시스템과 모니터링을 알고 접근할 수 있는 사람이 몇 명뿐이었다. Mandrill 의 로그 기록은 로컬에 쓸 수 있는 디스크에 기댔다. 잘못된 API 요청 로그와 실제 애플리케이션 오류를 구분하기 어려웠다. 작업 상태가 잘 보이지 않았다. 디스크 공간 문제로 원인 분석을 돕는 부분 배포가 위험했다. 잘된 점으로는 인시던트 지휘관을 중심으로 한 긴밀한 조율, 3시간 교대와 인수인계, 기록 담당과 기술 연락 담당 같은 역할 지정, 주기적인 요약과 결정 목록을 들었다. 화상 회의로 다시 모여 상황을 따져 본 것이 테이블을 비우는 해법으로 이어졌다. 대기 메일을 48시간 뒤에 지우는 기본 동작이 다가오자 더 과감한 방법을 검토하게 됐다. Mandrill 이 클라우드에서 돌아 스토리지를 빨리 늘릴 수 있었던 것은 운이었다. 지울 수 있는 데이터가 있었고 그 가운데 VACUUM 을 붙잡던 가장 큰 테이블이 있었던 것도 운이었다.

   사례 보기

원인별3