{"id":"IL-0588","org":"AppOptics","date":"2018-05-31","docs":[],"title":{"en":"AppOptics metrics APIs returned 5xx as Kafka partitions stayed leaderless after an AWS power event hit their ZooKeeper","ko":"AppOptics 와 Librato 의 메트릭 API 가 대부분의 데이터에 5xx 를 내고 Kafka 파티션이 리더 없이 오프라인으로 남았다"},"domain":["database","aws","observability"],"impact":{"scope":"Metrics APIs of AppOptics and Librato returned 5xx for a majority of incoming metric data; APM metrics and traces from AppOptics APM were affected and many alert notifications were delayed","users":"AppOptics and Librato customers","region":"AWS us-east-1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Running services across several availability zones and more than one Kafka cluster did not isolate the pipeline from the failure of one zone, because partitions of different clusters sat in the same zones and the clusters shared one ZooKeeper ensemble. More operational monitoring of the subsystems that needed help to recover would have led to a faster recovery.","ko":"여러 가용 영역에 서비스를 나눠 뒀지만 Kafka 와 ZooKeeper 가 이번처럼 실패하자 격리가 충분하지 않았다. Kafka 클러스터를 가용 영역과 리전 사이에 더 잘 격리하고 Kafka 클러스터마다 ZooKeeper 앙상블을 따로 둬야 한다는 것이 이 장애에서 가장 분명한 할 일이었다. 운영 모니터링을 더 갖췄다면 더 빨리 복구할 수 있었다."},"related":[],"sources":[{"url":"https://status.appoptics.com/incidents/dbnq4l2063hh","kind":"official-status","archived":"https://web.archive.org/web/20201214094405/https://status.appoptics.com/incidents/dbnq4l2063hh"}],"summary":{"en":"AppOptics and Librato run their metrics pipeline, including alerting, as stream processing on Apache Kafka, and every incoming data point is written to one or more Kafka topics. The infrastructure runs across several availability zones, including the one hit by the power event, and there is more than one Kafka cluster so that producers can fail over to another cluster when the partition they want to write to is offline. On May 31, 2018 a power event in one availability zone took nodes of several critical systems out of reach, including the ZooKeeper leader that coordinated the Kafka brokers. The ensemble briefly lost quorum and had to elect a new leader, and Kafka brokers in that zone were restarted.\n\nKafka should have moved partition leadership to the replicas, but many partitions stayed offline without a leader, so the metrics APIs returned 5xx for most incoming data. The multi-cluster setup did not help, because several partitions of the different clusters had ended up in the same availability zones, and the Kafka clusters shared one ZooKeeper ensemble, so coordination broke on both clusters while ZooKeeper had no quorum. AppOptics could not tell how much the loss of quorum affected Kafka's recovery, and it believed Kafka should have regained partition leadership without manual intervention once ZooKeeper had quorum again.\n\nThe team restarted one ZooKeeper node to force a leader election (quorum was back by 22:01 UTC), found the leaderless partitions at 22:07 UTC, and restarted every broker in turn until all partitions were online at 23:45 UTC. The postmortem gives the outage as 21:53 to 23:22 UTC. The status page marked the incident resolved at 01:00 UTC on June 1, once the backlog had been processed.","ko":"AppOptics 와 Librato 의 메트릭 파이프라인은 알림까지 포함해 Apache Kafka 위의 스트림 처리로 돌고, 들어오는 데이터는 모두 Kafka 토픽에 쓴다. 2018년 5월 31일 AWS US-East-1 의 가용 영역 하나에 전력 장애가 나면서 Kafka 브로커를 조율하는 ZooKeeper 클러스터의 리더 노드를 잃었고, 앙상블은 잠시 쿼럼을 잃었다. 엔지니어가 노드 하나를 손으로 재시작해 리더 선출을 일으켰고, 22:01 UTC 에 새 리더로 앙상블이 다시 동작하는 것을 확인했다.\n\n같은 가용 영역의 Kafka 브로커 여럿도 재시작됐는데, 많은 파티션이 복제본으로 리더를 넘기지 못하고 리더 없는 오프라인 상태로 남았다. 21:53 UTC 부터 23:22 UTC 까지 메트릭 API 는 대부분의 데이터에 5xx 를 냈다. 같은 시각에 ZooKeeper 쿼럼을 잃은 것이 Kafka 클러스터의 회복에 어떤 영향을 줬는지는 AppOptics 도 분명히 알지 못한다고 했다. 22:07 UTC 에 오프라인 파티션을 확인한 엔지니어들은 브로커를 하나씩 재시작했고, 재시작할수록 파티션이 하나둘 돌아왔다. 23:45 UTC 에 모든 브로커의 재시작과 모든 파티션의 복구를 확인했고, 메트릭 제출과 APM 데이터 처리와 알림 처리가 정상으로 돌아왔다. 밀린 작업과 알림은 6월 1일 01:00 UTC 까지 처리했다.\n\n여러 Kafka 클러스터를 둔 고가용성 구성도 도움이 되지 않았다. 두 클러스터의 파티션 여럿이 같은 가용 영역에 놓여 있었고, 두 클러스터가 ZooKeeper 앙상블 하나를 같이 썼다."},"trigger":{"en":"A power event in one of AWS's availability zones in us-east-1 cut off nodes in several critical parts of the AppOptics and Librato infrastructure, including the ZooKeeper node that was then the leader of the ensemble coordinating the Kafka brokers.","ko":"AWS US-East-1 리전의 가용 영역 하나에 난 전력 장애로 ZooKeeper 리더 노드를 잃었고, 그 가용 영역의 Kafka 브로커 여럿도 영향을 받았다."},"severity":"unknown","symptoms":["high-error-rate","failover-failed","monitoring-down"],"timeline":{"detected_after":"13m","resolved_after":"1h 29m"},"date_kind":"incident","detection":null,"components":["message-broker","coordination-store"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Restarted one ZooKeeper node by hand to force a leader election, after which the ensemble regained quorum","ko":"ZooKeeper 클러스터의 노드 하나를 손으로 재시작해 리더 선출을 일으켰고, 앙상블이 쿼럼을 되찾았다."}},{"text":{"en":"Restarted every Kafka broker in a rolling restart until all partitions were back online","ko":"Kafka 브로커를 하나씩 차례로 재시작해 리더 없이 오프라인이던 파티션을 다시 온라인으로 올렸다."}},{"text":{"en":"Worked through the backlog, including the backlog of alerts, and resumed normal operations","ko":"밀린 작업과 알림을 모두 처리하고 정상 운영으로 돌아갔다."}}],"action_items":[{"text":{"en":"Isolate the Kafka clusters better across availability zones and regions","ko":"Kafka 클러스터를 가용 영역 사이, 나아가 리전 사이에 더 잘 격리한다."}},{"text":{"en":"Stop sharing one ZooKeeper ensemble across Kafka clusters","ko":"Kafka 클러스터끼리 ZooKeeper 앙상블을 같이 쓰지 않게 한다."}},{"text":{"en":"Run game days on this failure and check whether newer Kafka versions fix it","ko":"ZooKeeper 쿼럼이 돌아온 뒤 Kafka 가 사람 손 없이 파티션 리더를 되찾는지 게임데이에서 이 상황을 더 재현해 본다. 새 Kafka 버전에서 이 문제가 고쳐졌는지도 확인한다."}},{"text":{"en":"Put in place more checks that notify the team earlier about subsystems that need extra help to recover","ko":"복구에 따로 손이 필요한 하위 시스템을 더 일찍 알려 주는 점검을 더 넣었다."}}],"contributing":["single-point-of-failure","blast-radius-too-wide","monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"On May 31, 2018 from 21:53 UTC the metrics APIs of AppOptics and Librato returned a 5xx for a majority of incoming metric data. APM metrics and traces sent from AppOptics APM were affected, and many alert notifications were delayed.\n\nThe status page reported errors for metric submission and trace processing delays at 22:06 UTC. In the metrics pipeline, which also drives alerting and writes all incoming data to Kafka topics, many Kafka partitions were offline and had no leader. Writes and reads to those topics stopped, and the API dropped requests with 500 codes.\n\nThe ZooKeeper ensemble that coordinates the Kafka brokers had lost its leader node in the power event. The team restarted one ZooKeeper node by hand to force a leader election, and by 22:01 UTC the ensemble had quorum again with a new leader. Kafka brokers in the affected availability zone were restarted as well, but many partitions did not fail over to their replicas and did not recover on their own.\n\nA rolling restart of every Kafka broker brought partitions back a few at a time, and availability improved slowly as each broker came back. Only at 23:45 UTC were all partitions online again. The backlog of alerts was then processed, and the status page warned that this could delay alert notifications. The backlog was fully processed by 00:38 UTC on June 1.","ko":"2018년 5월 31일 21:53 UTC 부터 AppOptics 와 Librato 의 메트릭 API 가 들어오는 메트릭 데이터 대부분에 5xx 를 냈다. AppOptics APM 이 보낸 APM 메트릭과 트레이스도 영향을 받았고, 알림 상당수가 늦게 나갔다.\n\n같은 무렵 AWS US-East-1 리전의 가용 영역 하나에 전력 장애가 났고, 여러 핵심 인프라의 노드에 잠시 접근할 수 없었다. Kafka 브로커를 조율하는 ZooKeeper 클러스터에서 노드 하나를 잃었는데, 그 노드가 리더여서 앙상블이 새 리더를 뽑아야 했다. 그 가용 영역의 Kafka 브로커 여럿도 영향을 받아 재시작됐다.\n\n브로커가 재시작된 뒤 많은 파티션이 복제본으로 자동 장애 조치되지 않고 곧바로 오프라인이 됐다. 메트릭 파이프라인의 Kafka 토픽에 읽기와 쓰기가 모두 멈췄고, 요청은 500 코드로 실패하며 버려졌다. 22:07 UTC 에 엔지니어들은 많은 파티션이 오프라인이고 리더가 없으며 스스로 회복되지 않는다는 것을 확인했다.\n\nAppOptics 는 Kafka 클러스터를 여럿 두고, 파티션이 온라인이 아니면 프로듀서가 다른 클러스터로 넘어가게 해 두었다. 그러나 이번에는 이 구성이 장애를 막지 못했다. 두 클러스터의 파티션 여럿이 같은 가용 영역에 몰려 있었고, 두 클러스터가 ZooKeeper 앙상블 하나를 같이 써서 쿼럼을 잃은 동안 양쪽 조율이 모두 깨졌다.\n\n상태 페이지에는 22:06 UTC 에 메트릭 제출 오류와 트레이스 처리 지연을 조사 중이라는 글이 올라왔다. 23:23 UTC 에 복구하며 밀린 작업을 처리하고 있다고 알렸고, 23:58 UTC 에는 밀린 알림을 처리하느라 알림이 늦을 수 있다고 알렸다. 6월 1일 00:38 UTC 에 밀린 작업을 다 처리했고 01:00 UTC 에 해결로 닫았다. 이때 자동으로 풀려야 할 알림이 풀리지 않았다면 손으로 해결해야 할 수 있다고 안내했다."},"updated_at":"2026-11-14T12:34:23.407780Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0588","org_slug":"appoptics"}