사례10건

10건 중 1~5번째

1. IL-0512 xPRO 의 쿠버네티스 APISIX 오리진 인증서가 갱신되지 못하고 만료되어 xpro.mit.edu 가 한 시간 동안 503 을 냈다

   MIT Open Learning2026sev1

   증상

   2026-06-03 오후 3시 38분 EDT 에 xPRO 운영 CMS 와 xPRO 본 애플리케이션이 503 을 낸다는 알림이 함께 울렸다. 공개 사이트 https://xpro.mit.edu 에 고객이 제대로 접속하지 못했다.

   서비스 중단TLS 인증서 오류

   촉발

   cert-manager 가 2026-05-04 에 xpro-web.odl.mit.edu 인증서의 갱신 구간에 들어가 DNS-01 검증을 시작했다. 이 검증이 Fastly 가 만든 _acme-challenge.xpro-web.odl.mit.edu CNAME 과 부딪혀 끝나지 못했고, 기존 오리진 인증서가 2026-06-03 오후 3시 29분 EDT 에 만료됐다.

   원인

   설정 변경

   구성 요소

   cert-managerCDN 과 엣지 네트워크DNS 서버와 레코드

   기여 요인

   설정 테스트 부재모니터링 사각지대늦게 드러난 변경

   감지

   오후 3시 38분 EDT 에 xPRO 운영 CMS 와 xPRO 본 사이트가 503 을 낸다는 알림이 울렸다. 인증서가 만료된 지 9분 뒤였다.

   조치

   • 오래된 cert-manager 자원을 지우고 다시 만들어 cert-manager 가 백엔드 오리진의 새 인증서를 발급하게 했다. 이것으로 서비스가 돌아왔다.

   후속 조치

   • OpenEdX 가 아닌 xPRO 의 Fastly TLS 구독에서 백엔드 오리진 도메인을 뺐다.
   • src/ol_infrastructure/applications/xpro 의 Production 스택에 Pulumi 변경을 배포했다.
   • Fastly 의 검증 CNAME 을 뺀 뒤, xpro 네임스페이스에 있는 OpenEdX 가 아닌 xPRO 인증서를 cert-manager 로 직접 갱신하거나 cert-manager 가 저절로 갱신하게 했다.
   • cert-manager 가 관리하는 오리진 도메인이 Fastly TLS 구독에 들어가지 못하게 막는 테스트나 정책 검사를 넣는 방안을 검토한다.
   • cert-manager 의 CertificateRequest 와 Order 가 실패하면 더 일찍 알림을 보내, 인증서가 만료되기 전에 오래된 ACME 실패를 찾는 방안을 검토한다.

   교훈

   이 장애는 처음에 cert-manager 의 ACME 갱신 실패로 이해됐다. 그 이해는 맞았지만 모자랐고, 빠진 진단은 Fastly 가 cert-manager 의 몫인 백엔드 오리진 도메인의 검증까지 관리하도록 설정돼 있었다는 점이었다. 갱신 실패를 일찍 잡지 못한 것은 cert-manager 가 관리하는 백엔드 오리진 도메인이 Fastly TLS 구독에 들어가면 안 된다는 것을 검사하는 장치나 테스트가 없었기 때문이다. 팀은 TLS 인증서와 DNS 검증 레코드를 누가 맡는지 경계를 분명히 정하고 그 경계를 지키는 장치를 둬야 한다고 정리했다. 특히 TLS 자동화를 설정할 때 Fastly 의 공개 프런트엔드 도메인과 쿠버네티스 APISIX 백엔드 오리진 도메인을 바꿔 써도 되는 같은 서비스 도메인으로 다루면 안 된다.

   사례 보기
2. 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분기다.

   교훈

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

   사례 보기
3. IL-0019 EKS 모듈 18 업그레이드로 새 노드의 디스크가 20Gb 로 줄어 이미지 풀이 no space left on device 로 실패했다

   UK Ministry of Justice2023

   증상

   2023-09-18 13:42, 팀은 High-priority-alert 채널에서 RootVolUtilisation-Critical 알림을 봤다. 14:03 에는 한 사용자가 이미지 풀이 no space left on device 오류로 실패한다고 알렸다.

   노드 디스크 가득 참이미지 풀 실패파드 축출파드 ContainerCreating 정체IP 주소 고갈

   촉발

   EKS 모듈을 버전 18 로 올리면서 런치 템플릿이 바뀌었고, 새 노드의 디스크가 100Gb 에서 20Gb 로 줄었다.

   원인

   설정 변경

   구성 요소

   노드 루트 디스크노드 런치 템플릿노드 풀AWS VPC CNICoreDNS

   기여 요인

   리뷰 누락설정 테스트 부재한계 경보 부재

   감지

   13:42 에 High-priority-alert 채널로 RootVolUtilisation-Critical 알림이 왔다. 14:03 에 사용자가 이미지 풀 실패를 보고했고, 장애 선언은 15:12 였다.

   조치

   • 예전 기본 노드 그룹을 uncordon 하고, 새 노드를 drain 해 워크로드를 예전 노드 그룹으로 되돌렸다.
   • 루트 볼륨을 20Gb 로 줄인 런치 템플릿 변경을 찾아, manager 클러스터와 live 클러스터에 수정을 적용했다.
   • 예전 노드 그룹을 drain 해 워크로드를 수정한 노드로 옮겼다.

   후속 조치

   • EKS 모듈을 올릴 때 런치 템플릿 변경을 비교하는 절차를 런북에 넣는다.
   • live 클러스터처럼 크기가 다양한 이미지를 받아 보는 테스트 환경을 만든다.
   • RootVolUtilisation 알림 런북에 디스크 크기 설정을 확인하는 단계를 넣는다.
   • 노드 수에 따라 CoreDNS 를 자동으로 늘리고 줄인다.
   • IP 접두사 부족을 IPv6 로 풀 수 있는지 조사한다.
   • terraform plan 에서 런치 템플릿이 바뀌면 알아챌 수 있게 드리프트 테스트를 추가한다.
   • CNI 와 ipamd 로그를 볼 수 있게 로깅을 갖추고, IP 접두사 부족 오류가 나면 알림을 보낸다.

   교훈

   이 글은 교훈 대신 후속 조치를 적었다. 조치를 보면 팀에는 빈틈이 두 가지 있었다. 하나는 모듈 업그레이드가 바꾼 런치 템플릿을 배포 전에 비교하지도, 드리프트 테스트로 잡지도 않은 것이다. 다른 하나는 drain 중 팀이 의심한 IP 접두사 부족을 확인할 CNI 와 ipamd 로그도, 알림도 없었던 것이다.

   사례 보기
4. IL-0459 쿠버네티스 위 MediaWiki 가 TLS 종료에 엉뚱한 인증서를 써서 약 30분 동안 트래픽 1% 가 오류를 받았다

   Wikimedia Foundation2023

   증상

   MediaWiki 설정 변경을 배포한 11:41 부터 쿠버네티스로 가는 MediaWiki 트래픽이 오류를 받기 시작했다. 11:47 에 mw-api-ext 와 mw-api-int 서비스의 프로브 실패 알림이 온콜 담당자를 호출했다. 전체 트래픽의 1%, 초당 120건의 요청이 약 30분 동안 오류를 받았다.

   오류율 상승TLS 인증서 오류컨트롤 플레인 지연

   촉발

   09:37 에 쿠버네티스 전역 기본값을 바꾸는 변경이 머지됐다. 이 변경으로 이 기본값을 따르는 차트가 cert-manager 인증서를 쓰게 됐다. 11:41 에 MediaWiki 설정 변경을 배포하면서 쿠버네티스 위 MediaWiki 배포가 이 기본값을 받아 TLS 종료에 엉뚱한 인증서를 쓰게 됐다.

   원인

   설정 변경

   구성 요소

   cert-managerHelm

   기여 요인

   늦게 드러난 변경설정 테스트 부재

   감지

   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% 만 쿠버네티스로 가서 피해가 작았다. 오류의 양이 적어 문제를 쿠버네티스 쪽으로 좁히는 데 시간이 걸렸다. 보고서는 쿠버네티스를 서비스 풀에서 더 일찍 뺐어야 했는지를 묻는다.

   사례 보기
5. IL-0017 live 클러스터 노드 6대에서 VPC CNI 가 IP 주소를 할당하지 못해 새 파드가 ContainerCreating 에 멈췄다

   UK Ministry of Justice2023

   증상

   2023-07-21 08:15, 한 사용자가 #ask-cloud-platform 채널에 새 배포가 ContainerCreating 상태에서 멈춘다고 알렸다.

   파드 ContainerCreating 정체IP 주소 고갈

   원인

   설정 변경

   구성 요소

   AWS VPC CNI노드 풀

   기여 요인

   설정 테스트 부재

   감지

   팀은 08:15 에 한 사용자가 #ask-cloud-platform 채널에 새 배포가 ContainerCreating 에서 멈춘다고 보고해 장애를 알았다. 장애 선언은 09:31 이었다.

   조치

   • 새 노드를 추가하고, 영향받은 노드 6대를 cordon 한 뒤 drain 하기 시작했다.
   • live 클러스터에서 Prefix Delegation 을 켜는 명령을 실행해 빠진 CNI 설정을 넣었다.

   후속 조치

   • IP 주소 할당이 제대로 되는지 확인하는 테스트나 점검을 추가한다. 작업 번호는 #4669 다.

   교훈

   이 글은 교훈을 따로 적지 않았다. 후속 조치로는 IP 주소 할당이 제대로 되는지 확인하는 점검을 추가한다는 것 하나만 적었다.

   사례 보기

원인별3