인사이트리포트

들어가며

전통적으로 Kafka는 베어 메탈이나 VM과 같은 전용 서버 환경에서 운영되며 자원 경합을 최소화하여 성능을 보장해왔다. 그러나 Kubernetes(이하 K8s)의 사용이 지속적으로 많아지면서 Kafka를 컨테이너화된 환경에서 운영하려는 시도가 증가하고 있다.
본 글에서는 전통적인 서버 기반의 Kafka 운영 방식과, K8s 컨테이너 기반 환경에서 Apache Kafka를 운영하는 방식을 비교한다. 이를 통해 K8s 환경으로 전환 시 얻을 수 있는 이점과 고려해야 할 단점을 객관적으로 짚어보고, 실제 프로덕션 환경에서 Kafka를 안정적으로 배포/운영하기 위해 고려할 수 있는 Strimzi 오퍼레이터(Operator) 활용 방안 등 실무에서 도움이 될 핵심 포인트들을 다룬다.

Zookeeper의 퇴장과 가벼워진 Kafka

Kafka를 K8s에 구성하는데 걸림돌이었던 Zookeeper

과거 Kafka는 클러스터 상태와 메타데이터 관리를 위해 외부 시스템인 Zookeeper가 필수였고, 둘 다 안정적 운영을 위해 클러스터링이 필요했다. 그런데 K8s에서는 데이터 영속성과 일관성을 보장해야 하는 Stateful 애플리케이션 운영 자체가 까다롭다. 이런 환경에서 2개의 분산시스템을 각각 클러스터로 구성하고 안정적인 연결까지 유지해야 하므로 운영 부담이 클 수밖에 없었다.

Kafka v4.0과 KRaft 모드가 가져온 구조적 가벼움

Kafka에 Zookeeper가 필수인 것에는 여러 단점이 존재했고, 결국 Kafka v4.0부터 Zookeeper가 완전히 빠지면서 이를 대체하는 KRaft(Kafka Raft) 모드가 표준으로 자리 잡았다. Kafka 내부에서 자체적으로 메타데이터를 관리하게 되면서 아키텍처가 단순해지고, 외부 시스템 의존성이 사라져 인프라 복잡성이 줄었으며, 장애 조치 및 복구 속도도 빨라졌다. 결과적으로 K8s 컨테이너 환경에 올리기에 더 적합한 구조를 갖추게 되었다.

비교 분석: 전통적 서버 vs Kubernetes

Kafka 운영 환경을 전통적인 서버 환경과 K8s 기반의 컨테이너 환경으로 구분하여 두 환경 간의 주요 차이점 및 Trade-off에 대해 분석한다.

K8s 전환 시 고려해야 할 Trade-off

Kafka를 K8s 환경으로 옮긴다고 해서 모든 문제가 자동으로 해결되는 것은 아니다. 오히려 전통적인 서버 환경에서는 크게 의식하지 않던 요소들이 새로운 운영 과제로 드러나는 경우가 많다. 특히 네트워크 안정성, 디스크 성능, 고정된 브로커 식별성이 중요한 Kafka는 K8s 전환 시 Trade-off를 함께 고려해야 한다.

• 성능 측면
  전통적인 환경에서는 브로커가 CPU, 메모리, 디스크, 네트워크 자원에 직접 접근할 수 있어 성능 예측이 비교적 쉽다. 반면 K8s 환경에서는 CNI 기반 네트워크, 컨테이너 런타임, 스토리지 추상화 계층이 추가되어 환경에 따라 지연 시간(latency)이나 I/O 성능에 영향을 받을 수 있다. 즉, 성능 일관성이 최우선인 워크로드는 더 신중한 검토가 필요하다.
• 상태 저장 워크로드 복잡도
  Kafka는 단순한 Stateless 애플리케이션과 달리 데이터와 상태를 지속적으로 유지해야하는 Stateful한 분산시스템이다. 따라서 K8s에서 Kafka를 운영하려면 Deployment/Pod 실행만으로는 부족하며, 브로커별 고정된 네트워크 식별 정보와 재시작 이후에도 유지되는 스토리지를 함께 보장해야 한다. 이 과정에서는 StatefulSet, Headless Service, 스토리지 클래스, 볼륨 정책 등을 함께 고려해야 하며, 설정이 잘못되면 장애 복구나 재배포가 더 까다로워질 수 있다.
• 이해도 범위 확장
  전통적인 서버 환경에서는 Kafka 자체에 대한 이해가 중요했다면, K8s 환경에서는 Kafka와 K8s를 동시에 이해해야 하므로 운영 복잡성이 커진다. 예를 들어 브로커 장애가 발생했을 때도 원인이 Kafka 내부 문제인지, Pod 재스케줄링 문제인지, 스토리지 attach 지연인지, 네트워크 정책 이슈인지 등을 함께 살펴봐야 한다. 즉, K8s는 운영을 자동화해 주지만, 장애 원인을 분석하는 관점에서는 더 넓은 기술 스택에 대한 이해를 요구할 수 있다.
• 리소스 공유 환경
  전통적인 전용 서버에서는 Kafka가 자원을 비교적 독점적으로 사용하도록 구성하기 쉽지만, K8s에서는 여러 애플리케이션이 클러스터 자원을 함께 사용하는 경우가 많다. 이 경우 CPU, 메모리, 디스크, 네트워크 자원 경쟁이 발생할 수 있으며, 적절한 requests/limits, 노드 분리, anti-affinity, taint/toleration 정책이 없으면 브로커 성능과 안정성에 영향을 줄 수 있다. 결국 K8s는 높은 자원 활용도를 제공하지만, 그만큼 성능 일관성을 확보하기 위한 추가 설계와 운영 기준이 필요하다.

K8s 환경에서 Kafka 운영 복잡도와 오퍼레이터의 역할

왜 Kafka를 K8s에서 직접 운영하기 어려운가

Zookeeper가 제거되고 KRaft 기반 구조가 도입되면서 Kafka 자체의 구성 복잡도는 일부 줄어들었다. 그러나 Kafka는 여전히 상태 저장 시스템이기 때문에, K8s에서 직접 운영하려면 스토리지, 네트워크, 외부 접근 경로를 함께 설계해야 한다. 특히 Kafka는 브로커 간 통신과 클라이언트 연결이 브로커별 주소 정보를 기반으로 이루어진다. 따라서 각 브로커가 재시작이나 재스케줄링 이후에도 일관된 네트워크 식별성을 유지해야 한다. 이 때문에 Kafka on K8s는 단순 배포보다 운영 자동화와 구성 표준화가 더 중요하며, 그래서 Kafka를 K8s에서 운영할 때는 오퍼레이터를 함께 검토하는 경우가 많다.

오퍼레이터가 운영 복잡도를 줄이는 방식

K8s 오퍼레이터는 사용자가 Kafka 클러스터의 원하는 상태를 선언적으로 정의하면, 이를 실제 K8s 리소스로 구성하고 지속적으로 관리한다. 사용자는 브로커 수, 스토리지, Listener, replication factor와 같은 핵심 설정에 집중하면 되고, StatefulSet, Service, Headless Service, PVC, Secret 등 세부 리소스의 생성과 연결은 오퍼레이터가 담당한다.

이러한 방식은 단순히 YAML 작성량을 줄이는 데 그치지 않고, 버전 변경, 설정 반영, 롤링 업데이트, 인증서 갱신, 장애 복구 같은 반복 작업을 표준화된 절차로 수행할 수 있게 한다. 결국 오퍼레이터는 Kafka on K8s 운영의 복잡성을 낮추고, 클러스터를 더 일관되고 예측 가능한 방식으로 관리할 수 있게 해준다.

오픈소스 Kafka 오퍼레이터: Strimzi

Strimzi는 K8s 환경에서 Kafka의 배포와 운영을 지원하는 대표적인 오픈소스 Kafka 오퍼레이터이다. 사용자는 Custom Resource로 Kafka 클러스터의 원하는 상태를 선언하고, Strimzi는 이를 바탕으로 필요한 K8s 리소스를 생성/관리한다. 이를 통해 Kafka on K8s의 배포와 운영을 보다 안정적이고 일관되게 관리할 수 있다. 또한 Strimzi는 Kafka 클러스터 배포뿐 아니라 KafkaTopic, KafkaUser와 같은 Custom Resource를 통해 토픽 생성·변경, 사용자 및 권한 관리 같은 운영 작업도 K8s 방식으로 다룰 수 있게 해준다.

아래 비교 예시는 오퍼레이터 사용 여부에 따라 Kafka on K8s 구성 방식이 어떻게 달라지는지를 보여준다. 첫 번째는 Strimzi 없이 Kafka를 직접 배포하는 예시이고, 두 번째는 Strimzi를 사용하는 예시이다. Strimzi를 사용하지 않는 경우에는 KRaft 초기화, StatefulSet과 스토리지 구성, 외부 노출, advertised.listeners 설정 등을 모두 직접 설계해야 한다. 아래 코드는 이러한 수작업 범위를 보여주기 위한 일부 예시이다.

[예시 코드] Strimzi를 사용하지 않는 경우

Strimzi를 사용하는 경우에는 컨트롤러/브로커 수, 스토리지와 같은 상위 수준의 요구사항만 정의하면 되며, 나머지 리소스 생성과 주요 운영 절차는 오퍼레이터가 관리한다. Strimzi는 YAML의 양뿐 아니라 운영자가 직접 관리해야 하는 구성 복잡도 또한함께 줄여준다.

 [예시 코드] Strimzi를 사용하는 경우

엔터프라이즈 Kafka 오퍼레이터: CFK(Confluent for Kubernetes)

CFK(Confluent for Kubernetes)는 Confluent Platform을 K8s 위에서 운영하기 위한 엔터프라이즈 오퍼레이터이다. Kafka뿐 아니라 Connect, Schema Registry, ksqlDB, Control Center 등 주요 구성요소를 선언적으로 함께 관리할 수 있어, 플랫폼 전체를 통합적으로 운영해야 하는 환경에 적합하다. 다만 엔터프라이즈 라이선스 비용이 발생하지만, 공식 문서와 기술 지원 체계를 활용할 수 있다는 장점이 있다. 따라서 K8s 환경에서 Kafka를 운영할 때는 오픈소스 중심의 운영을 원하면 Strimzi를, 플랫폼 단위의 표준화와 상용 지원까지 고려한다면 CFK를 선택하는 것이 현실적이다.

마치며

지금까지 Apache Kafka 운영에서 전통적인 서버 환경과 K8s 환경의 차이점과 주요 고려사항을 살펴보았다. 중요한 것은 어느 환경이 절대적으로 더 낫냐가 아니라, 서비스의 특성과 팀의 운영 역량에 더 잘 맞는 선택이 무엇인가이다. 전통적 서버 환경은 성능 일관성 및 예측이 중요한 경우에, K8s 환경은 확장성과 운영 자동화가 중요한 경우에 더 적합할 수 있다.

따라서 K8s 전환을 검토할 때는 단순히 트렌드를 따르기보다, 팀이 운영 복잡도를 감당할 준비가 되어 있는지, 그리고 오퍼레이터를 통해 운영 절차를 얼마나 표준화할 수 있는지를 함께 판단해야 한다. 결국 가장 좋은 플랫폼은 우리 서비스의 안정적인 운영과 성장을 가장 잘 뒷받침할 수 있는 환경이다.