사례11건

11건 중 1~5번째

1. IL-0098 ingress-nginx 에서 nginx-ingress 로 옮긴 뒤 같은 호스트를 나눠 쓰는 인그레스들의 동작이 바뀌어 cert-manager 가 새 TLS 인증서를 받지 못했다.

   2i2c2026

   증상

   새 허브를 띄우려 했는데 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 얼마 전 다른 허브에서도 같은 일이 있었다.

   요청 오라우팅배포 실패

   촉발

   nginx-ingress 로 옮긴 클러스터에서 새 TLS 인증서가 필요한 허브를 새로 배포했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러cert-manager

   기여 요인

   늦게 드러난 변경

   감지

   새 허브를 띄우다 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 전날 다른 허브에서도 같은 현상을 봤기 때문에 엔지니어가 웹사이트에서 장애를 직접 선언했다.

   조치

   • TLS 가 필요한 인그레스 객체에 어노테이션을 달아 cert-manager 가 edit-in-place 방식으로 인그레스를 고칠 수 있게 했다.

   후속 조치

   • 후속 작업을 2i2c-org/infrastructure 이슈 8016 으로 남겼다.
   • 후속 작업을 2i2c-org/infrastructure 이슈 3278 로 남겼다.

   교훈

   인그레스 컨트롤러를 바꾸면 같은 호스트를 나눠 쓰는 인그레스들 사이의 우선순위가 바뀔 수 있고, cert-manager 의 ACME 임시 인그레스처럼 그 동작에 기대는 구성 요소가 깨진다. 이 문제는 새 인증서가 필요한 배포에서 드러났다. 2i2c 는 내부 클러스터를 시험하면서 이 원인을 이미 알고 있었고, cert-manager 설정을 고치는 일도 빨랐다.

   사례 보기
2. IL-0124 서킷 브레이커가 풀리자 낡은 상태를 근거로 쌓여 있던 용량 조정이 한꺼번에 실행돼 여러 추론 엔진이 동시에 빠졌고, OpenAI API 의 오류율과 지연 시간이 올랐다.

   OpenAI2026

   증상

   2026년 3월 4일 오후 4시 26분 PST 무렵부터 약 30분 동안 여러 모델의 API 요청에서 오류율과 지연 시간이 올랐다. 영향은 주로 API 트래픽에 나타났고, Codex 트래픽 일부도 영향을 받았다.

   오류율 상승지연 시간 증가

   촉발

   보호용 서킷 브레이커가 일부 스케줄링 작업을 멈춰 둔 사이에 인프라 작업이 큐에 쌓였고, 서킷 브레이커가 풀리자 이 작업이 한꺼번에 실행됐다.

   원인

   소프트웨어 결함

   구성 요소

   자동 용량 관리 시스템

   기여 요인

   자동화 증폭늦게 드러난 변경파괴적 변경 보호 장치 부재모니터링 사각지대

   조치

   • 엔지니어들이 영향을 받은 모델에 인프라 자원을 손으로 다시 배정했다.
   • 추론 엔진을 다시 올리고 모델에 재배정해 서비스를 되살렸다.

   후속 조치

   • 자동 용량 관리 시스템이 실제 상태와 어긋났을 때 이를 더 잘 감지하고 대응하도록 보호 장치를 보강한다.
   • 서킷 브레이커와 스케줄링 시스템의 상태와 그 영향을 쉽게 알아볼 수 있도록 관측성을 높인다.
   • 오래 멈췄다가 풀린 뒤 큐에 쌓인 작업이 대량으로 한꺼번에 실행되지 않도록 보호 장치를 더한다.
   • 용량 조정이 실제 상태와 어긋나는 문제를 잡아내도록 모니터링과 알림을 개선한다.

   교훈

   실행을 멈춘 동안에도 작업을 큐에 쌓는 자동화는 멈춤이 풀리는 순간 낡은 상태를 근거로 한 변경을 한꺼번에 쏟아낼 수 있다. 서킷 브레이커가 무엇을 멈춰 두었는지, 풀릴 때 무엇이 실행될지 눈으로 확인할 수 있어야 한다. 긴 멈춤 뒤에 쌓인 작업이 대량으로 한 번에 실행되지 않게 막아야 한다.

   사례 보기
3. IL-0156 인증서 교체 뒤 옛 인증서를 폐기하자 애틀랜타 LKE 의 클러스터 관리와 오토스케일링이 5xx 오류로 실패했다.

   Linode2025

   증상

   2025년 9월 24일 02:29 UTC 무렵부터 US-Southeast 애틀랜타의 LKE 오토스케일링이 영향을 받았고 고객은 클러스터를 관리할 수 없었다. 노드 풀 수정, 스케일링, 클러스터 생성과 삭제가 막혔다. 실행 중인 고객 워크로드는 영향을 받지 않았다.

   오류율 상승오토스케일러 오동작

   촉발

   9월 23일 클러스터 컨트롤러의 만료가 다가온 인증서를 교체한 뒤, 후속 작업으로 9월 24일 02:29 UTC 에 관련 컨트롤러의 옛 인증서를 폐기했다.

   원인

   인증서·자격 증명 만료

   구성 요소

   관리형 쿠버네티스 컨트롤 플레인과 제공자 API클러스터 오토스케일러

   기여 요인

   늦게 드러난 변경

   조치

   • 문제를 고치는 수정을 배포했다.
   • API 엔드포인트를 재시작했다.

   후속 조치

   • Akamai 전문가들이 근본 원인을 계속 조사하고 알맞은 예방 조치를 한다.

   사례 보기
4. IL-0138 nvidia-dkms-390 드라이버 빌드 실패로 망가진 커널 헤더가 몇 주 동안 방치됐다가, 정전 뒤 재부팅하자 하나뿐인 마스터 노드가 커널 패닉에 빠져 홈랩 쿠버네티스 클러스터가 6일 동안 멈췄다.

   Barush Mendez2025

   증상

   2025년 3월 3일 14:15:34부터 홈랩 쿠버네티스에 올린 서비스에 접속되지 않았다. 운영자가 서비스에 들어가려다 직접 알아챘고, 알아채기까지 3시간이 걸렸다.

   컨트롤 플레인 무응답서비스 중단모니터링 중단

   촉발

   정전 때문에 마스터 노드가 재부팅됐다.

   원인

   소프트웨어 결함

   구성 요소

   GPU 드라이버리눅스 커널쿠버네티스 API 서버

   기여 요인

   초기 신호 무시늦게 드러난 변경단일 장애점모니터링 사각지대

   감지

   운영자가 서비스에 접속하려다 직접 알아챘다. 자동 알림이 없어서 알아채기까지 3시간이 걸렸다.

   조치

   • 원격 접속이 되지 않아 모니터를 연결해 부팅 로그를 보고 커널 패닉을 확인했다.
   • 이전 커널 버전으로 부팅해 시스템을 되살렸다.
   • sudo apt-get remove --purge '^nvidia-.*' 로 망가진 패키지를 지우고 sudo dpkg --configure -a 로 패키지 설정 문제를 고쳤다.
   • dpkg -l | grep -v ^ii 로 남은 망가진 패키지를 찾아 sudo apt-get remove --purge <package_name> 으로 하나씩 지웠다.
   • sudo apt-get install -f 로 빠진 의존성을 채우고 sudo apt-get install --reinstall linux-headers-$(uname -r) 로 커널 헤더를 다시 설치했다.
   • 머신을 재부팅해 커널 패닉이 사라진 것을 확인했다.

   후속 조치

   • GPU 드라이버 설치가 완전히 성공했는지 확인하고, 오류가 나면 바로 변경을 되돌린다.
   • 단일 장애 지점을 없애도록 클러스터를 고가용성 구성으로 옮긴다.
   • 고가용성 구성에서 Kube-API 를 로드 밸런서 뒤에 둔다.
   • 장애를 기록하고 해결 과정을 추적할 티켓 시스템을 만든다.
   • 미리 정해 둔 문제 해결 절차를 만들어 홈랩 장애 대응 시간을 줄인다.
   • Prometheus 와 Grafana 같은 인프라 모니터링을 넣어 문제를 미리 잡는다.
   • 주요 서비스에 HTTP, TCP 검사를 거는 블랙박스 모니터링을 넣어 쿠버네티스 클러스터 밖에서도 장애를 잡는다.

   교훈

   드라이버 빌드 실패를 그대로 두면 몇 주 뒤 재부팅 때 터질 수 있다. 자동 알림이 없어서 발견과 복구가 늦었다. 마스터 노드가 하나뿐이라 노드 하나의 고장이 클러스터 전체 장애가 됐다. 원인을 찾은 뒤에는 비교적 간단히 고쳤고, 데이터 손실은 없었다.

   사례 보기
5. IL-0203 클러스터 시스템 업데이트 뒤 AWS Load Balancer Controller 가 실패해 새 파드가 ALB 에 등록되지 않았고, Honeycomb EU1 의 수집과 UI 가 11분 동안 멈췄다

   Honeycomb2024

   증상

   4월 9일 22:00:10 UTC 에 Honeycomb EU1 의 이벤트 수집과 웹 UI 가 갑자기 멈췄다. 두 서비스가 거의 같은 시각에 끊겼다. 22:08 UTC 에 상태 페이지에 EU1 인스턴스가 다운됐다는 공지가 올라왔다.

   서비스 중단오래된 엔드포인트 라우팅

   촉발

   그날 앞서 쿠버네티스 클러스터에 배포한 일상적인 시스템 업데이트가 AWS Load Balancer Controller 를 간헐적으로 실패하게 만들었고, 그 뒤 이어진 서비스 배포가 마지막 옛 파드를 내렸다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러클라우드 로드 밸런서

   기여 요인

   모니터링 사각지대스테이징 불일치늦게 드러난 변경

   감지

   상태 페이지 첫 공지는 장애 시작 8분 뒤인 22:08 UTC 에 올라왔고, EU1 인스턴스가 다운돼 조사 중이라는 내용이었다. AWS Load Balancer Controller 에는 알림이 없었다.

   조치

   • AWS Load Balancer Controller 를 재시작해 서비스를 되살렸다.
   • 재발을 막으려고 시스템 업데이트를 롤백했다.

   후속 조치

   • 재발을 막고 시스템 업데이트를 안전하게 다시 배포할 수 있도록 실패의 정확한 원인을 밝힌다.
   • AWS Load Balancer Controller 에 모니터링과 알림을 추가해, 실패하면 온콜 엔지니어가 바로 알고 배포를 미리 멈출 수 있게 한다.

   교훈

   AWS Load Balancer Controller 는 배포 때마다 새 파드를 ALB 에 등록하는 핵심 구성 요소였다. 이 컨트롤러가 실패해도 서비스는 바로 멈추지 않았고, 다음 배포에서 마지막 옛 파드가 내려갈 때 끊겼다. 개발 환경과 스테이징 환경에서 충분히 시험한 시스템 업데이트도 운영 클러스터의 다른 구성 요소와 부딪칠 수 있다.

   사례 보기

원인별4