사례4건

4건 중 1~4번째

1. IL-0234 내부 배포 자동화가 개발용 애플리케이션을 고객의 Managed Kubernetes 클러스터들에 잘못 설치해 컨트롤 플레인 연결과 쿠버네티스 기능에 문제가 났다

   IONOS Cloud2026

   증상

   2026-05-08 15:15 UTC 에 상태 페이지에 공지가 올라왔다. 일부 고객이 컨트롤 플레인에 연결하지 못하고 쿠버네티스 기능이 떨어질 수 있다는 내용이었다. 영향을 받은 곳은 DE/TXL, DE/FRA, DE/FRA/2 의 Managed Kubernetes 였다.

   컨트롤 플레인 무응답이미지 풀 실패

   촉발

   새 Managed Kubernetes 개발 클러스터를 등록하는 정기 내부 작업에서 onboarding operator 를 제외 목록에서 빼는 변경이 들어가자 곧바로 배포가 시작되었다. 이때 operator 의 대상 범위를 정하는 설정 파일은 병합 충돌로 배포 브랜치에 들어가지 못한 상태였다.

   원인

   배포 결함

   구성 요소

   CI 시스템컨테이너 레지스트리와 자격 증명

   기여 요인

   설정 테스트 부재과도한 영향 범위리뷰 누락

   조치

   • onboarding operator 를 고쳐, 네임스페이스 설정이 명시되어 있어야만 클러스터에 작업하게 했다. 이제 operator 는 기본 설정만으로는 cluster-api 기반 클러스터에서 범위 없이 돌지 못한다.
   • 필요한 설정 파일이 없으면 배포가 실패하도록 배포 시스템을 다시 구성했다. 전에는 설정이 덜 갖춰져도 배포가 조용히 진행되었다.
   • 영향을 받은 리소스에서 찾아낸 변경을 되돌리는 롤백을 마쳤고, 남은 불일치가 있는지 리소스를 점검했다.
   • 복구 스크립트를 만들어 스테이징에서 검증한 뒤 운영의 모든 영향 클러스터에 돌렸고, 2026-05-15 까지 의도하지 않은 설치와 변경을 모두 지웠다.

   후속 조치

   • 배포를 시작하기 전에 필요한 설정 파일이 모두 대상 브랜치에 전파되었는지 확인하는 필수 검증 단계를 CI/CD 파이프라인에 넣는다. 목표는 2026년 3분기다.
   • 운영 시스템을 건드리는 모든 배포는 변경 크기와 상관없이 추가 동료 검토와 변경 관리 승인을 반드시 받게 한다. 이 절차는 기존 Change Approval Board 검토에 더해진다. 목표는 2026년 3분기다.
   • 장애 뒤 복구 작업의 진행 상황을 영향을 받은 고객마다 제때 알릴 수 있도록 장애 커뮤니케이션 절차를 고친다. 목표는 2026년 3분기다.

   교훈

   클러스터 구성이 의도하지 않게 바뀐 것은 내부 작업이 고객 환경에 영향을 주지 못하게 막아야 할 통제가 실패했기 때문이다. 정리 작업 동안 영향을 받은 고객에게 진행 상황을 제대로 알리지 않아 불확실성이 더 커졌다.

   사례 보기
2. 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 도 장애 중에 쓰지 않았다.

   사례 보기
3. IL-0467 Prow 빌드 클러스터의 노드 업그레이드 중 Boskos 파드가 크래시 루프에 빠져 GCP 프로젝트가 필요한 테스트 작업이 9시간 넘게 모두 실패했다

   Kubernetes project2019

   증상

   Boskos 에서 GCP 프로젝트를 받아야 하는 Prow 테스트 작업이 밤사이 전부 실패했다. kubernetes/kubernetes 의 모든 PR 에 필수인 pull-kubernetes-e2e-gce 가 계속 실패해서 PR 을 하나도 병합할 수 없었다.

   컨테이너 재시작 반복서비스 중단

   촉발

   Prow 클러스터를 쿠버네티스 1.11 에서 1.13 으로 올리는 노드 업그레이드 중 23:04 에 Boskos 파드 하나가 돌던 노드가 drain 됐다. 새 노드에서 다시 만들어진 Boskos 파드는 StatefulSet 스펙에 적힌 새 이미지로 시작했는데, 이 이미지에 버그가 있었다.

   원인

   배포 결함

   구성 요소

   CI 시스템노드 풀

   기여 요인

   늦게 드러난 변경미검증 가정단일 장애점한계 경보 부재업무 종료 직전에 시작한 변경

   감지

   알림은 울리지 않았다. Boskos 대시보드에는 실패가 뚜렷하게 보였지만 이를 잡는 알림이 없었다. 사용자들이 02:50 에 GitHub 로, 05:16 과 06:27 에 Slack 으로 장애를 알렸고, 담당자는 07:16 에 일어나 Slack 의 보고를 보고서야 알았다.

   조치

   • 버그를 찾은 뒤 고친 Boskos 이미지를 새로 빌드해 배포했고, Boskos 는 곧바로 살아났다.
   • 장애 동안 반납되지 않고 열린 채로 남은 GCP 프로젝트들을 그 뒤 몇 분에 걸쳐 정리했다.

   후속 조치

   • Boskos 설정을 고쳐 배포하면 실제로 파드가 교체되게 한다.
   • Boskos 배포를 자동화한다.
   • Boskos 상태를 지켜보는 알림을 개선한다.

   교훈

   팀은 당직자가 오후 6시까지만 있는 날 오후 5시가 넘어 10시간짜리 배포를 시작하지 말았어야 했다고 보았다. 배포는 실제로 무언가가 바뀌었는지 확인할 수 있게 지켜봐야 하고, 그럴 수 없으면 아예 하지 않아야 한다고 정리했다. Boskos 의 StatefulSet 은 업데이트하도록 설정되어 있지 않아서 배포해도 아무것도 바뀌지 않았다. 12월의 변경은 한 번도 시험되지 않은 것으로 보였다. Prow 의 다른 부분과 달리 Boskos 는 손으로 배포해서 실수할 여지가 컸다. 담당자가 대응을 시작한 뒤로는 문제를 비교적 빨리 풀었다.

   사례 보기
4. IL-0466 Prow 가 테스트 작업을 서비스 클러스터에 스케줄해 작업이 뜨지 못하고 Prow 전체가 느려졌다

   Kubernetes project2019

   증상

   16:04 PST 에 Prow 의 응답이 매우 느려졌다. hook 의 응답이 5분쯤 늦었고 봇 명령이 응답하지 않았으며, /lgtm 과 담당자 지정이 오류를 냈다. 작업은 네트워크 문제로 실패하고 GCS 에 로그를 올리지 못했다.

   파드 Pending노드 CPU 고부하지연 시간 증가

   촉발

   13:20 PST 에 Prow 가 자동으로 만든 버전 올림 PR 이 머지돼 배포가 시작됐다. 새로 들어간 클라이언트 코드 리팩터링이 빌드 클러스터 시크릿에 적힌 "default" 클러스터 별칭을 무시해, Prow 가 작업을 기본 별칭인 서비스 클러스터에 스케줄하기 시작했다.

   원인

   배포 결함

   구성 요소

   CI 시스템

   기여 요인

   스테이징 불일치리소스 요청과 한도 미설정디버그 접근 제한

   감지

   16:04 PST 에 담당자가 PR 을 보다가 cat 명령이 동작하지 않는 것을 알아챘다. githubstatus.com 은 정상이었다. Slack 에서 Prow 노드가 CPU 와 메모리를 100% 넘게 쓰는 것을 찾았고, 이어서 test-pods 네임스페이스에서 시크릿을 찾지 못해 멈춘 Pending 파드 600개를 확인했다.

   조치

   • 16:40 에 Prow 를 버전 올림 이전인 v20190206-b01b288 로 롤백했고, 그사이 서비스 클러스터의 파드와 prowjob 을 모두 지웠다.
   • 직접 배포할 권한이 없어 이슈를 연 뒤, 16:50 에 되돌린 버전을 kubectl apply 로 직접 배포했다. 문제는 계속됐다.
   • 17:25 에 주어진 "default" 클라이언트를 덮어쓰지 않게 하는 수정 PR https://github.com/kubernetes/test-infra/pull/11209 을 올렸다.
   • 17:25 에 결함이 들어가기 전인 v20190125-2aca69d 로 Prow 를 다시 롤백했다.
   • 17:59 에 잘못 스케줄된 파드와 prowjob 을 모두 다시 지우고 Prow 가 정상임을 확인했다.

   후속 조치

   • 이 동작이 왜 비결정적으로 나타나는지 더 알아본다.
   • Prow 를 크게 바꾸는 변경을 배포할 때 더 조심한다. e2e 테스트를 늘리거나 실제 스테이징 Prow 를 둔다.

   교훈

   사람들이 자리에 있어 문제를 적극적으로 찾고 완화했다. 이번에도 금요일 오후에 일어났고, 동작이 비결정적이었다. 실제 스테이징 Prow 가 필요하다. 지금은 OpenShift 의 Prow 가 잘 돌면 쿠버네티스 Prow 를 올려도 안전하다고 보며 서로에게 기댄다. 그러나 빌드 클러스터를 정의하는 방식처럼 Prow 마다 구성이 다르므로, 쿠버네티스 Prow 와 매우 비슷한 스테이징 환경이 있어야 한다. 크게 바꾸는 Prow 변경은 e2e 테스트를 늘리거나 실제 스테이징 Prow 를 두어 더 조심해서 배포해야 한다.

   사례 보기

원인별1