Data Eng Wiki

Transforming How We Run Kafka at Honeycomb

14 min read

Transforming How We Run Kafka at Honeycomb

Author: Josh Parsons (Honeycomb) | Source: honeycomb.io/blog | Published: 2026-07-15

한 줄 요약

Kafka 마이그레이션 성공의 기술적 요건은 롤백 안전성이지만, 진짜 성과는 마이그레이션 실행 자체를 반복 연습으로 삼아 Kafka 지식이 한 사람 머릿속에 있던 상태를 팀 전체의 자신감으로 바꾼 사회기술적 과정이었다.

핵심 주장/내용

  • 무엇에서 무엇으로: 자체 호스팅 Confluent Platform + ZooKeeper(EC2 인스턴스 클러스터) → 오픈소스 Apache Kafka 4.1.1, KRaft 모드, AWS EKS 배포(Strimzi로 오케스트레이션·관리)
  • 왜 마이그레이션했나 (여러 분기짜리 프로젝트에 교차팀 자원을 요청하려면 명확해야 했다):
    1. Honeycomb Private Cloud가 패키지 딜리버러블의 일부로 EKS 위 Kafka를 요구. SaaS 인프라에서 Kafka를 돌리던 방식은 그대로는 안 됐고, 장기 유지보수성을 위해 같은 방식으로 돌리면서 Kubernetes 위 Kafka가 프로덕션 규모 트래픽을 감당함을 증명해야 했다
    2. 현재 내부 운영 패턴과 정렬하고 레거시 패턴을 sunset할 기회
    3. 깊은 운영 통제와 유연성 — 주간 브로커 교체 연습의 복구 시간이 몇 년 전 8~12시간에서 마이그레이션 직전 48~72시간으로 점점 나빠지고 있었고, 원인은 의존하던 Confluent Platform Tiered Storage였다. 클로즈드 소스라 Confluent 지원 없이는 직접 고칠 방법이 없었다. 오픈소스로 옮기니 그런 이슈를 스스로 고칠 agency가 생겼다
  • 기능적 요구사항이 마이그레이션 옵션을 제약한다: Retriever(Kafka에서 나온 데이터를 컬럼 스토어에 쓰는 소비자)는 파티션 오프셋을 Kafka에 커밋하지 않고 내부적으로 유지한다. 사실상 exactly-once 시맨틱과 엄격한 데이터 보장을 지켜야 하고, 이미 직렬화해 컬럼 스토어에 쓴 메시지를 다시 소비하면 안 되기 때문
    • Retriever는 단일 Kafka 파티션을 병렬 인제스션 워커 쌍으로 소비한다 — 하나는 완성된 세그먼트를 컬럼 스토어에 업로드하고 다른 하나는 생성된 세그먼트 데이터가 쌍 간에 동일한지 대조 검사. exactly-once가 아니라 사실상 exactly-twice(쌍에 걸쳐)로 운영. Retriever가 파티션 오프셋을 로컬 디스크에 체크포인트하고 재시작·노드 교체 시 복원한 백업의 체크포인트에서 재개하기 때문에, consumer group 쌍을 쓰면 오프셋이 갈라진다
    • 이 정밀한 내부 오프셋 관리 의존성이 MirrorMaker 2 같은 크로스 클러스터 미러링 솔루션을 배제했다 — 오프셋 변환 메커니즘 때문에 Retriever가 체크포인트로 다음 메시지를 안정적으로 가져올 수 없다
  • 비기능적 요구사항도 제약한다: 99.99% 인제스트 가용성 SLO와 “보낸 이벤트를 1분 안에 쿼리 가능”이라는 매우 빠른 end-to-end 레이턴시. Kafka 디스크 I/O 레이턴시를 포함한 모든 레이턴시 원천에 민감
    • 그래서 diskless topic을 쓰는 관리형 Kafka(Confluent Warpstream 등)를 배제 — 더 비용 효율적인 데이터 전송·저장을 위해 높은 레이턴시를 교환할 수 없다
    • 고 IOPS 프로비저닝 EBS(io2)보다 EKS 인스턴스의 NVMe instance store를 선택해 최저 읽기·쓰기 레이턴시를 보장. 대가: NVMe instance store는 버퍼된 데이터를 전부 처음부터 rematerialize해야 하므로 브로커 교체와 데이터 복구가 더 오래 걸린다. EBS는 detach/reattach로 빠르지만 달러와 레이턴시에 지속 비용이 든다(EBS는 savings plan도 없다)
  • 인시던트에서 배운 것이 배당을 준다: 마이그레이션 착수 전 2025년 12월에 프로덕션 Kafka 클러스터를 완전히 evacuate해야 했던 대형 인시던트가 있었다. 저자는 evacuation의 역학에 주목했다 — 올바른 관점에서 보면 evacuation은 시간 압박과 스트레스 하의 정상 상태 마이그레이션처럼 생겼다
    • 그 인시던트에서 추측만 했지 실제로 해본 적 없던 사실을 알게 됐다: Retriever가 체크포인트된 파티션 오프셋을 0으로 리셋하고 새 Kafka 클러스터를 가리키게 하면, 새 클러스터에서 파티션 처음부터 메시지를 다시 읽는다. 피처 플래그로 결정적·동적으로, 데이터 유실이나 연속성 손실 없이 가능했다
    • 이것이 불가능하다고 생각했던 마이그레이션 경로를 열었다 — 고객 데이터를 하나도 떨어뜨리지 않고 완전한 데이터 연속성을 유지하며 조율된 컷오버 시퀀스를 실행할 수 있게 됐다
  • 롤백 절차를 우선순위로: 안전 가드레일과 롤백 스텝을 제대로 만들기 위해 초기 마이그레이션 일부를 미뤘다. 최저 환경 Kibble에서 완전히 forward → 완전히 backward → 부분 forward/backward → 최종적으로 다시 완전히 forward로 롤백 설계를 실제로 연습했다. 롤백 테스트 준비를 위한 명시적 역방향 마이그레이션에만 4시간 넘게 걸렸다
  • 실행 연습이 불확실성을 줄이고 학습 기회를 만든다: 마이그레이션 절차의 원본 템플릿은 12월 인시던트 때 만든 비상 evacuation 런북에서 직접 가져왔다. 마이그레이션마다 대응하는 “What did we learn?” 탭을 문서에 두고 이상하거나 새로운 것을 실시간으로 불릿 추가, 하루이틀 뒤 리뷰해 다음 마이그레이션 템플릿을 정제
    • 인시던트처럼 운영 — Zoom에서 실시간 조율, migration lead와 communication lead를 두고 핵심 런북 책임을 다른 사람에게 배정
    • 초기 마이그레이션은 7개 팀의 조율이 필요했지만, 여러 번 해야 했으므로 매번 7개 팀이 다 있길 원하지 않았다. 시간이 지나며 팀이 연습해 다른 팀의 런북 실행 소유권을 점진적으로 가져와 결국 한 팀만 필요해졌다. 팀원마다 매번 역할을 로테이션해 모두가 복잡하고 안무된 프로세스의 모든 핵심 조각을 직접 실행해봤다
    • 필요한 텔레메트리도 식별: EKS 클러스터에 OpenTelemetry Collector를 배포해 Prometheus JMX 지표 스크랩 + Kafka Admin API 정보 추출 + Kubernetes 노드 지표·이벤트 수집. 마이그레이션 중 검증해야 할 핵심 신호 중심의 전술적 대시보드를 만들어 계속할지 멈출지의 체크포인트로 사용
  • 팀이 스스로 성장을 확인하다: 프로젝트 전 저자가 사실상 팀의 “Kafka 전문가”였다. 마지막 비프로덕션 마이그레이션을 저자의 PTO 중에 팀이 실행하도록 배치했고, 팀은 트러블슈팅할 창발적 이슈 하나 없이 완벽하게 실행하고 최단 turn-up 기록을 세웠다
  • 일반화의 대가: 절차가 이제 self-hosted→managed, EKS→EKS, evacuation·DR 등 여러 마이그레이션 양상에 재사용 가능하다. 하지만 일반화 가능하게 만드는 개념적 단순함을 위해 일정 수준의 consume 가용성 감소를 수용했다 — 서비스와 시스템이 견딜 수 있는 것에 근거한 의도적 선택
    • 구체적으로: producer를 먼저 컷오버하고, consumer가 옛 클러스터에서 다 읽게 두고, 그 다음 consumer를 컷오버하며 체크포인트 오프셋을 리셋하는 방식이라 producer 컷오버와 consumer 컷오버 사이에 downtime 윈도우가 생긴다. produce 요청을 끊거나 고객 데이터를 잃지는 않지만, 그 윈도우 동안 consumer가 신규 데이터를 보지 못하고 결과적으로 고객이 gap을 본다
  • 기계적 실행과 사회기술적 성공은 다르다: 기계적으로 잘 실행된 마이그레이션 절차가 사회기술적으로 성공적인 마이그레이션을 보장하지 않는다. 영향 범위와 기대치를 동료·고객에게 얼마나 효과적으로 커뮤니케이션하느냐가 매끄러운 기계적 실행만큼 중요하다. (Honeycomb은 이 마이그레이션 관련 2026년 5월 유지보수 이벤트에서 선제적 커뮤니케이션에 실패했음을 별도 포스트에서 사과)

주요 수치 / 사실

  • 주간 브로커 교체 복구 시간: 몇 년 전 812시간 → 마이그레이션 전 **4872시간**
  • 클러스터 구성: 3개 환경 티어(Kibble → Dogfood → Prod) × 2개 리전 = 총 6개 클러스터
  • 마이그레이션 실행 시간이 연습을 통해 45시간 → 23시간으로 단축
  • 조율 필요 팀 수 7개 → 1개
  • Kafka가 Honeycomb 관측성 데이터 인제스션 파이프라인의 심장 — 초당 수백만 이벤트 처리. 인제스션과 처리를 분리해 다운타임 없이 하루에 여러 번 핵심 인제스션 경로 서비스를 업데이트할 수 있게 해준다
  • 조직의 Kafka 지식이 한두 사람 머릿속에 있다면, Kafka 마이그레이션 프로젝트는 그 학습 기반을 다른 사람들에게 확장하기 시작할 훌륭한 기회다. 지식 격차를 메우려 채용에 허둥대는 상황에 놓이지 않는 게 낫다 — 그래서 사내 문서에 Kafka 기초·아키텍처 내 위치·새 클러스터 운영법을 가르치는 교육용 라이브러리 리소스를 구축

관련 위키

Source: 원문 보기

그래프 뷰

백링크