그래프
사례5건
5건 중 1~5번째
- 증상
2026-02-23 17:30 UTC 에 ml-serve-codfw 업그레이드가 끝난 직후, 일부 머신러닝 서비스의 지표에 5XX 응답 코드가 나타나기 시작했고 알림이 울렸다. 실행 중인 모델 서버의 절반이 영향을 받았고, 이 서비스들에는 약 24시간 동안 접근할 수 없었다.
- 촉발
머신러닝 운영 쿠버네티스 클러스터 두 곳을 1.31 로 올리면서 Istio 를 1.15 에서 1.24 로 올렸다. 새 Istio 는 VirtualService 의 host 값을 더 엄격하게 검증해, host 가 겹치는 VirtualService 가 둘 이상이면 하나만 받고 나머지를 버렸다.
- 원인
- 구성 요소
- 기여 요인
- 감지
영향받은 모델 서버를 쓰는 사람들이 talk-to-machine-learning Slack 채널에 처음 알렸다. codfw 업그레이드 직후부터 Machine Learning 팀의 IRC 채널에 알림이 올라와 있었지만 팀은 알아채지 못했다.
- 조치
- Istio 핫픽스를 배포해 HTTP 500 대부분을 없앴고, 2026-02-24 16:00 UTC 에 장애가 끝났다.
- 근본 수정을 ml-staging-codfw 에서 확인한 뒤 2026-03-03 13:17 UTC 에 영향받은 모든 클러스터에 배포했다.
- 후속 조치
- 알림을 관련 Slack 채널로 보내거나, IRC 나 alerts.wikimedia.org 를 지켜보는 방안을 검토한다.
- SLO 를 더 두는 방안을 검토한다. Istio 지표가 바뀌었으므로 revertrisk-la 의 가용성 SLO 와 지연 SLO 같은 기존 SLO 도 고친다.
- 교훈
사용자가 처음 알린 시점부터 보면 비교적 짧은 시간에 문제를 풀었다. 반면 이 문제는 스테이징 클러스터에서 먼저 잡을 수 있었다. 팀은 업그레이드를 알리고 테스트를 요청했다. 클러스터를 올릴 때마다 팀 안에서 바로 테스트했다면 문제를 더 일찍 찾을 수 있었다. httpbb 테스트가 있다는 것을 관련자 모두가 알지는 못했다. codfw 업그레이드 직후 울린 알림을 Machine Learning 팀의 누구도 보지 못했다. 운도 따랐다. 깨진 기능을 되살릴 Istio 핫픽스를 찾는 데 도움을 줄 기술 담당자가 마침 온라인에 있었다.
- 증상
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] 를 배포했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
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 도 장애 중에 쓰지 않았다.
- 증상
2024-10-09 05:01:36 UTC 에 codfw 의 rest-gateway 에서 page-analytics_cluster 의 5xx 오류가 늘었다는 GatewayBackendErrorsHigh 알림이 울렸다. 05:03:32 UTC 에는 KubernetesCalicoDown 알림이 16건 묶여 울렸고, 알림 문구는 kubernetes2037.codfw.wmnet is not running calico-node Pod 였다. 05:04:15 UTC 에는 MediaWiki memcached 오류율이 전 세계에서 올랐다는 MediaWikiMemcachedHighErrorRate 알림이 울렸다.
- 촉발
한 운영자가 새 mwscript-k8s 도구로 TimedMediaHandler 의 requeueTranscodes.php 를 돌려 동영상 트랜스코딩을 일괄 정비했다. mwscript-k8s 는 스크립트를 실행할 때마다 helm 릴리스를 통째로 배포하므로, 이 작업이 몇 시간 동안 리소스를 계속 만들었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
자동 모니터링이 알아채고 당직 SRE 가 대응했다. 05:01:36 UTC 에 GatewayBackendErrorsHigh, 05:03:32 UTC 에 KubernetesCalicoDown 16건, 05:04:15 UTC 에 MediaWikiMemcachedHighErrorRate 알림이 울렸다.
- 조치
- calico 와 typha 의 자원 한도를 올리는 변경을 CI 를 기다리지 않고 반영하고, helmfile -e codfw --selector name=calico apply -i --context 5 로 적용했다. 적용 중 새 calico 파드가 정상으로 떴고, 06:10 UTC 에 Calico 가 회복되었다.
- 후속 조치
- mwscript-k8s 가 리소스를 너무 많이 만드는 문제를 해결한다.
- 교훈
완전한 장애 직전까지 갔다. 자동 모니터링이 장애를 잡았다. 새로 들어온 여러 사람이 함께 본 덕에 근본 원인을 찾았다. 미주 SRE 에서 EMEA SRE 로 장애 대응을 문제없이 넘겼다. 반면 최종 사용자에게 영향이 갔고, 비상시에 eqiad 로 전환할 수 있는지 확신하지 못했다. 운도 따랐다. 장애는 미주 SRE 근무가 끝나고 EMEA SRE 근무가 시작되기 바로 전에 발견되었다. 이 시간대는 오래전부터 대응 인력이 비는 때로 알려져 있었다. 트랜스코딩 작업을 미국의 금요일 저녁에 넣지 않은 것도 다행이었다.
- 증상
MediaWiki 설정 변경을 배포한 11:41 부터 쿠버네티스로 가는 MediaWiki 트래픽이 오류를 받기 시작했다. 11:47 에 mw-api-ext 와 mw-api-int 서비스의 프로브 실패 알림이 온콜 담당자를 호출했다. 전체 트래픽의 1%, 초당 120건의 요청이 약 30분 동안 오류를 받았다.
- 촉발
09:37 에 쿠버네티스 전역 기본값을 바꾸는 변경이 머지됐다. 이 변경으로 이 기본값을 따르는 차트가 cert-manager 인증서를 쓰게 됐다. 11:41 에 MediaWiki 설정 변경을 배포하면서 쿠버네티스 위 MediaWiki 배포가 이 기본값을 받아 TLS 종료에 엉뚱한 인증서를 쓰게 됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
11:47 에 "(ProbeDown) firing: (6) Service mw-api-ext:4447 has failed probes (http_mw-api-ext_ip4)" 와 "(ProbeDown) firing: Service mw-api-int:4446 has failed probes (http_mw-api-int_ip4)" 알림이 온콜 담당자를 호출해 알아챘다. 두 사람이 호출을 받았다.
- 조치
- 11:58 에 원인을 찾고 패치 https://gerrit.wikimedia.org/r/947331 을 준비했다.
- 12:08 에 MediaWiki 디플로이먼트를 모두 다시 배포하기 시작했고, 12:16 에 장애가 끝났다.
- 후속 조치
- 배포 절차와 테스트를 더 강화해야 하는지 검토한다. 다음 배포에 뜻밖의 변경이 함께 실리는 문제와 쿠버네티스 카나리 배포도 검토 대상이다.
- 배포 중에 일부 지표를 볼 수 없거나 비정상이 되는 문제를 지표 쪽에서 고칠지, 배포의 영향을 줄일지 검토한다.
- 교훈
문제를 일으킨 변경을 낸 사람이 대응자 가운데 있어 원인을 빨리 찾았다. 근본 원인은 CI 에서 보였어야 했다. 그러나 변경은 hieradata 저장소에서 했고 원인은 deployment-charts 저장소 쪽에 있어, 변경한 저장소의 CI 에서는 보이지 않았다. 당시에는 트래픽의 1% 만 쿠버네티스로 가서 피해가 작았다. 오류의 양이 적어 문제를 쿠버네티스 쪽으로 좁히는 데 시간이 걸렸다. 보고서는 쿠버네티스를 서비스 풀에서 더 일찍 뺐어야 했는지를 묻는다.
- 증상
18:45 에 toolschecker 의 icinga 검사 "All k8s nodes healthy" 가 알림을 울렸다. 쿠버네티스 API 서버가 응답하지 않아 모니터링에서도 사용자 쪽에서도 클러스터가 완전히 내려간 것처럼 보였다. 사용자는 webservice 명령으로 도구를 띄울 수 없었고 kubectl 로 상태를 보거나 도구를 다룰 수도 없었다.
- 촉발
18:30 에 maintain-kubeusers 프로세스가 쿠버네티스 API 서버를 재시작했다. 재시작한 API 서버는 etcd 에 다시 연결해야 했는데, 전날 밤 퍼핏 변경으로 CA 인증서가 etcd 서버의 것과 어긋나 있어 연결하지 못했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
처음 울린 것은 http://checker.tools.wmflabs.org/k8s/nodes/ready 를 검사하는 icinga 알림이었다. 18:45 에 toolschecker 의 "All k8s nodes healthy" 검사가 울렸다.
- 조치
- 19:10 과 20:30 에 쿠버네티스 마스터를, 20:18 에 etcd 클러스터를 재부팅했지만 도움이 되지 않았다.
- 21:06 에 백업을 떠 둔 뒤 잦은 raft 선출을 원인에서 빼려고 etcd 클러스터를 노드 하나로 줄였다.
- 노드를 다시 넣다 클러스터가 무너진 뒤 여러 시도 끝에 백업에서 etcd 전체 재해 복구를 해 00:25 쯤 etcd 를 원래 용량으로 되돌렸다.
- 01:28 에 API 서버가 쓰는 CA 를 etcd 서버의 CA 로 바꿨고, 통신과 서비스가 돌아왔다. 퍼핏이 곧 이 변경을 되돌렸다.
- 01:43 에 etcd 퍼핏 CA 인증서를 /var/lib/puppet/client/ssl/certs/ca.pem 에 두었고, 퍼핏이 이 인증서를 가져가 장애가 안정적으로 끝났다.
- 후속 조치
- etcd 클러스터 운영 절차를 문서로 남긴다. 작업 번호는 T232769 다.
- Toolforge 쿠버네티스 업그레이드로 etcd 와 쿠버네티스의 오류 보고를 개선하고, 도구를 추가할 때 API 서버를 재시작하지 않아도 되게 한다. 작업 번호는 T214513 이다.
- kube2proxy 가 API 서버 장애를 더 잘 견디게 만들어 본다. 작업 번호는 T232770 이다.
- 퍼핏 CA 인증서를 점검한다. tools 프로젝트 안에 CA 인증서가 둘 이상 있어서는 안 된다. 작업 번호는 T232772 다.
- 쿠버네티스 컨트롤 플레인을 고가용성으로 만든다. 작업 번호는 T142862 다.
- 교훈
etcd 처럼 원래 말썽이 잦은 구성 요소가 해법 찾기를 헷갈리게 했다. 퍼핏 인증서는 위험하다. 아주 오래된 쿠버네티스 버전은 로그에 남기는 오류 메시지가 형편없다. 팀은 CA 인증서가 아니라 etcd 를 고치려다 상황을 더 나쁘게 만들었다. 문제는 API 서버를 재시작할 때에야 드러났다. etcd 클러스터에는 문서화되지 않은 오래된 특이점이 있었고, etcd 재해 복구와 노드 교체 절차는 문서로 남아 있지 않았다. 이 셋이 겹쳐 해법을 찾는 데 오래 걸렸다. 교차 교육이 있었다면 도움이 됐을 수 있지만, 이번 일은 어차피 여럿이 함께 풀어야 했다.
이 5건에서 가장 많이 나오는 구성 요소: Helm, 인메모리 캐시. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.