Incident Library

IL-0286 Honeycomb · 2025-12-05databaseawsobservability

Honeycomb 운영 Kafka 클러스터에서 브로커가 한꺼번에 사라져 토픽 파티션 여럿이 리더를 잃고 일부는 되살릴 수 없게 망가졌다

Honeycomb 은 해마다 운영 환경을 포함한 여러 환경에서 재해 복구 시나리오를 돌린다. 12월 5일 가용 영역 장애 훈련을 마친 뒤, 장애 동안 새 가용 영역에 몰린 워크로드를 다시 고르게 나누는 정리 단계를 런북대로 진행하면서 Kafka 브로커를 일부러 없앴다. 이때 동기화가 끝나 있던 기존 브로커까지 함께 없어져, 일부 토픽 파티션은 그 파티션을 가진 브로커가 하나도 남지 않았다. 브로커가 적은 EU 사전 운영 클러스터에서는 구조상 이 상황이 거의 일어나지 않아 네 번의 시험에서 문제가 드러나지 않았다. 브로커를 모두 잃은 파티션은 dirty 리더 선출을 거쳐야 하고, 이 선출은 offset 을 되돌릴 수 있다. offset 이 되돌아가면 쿼리 엔진 Retriever 가 데이터 처리를 거부한다. Retriever 는 offset 으로 어떤 이벤트까지 처리했는지를 엄격히 추적하기 때문이다.

첫날 대응은 파티션을 옮길 팀과 환경을 찾고, offset 과 데이터를 잃지 않고 파티션을 살리는 두 갈래로 나뉘었다. 망가진 파티션을 프로듀서 쪽에서 읽기 전용으로 돌려 수집 서비스 Shepherd 의 크래시 루프를 멈추고 재배치를 돌렸다. 밤새 돌린 재배치는 진척이 없었고 디스크는 계속 찼다. 토요일 아침 7시 PT 에 여유 공간이 5.07% 일 때 수집을 껐다. tiered storage 를 끄자 디스크 공간이 바로 돌아왔고, 수집을 다시 열면서 고객 영향이 끝났다. 완전히 망가진 Retriever 파티션은 잘라 내고 읽기 전용으로 두었다.

다음 주 수요일 Activity Log 토픽을 지우려다 삭제가 타임아웃 나면서 클러스터가 토픽 목록 말고는 아무 관리 작업도 못 하게 됐다. 팀은 클러스터를 조심스럽게 살리는 길과 새 클러스터로 완전히 옮기는 길을 나눠 진행했다. 금요일에 Storage 팀이 Retriever 의 offset 초기화 장치를 완성했다. 월요일에 EU 사전 운영 클러스터에서 전체 리허설을 네 시간 안에 마쳤고, 화요일에 새 클러스터로 두 시간 만에 옮겼다. 영업일로 5일이 안 되는 기간이었다. Activity Log 는 12월 5일 오후 6시 무렵 ET 부터 12월 9일 오후 6시 무렵 ET 까지의 데이터를 잃었다.

심각도
–
영향 범위
Ingest failed for teams and environments whose partitions were all unavailable; one Retriever partition, about 2.5% of the cluster, lost all its data; older data on truncated partitions could not be queried for a while; SLO processing saw ~18h of late data; Activity Log data from 5 December ~6 p.m. ET to 9 December ~6 p.m. ET was lost
영향 사용자
the Honeycomb teams and environments assigned to the damaged partitions
지역
–
감지까지
–
복구까지
–

증상

가용 영역 장애 대비 훈련을 마친 뒤 정리 단계에서 런북대로 Kafka 브로커를 없애자, 운영 환경의 여러 토픽 파티션이 리더 없이 남았다. 망가진 파티션만 배정된 팀과 환경은 데이터 수집이 실패했다.

수집 이벤트를 나르는 토픽의 파티션 여럿이 망가졌고 그중 일부는 되돌릴 수 없었다. 컨슈머 그룹이 처리 위치를 기록하는 토픽도 일부 망가졌고, Kafka 와 tiered storage 를 관리하는 Confluent 부가 기능의 메타데이터 토픽도 일부 파티션이 완전히 깨졌다. 그날 밤 정리한 목록에서 Retriever 파티션의 약 3분의 1 이 영향을 받았고, 클러스터의 약 2.5% 인 파티션 하나는 데이터를 전부 잃었다.

수집 서비스 Shepherd 는 깨진 파티션에 쓸 이벤트를 메모리에 버퍼링하다 크래시 루프에 빠졌다. 알림이 너무 많아 대응자들은 이 크래시 루프를 한 시간 넘게 지나서야 알아챘다.

밤새 돌린 재배치는 토요일 아침까지 진척이 없었고 브로커 디스크 사용량은 계속 올랐다. 여유 공간이 30% 남은 상태에서 시간당 5% 씩 줄고 있었다. 수집을 끄고 나서도 디스크 사용량은 멈추기만 하고 줄지 않았다.

_confluent-tier-state 와 __consumer_offsets 토픽의 깨진 파티션을 고치자 SLO 처리 트리거가 약 18시간 늦은 데이터를 알렸다. SLO 처리 서비스는 그동안 새 데이터가 들어온 것을 보지 못하고 있었다.

수요일에 Activity Log 토픽을 지우려 하자 삭제 작업이 타임아웃 났고, 그 뒤 모든 Kafka 브로커가 토픽 목록 보기 말고는 관리 작업을 하지 못했다. describe, 재배치, 수정이 모두 타임아웃 났다.

증상 컨테이너 재시작 반복데이터 유실노드 디스크 가득 참모니터링 중단

원인

원인 운영 실수

구성 요소 메시지 브로커
기여 요인 파괴적 변경 보호 장치 부재스테이징 불일치잡음에 묻힌 신호수동 조치 악화
촉발
12월 5일 운영 환경에서 가용 영역 장애 훈련을 마친 뒤, 워크로드 균형을 되돌리는 정리 단계를 런북대로 진행하다 Kafka 브로커를 일부러 없앴다. 이때 동기화가 끝나 있던 기존 브로커까지 함께 없어졌다.

감지

대응자들은 알림이 쏟아지는 가운데 수집 서비스 Shepherd 의 크래시 루프를 한 시간 넘게 지나서야 알아챘다. 토요일 아침에는 대응자들이 Kafka 밸런싱 작업이 나아가지 않고 디스크 사용량이 줄지 않는 것을 봤다. 메타데이터 토픽을 고치자 SLO 처리 트리거가 약 18시간 늦은 데이터를 알렸다.

조치

후속 조치

교훈

Honeycomb 은 "다음에는 Kafka 클러스터를 없애지 말자" 는 설명에서 멈추지 않고 더 넓은 영향을 봐야 한다고 밝혔다. 사전 운영 클러스터는 노드가 적어 구조상 이 문제를 재현하기 어려웠고, 운영과 더 닮은 클러스터에서 시험했다면 잡을 가능성이 훨씬 높았다. 이번 장애에 얽힌 요소 상당수는 이미 알려져 있었고 우회 계획, RFC, 안전하게 훈련하는 절차를 적은 문서도 있었지만, 쓴 사람 말고는 그런 문서가 있는지 몰랐거나 검색으로 찾을 수 없었다. 마감이 멀고 범위가 불확실한 내부 작업은 급한 작업에 밀려 거듭 미뤄지기 쉽다. 핵심 개입 상당수는 이제 그 구성 요소를 맡지 않는 사람들에게서 나왔고, 이는 팀 구성과 기술 구성 사이에 틈이 벌어졌다는 뜻이다. 에스컬레이션을 더 빨리 했어야 했다는 의견과 대응을 지속 가능하게 해야 한다는 의견이 함께 나왔다. 선임 엔지니어들이 들어오자마자 저절로 지휘를 잡는 문제와, 베타 기능의 손실을 너무 자세히 알린 대외 소통도 과제로 남았다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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