사례4건

4건 중 1~4번째

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-0283 Cloudflare 네트워크 전체에서 코어 프록시가 Bot Management 피처 파일을 읽다 실패해 사이트 방문자들이 HTTP 5xx 오류 페이지를 받았다

   Cloudflare2025

   증상

   11:20 UTC 부터 Cloudflare 네트워크가 내보내는 HTTP 5xx 오류가 치솟았다. 고객 사이트를 찾은 인터넷 사용자들은 Cloudflare 네트워크 안에서 실패했다는 오류 페이지를 봤다.

   오류율 상승서비스 중단지연 시간 증가응답 품질 저하

   촉발

   11:05 UTC 에 Cloudflare 는 ClickHouse 사용자들이 암묵적으로 갖고 있던 r0 데이터베이스 하위 테이블 접근 권한을 명시적으로 주는 변경을 배포했다. Bot Management 피처 파일을 만드는 쿼리는 데이터베이스 이름으로 거르지 않았고, 이 변경 뒤 쿼리 결과에 중복 행이 섞이기 시작했다.

   원인

   설정 변경

   구성 요소

   데이터베이스CDN 과 엣지 네트워크

   기여 요인

   미검증 가정부분 배포단계적 배포 부재설정 테스트 부재장애 중첩재시도 폭주

   감지

   11:31 UTC 에 첫 자동 테스트가 문제를 감지했고, 11:32 에 수동 조사가 시작됐으며, 11:35 에 장애 대응 통화가 열렸다.

   조치

   • 13:05 UTC 에 Workers KV 와 Cloudflare Access 를 내부 우회 경로로 돌려 이전 버전의 코어 프록시를 쓰게 했다. 이전 버전에도 같은 문제가 있었지만 영향이 작았다.
   • 14:24 UTC 에 새 Bot Management 설정 파일의 자동 배포를 멈췄다.
   • 알려진 정상 피처 파일을 피처 파일 배포 큐에 손으로 넣었다.
   • 코어 프록시를 강제로 재시작했다. 14:30 UTC 에 주된 영향이 풀렸다.
   • 쌓인 로그인 시도와 재시도로 느려진 대시보드를 컨트롤 플레인 동시성을 늘려 15:30 UTC 무렵 되살렸다.
   • 나쁜 상태에 빠진 나머지 서비스들을 재시작했고, 17:06 UTC 에 5xx 오류량이 평소로 돌아왔다.

   후속 조치

   • Cloudflare 가 직접 만든 설정 파일도 사용자 입력처럼 엄격하게 검증한 뒤 받아들인다.
   • 기능을 네트워크 전체에서 끌 수 있는 킬 스위치를 더 늘린다.
   • 코어 덤프나 다른 오류 보고가 시스템 자원을 다 써 버리지 못하게 한다.
   • 모든 코어 프록시 모듈이 오류가 났을 때 어떻게 실패하는지 검토한다.

   사례 보기
3. IL-0339 Azure Front Door 와 Azure CDN 을 쓰는 Microsoft 서비스에 여러 리전에서 연결 오류, 타임아웃, 지연 급증이 났다

   Microsoft Azure2024

   증상

   2024년 7월 30일 11시 45분 UTC 부터 Azure Front Door 와 Azure CDN 을 거치는 Microsoft 서비스에 접속하던 일부 고객이 간헐적인 연결 오류, 타임아웃, 지연 급증을 겪었다. 11시 47분에 Azure Portal 팀이 먼저 서비스 성능 저하를 알아챘다.

   간헐적 연결 실패간헐적 타임아웃지연 시간 증가패킷 손실

   촉발

   Azure 네트워크 DDoS 보호 서비스가 TCP SYN flood DDoS 공격을 자동으로 막은 뒤 트래픽을 Azure Front Door 로 직접 돌려보내려 했다. 그런데 유럽의 한 사이트에서는 지역 정전으로 네트워크 컨트롤 플레인이 실패해 그 사이트의 경로를 바꾸지 못했다.

   원인

   설정 변경

   구성 요소

   CDN 과 엣지 네트워크DDoS 방어 서비스네트워크 컨트롤 플레인데이터센터 전력·냉각

   기여 요인

   장애 중첩과도한 영향 범위모니터링 사각지대

   감지

   장애가 시작되고 2분 뒤인 11시 47분 UTC 에 Azure Portal 팀이 서비스 성능 저하를 알아채고 조사를 시작했다. 12시 10분에 네트워크 모니터링이 이 포털 장애를 유럽의 한 사이트에서 난 네트워크 문제와 연결 지었다.

   조치

   • 12시 55분 UTC 에 국지적인 혼잡을 확인하고, 트래픽 경로 변경을 포함한 혼잡 완화용 표준 플레이북을 실행했다. 13시 58분에 영향 대부분이 사라졌다.
   • 16시 58분, 네트워크 컨트롤 플레인이 명령을 다시 내리게 했지만 문제의 장비에는 명령이 닿지 않았다.
   • 17시 50분부터 문제의 장비를 네트워크에서 안전하게 빼면서 다른 문제가 없는지 네트워크를 훑었다. 장비는 19시 32분에 다 뺐다.

   후속 조치

   • 한 지역의 DDoS 완화 문제가 다른 지역으로 번지지 않도록, 네트워크 장비에 빠져 있던 설정을 넣었다. 이 일은 끝났다.
   • 잘못된 설정을 찾아내도록 Azure 네트워크의 기존 검증과 모니터링을 강화한다. 2024년 11월에 끝낼 예정이다.
   • DDoS 보호 서비스가 컨트롤 플레인에서 닿지 않는데도 트래픽을 계속 받는 상황을 잡아내도록 모니터링을 개선한다. 2024년 11월에 끝낼 예정이다.

   사례 보기
4. IL-0363 static.crates.io 의 DNS 레코드가 10~15분 동안 해석되지 않아 crate 를 받지 못했다

   Rust Project2023

   증상

   2023-01-25 09:15 UTC 에 crates.io 운영 인프라에 변경을 배포하는 동안 static.crates.io 의 DNS 레코드가 해석되지 않았다. 사용자는 crate 를 내려받지 못해 빌드가 실패했다.

   DNS 조회 실패

   촉발

   Rust 인프라 팀이 Terraform 으로 운영 환경에 현재 CDN 의 새 TLS 인증서와 바뀐 DNS 레코드를 함께 배포했다. Terraform 은 기존 인증서와 DNS 레코드를 먼저 지운 뒤 새 인증서를 발급했다.

   원인

   설정 변경

   구성 요소

   TerraformDNS 서버와 레코드CDN 과 엣지 네트워크

   기여 요인

   파괴적 변경 보호 장치 부재스테이징 불일치

   조치

   • Terraform 이 배포를 마치고 static.crates.io 의 새 DNS 레코드를 만들자 장애가 저절로 풀렸다.

   후속 조치

   • 운영에 변경을 배포하는 절차, 특히 Git 커밋을 고르는 방법과 변경 내역을 검토하는 방법을 문서로 남긴다. 절차를 정해 두고 계속 고쳐 나가 같은 문제를 피한다.
   • 스테이징에서 따로 만들고 시험한 변경은 운영에도 하나씩 차례대로 배포하고, 이 규칙을 문서에 넣는다.
   • main 브랜치에 병합한 변경은 운영에도 반드시 배포해, Git 에 있는 구성과 실제로 배포된 것이 벌어지지 않게 한다.

   교훈

   TLS 인증서 변경과 DNS 레코드 변경을 따로 배포했다면 이번 장애를 피할 수 있었다. 운영 환경을 master 의 최신 커밋에 고정하면서 여러 변경이 한꺼번에 들어갔고, 병합한 변경을 그때그때 배포하지 않아 운영과 스테이징이 너무 벌어졌다. 팀이 얻은 교훈은 세 가지다. 배포 절차를 문서로 정해야 한다. 스테이징에서 따로 시험한 변경은 운영에도 하나씩 차례로 배포해야 한다. 병합한 변경은 운영에도 배포해야 한다.

   사례 보기

원인별1