사례11건

11건 중 6~10번째

1. IL-0255 데이터센터 사이 메트로 회선이 잠깐 끊긴 뒤 Redis 레플리카가 재동기화 루프에 빠져 BC3 가 느려지고 채팅이 멈췄다

   37signals2020

   증상

   2020년 8월 28일 금요일 11:59AM CDT 에 PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. 모니터링에는 새 메트로 회선이 20~30초쯤 끊긴 것이 보였고, 네트워크가 돌아온 뒤에도 BC3 응답이 계속 느렸다.

   링크 플래핑지연 시간 증가복제 지연

   촉발

   2020년 8월 28일 11:59AM CDT 에 Ashburn 의 주 데이터센터와 Chicago 데이터센터를 잇는 이중 메트로 회선이 짧게 끊겼다. 모니터링에는 새 회선이 20~30초 끊긴 것만 보였지만, 로그에서는 두 회선이 모두 잠깐씩 끊긴 것이 드러났다.

   원인

   의존성 장애

   구성 요소

   백본망BGP 라우팅인메모리 캐시데이터베이스 복제

   기여 요인

   단일 장애점재시도 폭주잡음에 묻힌 신호

   감지

   PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. Redis 문제는 상황이 진정된 뒤 Redis DB 인스턴스 하나에 계속 떠 있던 알림을 보고 찾았다.

   조치

   • 로드 밸런서 계층에서 채팅을 꺼 나머지 BC3 를 안정시켰다.
   • 레플리카의 Redis 를 재시작했다.

   후속 조치

   • 알려진 Redis 문제의 문서화된 우회 방법대로 Redis 서버의 설정을 바꾼다.
   • 두 메트로 회선이 펜실베이니아에서 같은 물리 경로를 지나는 문제를 없앨 구체적인 계획을 세운다.
   • 장애 조치 시스템을 최대 부하 때 운영 환경에서 직접 검증한다.
   • 사고 후속 조치를 할 시간을 명시적으로 비우고, 우선순위를 밝혀 다른 일을 뒤로 미룬다.

   교훈

   이중화를 계획하고 실제 시험을 늘려 왔지만 충분하지 않았고, 특히 최대 부하에서는 안전하다는 착각을 하고 있었다. 데이터센터 사이로 부하를 옮기거나 이중 회선 사이를 오가는 일은 문제없이 돼야 한다. 그렇지 않다면 팀 전체가 준비된 통제된 상황에서 그 사실을 알아야 한다. 장애에서 나온 후속 조치는 목록에 더하는 데서 그치지 말고 더 급하게 처리해야 한다.

   사례 보기
2. IL-0359 Gandi LiveDNS 노드 두 대가 멈춰 그 노드로 간 DNS 질의가 타임아웃됐다

   Gandi2020

   증상

   2020-07-16 13:26 UTC 부터 Gandi LiveDNS 의 DNS 노드 두 대로 간 질의가 타임아웃으로 실패했다. 상태 페이지에는 13:26 에 FR 고객에게 영향이 있다는 글이 올라갔다.

   DNS 조회 실패

   촉발

   LiveDNS 노드 두 대의 DNS 서버 소프트웨어에서 버그가 장애를 일으켜 서버가 멈췄다.

   원인

   소프트웨어 결함

   구성 요소

   DNS 서버와 레코드BGP 라우팅

   기여 요인

   단일 장애점잡음에 묻힌 신호장애 중첩

   감지

   DNS 서버에서 LiveDNS 모니터링 알림이 울렸다. 그러나 앞서 다루던 내부 네트워크 사고가 모니터링 시스템에 소음을 많이 만들고 있어 엔지니어들은 이 알림을 오탐으로 잘못 읽었고, 알림을 다시 판단하기까지 시간이 걸렸다.

   후속 조치

   • DNS 서버가 제대로 동작하지 않을 때 노드를 서비스에서 빼는 방식을 고친다.
   • 노드 설정을 고치고, 한 노드가 여러 클러스터의 주소를 알리지 않는지 확인하는 모니터링을 둔다.
   • 모니터링과 내부 교육, 조직 운영을 다시 짠다.
   • DNS 서버 소프트웨어의 버그를 찾아냈고, 고친 판을 배포하고 있다.

   사례 보기
3. IL-0365 ALB 의 인스턴스 연결이 모두 사라져 Hellman 쿠버네티스 클러스터의 모든 서비스가 외부에서 닿지 않았다

   DFDS2020

   증상

   2020-06-09 12:25 CET 에 CloudWatch 알림이 두 ALB 의 5XX 수가 높다고 알렸다. 12:28 에 인그레스 트래픽이 전혀 들어오지 않는 문제를 감지하고 확인했다.

   서비스 중단

   촉발

   가용 영역마다 오토스케일링 그룹을 따로 두도록 Hellman 클러스터를 바꾸는 계획된 유지보수에서 12:20 CET 에 Terraform 변경을 적용하자, 두 ALB 의 인스턴스 연결이 모두 지워졌다.

   원인

   설정 변경

   구성 요소

   Terraform클라우드 로드 밸런서노드 런치 템플릿

   기여 요인

   스테이징 불일치잡음에 묻힌 신호모니터링 사각지대

   감지

   12:25 CET 에 CloudWatch 알림이 ALB 의 5XX 수가 높다고 알렸고, 12:28 에 인그레스 트래픽이 들어오지 않는 문제를 감지하고 확인했다.

   조치

   • 인스턴스를 ALB 에 손으로 붙여 빠르게 문제를 완화했다.
   • 그 뒤 한 시간 안에 영구 수정을 적용했다.

   후속 조치

   • ALB 대상이 정상인지 비정상인지에 알림을 걸어 더 정확하고 즉각적으로 알 수 있게 한다.
   • 알림 소음을 더 줄인다.
   • Goldpinger 에 호스트 이름 해석을 구현한다.

   교훈

   평소 알림 소음이 여전히 너무 높았고, ALB 대상이 정상인지 비정상인지를 보는 알림이 없었다. 테스트 클러스터에서도 ALB 를 거치는 인그레스를 검증해야 한다.

   사례 보기
4. IL-0211 Mandrill 의 PostgreSQL 샤드 하나가 트랜잭션 ID 랩어라운드를 막으려고 쓰기를 멈춰 약 40시간 동안 메일 발송이 줄었다

   Mailchimp2019

   증상

   2019년 2월 4일 05:35 UTC 부터 Mandrill 이 대기열에 쌓인 메일의 80% 만 보냈다. 첫 예외는 일요일 밤에 로그에 남았지만 다른 시스템의 관계없는 예외에 묻혀 중앙 오류 보고에서 눈에 띄지 않았다.

   쓰기 거부처리량 저하부하 불균형노드 디스크 가득 참

   촉발

   Mandrill 의 키 해시 알고리즘이 shard4 에 쓰기를 더 많이 몰아 이 샤드의 autovacuum 이 밀렸거나 실패했고, 2019년 2월 4일 05:35 UTC 에 XID 가 상한에 닿아 데이터베이스가 안전 종료 모드로 들어갔다.

   원인

   용량 한계

   구성 요소

   데이터베이스PostgreSQL vacuum

   기여 요인

   초기 신호 무시한계 경보 부재잡음에 묻힌 신호재시도 폭주모니터링 사각지대

   감지

   첫 예외는 일요일 밤에 로그에 남았지만 다른 시스템의 관계없는 예외에 묻혀 중앙 오류 보고에서 늦게 발견됐다. 11:58 UTC 에 Mandrill 엔지니어가 조사를 시작했고, shard4 의 부하 급증을 쫓다가 12:56 UTC 에 랩어라운드를 찾았다.

   조치

   • 14:16 UTC 에 shard4 를 단일 사용자 모드로 띄우고 VACUUM 을 시작했다.
   • VACUUM 이 며칠 걸릴 것으로 보여 설정을 바꿔 속도를 높인 뒤 다시 시작했다.
   • VACUUM 이 도는 동안 데이터베이스 덤프와 복원을 시작했고, 속도를 높이려고 TB 단위인 Search 와 Url 테이블을 뺐다.
   • 실패한 작업과 로그로 디스크가 모자라자 Mandrill 앱 서버들의 스토리지 볼륨을 교체했다.
   • shard4 에 있던 작업 대기열 테이블을 살아 있는 다른 샤드로 옮겨 작업이 처리되게 하려 했다.
   • 잠긴 데이터베이스에서 테이블을 비우면 그 XID 가 풀린다는 것을 확인한 뒤 2월 5일 19:12 UTC 에 Search 와 Url 테이블을 비웠고, VACUUM 이 약 한 시간 뒤에 끝났다.
   • 21:36 UTC 에 밀린 메일 발송을 시작했다.
   • 22:40 UTC 에 XID 랩어라운드 알림을 새로 걸었다.

   교훈

   Mailchimp 는 대응을 늦춘 요인으로 다섯 가지를 들었다. Mandrill 시스템과 모니터링을 알고 접근할 수 있는 사람이 몇 명뿐이었다. Mandrill 의 로그 기록은 로컬에 쓸 수 있는 디스크에 기댔다. 잘못된 API 요청 로그와 실제 애플리케이션 오류를 구분하기 어려웠다. 작업 상태가 잘 보이지 않았다. 디스크 공간 문제로 원인 분석을 돕는 부분 배포가 위험했다. 잘된 점으로는 인시던트 지휘관을 중심으로 한 긴밀한 조율, 3시간 교대와 인수인계, 기록 담당과 기술 연락 담당 같은 역할 지정, 주기적인 요약과 결정 목록을 들었다. 화상 회의로 다시 모여 상황을 따져 본 것이 테이블을 비우는 해법으로 이어졌다. 대기 메일을 48시간 뒤에 지우는 기본 동작이 다가오자 더 과감한 방법을 검토하게 됐다. Mandrill 이 클라우드에서 돌아 스토리지를 빨리 늘릴 수 있었던 것은 운이었다. 지울 수 있는 데이터가 있었고 그 가운데 VACUUM 을 붙잡던 가장 큰 테이블이 있었던 것도 운이었다.

   사례 보기
5. 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시간 지원을 시작한다.

   사례 보기

원인별7