사례6건

6건 중 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-0502 새 와일드카드 DNS 레코드 때문에 temple.2i2c.cloud 가 조회되지 않아 JupyterHub 에 접속할 수 없었다

   2i2c2025

   증상

   temple.2i2c.cloud 의 JupyterHub 에 접속할 수 없었고 업타임 체크 경보가 울렸다. 커뮤니티가 데모를 하기 직전이었다.

   DNS 조회 실패서비스 중단

   촉발

   Temple 의 새 클러스터를 준비하면서 *.temple.2i2c.cloud 와일드카드 레코드를 더해 새 클러스터의 Ingress IP 를 가리키게 했다.

   원인

   설정 변경

   구성 요소

   DNS 서버와 레코드

   기여 요인

   미검증 가정캐시로 가려진 장애기본 설정 방치

   감지

   오전 10:02 에 Google Cloud 의 업타임 체크 경보가 PagerDuty 로 울렸다. 커뮤니티 신고는 그 뒤인 오전 10:09 에 들어왔다.

   조치

   • NameCheap DNS 에 temple.2i2c.cloud 의 A 레코드를 따로 더했다.
   • 기본값이 30분이던 DNS TTL 을 5분으로 바꿨다. 데모가 임박해서 해 본 조치였고, 전파 속도에 실제 효과가 있었는지는 분명하지 않았다.
   • 데모를 하려는 커뮤니티 사용자에게 /etc/hosts 항목을 넣는 우회책을 안내했다.

   후속 조치

   • 팀원 모두가 Namecheap 에 들어갈 수 있게 권한을 고친다. 그럴 수 없으면 DNS 사업자를 옮긴다.
   • 새로 만드는 모든 DNS 레코드의 TTL 을 30분이 아니라 5분으로 둔다.
   • *.X.2i2c.cloud 레코드를 더할 때는 X.2i2c.cloud 레코드도 반드시 같이 더해야 한다고 문서에 적는다.

   교훈

   자동 경보가 커뮤니티 신고보다 먼저 문제를 잡았다. 새 클러스터를 준비한 엔지니어가 DNS 를 관리하는 Namecheap 에 권한이 없어서 다른 사람에게 부탁해 레코드를 만들었다. Namecheap 의 기본 TTL 이 30분이라 고친 값이 전파되는 데 그만큼 걸릴 수 있었다. 2i2c 는 장애가 데모 도중이 아니라 데모 전에 났고, DNS 를 고칠 권한이 있는 사람이 마침 자리에 있었던 것이 운이 좋았다고 적었다.

   사례 보기
3. IL-0533 Azure China 의 핵심 시스템 도메인 chinacloudapp.cn 과 chinacloudsites.cn 의 이름 해석이 실패해 여러 서비스에 연결할 수 없었다

   Microsoft Azure2024

   증상

   Azure China 리전에서 고객이 여러 Azure 서비스에 연결하지 못했다. Azure Portal 인 portal.azure.cn 과 API 로도 리소스를 보거나 관리하기 어려웠다. chinacloudapp.cn 과 chinacloudsites.cn 도메인 안의 FQDN 을 해석하지 못한 것이 원인이었다.

   DNS 조회 실패오류율 상승모니터링 중단

   촉발

   도메인 등록 기관을 거친 설정 변경으로 2024-04-23 03:45 CST 에 chinacloudapp.cn 과 chinacloudsites.cn 의 네임서버가 비활성 서버 묶음으로 바뀌었다.

   원인

   설정 변경

   구성 요소

   DNS 서버와 레코드

   기여 요인

   미검증 가정캐시로 가려진 장애

   감지

   04:37 CST 에 내부 모니터가 Azure China Cloud 의 서비스 저하를 알리고 인시던트를 만들었다. 04:39 CST 에 엔지니어링 팀이 인시던트를 확인했다.

   조치

   • 04:59 CST 에 두 도메인의 네임서버를 이전의 정상 네임서버로 되돌렸고, 05:13 CST 에 되돌리기를 마쳤다.

   후속 조치

   • Azure China 의 관리 도구의 수정이 끝날 때까지 이 도메인 수명 주기 절차의 실행을 모두 멈췄다.
   • 도메인 수명 주기 관리의 검증 절차를 고쳐 모든 클라우드 리전의 신호가 들어가게 한다. 2024년 6월에 마칠 예정이다.
   • 인터넷에서 영역을 직접 조회해 네임서버 정보를 얻는 검증을 더한다. 2024년 7월에 마칠 예정이다.

   사례 보기
4. IL-0254 내부 DNS 서버가 무너져 Square 의 제품과 서비스가 약 15시간 멈추고 결제가 되지 않았다

   Square2023

   증상

   2023년 9월 7일 오후 1:54 ET 부터 Square 의 제품과 서비스를 쓸 수 없었다. 오후 2:02 ET 에 엔지니어들이 인프라 문제 알림을 받고 DNS 부터 조사하기 시작했다.

   DNS 조회 실패서비스 중단

   촉발

   Square 는 2023년 9월 7일 오전 11:04 ET 에 리전 간 통신을 열려고 호스트 방화벽 규칙 변경을 배포했고, 오후 1:56 ET 에는 DNS 영역 변경이 있었다. 작은 정책 변경이 노드에서 훨씬 큰 규칙 묶음으로 펼쳐졌다.

   원인

   설정 변경

   구성 요소

   DNS 서버와 레코드노드 iptables 규칙

   기여 요인

   단계적 배포 부재캐시로 가려진 장애순환 의존

   감지

   오후 2:02 ET 에 엔지니어들이 인프라 문제 알림을 받았다. 장애가 시작되고 8분 뒤였다.

   조치

   • DNS 서버로 가는 네트워크 트래픽을 덜고, 새 DNS 서버를 손으로 띄우기 시작했다.
   • 인증과 접근 서비스를 되살리려고 네트워크 변경을 손으로 배포했다.
   • 모든 데이터센터에 네트워크 변경을 손으로 배포했다.
   • DNS 서버를 다시 만들었다.
   • 되돌린 방화벽 규칙 묶음으로 새 설정을 만들어 DNS 호스트에 내보냈다.

   후속 조치

   • DNS 인프라를 격리된 인프라로 옮긴다.
   • 핵심 네트워크 인프라에 모니터링과 최적화를 더한다.
   • 가능한 곳에서 배포 인프라와 플랫폼 인프라 사이의 의존 관계를 최적화한다.
   • 오프라인 모드 지원을 넓히고, 오프라인 모드를 쓸 수 있는지 판매자에게 더 잘 알린다.

   사례 보기
5. IL-0549 Atlassian 의 us-west-1 리전에서 미디어, 첨부 파일, Git LFS, 빌드 아티팩트의 저장과 조회가 실패했다

   Atlassian2023

   증상

   2023년 5월 15일 02:36 UTC 부터 us-west-1 리전에 서비스를 둔 Atlassian 고객에게 미디어, 첨부 파일, 빌드 아티팩트 같은 데이터 자산의 저장과 조회가 실패했다. 자동 모니터링이 3분 안에 감지했다.

   오류율 상승오래된 엔드포인트 라우팅

   촉발

   네트워크 세그먼트 사이의 분리를 강화해 보안을 높이는 작업의 하나로 내부 서비스를 새 네트워크 세그먼트로 옮겼다.

   원인

   설정 변경

   구성 요소

   DNS 서버와 레코드

   기여 요인

   미검증 가정스테이징 불일치

   감지

   자동 모니터링이 3분 안에 감지했다.

   조치

   • 네트워크 이전 변경을 롤백해 Atlassian 시스템을 정상이던 상태로 되돌렸다.

   후속 조치

   • 서비스 스택을 내리는 시스템을 검토하고, 스택을 내리기 전에 그 스택이 더는 고객 트래픽을 받지 않는지 확인하는 검사를 넣는다.
   • 서비스 네트워크 이전 절차에 함께 손봐야 할 DNS 레코드가 있는지 찾는 단계를 더한다.

   교훈

   Atlassian 은 기존 테스트와 예방 절차가 이 문제를 잡지 못했다고 밝혔다. 서비스를 네트워크 세그먼트 사이로 옮기는 일은 자주 하는 작업이 아니고, 테스트 환경에서 정확히 재현하기도 어렵기 때문이라고 설명했다. 이런 문제를 막으려고 블루/그린 배포 방식을 썼지만, 옛 스택을 내리기 전에 충분한 검증 단계를 돌리지 않았다고 적었다.

   사례 보기

원인별1