개요 #

Kafka docs에는 어디에 데이터를 저장해야한다는 글이 없지만, Kafka를 k8s에 올릴 때 사용하는 strimzi operator에는 다음과 같은 문구가 있다.

Efficient data storage is essential for Strimzi to operate effectively, and block storage is strongly recommended. Strimzi has been tested only with block storage, and file storage solutions like NFS are not guaranteed to work.

기존에는 k8s에서 kafka의 저장소로 nfs를 사용했던 터라, block storage를 추가로 깔아야한다고 생각했고 이에 따라 longhorn, openebs, ceph 중 ceph가 가장 대중적(?)이면서 de-factor standard로 알고있어서 채요했다. 물론 ceph의 여러 storage가 있지만 그 중 ceph rbd만을 사용했으며, nfs와의 성능 테스트에 대한 글이다.

성능 테스트를 위한 시나리오는 크게 6가지로 잡았다.

이제 코드와 결과 및 분석 내용에 대해 순차적으로 나열하겠다.

S1. 단일 Producer Throughput 측정 #

bin/kafka-producer-perf-test.sh \
  --topic test-topic \
  --num-records 100000 \
  --record-size 1024 \
  --throughput -1 \
  --producer-props bootstrap.servers=<bootstrap>

S1 - 결과 #

• Ceph RBD는 처리량(Throughput)이 NFS 대비 4~6배 이상 높고, latency도 현저히 낮음
• NFS는 쓰기 IOPS 한계와 fsync() 동기화 지연으로 인해 latency가 선형적으로 증가
• Ceph은 병렬 쓰기 처리 능력이 훨씬 뛰어나 throughput을 일정 수준 이상으로 유지함

클러스터 | Kafka UI Topic Size | 메시지 수 NFS | 약 63 MB | 19,000 Ceph | 약 383 MB | 19,000

S2. 다중 Producer Throughput 측정 #

for i in {1..5}; do
  echo "[INFO] Starting producer $i"
  bin/kafka-producer-perf-test.sh \
    --topic test-topic \
    --num-records 100000 \
    --record-size 1024 \
    --throughput -1 \
    --producer-props bootstrap.servers=<bootstrap> \

S2 - 결과 #

✅ Ceph RBD는 전 구간에서 NFS 대비 3~4배 이상 우수한 성능

• Throughput은 NFS 대비 3~4배 이상 높음
• Latency는 NFS 대비 4~10배 이상 낮음

✅ NFS는 메시지 수 증가에 따라 Latency가 선형적으로 악화

• 디스크 flush 주기와 fsync() 동기화 지연이 누적되어 전체 처리 시간 증가
• 초당 처리량은 일정 수준(400~440 MB/s)에서 정체, 스로틀링 발생

✅ Ceph은 병렬 쓰기 구조로 throughput 유지력 우수

• 메시지 수 증가에도 일정 수준 throughput 유지 (특히 50,000건에서 안정적)
• 병렬 처리, OSD 분산 저장, 빠른 segment flush 구조가 원인

S3. Consumer 처리 시간 #

time bin/kafka-consumer-perf-test.sh \
  --broker-list <bootstrap> \
  --topic test-topic \
  --messages 100000 \

S3 - 결과 #

✅ Ceph RBD는 전체적으로 안정적이지만, Consumer 테스트에선 Throughput에서 NFS와 큰 차이는 없음. 그러나 Fetch Time과 Rebalance Time에서 Ceph이 일관되고 짧은 시간을 보임.

• Fetch Time : Kafka Consumer가 Broker로부터 message를 가져오는 데 걸리는 시간
• Rebalance Time : Kafka Consumer Group에서 새로운 Consumer가 join하거나 leave 할 때, 파티션이 재할당되며 이 과정에서 걸리는 시간

S4. 장시간 부하테스트 #

time bin/kafka-producer-perf-test.sh \
  --topic test-topic \
  --num-records 3600000 \
  --record-size 1024 \
  --throughput 1000 \
  --producer-props bootstrap.servers=<bootstrap> \

S4 - 결과 #

S5. 대용량 메세지 처리 테스트 #

bin/kafka-producer-perf-test.sh \
  --topic test-topic-large \
  --num-records 100000 \
  --record-size 100000 \
  --throughput -1 \
  --producer-props bootstrap.servers=<bootstrap>

총평 #

• Ceph RBD는 모든 구간에서 NFS 대비 3~10배 이상 우수
• Kafka의 특성상, 저장소 선택이 성능과 안정성에 직접 영향
• NFS는 실시간 처리 시스템에 부적합
• 운영 환경에서는 반드시 block 기반 고성능 스토리지 사용 권장

이 테스트를 마칠 떄 쯤 한가지 깨달은게 있었다. k8s 클러스터 외부에 두는게 가장 성능은 좋지만, “성능"만 생각한다면 굳이 block storage tool을 안쓰고도 Local PV를 쓸 수 있고 이를 잘만 백업해둔다면 “장애” 측면도 무리가 없다는 것을…