Incident Library

IL-0588 AppOptics · 2018-05-31databaseawsobservability

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

AppOptics 와 Librato 의 메트릭 파이프라인은 알림까지 포함해 Apache Kafka 위의 스트림 처리로 돌고, 들어오는 데이터는 모두 Kafka 토픽에 쓴다. 2018년 5월 31일 AWS US-East-1 의 가용 영역 하나에 전력 장애가 나면서 Kafka 브로커를 조율하는 ZooKeeper 클러스터의 리더 노드를 잃었고, 앙상블은 잠시 쿼럼을 잃었다. 엔지니어가 노드 하나를 손으로 재시작해 리더 선출을 일으켰고, 22:01 UTC 에 새 리더로 앙상블이 다시 동작하는 것을 확인했다.

같은 가용 영역의 Kafka 브로커 여럿도 재시작됐는데, 많은 파티션이 복제본으로 리더를 넘기지 못하고 리더 없는 오프라인 상태로 남았다. 21:53 UTC 부터 23:22 UTC 까지 메트릭 API 는 대부분의 데이터에 5xx 를 냈다. 같은 시각에 ZooKeeper 쿼럼을 잃은 것이 Kafka 클러스터의 회복에 어떤 영향을 줬는지는 AppOptics 도 분명히 알지 못한다고 했다. 22:07 UTC 에 오프라인 파티션을 확인한 엔지니어들은 브로커를 하나씩 재시작했고, 재시작할수록 파티션이 하나둘 돌아왔다. 23:45 UTC 에 모든 브로커의 재시작과 모든 파티션의 복구를 확인했고, 메트릭 제출과 APM 데이터 처리와 알림 처리가 정상으로 돌아왔다. 밀린 작업과 알림은 6월 1일 01:00 UTC 까지 처리했다.

여러 Kafka 클러스터를 둔 고가용성 구성도 도움이 되지 않았다. 두 클러스터의 파티션 여럿이 같은 가용 영역에 놓여 있었고, 두 클러스터가 ZooKeeper 앙상블 하나를 같이 썼다.

심각도
–
영향 범위
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
영향 사용자
AppOptics and Librato customers
지역
AWS us-east-1
감지까지
13m
복구까지
1h 29m

증상

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

같은 무렵 AWS US-East-1 리전의 가용 영역 하나에 전력 장애가 났고, 여러 핵심 인프라의 노드에 잠시 접근할 수 없었다. Kafka 브로커를 조율하는 ZooKeeper 클러스터에서 노드 하나를 잃었는데, 그 노드가 리더여서 앙상블이 새 리더를 뽑아야 했다. 그 가용 영역의 Kafka 브로커 여럿도 영향을 받아 재시작됐다.

브로커가 재시작된 뒤 많은 파티션이 복제본으로 자동 장애 조치되지 않고 곧바로 오프라인이 됐다. 메트릭 파이프라인의 Kafka 토픽에 읽기와 쓰기가 모두 멈췄고, 요청은 500 코드로 실패하며 버려졌다. 22:07 UTC 에 엔지니어들은 많은 파티션이 오프라인이고 리더가 없으며 스스로 회복되지 않는다는 것을 확인했다.

AppOptics 는 Kafka 클러스터를 여럿 두고, 파티션이 온라인이 아니면 프로듀서가 다른 클러스터로 넘어가게 해 두었다. 그러나 이번에는 이 구성이 장애를 막지 못했다. 두 클러스터의 파티션 여럿이 같은 가용 영역에 몰려 있었고, 두 클러스터가 ZooKeeper 앙상블 하나를 같이 써서 쿼럼을 잃은 동안 양쪽 조율이 모두 깨졌다.

상태 페이지에는 22:06 UTC 에 메트릭 제출 오류와 트레이스 처리 지연을 조사 중이라는 글이 올라왔다. 23:23 UTC 에 복구하며 밀린 작업을 처리하고 있다고 알렸고, 23:58 UTC 에는 밀린 알림을 처리하느라 알림이 늦을 수 있다고 알렸다. 6월 1일 00:38 UTC 에 밀린 작업을 다 처리했고 01:00 UTC 에 해결로 닫았다. 이때 자동으로 풀려야 할 알림이 풀리지 않았다면 손으로 해결해야 할 수 있다고 안내했다.

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

원인

원인 클라우드 제공자 장애

구성 요소 메시지 브로커코디네이션 키-값 저장소
기여 요인 단일 장애점과도한 영향 범위모니터링 사각지대
촉발
AWS US-East-1 리전의 가용 영역 하나에 난 전력 장애로 ZooKeeper 리더 노드를 잃었고, 그 가용 영역의 Kafka 브로커 여럿도 영향을 받았다.

감지

–

조치

후속 조치

교훈

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

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 메시지 브로커, 코디네이션 키-값 저장소. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.