사례2건
2건 중 1~2번째
- 증상
미국과 국제 리전의 고객이 Zoom 서비스에 접속하지 못했다. Zoom 은 zoom.us 도메인의 이름 해석이 실패하는 문제를 조사하기 시작했다.
- 촉발
도메인 등록기관 Markmonitor 와 GoDaddy Registry 사이에 소통 오류가 생겼고, 그 결과 GoDaddy Registry 가 zoom.us 도메인에 server block 을 걸어 도메인을 잘못 내렸다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 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 와 함께 같은 일이 다시 나지 않도록 기술 변경과 절차를 추가로 도입했다.
- 증상
04시 34분에 모니터링 시스템이 첫 노드의 DNS 이름 해석 문제를 잡아 pager duty 알림을 울렸다. 첫 노드가 DNS 레코드를 해석하지 못하면서 인프라 전체의 가용성에 영향이 갔다.
- 촉발
Octez Connect 가 쓰는 하나뿐인 DNS 공급사 MetaNet 에서 장애가 났다. 공급사의 긴급 전화, 상태 페이지, 티켓 시스템도 함께 멈췄다.
- 원인
- 구성 요소
- 기여 요인
- 감지
04시 34분에 모니터링 시스템이 DNS 이름 해석 문제를 잡았다. 첫 노드가 DNS 를 해석하지 못해 pager duty 알림이 울렸다.
- 조치
- 04시 34분에 DNS 이름 해석 문제를 감지하고 pager duty 호출을 걸었다.
- 공급사의 긴급 전화를 계속 걸고 상태 페이지를 지켜보며 공급사에 광범위한 장애가 났음을 확인했다.
- 08시 20분에 [email protected] 에서 공급사가 문제를 살펴보고 있다는 답을 받았다.
- 08시 30분에 시험해서 DNS 가 다시 돌기 시작한 것을 확인했다.
- 08시 40분에 Slack 과 Twitter 에 복구를 알리는 공개 공지를 올렸다.
- 후속 조치
- DNS 공급사를 둘로 쓰는 구성을 만든다.
- 장애 정보를 실시간으로 알리는 공개 상태 페이지를 만든다.
- 외부 공급사 장애 때의 내부 에스컬레이션 절차를 다시 살피고 고친다.
- 교훈
DNS 공급사 하나에만 기대면 그 공급사가 단일 장애 지점이 되어 연결된 서비스가 모두 멈출 수 있다. 이번 DNS 장애는 가용성만이 아니라 공급사와의 소통도 늦춰 중단을 키웠다. 몇 시간 안에 복구됐지만, 공급사 하나가 장애를 겪어도 서비스가 계속 돌도록 DNS 공급사를 둘로 두어야 한다.
이 2건에서 가장 많이 나오는 구성 요소: DNS 서버와 레코드. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.