사례1건

1건 중 1~1번째

1. 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 앙상블을 따로 둬야 한다는 것이 이 장애에서 가장 분명한 할 일이었다. 운영 모니터링을 더 갖췄다면 더 빨리 복구할 수 있었다.

   사례 보기

원인별1