IL-0269 Octez Connect · 2025-02-05networking
하나뿐인 DNS 공급사가 장애를 일으켜 Octez Connect 의 모든 노드에서 이름 해석이 실패하고 서비스가 몇 시간 멈췄다
2025년 2월 5일 04시 34분에 첫 노드에서 DNS 이름 해석 문제가 나서 pager duty 알림이 울렸다. Octez Connect 의 인프라는 DNS 공급사 하나에만 기대고 있었고, 바로 넘길 대안이 없어서 이 공급사를 쓰는 모든 서버가 내려갔다. 사용자는 공급사가 기능을 되살릴 때까지 서비스를 쓸 수 없었다.
담당 엔지니어가 04시 40분에 조사를 시작했고, 04시 52분에 DNS 공급사가 장애를 겪고 있음을 확인했다. 공급사의 긴급 전화는 응답이 없었고, 상태 페이지는 내려가 있었으며, 티켓 시스템도 응답하지 않았다. 05시 10분에 [email protected] 로 메일을 보냈지만 자동 응답도 오지 않았다. 팀은 긴급 전화를 계속 걸고 상태 페이지를 지켜보며 다른 방법을 찾았다. 08시 20분에 공급사가 메일로 문제를 살펴보고 있다고 답했다. 08시 30분에 시험해서 모든 노드의 DNS 이름 해석이 정상으로 돌아온 것을 확인했고, 08시 40분에 Slack 과 Twitter 에 복구를 알렸다.
- 심각도
- –
- 영향 범위
- all servers relying on the DNS provider; users could not access the services
- 영향 사용자
- users of the Octez Connect services
- 지역
- –
- 감지까지
- 0m
- 복구까지
- 3h 56m
증상
04시 34분에 모니터링 시스템이 첫 노드의 DNS 이름 해석 문제를 잡아 pager duty 알림을 울렸다. 첫 노드가 DNS 레코드를 해석하지 못하면서 인프라 전체의 가용성에 영향이 갔다.
이 DNS 공급사에 기대는 서버가 모두 내려갔다. 사용자는 DNS 공급사가 기능을 되살릴 때까지 서비스를 쓸 수 없었다. DNS 공급사가 하나뿐이라 대신 쓸 곳이 없어서 장애가 모든 노드로 번졌다.
팀은 04시 50분에 1차 진단으로 DNS 문제라고 보고 공급사에 연락했다. 04시 52분에는 공급사가 장애를 겪고 있음을 확인했다. 공급사와 닿을 길은 거의 다 막혀 있었다. 04시 55분에 건 긴급 전화는 응답이 없었다. 05시 00분에는 공급사의 상태 페이지가 내려가 있었고, 05시 05분에는 티켓 시스템도 응답하지 않았다. 05시 10분에 [email protected] 로 보낸 메일에는 자동 응답도 오지 않아 장애 상황을 파악하기가 늦어졌다. 팀은 05시 20분부터 다른 해결 방법을 찾아봤다.
원인
원인 의존성 장애
- 촉발
- 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 공급사를 둘로 두어야 한다.
출처
관련 사례
같은 원인 · 공통 DNS 서버와 레코드
같은 원인 · 공통 DNS 서버와 레코드
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0269
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0269/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.