사례8건

8건 중 3~7번째

1. IL-0298 Wikimedia sessionstore 의 Cassandra 노드가 디스크가 가득 차 잇따라 죽고 쿼럼을 잃어 편집이 실패했다

   Wikimedia Foundation2025

   증상

   2025-03-31 02:58 UTC 에 두 데이터센터의 sessionstore 서비스가 500 오류를 내기 시작했고 편집이 실패했다. 03:03 에 세션 손실을 알리는 MediaWikiEditFailures 가 critical 로 울렸고, 03:04 에 SessionStoreErrorRateHigh 가 호출을 보냈다.

   오류율 상승서비스 중단노드 디스크 가득 참데이터 유실

   촉발

   세션 쓰기가 늘어 저장 장치를 채웠다. 쓰기가 늘어난 배경에는 세션을 높은 비율로 덮어쓰는 비정상적인 워크로드가 있었고, 이 워크로드는 SUL3 롤아웃과 시기가 강하게 겹쳤다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   한계 경보 부재미검증 가정

   감지

   03:04 UTC 에 SessionStoreErrorRateHigh 가 높은 5xx 비율로 울려 batphone 으로 호출이 나갔고, 그 1분 앞서 03:03 에 MediaWikiEditFailures 가 critical 로 울렸다. Cassandra 노드의 디스크 사용률이나 증가 속도에는 자동 알림이 없었다. 사용자 신고도 task T390512 로 들어왔다.

   조치

   • 03:36 UTC 에 스토리지를 지우고 Cassandra 를 재시작해 편집이 다시 들어오게 했다. 모든 세션이 사라졌고, 편집 비율은 03:40 무렵 평소 수준으로 돌아왔다.

   후속 조치

   • 디스크 사용률 추세가 비정상적으로 오르면 호출한다.
   • sessionstore 의 저장 용량을 늘린다.
   • sessionstore 에 네임스페이스 구분을 둔다.
   • sessionstore 워크로드의 관측성을 높인다.
   • sessionstore Cassandra 의 저장 공간이 빠르게 늘어난 원인을 찾는다.
   • Cassandra 오류율에 호출하지 않는 알림을 둘지 검토한다.
   • Cassandra 노드가 down 상태가 되면 호출이나 알림을 보낼지 검토한다.

   교훈

   노드 장애는 디스크 공간이 모자라서 났고, 그 전의 저장 증가 속도로 장애 시점을 내다볼 수 있었다. 노드가 죽기 한참 전에 높은 저장 사용률을 알렸다면 영향이 생기기 전에 막을 기회가 있었다. 5xx 비율로 호출한 것은 맞았다. 다만 Cassandra 노드가 치명적인 수만큼 죽었다는 알림이 따로 있었다면 대응하는 엔지니어에게 상황을 더 잘 알려 줬을 것이다. 지나치게 넉넉하다고 여긴 클러스터도 비정상적인 워크로드가 생기면 감당할 수 없이 빠르게 찰 수 있다. 디스크가 고갈됐을 때 스토리지를 비우는 완화책도 서비스를 흔든다. 그래도 편집이 계속 멈추는 것보다는 영향이 작다. sessionstore 쓰기 비율이 오른 데 워크로드 변화와 SUL3 마이그레이션 같은 요인이 어떻게 얽혔는지는 지금도 파악하기 어렵다.

   사례 보기
2. IL-0552 보관 데이터베이스의 저장 공간이 차서 CircleCI 워크플로 시작이 늦어지고 UI에서 워크플로가 잘 보이지 않았다

   CircleCI2025

   증상

   2025년 1월 21일 23시 UTC쯤, 보관 데이터를 담는 데이터베이스 인스턴스의 남은 저장 공간이 거의 없다는 자동 알림이 울렸다. 23시 26분부터 워크플로 대기열이 늘면서 워크플로와 잡의 시작과 취소가 느려지고 UI에서 워크플로를 보기 어려워졌다.

   지연 시간 증가간헐적 타임아웃로그 폭증노드 디스크 가득 참클라우드 API 호출 한도 소진

   촉발

   1월 16일에 보관 데이터베이스의 함수 하나를 고친 코드 변경이 의도치 않게 로그 메시지를 지나치게 많이 만들어 냈다.

   원인

   배포 결함

   구성 요소

   데이터베이스CI 시스템

   기여 요인

   늦게 드러난 변경과도한 영향 범위장애 중첩

   감지

   23시쯤 보관 데이터베이스의 남은 저장 공간이 거의 없다는 자동 알림이 울렸다. 같은 시각에 요청량 알림이 따로 울려 팀은 워크플로 지연을 곧바로 이 문제와 연결하지 못했다. 그 알림이 해결된 뒤에도 대기열이 늘자 다른 팀이 조사에 나섰다.

   조치

   • 23시 44분에 워크플로 대기열을 처리하는 이벤트 소비자를 증설했다.
   • 23시 55분에 문제가 난 보관 데이터베이스의 읽기 복제본을 독립된 주 인스턴스로 승격했다.

   후속 조치

   • 로그 메시지를 지나치게 많이 만들던 데이터베이스 함수를 고쳤다.
   • 워크플로 보관 호출의 재시도 정책에 최대 지속 시간을 두어 기본 타임아웃보다 일찍 실패하게 하고, 보관 서비스에 문제가 생겨도 워크플로 서비스가 받는 영향을 줄인다.
   • 장기적으로 워크플로 보관 과정을 이벤트 기반 방식으로 바꿔 두 서비스를 떼어 놓는다.
   • 데이터베이스에 예측 모니터링과 이상 탐지 모니터링을 더해, 이상한 움직임이 위험 수준에 닿기 전에 알림을 받는다.

   교훈

   보관 데이터베이스의 문제를 알리는 알림은 울렸지만, 데이터베이스가 예측보다 훨씬 빨리 차서 고객 영향이 나기 전에 대응할 시간이 거의 없었다. 워크플로 서비스가 보관 서비스를 동기로 호출하기 때문에 보관 쪽 문제가 워크플로 전체의 지연으로 번졌다.

   사례 보기
3. IL-0523 TANF-app 의 운영 배포가 PostgreSQL 마이그레이션 실패로 두 달 동안 막힘

   U.S. Department of Health and Human Services2023

   증상

   2023년 9월 7일 TANF-app 의 sprint 80 운영 배포가 실패했고, 9월 20일 sprint 82 배포는 디스크 공간 오류로 실패했다. 그 뒤 11월 9일까지 운영에 배포하지 못했다.

   배포 실패노드 디스크 가득 참

   촉발

   2023년 9월 7일 sprint 80 배포에서 이미 배포된 마이그레이션 search_indexes 0016 을 지웠고, 9월 20일 sprint 82 배포가 이 마이그레이션을 다시 만들어 큰 마이그레이션 0017 과 함께 운영 데이터베이스에서 돌렸다.

   원인

   배포 결함

   구성 요소

   데이터베이스스키마 마이그레이션

   기여 요인

   장애 중첩자동 테스트 공백스테이징 불일치런북 부재

   감지

   운영 배포가 실패하면서 드러났다. 9월 7일 sprint 80 배포와 9월 20일 sprint 82 배포가 차례로 실패했고, 9월 20일 배포에서 디스크 공간 오류가 났다.

   조치

   • 11월 8일 운영 데이터베이스 인스턴스 크기를 키우고 마이그레이션을 다시 돌렸다. 이번에는 빈 문자열을 정수로 바꾸는 오류로 마이그레이션이 실패했다.
   • 운영 데이터베이스의 백업을 만들었다.
   • `search_indexes` 테이블을 모두 비웠다. 팀은 여기서 운영 데이터를 잃는 것을 걱정하지 않았다.
   • sprint 82 릴리스를 다시 배포해 운영을 sprint 82 로 되살렸고, 배포가 다시 가능해졌다.
   • 빈 문자열 버그를 고쳤다.

   후속 조치

   • 데이터베이스 문제 해결 절차를 기술 문서에 더한다.
   • 위키 페이지와 운영 플레이북에 흔한 문제와 대응을 정리한다.
   • Failed-Deployment-Troubleshooting 문서에 데이터베이스 문제 절을 만들고 cf revisions 명령을 적는다.
   • 운영에 직접 한 변경을 모은 GitHub 레포를 만들어, 비슷한 문제가 다시 날 때 길잡이로 쓴다.
   • 운영 디버깅 세션의 터미널 출력을 저장한다.
   • 코드 리뷰에서 지킬 Django 마이그레이션 모범 사례를 만든다.
   • develop 에 머지된 마이그레이션은 고치지 않고, 그 시점부터 모델을 바꾸는 새 마이그레이션을 쓴다.
   • 자동 생성된 마이그레이션 이름을 알아보기 쉬운 이름으로 바꾼다. 이름만 보고 내용을 알 수 없으면 조사하기 어렵다.
   • 자동 생성 마이그레이션은 모델 변경 하나에 하나만 두고, PR 하나에서 모델을 여러 번 바꾸면 마이그레이션을 다시 생성한다.
   • 시험에 쓸 데이터베이스 시딩과 백업을 어떻게 할지 논의 자리를 만든다.

   교훈

   계획에 없던 일이라 많은 개발자가 손을 보태야 했고, 팀이 작아 분야마다 모든 사람이 필요했다. 팀은 문제와 대응을 일찍 문서로 남겨 더 적은 사람으로 대응할 수 있게 하자고 했다. 작업 중인 코드를 raft, qasp, sandbox 환경에 배포한 뒤 마이그레이션을 바꾸면 그 환경에서 충돌이 난다. 대용량 데이터와 공백 채움이 없는 레코드 같은 예외 상황은 시험하지 않았고, 개인정보를 지운 운영 데이터베이스 사본이 있으면 실제 데이터로 더 많이 시험할 수 있다.

   사례 보기
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-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 을 붙잡던 가장 큰 테이블이 있었던 것도 운이었다.

   사례 보기

원인별2