사례2건

2건 중 1~2번째

1. 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 도 장애 중에 쓰지 않았다.

   사례 보기
2. IL-0066 ConfigMap 만 바꾸고 디플로이먼트는 그대로 둔 탓에 잘못된 설정이 몇 주 뒤 노드 교체 때 모든 브리지 파드에 퍼져 Pusher 의 모든 트래픽이 끊겼다

   Pusher2019

   증상

   Pusher 의 모든 제품으로 가는 트래픽이 멈췄다. 고객 트래픽은 ELB 와 nginx 를 지나, 브리지라고 부르는 자체 개발 7계층 프록시를 거쳐 각 제품 서비스로 간다. 그래서 브리지가 망가지면 플랫폼 전체가 내려간다. 발표자는 이때 요청이 모두 500 오류였던 것으로 기억했다.

   서비스 중단오류율 상승

   촉발

   동료가 ConfigMap 의 설정을 바꿔 운영 클러스터에 배포했지만, 그 설정에 의존하는 디플로이먼트는 갱신하지 않았다. 3주에서 4주 뒤 클러스터 업그레이드로 노드를 교체하면서 브리지 파드가 새로 떴다.

   원인

   설정 변경

   구성 요소

   컨피그맵과 시크릿

   기여 요인

   늦게 드러난 변경미검증 가정

   후속 조치

   • 오픈소스 컨트롤러 Wave 를 만들었다. Wave 는 디플로이먼트, 스테이트풀셋, 데몬셋이 참조하는 ConfigMap 과 Secret 의 해시를 파드 템플릿에 넣어, 설정이 바뀌면 곧바로 새 파드가 롤아웃되게 한다.

   교훈

   ConfigMap 을 바꿔도 디플로이먼트는 새 파드를 만들지 않는다. 설정을 실행 중에 다시 읽지 못하는 애플리케이션은 파드가 다시 뜰 때에야 새 설정을 읽으므로, 잘못된 설정이 몇 주 뒤에 드러날 수 있다. 설정을 바꾸면 곧바로 새 파드가 뜨게 해야 설정이 맞는지 그 자리에서 확인할 수 있다.

   사례 보기

원인별2