사례5건

5건 중 1~5번째

1. IL-0305 Intercom 의 PlanetScale 샤드 하나에서 복제본이 CPU 100% 로 주 데이터베이스를 따라가지 못해 받은편지함에 최대 2.2시간 전의 데이터가 보였다

   Intercom2026

   증상

   2026년 1월 27일 17:25 UTC 에 메시지 백로그가 지나치게 쌓였다는 워커 알람이 울려 장애가 자동으로 선언되었다. 일부 고객의 받은편지함에서 지연이 들쭉날쭉했고 오래된 데이터가 보였다.

   복제 지연데이터베이스 과부하지연 시간 증가

   촉발

   내부 앱 삭제 작업과 ETL 파이프라인이 한 샤드에 겹쳤다. 앱 삭제 작업은 속도 제한 없이 평소보다 많은 삭제 단계를 동시에 돌렸고, ETL 파이프라인은 분석과 보고에 쓸 데이터를 같은 샤드에서 읽고 있었다.

   원인

   용량 한계

   구성 요소

   데이터베이스데이터베이스 복제

   기여 요인

   여유 용량 부재

   감지

   17:25 UTC 에 워커에서 메시지 백로그가 지나치게 쌓였다는 알람이 울렸고, 이 알람으로 장애가 자동으로 선언되었다.

   조치

   • 18:25 UTC 에 영향받은 샤드의 부하를 줄이려고 ETL 처리를 껐다.
   • 21:33 UTC 에 앱 삭제 워커를 0 으로 줄였다.
   • 모니터링에서 지표가 안정된 것을 확인한 뒤 ETL 을 조심스럽게 다시 켰다.

   후속 조치

   • 예상하지 못한 부하 급증에 대비할 여유를 두려고 샤드 용량을 미리 늘렸다.
   • 앱 삭제 작업에 속도 제한과 자원 통제를 넣어 데이터베이스 인프라를 짓누르지 못하게 했다. 이제 워커는 용량 한도를 지키고, 데이터베이스 부하가 높으면 처리 속도를 늦춘다.
   • ETL 과 유지보수 작업 같은 백그라운드 작업이 운영 데이터베이스 용량과 어떻게 얽히는지 검토한다. 이런 작업이 고객이 쓰는 기능과 핵심 자원을 다투지 못하게 하는 것이 목표다.
   • 복제 지연을 더 일찍 잡고 특정 작업과 연결해 볼 수 있도록 알림을 보강한다.
   • 영향 범위가 좁은 장애에서도 영향받은 고객에게 먼저 연락하도록 절차를 고친다. 상태 페이지 전체에 올릴 일이 아니어도 영향받은 고객은 제때 소식을 받게 한다.

   교훈

   Intercom 은 이 장애가 샤딩한 데이터베이스 구조의 가치를 보여 줬다고 밝혔다. 데이터를 서로 독립된 여러 샤드에 나눠 두었기 때문에, 플랫폼 전체의 성능 저하가 될 수 있었던 일이 고객 1% 미만에 그쳤다.

   사례 보기
2. IL-0287 Atlas 와 Cloud Manager 의 모니터링을 받치는 내부 데이터베이스 클러스터의 샤드 하나가 과부하되어 지표 수집과 클러스터 작업이 늦어졌다

   MongoDB2025

   증상

   MongoDB Atlas 와 Cloud Manager 에서 지표 수집 파이프라인이 늦어졌고, Atlas 대시보드의 지표가 늦거나 빠졌다. Host Down 알림이 울리지 않았고, 프로비저닝과 크기 조정 같은 Atlas 클러스터 관리 작업이 늦어졌다.

   모니터링 중단데이터베이스 과부하부하 불균형

   촉발

   새 내부 소프트웨어 버전을 롤아웃하는 동안 자원 사용량이 일시적으로 치솟아, 이미 부하가 몰려 있던 샤드의 부하가 예상한 한도를 넘었다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   비효율적인 쿼리여유 용량 부재

   조치

   • 원인을 찾아 바로잡는 조치를 하고 그 효과를 지켜봤다. 그동안 Host Down 알림, 지표, 일부 Atlas 클러스터 작업은 계속 늦거나 빠질 수 있었다.
   • 수정을 적용하고 결과를 지켜봤으며, 이후 장애가 해결됐다.

   후속 조치

   • 부하가 몰리는 컬렉션을 샤딩해 트래픽을 여러 노드에 고르게 나누고 샤드 하나에 몰리는 부하를 던다.
   • 비효율적인 쿼리를 최적화해 자원 사용을 개선하고 평소 작업의 지연을 줄인다.
   • 늘어난 트래픽을 감당하도록 인프라 용량을 더 확보했다.
   • 앞으로의 부하 급증을 미리 내다보도록 용량 계획 절차를 다듬는다.
   • 롤아웃 중 예상할 수 있는 자원 수요 증가를 감안하도록 새 소프트웨어 버전 배포 절차를 다시 설계한다.
   • 엔지니어링 팀이 샤딩 전략과 쿼리 최적화의 성능을 계속 지켜보며 핫스팟이 제대로 풀렸는지 확인한다.
   • 높은 부하 상태를 감지하는 피드백 장치를 넓혀 이상을 더 빨리 찾고 대응한다.

   사례 보기
3. IL-0270 인증용 ScyllaDB 클러스터가 과부하로 조회를 처리하지 못해 Discord 에서 약 50분 동안 접속과 로그인이 되지 않았다

   Discord2023

   증상

   2023년 11월 6일 10:52 AM PST 에 업그레이드 스크립트가 scylla-authentication 클러스터의 존 c 연결을 모두 비우자, 2xx 응답 비율로 재는 Discord 의 가용성이 곧바로 약 25% 로 떨어졌다. 사용자는 접속, 로그인, 메시지 읽기와 보내기를 거의 할 수 없었다. 첫 알림은 4분쯤 뒤인 10:56 AM 에 울렸다.

   서비스 중단데이터베이스 과부하지연 시간 증가

   촉발

   2023년 11월 6일 운영체제 업그레이드 절차가 scylla-authentication 클러스터의 존 b 를 마친 뒤, 10:52 AM 에 스크립트가 존 c 의 연결을 모두 비우고 업그레이드를 시작했다. 존 b 에는 디스크 성능이 떨어진 노드가 있었다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   여유 용량 부재장애 중첩데워진 캐시에 기댄 구조미검증 가정초기 신호 무시재시도 폭주

   감지

   첫 알림이 장애 시작 4분쯤 뒤인 10:56 AM 에 울렸지만, 팀은 그 전에 이미 사고 대응 통화를 열고 조사하고 있었다. 하위 서비스별 소요 시간 그래프가 인증 서비스를 가리켰고, 잠시 뒤 인증 알림이 울렸다.

   조치

   • 11:05 AM 에 인증 클러스터의 부하를 덜려고 입력 중 표시 이벤트와 메시지 읽음 표시를 껐다.
   • RAID 재구축이 끝나기를 기다려 11:41 AM 에 존 c 의 두 노드를 다시 올렸다.
   • 과부하였던 존 b 의 두 노드를 한 대씩 재시작했다.

   후속 조치

   • 사고 직후 scylla-authentication 클러스터를 두 배로 늘려 용량을 더했다.
   • scylla-authentication-b-2 를 성능이 떨어지지 않은 새 디스크로 다시 만들었다.
   • 전체 지연에는 드러나지 않을 만큼 약하지만 서비스 신뢰성에 위험이 될 수 있는 디스크 성능 저하를 찾아내는 방법을 만든다.
   • Scylla 클러스터의 컨트롤 플레인을 더 자동화하고 업그레이드 작업을 그곳으로 옮겨, 캐시 적중률 같은 클러스터 분석을 업그레이드 절차에 넣는다.
   • 복제 계수를 늘리거나 다른 리전에 핫 스탠바이 클러스터를 두는 방안을 검토해, 이 작고 중요한 클러스터의 이중화를 늘린다.

   교훈

   클러스터는 존 하나를 잃어도 견디게 설계했지만, 존 하나가 내려간 상태에서 다른 존의 노드 하나 성능이 떨어진 것만으로 이 정도 장애가 났다는 것은 클러스터의 용량이 부족했다는 뜻이다. 노드 재시작 전에 캐시 적중률이 일정 수준이 돼야 하는 것도 용량 부족의 신호다. 업그레이드 전 존 중단 시험은 계속 진행해도 안전하다는 잘못된 확신을 줬다. 이 작고 중요한 클러스터는 훨씬 큰 다른 클러스터들과 다르게 운영해야 한다.

   사례 보기
4. 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 를 만들고 있다고 밝혔다.

   사례 보기
5. IL-0383 PagerDuty 알림 파이프라인이 이틀 연속 장애를 겪어 이벤트를 받지 못하고 알림이 늦거나 가지 않았다

   PagerDuty2014sev1

   증상

   6월 3일 PagerDuty 알림 파이프라인의 성능이 떨어져 일부 알림이 늦게 갔다. 통합 API 로 보낸 이벤트의 약 3% 를 받지 못했고, 1% 에 못 미치는 일부 알림이 늦게 전달됐다.

   데이터베이스 과부하오류율 상승지연 시간 증가

   촉발

   6월 3일 Cassandra 클러스터의 노드 하나에서 repair 작업이 평소대로 시작됐고, 그때 걸린 높은 부하와 겹쳤다. 6월 4일에는 팀이 전날 미룬 repair 작업을 손으로 다시 시작했다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   여유 용량 부재과도한 영향 범위수동 조치 악화초기 신호 무시

   조치

   • 6월 3일 Cassandra 클러스터의 부하를 줄였다.
   • 6월 3일 부하를 줄이면서 repair 작업을 멈췄다.
   • 클러스터를 안정시키려고 일부 노드 사이의 통신을 끊었고, 그 뒤 정상으로 돌아왔다.
   • 6월 4일 알림 파이프라인에서 처리 중이던 데이터를 모두 지웠고, Cassandra 가 바로 회복했다.
   • 새로 비운 상태와 데이터를 맞추도록 일부 하위 시스템을 수동으로 손봤다.

   후속 조치

   • 기존 Cassandra 노드를 더 크고 빠른 서버로 수직 확장한다. 6월 4일 이후 이 작업은 이미 끝냈다.
   • Cassandra 클러스터를 여러 개로 나누고 작업량을 그 클러스터들에 나눠 싣는다. 부하와 사용 방식에 따라 클러스터를 나누는 작업이 진행 중이다.
   • 시스템 부하 기준을 정해 그 기준에 닿으면 기존 Cassandra 클러스터를 미리 수평 확장한다.
   • 기존 클러스터와 새 클러스터를 더 최근 버전의 Cassandra 로 업그레이드한다.
   • 높은 부하에서도 Cassandra 를 통제할 수 있도록 로드 셰딩 기법을 더 넣는다.
   • Cassandra 전문 인력을 사내에 더 둔다.

   교훈

   PagerDuty 는 Cassandra 클러스터의 규모가 모자랐고, 부하와 사용 방식이 서로 다른 너무 많은 서비스가 한 클러스터를 나눠 쓰고 있었다고 밝혔다. 비슷한 문제를 보고 개선을 계획했지만 효율을 기준으로 버전 업그레이드를 먼저 하려 했고, 확장을 먼저 했어야 했다고 적었다.

   사례 보기

원인별1