Data Eng Wiki

Designing Apache Pinot for High Availability in the Cloud

8 min read

Designing Apache Pinot for High Availability in the Cloud

Author: James Dilworth, Amol Mathur (StarTree) | Source: startree.ai | Published: 2026-07-15

한 줄 요약

고가용성은 복제본을 갖는 것이 아니라 복제본들이 함께 죽지 않게 만드는 것이고, 그러려면 클라우드(장애 도메인 정의)·Kubernetes(배치)·Pinot(복제와 라우팅) 세 레이어가 같은 장애 경계에 대해 합의해야 한다.

핵심 주장/내용

  • “multi-AZ”는 마법의 주문이 아니라 출발점이다. 애플리케이션은 컴퓨트·스토리지·라우팅·스케줄링·데이터 복제가 실제로 그 장애 경계를 중심으로 설계되었을 때에만 가용 영역의 혜택을 본다. 배포가 여러 존에 걸쳐 있어도 여전히 남는 질문들: 브로커가 존에 분산되어 있나? 같은 테이블 세그먼트의 서버 복제본이 독립적 장애 도메인에 배치되어 있나? 로드밸런서가 비정상 브로커로 트래픽 보내기를 멈추나? 딥 스토리지가 영향받은 존 밖에서 durable하고 접근 가능한가?
  • 실시간 분석에서 더 중요한 이유: Pinot은 흔히 사용자 대면 대시보드, 관측성 워크플로, 개인화, 이상 탐지, 사기 탐지, 운영 의사결정 뒤에 있다. 분석 레이어가 죽으면 조직은 리포트 하나를 잃는 게 아니라 지금 무슨 일이 일어나고 있는지에 대한 라이브 가시성을 잃는다
  • 레이어 1 — 클라우드 인프라: blast radius를 정의한다. 존·노드 풀·스토리지 경로·네트워크 경로가 손상될 수 있다고 가정하고 설계. 목표는 모든 인프라 이슈를 막는 것이 아니라 인프라 이슈가 애플리케이션 장애가 되지 않게 하는 것. 실용적 출발 질문 하나: “가용 영역 하나가 사라지면 무엇이 함께 사라지는가?” 를 컴퓨트·스토리지·네트워킹·로드밸런싱·capacity(남은 존에 여유가 있나)·운영(존 이벤트 중에도 모니터링·배포·복구 도구가 쓸 수 있나) 각각에 대해 답한다
    • Pinot 특유: 로컬 디스크와 존 볼륨은 런타임 성능에 적절할 수 있지만 장기 세그먼트 durability는 S3/GCS/ADLS 같은 스토리지에 의존해야 한다
  • 레이어 2 — Kubernetes 배치: 토폴로지를 런타임 동작으로 바꾼다. 클러스터가 여러 존에 걸쳐 있다는 것만으로 중요한 파드가 애플리케이션을 보호하는 방식으로 분산된다는 보장은 없다. 의도적 스케줄링 룰이 없으면 복제본이 같은 장애 도메인에 몰릴 수 있다. topology spread constraints, pod anti-affinity, 노드 풀, readiness/liveness/startup probe, resource requests/limits, PodDisruptionBudget이 HA 설계의 일부가 된다
    • 유용한 테스트: “Kubernetes가 이 파드들을 같은 장애 도메인에 너무 많이 배치하는 것을 허용하는가?” 그렇다면 시스템은 redundant해 보이면서 실제로는 resilient하지 않다
  • 레이어 3 — Pinot의 복제와 라우팅: 복제본을 쿼리 회복력으로 바꾼다. 복제본 개수보다 어디에 배치되는지, 세그먼트가 어떻게 할당되는지, 브로커가 어떻게 라우팅하는지, 인스턴스가 사라졌을 때 클러스터가 어떻게 반응하는지에 달려 있다. 건강한 Pinot 클러스터는 장애 중에 계속 서빙하기 위해 스스로를 재구축할 필요가 없어야 한다 — 이미 올바른 복제본이 올바른 자리에 있어야 한다
  • Recovery와 Availability의 구분: Recovery는 장애 이후에 일어나는 일이고 Availability는 장애 중에 계속 작동하는 것이다. 둘 다 중요하지만 사용자 대면 분석에서는 차이가 결정적이다. 잘 설계된 배포에서 존 하나가 죽으면 — 클라이언트가 그 존의 브로커로 트래픽을 보내지 않고, 남은 존의 브로커가 필요한 세그먼트를 가진 건강한 서버 복제본으로 라우팅하고, Helix가 실패한 인스턴스를 관측해 클러스터 상태를 갱신한다. Kubernetes가 가능하면 워크로드를 재스케줄하겠지만 쿼리 가용성이 실패한 존의 즉각적 재구축에 의존하지 않는다
  • 가장 중요한 작업은 장애 이전에 일어난다. 존이 비정상이 되는 시점에는 이미 건강한 브로커를 통해 건강한 서버 복제본으로 트래픽이 흐를 수 있도록 배치가 끝나 있어야 한다

주요 수치 / 사실

  • 계기가 된 사건: 2026년 5월 AWS가 단일 가용 영역 인프라의 thermal event 보고. 영향받은 하드웨어의 EC2 인스턴스와 EBS 볼륨이 손상되어 다수 서비스의 트래픽을 해당 존에서 이동
  • 실용 체크리스트를 브로커/서버/컨트롤러·조율/스토리지/라우팅·쿼리 동작/모니터링·운영 6개 레이어로 제시
  • 모니터링은 사용자 가시적 증상 기준으로 — 쿼리 레이턴시, 에러, partial response, 인제스션 지연, 세그먼트 가용성. 전면 장애뿐 아니라 부분 저하를 탐지할 수 있어야 하고, 존 레벨 장애 시나리오를 정기적으로 테스트해야 한다
  • 체크리스트의 목적은 HA를 더 복잡하게 만드는 게 아니라 설계를 보이게 하는 것 — 의존성을 다 매핑하고 나면 비용·복잡도·가용성 사이의 트레이드오프를 정보에 기반해 결정할 수 있다

관련 위키

Source: 원문 보기

그래프 뷰

백링크