사례11건

11건 중 4~8번째

1. IL-0315 약 10억 행 테이블에 인덱스를 만드는 스키마 변경이 테이블 전체를 잠가 Railway 의 백엔드 API 가 멈췄다

   Railway2025

   증상

   2025-10-28 18:36 UTC 에 내부 모니터링 알림이 울려 엔지니어링 팀이 호출됐다. 대시보드가 열리지 않았고, railway up 처럼 API 를 쓰는 CLI 작업이 실패했으며, Public API 작업이 모두 멈췄다.

   서비스 중단잠금 경합과 교착데이터베이스 과부하

   촉발

   일상적인 Postgres 데이터베이스 변경으로 약 10억 행 테이블에 새 컬럼과 인덱스가 더해졌다. 인덱스 생성에 CONCURRENTLY 옵션을 쓰지 않아 테이블 전체에 배타적 잠금이 걸렸다.

   원인

   배포 결함

   구성 요소

   데이터베이스데이터베이스 프록시와 커넥션 풀러

   기여 요인

   설정 테스트 부재디버그 접근 제한

   감지

   변경이 운영에 반영되고 2분 뒤인 18:36 UTC 에 내부 모니터링 알림이 울려 엔지니어링 팀이 호출됐다.

   조치

   • 인덱스를 만드는 마이그레이션이 약 30분 만에 끝나 테이블 잠금이 스스로 풀렸고, 줄을 선 작업이 처리되며 커넥션 풀이 정상으로 돌아왔다.

   후속 조치

   • CI 에서 모든 인덱스 생성에 CONCURRENTLY 사용을 강제하고, 지키지 않은 풀 리퀘스트는 머지 전에 막는다.
   • PgBouncer 커넥션 풀 한도를 조정해 뒤에 있는 Postgres 인스턴스의 용량을 넘지 않게 한다.
   • 데이터베이스 사용자별 커넥션 한도를 설정해 장애 중에도 관리용 접속을 보장하고, 어떤 상황에서도 유지 보수 작업을 할 수 있게 한다.

   사례 보기
2. IL-0327 워크플로 데이터베이스를 blue/green 으로 업그레이드한 뒤 워크플로 시작과 취소가 지연되고 실패했다

   CircleCI2025

   증상

   blue/green 전환은 22:08 UTC 에 끝났다. 22:17 에 워크플로 서비스의 지연이 커졌고, 10분 재시도를 다 쓴 작업이 버려지며 오류가 났다. 고객은 워크플로와 작업을 시작하거나 취소할 때 지연과 실패를 겪었고 UI 에서 워크플로를 보기 어려웠다.

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

   촉발

   22:00 UTC 무렵 워크플로를 맡는 서비스의 데이터베이스를 blue/green 배포로 업그레이드했고, 22:08 에 전환이 끝났다.

   원인

   배포 결함

   구성 요소

   데이터베이스쿼리 플래너와 테이블 통계

   기여 요인

   –

   감지

   22:17 UTC 에 워크플로 서비스의 지연이 커지고 10분 재시도를 다 쓴 작업이 버려지며 오류가 나는 것을 확인했다.

   조치

   • 22:30 UTC 에 모든 워크플로 파드가 올바른 데이터베이스에 연결하도록 파드를 재시작했다.
   • 22:41 에 새 데이터베이스의 모든 쿼리가 디스크에서 읽히는 것을 보고 곧바로 데이터베이스 크기를 키우고 업무에 꼭 필요하지 않은 데이터베이스 작업을 껐다.
   • 23:00 에 통계 테이블을 다시 만드는 동안 데이터베이스가 회복할 여유를 주려고 워크플로 서비스를 파드 하나로 줄였다.
   • 23:19 에 옛 데이터베이스의 쓰기를 다시 켜고 옛 데이터베이스를 다시 주 데이터베이스로 되돌리기로 했다. 이 작업은 23:29 에 끝났다.

   후속 조치

   • blue/green 데이터베이스 배포 절차에서 메이저 버전이 바뀔 때마다 analyze 절차를 돌리도록 바꿨다.
   • 부하가 걸린 데이터베이스에서 analyze 명령을 돌려도 성능이 더 나빠지지 않는다는 것을 시험으로 확인했다. 앞으로 복구할 때 참고하도록 이 결과를 적어 둔다.
   • 다음 마이그레이션 전에 자동 테스트와 수동 확인 지점을 절차 곳곳에 더해 blue/green 전환 전에 문제를 찾아 해결한다.

   사례 보기
3. IL-0324 External Storage 데이터베이스 클러스터에 과부하가 걸려 mw-api-int, mw-parsoid, mw-jobrunner 의 지연과 데이터베이스 오류가 늘었다

   Wikimedia Foundation2025

   증상

   2025-03-12 10:58 UTC 부터 백엔드 응답 시간이 높다는 알림이 들어왔다. 3월 12일과 13일 이틀 동안 mw-api-int, mw-parsoid, mw-jobrunner 에서 지연이 커지고 데이터베이스 오류가 늘었다. External Storage 클러스터의 부하와 연결 수도 크게 늘었다.

   데이터베이스 과부하지연 시간 증가오류율 상승로그 폭증모니터링 중단

   촉발

   mw-api-int, mw-parsoid, mw-jobrunner 를 PHP 8.1 로 옮기는 예정된 Scap 배포가 장애를 일으켰다. 3월 12일 10:44 UTC 에 1126607[puppet] 과 1126650 [deployment-charts] 를, 3월 13일 11:15 UTC 에 1127476[puppet] 과 1127478[deployment-charts] 를 배포했다.

   원인

   배포 결함

   구성 요소

   데이터베이스인메모리 캐시컨피그맵과 시크릿HelmCI 시스템

   기여 요인

   미검증 가정데워진 캐시에 기댄 구조잡음에 묻힌 신호

   감지

   3월 12일 10:58 UTC 에 백엔드 응답 시간이 높다는 알림이 들어오기 시작했다. 처음 세운 가설은 특정 네트워크나 클라이언트의 많은 트래픽, 잘못 실행된 예약 작업, 자원을 많이 먹는 changeprop-jobqueue 작업이었다. 원인을 가리켰을 MediaWikiMemcachedHighErrorRate 알림은 logstash-prometheus 파이프라인이 밀려 빠지거나 곧바로 회복됐다. 장애 중에는 알림 78개가 울리고 있어서, 그 알림이 울렸더라도 부수 증상으로 보고 넘겼을 가능성이 컸다.

   조치

   • 3월 12일 13:19 UTC 에 cirrus-streaming-updater 의 SUP 병렬도를 낮추는 패치 1126988[deployment-charts] 를 배포했다.
   • 13:33 에 1127000[deployment-charts] 로 changeprop-jobqueue 의 categoryMembershipChange 작업 동시성을 낮췄다.
   • 13:44 에 1126607[puppet] 과 1126650 [deployment-charts] 를 되돌리고 Scap 을 다시 돌렸다.
   • 3월 13일 11:34 UTC 에 changeprop-jobqueue 를 롤링 재시작했다.
   • 11:43 에 mw-api-int 를 롤링 재시작했다.
   • 11:44 에 1127500[deployment-charts] 로 changeprop-jobqueue 의 categorymembership 작업을 껐다.
   • 11:46 에 1127476[puppet] 과 1127478[deployment-charts] 를 되돌렸다.
   • 11:58 에 되돌린 내용을 반영하려고 mw-api-int 를 다시 배포했다.
   • 12:07 에 mw-api-int 의 레플리카 수를 늘렸다.
   • 12:28 에 되돌린 내용을 반영하려고 mw-jobrunner 를 다시 배포했다.
   • 14:06 에 되돌린 내용을 반영하려고 mw-parsoid 를 다시 배포했다.

   후속 조치

   • 장애 때 channel:Memcached 로 보내는 메시지 양을 줄인다.
   • Scap 에 helm 롤백 기능을 넣는다.
   • -Dbuild_mw_container_image:False 로 실행할 때도 Scap 이 helmfile-defaults 를 갱신해야 하는지 검토한다.
   • MediaWiki 이미지에서 envvars.inc 를 뺄지 검토한다.
   • 서로 관련된 구성 요소를 한꺼번에 보여 주고 따라갈 링크를 담은 "Why" 대시보드를 만들지 검토한다.
   • 장애 대응 조율을 개선한다. 누가 무엇을 맡았는지, 누가 대응에 들어오고 나갔는지 장애 조율자가 알 수 있어야 한다. 또 맥락 없는 의견과 대응과 관계없는 논의로 채널이 시끄러워지지 않아야 한다.
   • 장애 중에 MediaWiki 개발자와 연락해 개발자의 관점을 바로 들을 수 있게 한다.

   교훈

   Wikimedia 는 기술적 원인보다, 3월 12일 장애 때부터 MediaWiki 배포 세 곳이 Memcached 클러스터에 닿지 못하고 있다는 것을 알아채지 못한 이유가 더 중요하다고 봤다. 알림에 연결된 대시보드는 무엇이 일어나는지만 보여 줬다. Wikimedia 는 서로 의존하거나 영향을 주는 구성 요소를 함께 보여 주는 대시보드가 있었다면 달랐을 것이라고 적었다. 예를 들어 SQLBlobStore 키는 External Storage 와 바로 이어져 있다. 원인을 가리킬 알림은 곧바로 회복됐다. 그 알림이 울렸더라도 알림 78개 사이에서는 부수 증상으로 봤을 수 있었다. 응답자가 많았지만 누가 무엇을 하는지, 누가 대응에 들어오고 나갔는지 분명하지 않아 장애 조율자가 조율하기 어려웠다. 외부 사용자 영향을 제대로 가늠하지 못해 실제보다 심각하게 여겼다. trace.wikimedia.org 도 장애 중에 쓰지 않았다.

   사례 보기
4. IL-0554 데이터베이스 마이그레이션의 긴 쿼리가 Postgres 커넥션을 고갈시켜 Sentry US 의 사이트와 수집이 22분 동안 멈췄다

   Sentry2024

   증상

   2024년 10월 10일 오후 3시 42분부터 4시 4분 PT까지 Sentry US 의 사이트와 이벤트 수집을 모두 쓸 수 없었다. 상태 페이지는 Postgres 데이터베이스 문제로 사이트를 쓸 수 없다고 알렸다.

   서비스 중단데이터베이스 과부하

   촉발

   RunSQL 명령으로 실행한 데이터베이스 마이그레이션에 잠금 타임아웃과 구문 타임아웃이 걸려 있지 않아 쿼리가 오래 돌았다.

   원인

   배포 결함

   구성 요소

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

   기여 요인

   설정 테스트 부재런북 부재

   조치

   • 수정을 적용했고, 대시보드와 이벤트 수집이 회복하기 시작했다.

   후속 조치

   • 마이그레이션 프레임워크 안의 더 견고한 방법으로 바꿔 RunSQL 명령을 아예 없앤다.
   • 데이터베이스 프레임워크를 최신 버전으로 올린다. 새 버전은 전에 RunSQL 로 하던 작업 일부를 직접 처리한다.
   • 마이그레이션 중에 잠금이나 타임아웃 문제가 생겼을 때 복구를 안내하는 런북을 만들었다.
   • 더 빨리 대응하고 앞으로의 중단 시간을 줄이도록 알림과 관측 도구를 보강했다.

   사례 보기
5. IL-0571 STORES 予約의 스마트리스트 검색 쿼리가 특정 테넌트에서 20분 넘게 DB 프로세스를 붙잡아 504 에러가 급증했다

   STORES2024

   증상

   스마트리스트 프리셋 데이터를 고쳐 쓰는 배치를 20분쯤 돌린 시점에 504 Gateway Timeout 에러가 갑자기 늘었다는 알림이 왔다. 작업은 03:00 UTC 조금 넘어 시작했다.

   오류율 상승데이터베이스 과부하

   촉발

   검색 사양 변경에 맞춰 스마트리스트 프리셋 데이터인 初回予約の顧客 와 要フォロー顧客 의 검색 조건을 새 조건으로 고쳐 쓰는 배치를 실행했다. 프리셋 이름은 그대로였지만 검색 파라미터가 달라져 새 검색 쿼리를 타게 됐다.

   원인

   배포 결함

   구성 요소

   데이터베이스

   기여 요인

   비효율적인 쿼리늦게 드러난 변경스테이징 불일치모니터링 사각지대미검증 가정

   감지

   고쳐 쓰기 배치를 시작하고 20분쯤 지나 504 에러가 늘었다는 알림으로 알았다. 작업 중 보던 라이터 인스턴스 지표에는 변화가 없었다.

   후속 조치

   • DB 설계부터 다시 봤고, 이번 글의 인라인 뷰 검색 로직은 더 이상 쓰지 않는다.
   • 이 API의 EXPLAIN을 확인해 훑는 행 수가 예상보다 많지 않은지 검사하는 테스트를 더했다.
   • 해당 로직의 실제 실행 시간을 재기 쉬운 환경을 갖췄다.

   교훈

   실행 계획을 보고 실제 데이터로 동작을 확인해도, 멀티테넌트 환경에서는 테넌트 인덱스만으로 크게 좁혀지는 것처럼 보여 실제로 훑는 양을 놓칠 수 있다. 검증은 양극단만이 아니라 일부만 느린 경우까지 봐야 한다. 작업 중 모니터링하는 대상이 실제 부하가 걸리는 곳인지도 확인해야 한다. 일정을 너무 서두르면 이런 부분이 빠지기 쉽고, 결국 일정이 늦어지고 사용자에게 피해를 준다.

   사례 보기

원인별1