사례2건

2건 중 1~2번째

1. IL-0398 GOV.UK 가 쓰는 주 CDN 에 전 세계 장애가 나서, 1시간이 안 되는 동안 GOV.UK 방문자가 오류 페이지만 봤다

   Government Digital Service2021

   증상

   2021년 6월 8일 1시간이 안 되는 동안 GOV.UK 방문자가 정보와 서비스에 접근하지 못하고 오류 페이지를 봤다. 팀은 장애가 시작되고 4분 뒤에 알아챘다.

   서비스 중단

   원인

   의존성 장애

   구성 요소

   CDN 과 엣지 네트워크

   기여 요인

   –

   감지

   장애는 시작되고 4분 뒤에 감지됐다. 팀은 장애 책임자를 정했고, 장애 책임자는 커뮤니케이션 책임자와 함께 공식 장애 대응 절차를 시작했다.

   조치

   • 감지하고 15분이 지나도 상태가 바뀌지 않자 보조 CDN 으로 페일오버하기로 했다.
   • 30분 안에 DNS 레코드 변경을 배포했고, 트래픽이 보조 CDN 으로 가기 시작했다.
   • 주 CDN 이 회복되는 것을 몇 분 지켜본 뒤 주 CDN 으로 되돌렸고, 1시간을 더 지켜본 뒤 장애 종료를 선언했다.

   후속 조치

   • 공식 장애 리뷰를 열어 무슨 일이 있었는지, 대응이 어땠는지, 다음에 더 잘하려면 무엇을 해야 하는지 논의한다.
   • 장애 중에 더 빠르고 투명하게 소통할 방법을 검토한다.
   • 이미 계획한 플랫폼 기술과 절차의 변경으로 앞으로 장애가 났을 때 더 빨리 복구할 수 있는 방법을 검토한다.

   교훈

   어떤 인프라도 100% 믿을 수는 없고, 네트워크 엣지에 있는 CDN 이 망가지면 사이트 전체가 내려가므로 예비 계획이 있어야 한다고 팀은 말했다. 보조 CDN 으로는 기능이 줄어든 서비스만 할 수 있어서 페일오버는 큰 결정이고, 주 CDN 장애가 빨리 끝나면 너무 이른 페일오버가 오히려 장애를 키울 수 있다고 했다. 이런 장애에서는 침착하게, 목적을 분명히 하고 움직이는 것이 중요하다고 했다. 방문자가 본 오류 페이지는 GOV.UK 가 손댈 수 없는 페이지였고, 아무 정보도 주지 못해 GOV.UK 의 콘텐츠 기준에 크게 못 미쳤다고 했다.

   사례 보기
2. IL-0399 AWS eu-west-1 의 EC2 DNS resolver 문제로 GOV.UK PaaS 와 그 위의 애플리케이션이 DNS 조회에 간헐적으로 실패했다

   Government Digital Service2016

   증상

   2016년 12월 15일 새벽 GOV.UK PaaS 의 VM 에 DNS 조회 오류가 기록되기 시작했고, PaaS 에 배포한 애플리케이션이 DNS 조회에 간헐적으로 실패했다. 그 때문에 서비스가 데이터베이스, 백엔드 서비스, API 에 연결하지 못했을 수 있다. 01:00 부터 03:17 사이에 이 애플리케이션을 쓴 사용자는 간헐적인 느려짐과 오류를 봤을 수 있다.

   DNS 조회 실패간헐적 연결 실패모니터링 중단

   원인

   클라우드 제공자 장애

   구성 요소

   VPC DNS 리졸버

   기여 요인

   잡음에 묻힌 신호

   감지

   장애가 난 시각에 팀은 PaaS 를 24시간 지원하지 않았다. 팀은 12월 15일 업무를 시작하면서 모니터링 알림이 나가 있던 것을 알아챘다. 08:00 에 팀원이 경고를 보고, 모니터링에서 영향이 끝났음을 확인했다.

   후속 조치

   • 디스크 모니터링 데이터가 들어오지 않을 때는 모니터링 시스템이 메일을 보내지 않게 한다. 메일이 너무 많으면 다른 알림을 알아보기 어렵기 때문이다.
   • 장애를 tenant 에게 더 쉽고 빠르게 알릴 수 있게 한다.
   • 업무 시간 밖 지원에 쓸 알림을 곧 도입하고, 어떤 알림을 둘지는 이 장애를 예로 삼아 정한다.
   • PaaS 를 쓰는 서비스의 필요에 맞춰 곧 24시간 지원을 시작한다.

   사례 보기

원인별2