사례11건

11건 중 4~8번째

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-0348 FR-PAR 리전의 모든 제품에서 공용 인터넷 연결이 끊기고 여러 제품이 오래 불안정했다

   Scaleway2025

   증상

   2025-03-10 16:23 UTC 무렵 FR-PAR 리전의 모든 제품에서 공용 인터넷 연결이 크게 흔들렸다. 인터넷 트래픽 대부분이 사실상 버려졌고, FR-PAR-2 가용 영역과 나머지 PAR 리전 사이의 공용 인터넷 연결이 심하게 끊겼다.

   패킷 손실서비스 중단지연 시간 증가

   촉발

   Scaleway 네트워크 팀이 FR-PAR 리전 백본에 새 데이터 센터를 붙이던 중 라우터 구성을 잘못 넣었다. 이 실수로 OpCore DC3 와 DC5 사이의 1Tbps 넘는 트래픽이 100Gbps 링크 하나로 돌아갔다.

   원인

   운영 실수

   구성 요소

   백본망오브젝트 스토리지DNS 서버와 레코드

   기여 요인

   자동화 증폭

   감지

   라우터 구성 실수는 빨리 발견되어 4분 안에 롤백됐다.

   조치

   • 잘못 넣은 라우터 구성을 4분 안에 롤백해 16:27 UTC 에 올바른 구성을 되돌렸다.

   후속 조치

   • 변경 관리를 고쳐 동료 검토와 운영 공지 절차를 강화한다.
   • 백본 수준의 네트워크 구성을 적용하기 전에 안전장치와 시험을 더 거치도록 운영 절차를 고친다.
   • Object Storage 동기화 소프트웨어의 문제를 찾아 수정을 만들고 시험했으며, 이 수정을 배포하고 있다.

   사례 보기
3. IL-0269 하나뿐인 DNS 공급사가 장애를 일으켜 Octez Connect 의 모든 노드에서 이름 해석이 실패하고 서비스가 몇 시간 멈췄다

   Octez Connect2025

   증상

   04시 34분에 모니터링 시스템이 첫 노드의 DNS 이름 해석 문제를 잡아 pager duty 알림을 울렸다. 첫 노드가 DNS 레코드를 해석하지 못하면서 인프라 전체의 가용성에 영향이 갔다.

   DNS 조회 실패서비스 중단

   촉발

   Octez Connect 가 쓰는 하나뿐인 DNS 공급사 MetaNet 에서 장애가 났다. 공급사의 긴급 전화, 상태 페이지, 티켓 시스템도 함께 멈췄다.

   원인

   의존성 장애

   구성 요소

   DNS 서버와 레코드

   기여 요인

   단일 장애점디버그 접근 제한

   감지

   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 공급사를 둘로 두어야 한다.

   사례 보기
4. IL-0531 West US 의 Azure Database for MySQL Single Server 와 MariaDB 일부 서버로 가는 새 연결이 모두 거부됐다

   Microsoft Azure2024

   증상

   West US 리전에서 Azure Database for MySQL - Single Server 와 Azure Database for MariaDB 의 일부 고객은 데이터베이스로 가는 연결이 모두 실패했고, 재시도해도 성공하지 못했다. 데이터베이스 자체는 정상이었지만 연결이 하나도 맺어지지 않았다.

   서비스 중단간헐적 타임아웃

   촉발

   계획된 게이트웨이 하드웨어 교체 작업에서 2024-04-19 04:26 UTC 에 Azure Database for MySQL 과 MariaDB 서버 한 묶음의 DNS 를 바꿨다. 절차상의 실수로 새 연결이 설정이 덜 끝난 새 게이트웨이 링으로 보내졌다.

   원인

   운영 실수

   구성 요소

   데이터베이스DNS 서버와 레코드

   기여 요인

   모니터링 사각지대

   감지

   새 게이트웨이 링에 텔레메트리와 모니터링이 없어 서비스 텔레메트리는 실패를 잡지 못했다. MySQL 팀은 04:46 UTC 에 Azure Databricks 가 여러 데이터베이스에 닿을 수 없다고 알려 와서 장애를 알았다.

   조치

   • 07:30 UTC 에 변경을 완전히 롤백했고, 검증을 거쳐 모든 연결을 정상 동작하던 이전 게이트웨이 링으로 되돌렸다.

   후속 조치

   • MySQL 엔지니어링 팀은 운영 게이트웨이 링을 전환하기 전에 점검, 테스트, 승인 절차를 더한다. 2024년 5월에 마칠 예정이다.
   • Azure Databricks 엔지니어링 팀은 짧은 시간 안에 여러 데이터베이스를 쓸 수 없게 되는 상황을 잡는 알림을 만든다. 2024년 5월에 마칠 예정이다.

   사례 보기
5. 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