사례1건

1건 중 1~1번째

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

   사례 보기

원인별1