"Kafka + Longhorn 환경에서 replication 전략 최적화" 필요성

카프카 자체가 replication을 하는데, Longhorn도 replication을 하기 때문에 중복 복제가 발생해서 디스크 및 네트워크 비용이 2배 이상 들 수 있다. 고성능이 필요한 카프카는 가능하면 로컬 SSD + 카프카 replication만 쓰는 것이 일반적이다. CSI 기반 스토리지를 쓰면 장애 복구는 단순해지지만 레イ턴시 증가 가능성 있다.

기본 카프카의 저장 구조

Kafka는 브로커 노드 로컬 디스크에 데이터를 저장한다.
각 파티션은 여러 브로커에 replication 되어 장애가 나도 다른 노드에서 데이터를 복구할 수 있다.
여기서 "파일 관리"는 카프카 브로커가 담당합니다. 파일 관리는 메시지를 세그먼트 파일 형태로 저장하고, 로그 세그먼트 회전(rotation), retention 정책에 따라 삭제, OS 레벨 파일 시스템 사용 (ext4, xfs 등) 하는 것들이다.

Longhorn 같은 CSI(StorageClass + PVC) 사용 시

CSI는 컨테이너 환경에서 Persistent Volume(PV) 제공자 역할을 한다.
Longhorn은 분산 블록 스토리지로, PV를 여러 노드에 복제해 저장한다.
여기서 "파일 관리"는 역할이 두 겹이 된다.

계층	역할
카프카 브로커	여전히 파티션/세그먼트 관리, 로그 파일 생성 및 삭제
Longhorn(CSI)	PV 블록 장치를 노드에 마운트, 블록 레벨 복제·스냅샷·복구 관리

"Kafka + Longhorn 환경에서 replication 전략 최적화" 방향

목표 요약

Kafka의 논리적 복제(파티션 복제) 를 기본 가용성 수단으로 유지한다. Longhorn(블록 수준) 복제는 노드/디스크 장애 대비와 데이터 복구 편의성에 집중 — Kafka 복제와 중복되지 않도록 설계.
성능(지연, 처리량) 저하를 최소화하고, 운영·복구 절차를 명확히 한다.

핵심 권장값(우선순위)

• Kafka replication.factor (RF): 운영 파티션에 대해 3 권장 (작은 클러스터은 2도 가능하나 가용성/리더 이동 고려 시 3이 안전).

• min.insync.replicas: 프로듀서 내구성 요구에 따라 2 권장 (RF=3일 때).

• Longhorn replica count: 2 권장 (노드 수가 충분하다면 2) — 이유: 블록 레벨 복제가 3이면 네트워크·디스크 부담이 커짐. Kafka 레플리케이션으로 데이터 복원 가능하므로 Longhorn은 2로 가용성 보조.

• StorageClass reclaimPolicy: Retain (실수로 PVC 삭제 시 데이터 손실 방지) — 운영 정책에 따라 Delete도 가능.

• PVC 접근 모드: ReadWriteOnce (Kafka는 블록 디바이스를 브로커마다 독점 사용).

• Pod Anti-affinity: Kafka broker들끼리 같은 물리 노드에 스케줄되지 않게 강제(가능한 경우).

• Network: 저지연 네트워크(40Gbps 권장 옵션)와 안정적인 MTU 설정 — 블록 복제/리더-팔로워 트래픽을 고려.

근거

Kafka는 자체적으로 파티션 복제와 ISR(In-Sync Replicas) 메커니즘을 통해 메시지 내구성/가용성을 제공.

Longhorn은 디스크/노드 하드웨어 장애 또는 볼륨 수준의 복구(스냅샷, 복제본 이동)를 간편하게 해주지만, 블록 복제를 3으로 설정하면 네트워크·IO 비용이 크게 증가.

따라서 Kafka의 논리 복제를 1차, Longhorn을 2차 안전장치로 사용 — 비용/성능 균형에서 합리적.

아키텍처 흐름

Kafka broker (StatefulSet) — 각 브로커는 Longhorn PV(=로컬처럼 보이는 블록 디바이스)를 마운트.

Longhorn은 각 PV를 2복제(replica count=2)로 유지.

Kafka 설정: RF=3, min.insync.replicas=2, unclean.leader.election.enable=false.

운영시: 브로커 노드 장애 → Kafka replication으로 리더 전환 → Longhorn가 신규 노드로 PV 복구(스케줄링) 또는 스냅샷 복원 가능.

브로커 PVC 할당 구조

Kafka 브로커 하나당 PVC 하나를 가지게 된다. Kafka는 브로커 로컬 디스크에 파티션 데이터를 저장한다.

StatefulSet의 volumeClaimTemplates는 Pod(브로커)마다 독립된 PersistentVolume을 동적으로 생성한다.

요구되는 스토리지 용량을 예측해야 한다. 브로커 수 × PVC 크기 만큼의 스토리지가 필요하다.Longhorn replica count 값까지 고려하면 실제 물리 스토리지 요구량이 더 커진다.
(예: PVC=500Gi, replica=2 → 물리 저장소 1TB 필요).

브로커 수를 줄여도 PVC는 기본적으로 자동 삭제되지 않으니, 삭제 정책(Retain vs Delete)에 유의해야 한다.

Kafka 전용 PV/StorageClass 분리

공용 Longhorn 클러스터를 쓰면서 Kafka만 최적화하는 가장 안전한 방법은 StorageClass를 별도로 만드는 것이다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-kafka
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "2"   # Kafka 전용 튜닝
  staleReplicaTimeout: "30"
  fromBackup: ""
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
Kafka StatefulSet은 storageClassName: longhorn-kafka를 사용.

다른 워크로드는 기존 longhorn StorageClass 사용한다.