사례3건

3건 중 1~3번째

1. IL-0514 클라우드 사업자의 노드 교체 뒤 Consul 이 리더를 뽑지 못하고 Vault 가 봉인된 채 남아 PyPI 백엔드가 7분 동안 응답하지 않았다

   Python Software Foundation2022

   증상

   18:23 UTC 에 PSF 인프라 팀에 Vault 컨테이너가 적어도 하나 내려가 있고 다시 올라오려면 봉인 해제가 필요하다는 첫 알림이 왔다. 살펴보니 클러스터의 Vault 컨테이너는 모두 쓸 수 없었고 Consul 컨테이너는 새 리더를 뽑지 못하고 있었다.

   서비스 중단파드 Terminating 정체

   촉발

   2022-07-28 17:24 UTC 부터 클라우드 사업자가 알 수 없는 장애를 이유로 PyPI 가 도는 쿠버네티스 클러스터의 클라우드 인스턴스 여러 대를 자동으로 교체했다.

   원인

   클라우드 제공자 장애

   구성 요소

   코디네이션 키-값 저장소시크릿 저장소

   기여 요인

   자동화 증폭

   감지

   18:23 UTC 에 PSF 인프라 팀에 Vault 컨테이너가 적어도 하나 내려가 있고 봉인 해제가 필요하다는 알림이 왔다.

   조치

   • Terminating 상태에 멈춘 Consul 파드를 강제로 지우고 다시 만들어지게 했다. 그 뒤 Consul 회복이 시작됐다.
   • Consul 을 되살린 뒤 새 Vault 컨테이너의 봉인을 풀었다.

   사례 보기
2. IL-0588 AppOptics 와 Librato 의 메트릭 API 가 대부분의 데이터에 5xx 를 내고 Kafka 파티션이 리더 없이 오프라인으로 남았다

   AppOptics2018

   증상

   2018년 5월 31일 21:53 UTC 부터 AppOptics 와 Librato 의 메트릭 API 가 들어오는 메트릭 데이터 대부분에 5xx 를 냈다. AppOptics APM 이 보낸 APM 메트릭과 트레이스도 영향을 받았고, 알림 상당수가 늦게 나갔다.

   오류율 상승장애 조치 실패모니터링 중단

   촉발

   AWS US-East-1 리전의 가용 영역 하나에 난 전력 장애로 ZooKeeper 리더 노드를 잃었고, 그 가용 영역의 Kafka 브로커 여럿도 영향을 받았다.

   원인

   클라우드 제공자 장애

   구성 요소

   메시지 브로커코디네이션 키-값 저장소

   기여 요인

   단일 장애점과도한 영향 범위모니터링 사각지대

   조치

   • ZooKeeper 클러스터의 노드 하나를 손으로 재시작해 리더 선출을 일으켰고, 앙상블이 쿼럼을 되찾았다.
   • Kafka 브로커를 하나씩 차례로 재시작해 리더 없이 오프라인이던 파티션을 다시 온라인으로 올렸다.
   • 밀린 작업과 알림을 모두 처리하고 정상 운영으로 돌아갔다.

   후속 조치

   • Kafka 클러스터를 가용 영역 사이, 나아가 리전 사이에 더 잘 격리한다.
   • Kafka 클러스터끼리 ZooKeeper 앙상블을 같이 쓰지 않게 한다.
   • ZooKeeper 쿼럼이 돌아온 뒤 Kafka 가 사람 손 없이 파티션 리더를 되찾는지 게임데이에서 이 상황을 더 재현해 본다. 새 Kafka 버전에서 이 문제가 고쳐졌는지도 확인한다.
   • 복구에 따로 손이 필요한 하위 시스템을 더 일찍 알려 주는 점검을 더 넣었다.

   교훈

   여러 가용 영역에 서비스를 나눠 뒀지만 Kafka 와 ZooKeeper 가 이번처럼 실패하자 격리가 충분하지 않았다. Kafka 클러스터를 가용 영역과 리전 사이에 더 잘 격리하고 Kafka 클러스터마다 ZooKeeper 앙상블을 따로 둬야 한다는 것이 이 장애에서 가장 분명한 할 일이었다. 운영 모니터링을 더 갖췄다면 더 빨리 복구할 수 있었다.

   사례 보기
3. IL-0362 PagerDuty 의 알림 발송이 18분 동안 멈추고 API 가 500 을 냈다

   PagerDuty2013sev1

   증상

   2013-04-13 태평양 시간 8:11 에 PagerDuty 당직 엔지니어가 알림 발송 시스템의 노드 하나에 문제가 있다는 호출을 받았다. 8:13 에 그 노드를 되살리려 했지만 실패했다.

   지연 시간 증가오류율 상승간헐적 연결 실패

   촉발

   PagerDuty 가 쓰는 AWS 리전 두 곳이 함께 쓰던 북부 캘리포니아의 피어링 지점이 나빠졌다. AWS 에 따르면 연결 문제는 태평양 시간 7:57 에 시작됐다.

   원인

   클라우드 제공자 장애

   구성 요소

   트랜짓 게이트웨이와 네트워크 연결 장비코디네이션 키-값 저장소

   기여 요인

   단일 장애점미검증 가정모니터링 사각지대

   감지

   8:11 에 당직 엔지니어가 알림 발송 시스템 노드 하나의 문제로 호출을 받았다. 8:18 에 모니터링 시스템이 연결 문제 때문에 알림 제공자 여러 곳에서 실패가 나는 것을 감지했다.

   조치

   • 장애 동안 실패한 coordinator 프로세스 대부분을 손으로 재시작했다.
   • 8:53 에 알림 발송 시스템이 쿼럼을 이뤄 쌓여 있던 알림을 모두 처리하기 시작했다.

   후속 조치

   • 일부 시스템의 문제를 디버깅할 로그가 부족했으므로, 로그를 더 남기고 검색하기 쉽게 한곳으로 모으기 시작했다.
   • 실패한 coordinator 같은 프로세스를 자동으로 재시작하는 프로세스 감시자를 둔다.
   • 호스트 사이 연결 상태를 보여 주는 대시보드를 만든다.
   • 모든 엔지니어가 Cassandra 와 ZooKeeper 를 잘 알지는 못하므로, 두 기술을 교육하는 데 시간을 들인다.
   • AWS 리전 하나에서 옮겨 가는 방안을 조사한다. 새 호스팅 사업자와 데이터센터를 고를 때 단일 장애 지점이 생기지 않도록 미리 따져 본다.

   교훈

   서로 의존하지 않고 물리적으로 떨어지게 고른 데이터센터 셋 가운데 둘이 같은 피어링 지점을 쓰고 있었고, 그 지점 하나가 나빠지자 두 데이터센터가 함께 오프라인이 됐다. 데이터센터 하나를 잃는 것은 견디게 설계했지만 둘을 함께 잃는 경우는 설계에 없었다. 일부 시스템에는 디버깅할 로그가 부족했고, 호스트 사이 연결을 볼 수단도 부족했다. 모든 엔지니어가 Cassandra 와 ZooKeeper 에 밝지도 않았다.

   사례 보기

원인별1