사례6건

6건 중 5~6번째

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

   사례 보기
2. IL-0275 Kafka 브로커들이 네트워크 한계에 닿아 줄줄이 쓰러지면서 Parse.ly 의 데이터 처리가 멈추고 대시보드에 몇 시간 동안 새 데이터가 나오지 않았다

   Parse.ly2015

   증상

   2015년 3월 26일 목요일 밤, 첫 장애가 나자 PagerDuty 가 한밤중에 온콜 엔지니어를 깨웠다. Munin, Sentry, Pingdom 같은 모니터링 도구에서 장애 보고가 쏟아졌고, Graphite 그래프에도 장애가 보였다. 고객 사이트는 JavaScript 코드를 계속 불러왔지만 분석 데이터가 실시간 처리 스트림으로 흘러 들어오지 않았고, 대시보드에 새 데이터가 나오지 않았다.

   서비스 중단DNS 조회 실패

   촉발

   2015년 3월 27일 금요일 데이터 양이 한계를 넘어 Kafka 브로커들이 운영체제 네트워크 한계에 닿았고, 한 대가 쓰러지자 나머지가 차례로 쓰러졌다. 그 뒤 클러스터를 넓히려고 넣은 새 브로커들이 잘못된 호스트 이름으로 들어왔다.

   원인

   용량 한계

   구성 요소

   메시지 브로커서비스 디스커버리

   기여 요인

   모니터링 사각지대한계 미인지여유 용량 부재수동 조치 악화

   감지

   Munin, Sentry, Pingdom 같은 모니터링 도구에서 장애 보고가 쏟아졌고 Graphite 그래프에서도 확인했다. 첫 장애 때 PagerDuty 가 한밤중에 온콜 엔지니어를 깨웠다.

   조치

   • Kafka 클러스터를 넓히려고 노드를 몇 대 더했다.
   • 새 Kafka 노드에 올바른 설정을 넣고 클러스터에 배포했다.
   • Apache Storm 으로 하위 컨슈머 시스템을 모두 천천히 다시 켜고, 쌓인 데이터를 다시 처리했다.
   • Amazon S3 에 보관한 원시 데이터로 모든 고객 계정에 데이터를 다시 채우기 시작했다.

   교훈

   호스트와 운영체제의 한계까지 생각하면 장애를 피할 수 있는 시스템은 없다. CPU 와 디스크 I/O 는 장비 상태를 잘 보여 주지만, 서서히 늘어나는 네트워크 사용률은 더 해롭고 지켜보기도 어렵다. CPU 는 100% 의 뜻이 분명하지만 네트워크 사용률 100% 는 대부분의 노드에서 뜻이 분명하지 않고, 특히 VM 이 호스트를 나눠 쓰는 클라우드에서 그렇다. 원시 데이터 보관을 웹 서버 로그, 일반 파일, Amazon S3 업로드처럼 단순한 방식으로 하고 실시간 처리 스트림과 완전히 떼어 둔 덕분에 Parse.ly 는 영구 데이터 손실을 걱정하지 않아도 됐다. 기계 한두 대가 아니라 서브시스템 전체가 꺼져 하위 시스템이 손쓸 수 없게 되는 연쇄 장애 상황을 더 깊이 생각해야 한다.

   사례 보기

원인별5