사례3건

3건 중 1~3번째

1. IL-0260 zoom.us 도메인이 레지스트리에서 차단되어 DNS 조회가 실패하고 Zoom 서비스에 접속할 수 없었다

   Zoom2025

   증상

   미국과 국제 리전의 고객이 Zoom 서비스에 접속하지 못했다. Zoom 은 zoom.us 도메인의 이름 해석이 실패하는 문제를 조사하기 시작했다.

   DNS 조회 실패서비스 중단

   촉발

   도메인 등록기관 Markmonitor 와 GoDaddy Registry 사이에 소통 오류가 생겼고, 그 결과 GoDaddy Registry 가 zoom.us 도메인에 server block 을 걸어 도메인을 잘못 내렸다.

   원인

   의존성 장애

   구성 요소

   DNS 서버와 레코드

   기여 요인

   파괴적 변경 보호 장치 부재

   조치

   • Zoom, Markmonitor, GoDaddy 가 함께 server block 을 찾아 풀었고, zoom.us 도메인 서비스가 되살아났다.
   • 복구 뒤에도 접속 문제가 남은 사용자에게 DNS 캐시를 비우고 다시 접속하라고 안내했다. Windows 에서는 명령 프롬프트에서 "ipconfig /flushdns" 를, Mac 에서는 터미널에서 "sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder" 를 실행하게 했다.

   후속 조치

   • GoDaddy Registry 와 Markmonitor 는 zoom.us 도메인에 server block 명령을 걸지 못하게 막는 registry lock 을 걸었다.
   • Zoom 은 GoDaddy Registry, Markmonitor 와 함께 같은 일이 다시 나지 않도록 기술 변경과 절차를 추가로 도입했다.

   사례 보기
2. 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 의 최신 커밋에 고정하면서 여러 변경이 한꺼번에 들어갔고, 병합한 변경을 그때그때 배포하지 않아 운영과 스테이징이 너무 벌어졌다. 팀이 얻은 교훈은 세 가지다. 배포 절차를 문서로 정해야 한다. 스테이징에서 따로 시험한 변경은 운영에도 하나씩 차례로 배포해야 한다. 병합한 변경은 운영에도 배포해야 한다.

   사례 보기
3. IL-0389 AWS 서울 리전에서 EC2 DNS 확인 서버군의 정상 호스트가 줄어 EC2 인스턴스 안의 DNS 쿼리가 실패했다

   Amazon Web Services2018

   증상

   2018년 11월 22일 한국 시간 오전 8시 19분부터 서울 리전 AP-NORTHEAST-2 에서 고객 EC2 인스턴스 안의 DNS 쿼리가 실패하기 시작했다. AWS 엔지니어링 팀은 8시 21분에 이 DNS 확인 문제를 알림으로 받았다.

   DNS 조회 실패

   촉발

   설정 업데이트가 서울 리전 EC2 DNS 확인 서버군의 최소 정상 호스트 수를 지정하는 설정을 잘못 지웠다.

   원인

   설정 변경

   구성 요소

   VPC DNS 리졸버

   기여 요인

   설정 테스트 부재파괴적 변경 보호 장치 부재

   감지

   한국 시간 오전 8시 21분에 엔지니어링 팀이 서울 리전의 DNS 확인 문제를 알림으로 받았다.

   조치

   • 정상 호스트가 서비스에서 더 빠지지 않게 막아 영향이 더 커지지 않게 했다. 이 작업에 15분이 걸렸다.
   • EC2 DNS 확인 서버군의 용량을 이전 수준으로 되돌렸다. 복구 시간 대부분이 이 작업에 들었고, 한국 시간 오전 9시 43분에 완전히 복구됐다.

   후속 조치

   • 모든 AWS 리전의 EC2 DNS 확인 서비스에 올바른 용량 설정이 들어 있는지 바로 확인했다.
   • 모든 리전이 늘 충분한 최소 정상 호스트를 갖도록, EC2 DNS 확인 서버군의 설정 업데이트마다 설정 값의 의미까지 확인하는 검증을 넣는다.
   • 서비스에서 시간당 뺄 수 있는 정상 호스트 용량을 제한하는 스로틀링을 더한다. 잘못된 설정 값이 들어와도 EC2 DNS 확인 서버군의 용량이 줄지 않게 하려는 것이다.

   사례 보기

원인별2