IL-0399 Government Digital Service · 2016-12-15awsnetworking
AWS eu-west-1 의 EC2 DNS resolver 문제로 GOV.UK PaaS 와 그 위의 애플리케이션이 DNS 조회에 간헐적으로 실패했다
2016년 12월 15일 AWS eu-west-1 의 EC2 DNS resolver 에 문제가 생겼다. GOV.UK PaaS 의 많은 구성 요소와 작업은 DNS 조회가 제대로 돼야 동작한다. 그래서 PaaS 와 그 위의 애플리케이션이 DNS 조회에 간헐적으로 실패했고, 데이터베이스, 백엔드 서비스, API 에 연결하지 못했을 수 있다. 오류는 01:17 에 운영 계정 zone 3 의 VM 들에서 시작해 02:57 에 마지막으로 기록됐고, AWS 는 03:17 에 복구를 알렸다. 팀은 장애가 난 시각으로 보아, PaaS 를 쓰는 tenant 인 서비스 팀이 겪은 문제는 주로 예약해 둔 자동 작업에서 났을 것이라고 봤다.
그 무렵 팀은 PaaS 를 24시간 지원하지 않았다. 08:00 에 팀원이 경고를 보고 모니터링에서 영향이 끝났음을 확인했고, 11:06 에 플랫폼 사용자에게 알림 메일을 보냈다. 팀은 EC2 resolver 에 바로 질의하는 대신 로컬 DNS resolver 캐시를 두는 방안을 검토했다. 그러나 캐시에 없는 레코드는 여전히 실패했을 것이라고 보고 택하지 않았다. google 이나 OpenDNS 같은 resolver 를 더하는 방안도 검토했지만, 그 서비스들의 rate limiting 같은 동작이 새 문제를 부를 수 있다고 보고 택하지 않았다. 팀은 DNS 조회 장애가 또 나면 두 방안을 다시 검토하겠다고 했다. AWS 는 DNS 조회 서비스에 비슷한 문제가 다시 나지 않게 할 계획을 진행하고 있었다.
- 심각도
- –
- 영향 범위
- Applications on GOV.UK PaaS had intermittent DNS failures and could fail to reach databases, backend services and APIs; some end users would have seen intermittent slowness and errors
- 영향 사용자
- –
- 지역
- AWS eu-west-1, zone 3
- 감지까지
- 6h 43m
- 복구까지
- 2h
증상
2016년 12월 15일 새벽 GOV.UK PaaS 의 VM 에 DNS 조회 오류가 기록되기 시작했고, PaaS 에 배포한 애플리케이션이 DNS 조회에 간헐적으로 실패했다. 그 때문에 서비스가 데이터베이스, 백엔드 서비스, API 에 연결하지 못했을 수 있다. 01:00 부터 03:17 사이에 이 애플리케이션을 쓴 사용자는 간헐적인 느려짐과 오류를 봤을 수 있다.
첫 DNS 오류는 01:17 에 VM cell/4, cell/5, cell/8, consul/2, etcd/2 에 기록됐다. 모두 운영 계정에서 AWS zone 3 에 있는 VM 이었다. 대부분은 datadog 모니터링 주소의 이름을 해석하지 못한 오류였고, 10초마다 되풀이됐다. Datadog agent 는 지표를 보내지 못했다.
01:21 에 Pingdom 이 healthcheck 앱의 DB endpoint 에서 첫 오류를 잡았고, 이 endpoint 는 3분 동안 내려가 있었다. 이 endpoint 는 애플리케이션이 뒤의 데이터베이스에 연결되는지 확인한다. 01:24 부터 02:18 까지 1분에서 6분짜리 실패가 5번 더 있었다.
01:26 에 smoke test 의 CF API 작업 하나가 VM api/1 에서 UAA 주소의 이름을 해석하지 못해 실패했다. 같은 오류가 01:37, 01:42, 02:11, 02:21, 02:31, 02:46 에 6번 더 났다.
01:33 부터 Datadog 에서 앞의 VM 들의 디스크 모니터가 "no-data" 알림을 내기 시작했다. 02:58 까지 6개 호스트 cell/4, cell/5, cell/8, consul/2, elasticsearch_master/2, etcd/2 에서 Alert/Recover 이벤트가 68번 났다.
01:50 에 AWS 가 상태 페이지에 "We are investigating DNS resolution issues from some instances in the EU-WEST-1 Region." 이라고 올렸다. 02:52 에 VM 의 DNS 오류가 줄었고, 02:57 에 마지막 오류가 기록됐다. AWS 는 03:17 에 완전히 복구됐다고 알렸다.
원인
원인 클라우드 제공자 장애
- 촉발
- –
감지
장애가 난 시각에 팀은 PaaS 를 24시간 지원하지 않았다. 팀은 12월 15일 업무를 시작하면서 모니터링 알림이 나가 있던 것을 알아챘다. 08:00 에 팀원이 경고를 보고, 모니터링에서 영향이 끝났음을 확인했다.
조치
–
후속 조치
- 디스크 모니터링 데이터가 들어오지 않을 때는 모니터링 시스템이 메일을 보내지 않게 한다. 메일이 너무 많으면 다른 알림을 알아보기 어렵기 때문이다.
- 장애를 tenant 에게 더 쉽고 빠르게 알릴 수 있게 한다.
- 업무 시간 밖 지원에 쓸 알림을 곧 도입하고, 어떤 알림을 둘지는 이 장애를 예로 삼아 정한다.
- PaaS 를 쓰는 서비스의 필요에 맞춰 곧 24시간 지원을 시작한다.
교훈
–
출처
관련 사례
–
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0399
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0399/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.