사례13건

13건 중 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-0200 새로 띄운 쿠버네티스 노드가 호환되지 않는 etcd 버전으로 돌아 여러 운영 클러스터의 합의가 깨졌고, GitHub.com 의 git 작업과 웹 요청이 5XX 오류로 실패했다.

   GitHub2026

   증상

   2026년 3월 12일 01:36 UTC 부터 GitHub.com 의 git 작업, 웹 요청, 관련 서비스에서 오류율이 올라갔다. git push, git clone, 페이지 로드가 간헐적으로 5XX 오류를 내며 실패했다.

   오류율 상승

   촉발

   계획된 인프라 업그레이드 중에 설정 문제가 생겨 새로 프로비저닝한 쿠버네티스 노드가 호환되지 않는 etcd 버전으로 올라왔다.

   원인

   설정 변경

   구성 요소

   etcd

   기여 요인

   모니터링 사각지대

   감지

   상태 페이지의 첫 공지는 01:54 UTC 에 올라왔다. 일부 GitHub 서비스의 성능이 떨어졌다는 보고를 조사하고 있다는 내용이었다. 오류율이 오르기 시작한 01:36 UTC 에서 18분 뒤였다.

   조치

   • 장애가 이어지는 동안 배포를 멈췄다.
   • 호환되지 않는 etcd 버전으로 돌던 새 노드를 찾아 빼냈고, 그 뒤 클러스터 합의가 돌아왔다.
   • 검증용 배포로 모든 시스템이 정상인 것을 확인한 다음 평소 운영을 재개했다.

   후속 조치

   • 노드를 교체할 때 버전 호환성 검사를 자동화해 강제한다.
   • 스플릿 브레인 상태를 더 일찍 잡아내는 모니터링을 만든다.
   • 복구 도구를 고쳐 복구에 걸리는 시간을 줄인다.

   사례 보기
3. IL-0005 새 텔레메트리 서비스가 모든 노드에서 무거운 쿠버네티스 API 요청을 보내 대형 클러스터의 컨트롤 플레인이 무너졌고, DNS 기반 서비스 디스커버리가 깨져 OpenAI 의 모든 서비스가 멈췄다

   OpenAI2024

   증상

   2024년 12월 11일 오후 3시 13분 PST 에 알림이 울려 엔지니어들에게 전달됐다. 3시 16분부터 ChatGPT, API, Sora 를 포함한 OpenAI 의 모든 서비스가 크게 느려지거나 완전히 멈췄다.

   서비스 중단오류율 상승컨트롤 플레인 무응답DNS 조회 실패

   촉발

   오후 3시 12분 PST 에 쿠버네티스 컨트롤 플레인 지표를 자세히 수집하는 새 텔레메트리 서비스를 배포했다. 이 서비스의 설정 때문에 각 클러스터의 모든 노드가 무거운 쿠버네티스 API 요청을 보냈다. 이 요청은 클러스터가 클수록 비용이 커진다. 변경은 오후 2시 51분부터 3시 20분 사이에 모든 클러스터에 적용됐다.

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버클라이언트 쪽 DNS 리졸버와 캐시텔레메트리 에이전트

   기여 요인

   스테이징 불일치단계적 배포 부재캐시로 가려진 장애모니터링 사각지대디버그 접근 제한

   감지

   변경이 모든 클러스터에 적용되던 오후 3시 13분 PST 에 알림이 울려 엔지니어들에게 전달됐다. 탐지 도구는 고객이 영향을 받기 몇 분 전에 문제를 잡았고, 엔지니어들은 3시 16분에 원인을 찾았다. 다만 노드의 DNS 캐시가 실제 실패를 늦춰, 문제의 전체 범위가 보이기 전에 배포가 계속 진행됐다.

   조치

   • 클러스터 규모를 줄여 쿠버네티스 API 부하의 총량을 낮췄다.
   • 쿠버네티스 관리 API 로 가는 네트워크 접근을 막아 새로 들어오는 무거운 요청을 차단하고 API 서버가 회복할 시간을 벌었다.
   • 쿠버네티스 API 서버를 증설해 밀린 요청을 처리할 자원을 늘리고 수정을 적용할 수 있게 했다.
   • 컨트롤 플레인 제어권을 되찾은 뒤 문제의 텔레메트리 서비스를 지웠다.
   • 오후 3시 27분부터 영향받은 클러스터에서 트래픽을 빼기 시작했고, 가능한 곳에서는 트래픽을 정상 클러스터로 옮겼다.
   • 많은 서비스가 동시에 자원을 내려받아 자원 한도가 찬 클러스터에는 추가로 수동 조치를 했다.

   후속 조치

   • 모든 인프라 설정 변경에 단계적 배포를 적용하고, 서비스 워크로드와 쿠버네티스 컨트롤 플레인을 포함한 클러스터 상태를 계속 감시한다.
   • 데이터 플레인이 컨트롤 플레인 없이 버티는 상황과 잘못된 변경을 일부러 배포하는 상황을 시험하는 장애 주입 테스트를 돌린다.
   • 데이터 플레인이 컨트롤 플레인을 지나치게 압박할 때도 엔지니어가 쿠버네티스 API 서버에 접근할 수 있는 비상 접근 수단을 만든다.
   • 데이터 플레인과 컨트롤 플레인을 분리한다. 서비스 디스커버리가 쿠버네티스 DNS 에 묶여 있는 구조를 풀어, 핵심 서비스가 요청을 처리할 때 컨트롤 플레인에 기대지 않게 한다.
   • 클러스터 기동에 필요한 자원에 캐시와 동적 속도 제한을 더하고, 클러스터 하나를 통째로 빠르게 교체하는 훈련을 정기적으로 한다.

   교훈

   이 장애는 여러 시스템과 절차가 동시에 실패하며 예상하지 못한 방식으로 얽혀 생겼다. 테스트는 이 변경이 쿠버네티스 컨트롤 플레인에 주는 영향을 잡지 못했다. DNS 캐시 때문에 변경과 서비스 실패 사이에 시간 차가 생겼다. 컨트롤 플레인에 접근할 수 없게 되면서 복구가 매우 느렸다. 데이터 플레인이 컨트롤 플레인과 따로 돌도록 설계되어 있어도, DNS 기반 서비스 디스커버리가 컨트롤 플레인에 기대면 컨트롤 플레인 장애가 서비스 장애로 번진다. 배포 전 점검은 클러스터의 CPU 와 메모리 사용량만 봤고 API 서버 부하는 보지 않았다.

   사례 보기
4. IL-0068 익명 요청을 허용한 쿠버네티스 API 서버로 공격자가 들어와 RBAC 로 백도어를 만들고, DaemonSet 으로 Monero 채굴기를 모든 노드에 띄웠다.

   Aqua Security2023

   증상

   Aqua 의 쿠버네티스 허니팟 클러스터에 공격이 들어왔다. 공격자는 Secret 목록을 조회하는 HTTP 요청 몇 개를 보내고, kube-system 네임스페이스의 리소스 목록을 조회하는 API 요청 두 개로 클러스터 정보를 모았다.

   무단 접근과 낯선 워크로드리소스 삭제

   촉발

   API 서버가 잘못 설정되어, 권한을 가진 익명 사용자의 인증 없는 요청을 받아들였다.

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버RBAC 와 서비스 어카운트컨테이너 레지스트리와 자격 증명

   기여 요인

   모니터링 사각지대

   감지

   Aqua 가 운영하는 쿠버네티스 허니팟에 들어온 공격을 기록하고 분석해 찾았다. 허니팟에 일부러 노출해 둔 AWS 액세스 키가 쓰이자 비컨 신호가 왔다.

   교훈

   API 서버에 익명 접근을 허용하는 설정 실수 하나로 클러스터 전체를 내줄 수 있다. 공격자가 ClusterRoleBinding 으로 지속적인 접근 경로를 만들어 두면 잘못된 설정을 고친 뒤에도 계속 들어올 수 있다. 공격자는 system:controller: 로 시작하는 정상 구성 요소 같은 이름과 kube-controller-manager 를 닮은 이미지 이름으로 감사 로그와 사람의 눈을 피한다. Aqua 는 Trivy 같은 도구로 취약점, 노출된 Secret, 잘못된 설정을 찾으라고 권한다.

   사례 보기
5. IL-0116 CNI 설정 변경이 스테이징에 없던 하드웨어 종류와 호환되지 않아 GPU 클러스터 하나의 워크로드가 네트워크 연결을 잃었고, text-davinci-003 모델이 완전히 멈췄다.

   OpenAI2023

   증상

   2023년 1월 25일 태평양 시각 오후 4시 53분, GPU 클러스터 하나에 큰 장애가 나서 text-davinci-003 모델이 완전히 멈췄다.

   서비스 중단처리량 저하

   촉발

   컨테이너에 네트워크 연결을 제공하는 CNI 플러그인의 설정을 바꿨고, 이 변경이 운영에만 있는 하드웨어 종류를 쓰는 클러스터에 배포됐다.

   원인

   설정 변경

   구성 요소

   CNI 플러그인

   기여 요인

   스테이징 불일치모니터링 사각지대

   감지

   엔지니어들은 네트워크 연결 문제임을 곧바로 알아봤지만, CNI 가 원인임을 밝히는 데 거의 한 시간이 걸렸다.

   조치

   • CNI 를 원인으로 찾은 뒤 수정을 적용해 트래픽의 80% 를 바로 되살렸다.
   • 이후 약 3시간에 걸쳐 모델을 GPU 에 다시 올려 용량을 완전히 안정시켰다.

   후속 조치

   • 스테이징 환경에 가능한 모든 하드웨어 구성을 갖춰 운영 환경과 더 가깝게 만든다.
   • CNI 시스템 자체의 상태를 직접 모니터링하고 알림을 걸어 장애가 더 잘 보이게 한다.
   • 모델 복제본을 빠르게 대량으로 배포하지 못하게 막는 네트워크와 스토리지 인프라의 병목을 고친다.

   교훈

   변경을 스테이징에서 충분히 시험해도, 운영에만 있는 하드웨어 종류가 스테이징에 없으면 문제를 잡지 못한다. 다른 클러스터에 24시간 동안 배포돼 안전하다고 본 변경도, 하드웨어가 다른 클러스터에서는 깨졌다.

   사례 보기

원인별1