사례19건

19건 중 4~8번째

1. IL-0236 머신러닝 모델 서빙 클러스터 두 곳에서 투명 프록시로 MediaWiki API 를 부르던 모델 서버들이 약 24시간 5XX 를 냈다

   Wikimedia Foundation2026

   증상

   2026-02-23 17:30 UTC 에 ml-serve-codfw 업그레이드가 끝난 직후, 일부 머신러닝 서비스의 지표에 5XX 응답 코드가 나타나기 시작했고 알림이 울렸다. 실행 중인 모델 서버의 절반이 영향을 받았고, 이 서비스들에는 약 24시간 동안 접근할 수 없었다.

   오류율 상승

   촉발

   머신러닝 운영 쿠버네티스 클러스터 두 곳을 1.31 로 올리면서 Istio 를 1.15 에서 1.24 로 올렸다. 새 Istio 는 VirtualService 의 host 값을 더 엄격하게 검증해, host 가 겹치는 VirtualService 가 둘 이상이면 하나만 받고 나머지를 버렸다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   Istio모델 추론 서버

   기여 요인

   초기 신호 무시

   감지

   영향받은 모델 서버를 쓰는 사람들이 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 핫픽스를 찾는 데 도움을 줄 기술 담당자가 마침 온라인에 있었다.

   사례 보기
2. IL-0405 AWS Load Balancer Controller 의 webhook 인증서가 만료돼 US·Canada 지역의 BSEE SaaS 인스턴스가 전부 멈췄다

   PortSwigger2026

   증상

   US 와 Canada 지역 고객이 BSEE SaaS 인스턴스의 Web UI 에 들어가지 못했고 스캔도 시작하지 못했다. 엔지니어는 고객이 지원 창구로 알려 온 뒤에야 장애를 알았다.

   서비스 중단TLS 인증서 오류

   촉발

   PortSwigger 는 2025년 11월 28일 AWS Load Balancer Controller 를 v1.14.1 에서 v1.16.0 으로 올렸다. v1.15.0 의 Helm 차트가 인증서를 관리하는 방식을 바꿨고, 이 업그레이드 뒤에 소유자가 사라진 webhook 용 TLS Secret 이 남았다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러어드미션 웹훅cert-managerHelm컨피그맵과 시크릿클라우드 로드 밸런서

   기여 요인

   늦게 드러난 변경모니터링 사각지대

   감지

   엔지니어는 고객이 지원 창구로 신고한 뒤에야 장애를 알았다. 신고는 2026년 1월 12일 09:52 UTC 에 들어왔고, 영향이 시작되고 23시간 52분이 지난 때였다.

   조치

   • US 와 Canada 클러스터에서 소유자가 사라진 aws-load-balancer-tls Secret 을 지웠다.
   • Helm 으로 AWS Load Balancer Controller 설정을 다시 배포했다.
   • 인증서가 새로 만들어졌는지, webhook 이 제대로 동작하는지 확인했다.

   후속 조치

   • 모든 클러스터에서 소유자인 Certificate 리소스가 사라진 Secret 을 찾아 정리한다.
   • SaaS 클러스터마다 외부 프로브가 애플리케이션에 접속할 수 있는지 확인하고, 접속하지 못하면 알림을 보내게 한다.

   사례 보기
3. IL-0101 자동 업그레이드를 꺼 둔 GKE 클러스터의 컨트롤 플레인이 지원 종료 기한에 1.33.2 로 강제 업그레이드된 뒤 새 노드가 모두 초기화에 실패해, 오토스케일링과 스팟 노드 복구가 15시간 멈췄다.

   Wealthy2025sev1

   증상

   2025년 9월 14일, 이미 떠 있던 노드는 계속 돌았지만 새로 만들어지는 노드는 하나도 클러스터에 제대로 들어오지 못했다. 스팟 인스턴스에서 돌던 백그라운드 워커, 리포트 서비스, 주문 할당 시스템이 완전히 멈췄다. API 는 기존 노드에서 계속 응답했지만 부하가 늘어도 확장할 수 없었다.

   노드 증설 실패컨테이너 재시작 반복서비스 중단DNS 조회 실패

   촉발

   노드 풀의 자동 업그레이드를 꺼 두었는데도 Google 이 버전 지원 종료 기한을 이유로 컨트롤 플레인을 v1.32.x 에서 v1.33.2 로 강제 업그레이드했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   GKE 컨트롤 플레인노드 풀클라이언트 쪽 DNS 리졸버와 캐시영구 볼륨과 스테이트풀셋컨피그맵과 시크릿

   기여 요인

   미뤄 둔 업그레이드단일 장애점롤백 무효여유 용량 부재

   조치

   • 강제 업그레이드와 같은 버전인 v1.33 으로 새 GKE 클러스터를 만들었다.
   • 쿠버네티스 1.33 과 호환되도록 Istio 를 1.27.1 로 올렸다.
   • 쿠버네티스 1.33 에 맞게 cert-manager 설정을 갱신했다.
   • 모든 운영 워크로드를 새 클러스터로 옮기고, 파드 스케줄링, DNS 조회, PVC 마운트, 외부 연동이 정상인지 확인했다.
   • 손상된 기존 클러스터를 폐기했다.

   후속 조치

   • 모든 클러스터를 GKE stable 릴리스 채널로 설정한다.
   • 2025년 4분기까지 Argo CD 와 모니터링 같은 관리용 구성 요소를 따로 돌리는 관리 클러스터를 만든다.
   • 중요한 워크로드의 스팟 인스턴스 사용을 다시 검토하고, 온디맨드 대체 노드 풀을 추가한다.
   • SRE 업그레이드 절차를 문서로 남긴다. 관리 클러스터를 먼저 올리고, 며칠 동안 지켜본 뒤 운영 클러스터를 올린다.
   • 쿠버네티스, Istio, cert-manager 사이의 호환 표를 문서로 남긴다.
   • 업그레이드를 자동으로 시험하는 파이프라인을 만든다.
   • 빠르게 이전할 수 있도록 고정 IP 를 예약해 둔다.
   • Istio, cert-manager, CSI, DNS 애드온의 버전을 고정한다.
   • 지원 종료 기한에 몰리지 않도록 stable 릴리스를 따라 제때 올리고, GKE 알림과 공지를 정기적으로 확인한다.

   교훈

   Google 은 자동 업그레이드를 꺼 두어도 버전 지원 종료 기한이 되면 컨트롤 플레인을 강제로 올린다. 강제 업그레이드를 피하려면 지원 버전 범위 안에 머물러야 한다. 기존 노드가 멀쩡해도 새 노드 초기화는 완전히 실패할 수 있다. 선점된 스팟 노드가 클러스터에 돌아오지 못하면 장애가 연쇄로 번진다. 컨트롤 플레인을 올린 뒤 노드 초기화가 되돌릴 수 없게 망가지면 클러스터를 통째로 다시 만들어야 할 수도 있다. 예측할 수 있고 검증된 릴리스 주기를 원하면 GKE stable 채널을 쓴다. 쿠버네티스를 올릴 때는 Istio, cert-manager 같은 의존 구성 요소를 함께 맞춰야 한다. 같은 클라우드에 대기 클러스터가 없으면 바로 넘어갈 곳이 없다. SRE 가 롤아웃을 단계적으로 관리하면 업그레이드 위험이 줄어든다.

   사례 보기
4. IL-0079 GKE 노드가 새 ubuntu_containerd 이미지로 자동 업그레이드된 뒤 커널에서 kube-proxy 가 쓰는 iptables 확장이 빠져, 여러 GKE 클러스터의 인그레스 트래픽이 완전히 끊겼다.

   Altinity2025

   증상

   토요일인 5월 17일 이른 시각에 OpsGenie 알림이 울렸다. Altinity.Cloud 의 ClickHouse 클러스터 하나가 갑자기 조용해졌다. 쿼리도, 지표도, 접속하려는 고객의 로그도 들어오지 않았다. 파드는 모두 Running 이었고 노드도 정상으로 보였지만 데이터베이스까지 오는 트래픽이 없었다.

   서비스 중단

   촉발

   GKE 가 노드를 ubuntu_containerd 1.32.3-gke.1785003 이미지와 커널 6.8.0-1022-gke 로 자동 업그레이드했다. 이 커널은 nf_tables 모듈의 패키징이나 로딩 방식에 회귀가 있어 kube-proxy 가 쓰는 iptables 확장을 지원하지 않았다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   kube-proxy노드 운영체제 이미지리눅스 커널클라우드 로드 밸런서

   기여 요인

   미패치 알려진 버그단계적 배포 부재

   감지

   OpsGenie 알림으로 알았다. ClickHouse 클러스터 하나에서 쿼리, 지표, 고객 접속 로그가 모두 끊겼고, 곧 다른 클러스터들도 같은 상태가 됐다.

   조치

   • 아직 영향받지 않은 클러스터에 유지보수 제외를 걸어 업그레이드를 모두 멈췄다. 이 조치로 문제가 GKE 에서 운영하는 모든 클러스터로 번지는 것을 막았다.
   • 로드밸런서 헬스 체크 정책을 바꿔 kube-proxy 헬스 체크 실패를 무시하게 했다. kube-proxy 에 필요한 확장이 없는 노드로도 트래픽이 흐르면서 서비스가 회복됐다.
   • 영향받은 클러스터 전부를 ubuntu_containerd 에서 nf_tables 문제가 없는 다른 커널을 쓰는 cos_containerd 이미지로 옮기기 시작했다. 노드를 새 이미지로 다시 만들어야 해서 짧은 다운타임이 생겼다.

   후속 조치

   • 회귀를 더 일찍 잡도록 이미지 사전 테스트 파이프라인을 넓힌다.
   • GKE 자동 업그레이드 예정 알림을 켜서 미리 대비한다.
   • 모든 클러스터에 GKE 유지보수 기간을 반드시 설정해 업그레이드가 배포되는 시점을 직접 정한다.
   • Google 이슈 트래커에 올린 커뮤니티 이슈를 추적하며 고쳐진 Ubuntu 이미지를 기다린다.

   교훈

   관리형 Kubernetes 의 노드 자동 업그레이드는 사용자가 검증하지 않은 커널을 운영 노드에 올린다. 클라우드 업체의 이미지 검증만 믿으면 이런 회귀를 막지 못한다. IPv6 를 쓰지 않아도 kube-proxy 는 IPv6 iptables 규칙을 적용하므로, 그 적용이 실패하면 로드밸런서 헬스 체크도 실패해 모든 인그레스가 끊길 수 있다. 영향받은 버전이 확인되면 아직 업그레이드되지 않은 클러스터의 업그레이드부터 멈춰야 피해가 번지지 않는다. Altinity 는 영향받은 사용자에게 externalTrafficPolicy: Cluster 로 바꿔 kube-proxy 헬스 체크를 끄고, 운영 노드 이미지를 cos_containerd 로 바꾸고, 고쳐진 이미지가 확인될 때까지 자동 업그레이드를 멈추라고 권한다.

   사례 보기
5. IL-0201 프레임워크 업그레이드가 쿠버네티스 인프라에서 커널 패닉을 일으켜 GitHub.com 의 웹과 API 요청이 15시간 넘게 간헐적으로 실패했다

   GitHub2025

   증상

   2025년 3월 17일 18:05 UTC 부터 GitHub.com 의 웹 요청과 API 요청이 간헐적으로 실패했다. 실패는 주로 풀 리퀘스트와 이슈 관련 요청에서 났고, 영향을 받은 사용자는 일부였다. 18:39 UTC 에 상태 페이지에 Issues 의 성능 저하 신고를 조사 중이라는 첫 공지가 올라왔다.

   오류율 상승간헐적 타임아웃

   촉발

   GitHub 이 쿠버네티스 인프라에 프레임워크 업그레이드를 적용했고, 이 업그레이드가 커널 패닉을 일으켰다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   리눅스 커널

   기여 요인

   –

   감지

   상태 페이지 첫 공지는 장애 시작 34분 뒤인 18:39 UTC 에 올라왔고, Issues 의 성능 저하 신고를 조사 중이라는 내용이었다.

   조치

   • 업그레이드한 프레임워크를 이전 버전으로 다운그레이드해 영향을 줄였다.
   • 문제를 일으킨 기능을 끌 수 있게 된 뒤 그 기능을 껐다.

   후속 조치

   • 업그레이드가 왜 예상하지 못한 문제를 일으켰는지 조사했다.
   • 같은 문제가 다시 나지 않도록 임시 조치를 했다.
   • 장기적인 패치 계획을 세운다.
   • 비슷한 종류의 문제에 빨리 대응할 수 있도록 관측성을 높인다.

   사례 보기

원인별1