쿠버네티스에서 카프카(kafka on k8s) 정말 좋은 선택일까?

카프카를 쿠버네티스 위에서 사용하는 이유와 장단점을 알아보자

 

최근 카프카를 주요하게 사용하는 프로젝트를 진행하면서 카프카와 쿠버네티스의 관계에 대해 궁금증이 생겼다. 일전에 카프카 커넥터를 쿠버네티스 위에 구축하여 사용해보면서 꽤나 좋은 경험을 했었는데, 커넥터 말고 카프카 전체를 쿠버네티스 위에서 사용하면 어떨지에 대한 호기심이 들었다. 이번 포스팅에서는 kafka on k8s를 사용하는 이유와 운영 시 주의할 사항들이 무엇이 있는지 알아보자.

 

왜 kafka on k8s를 사용할까?

만약 이미 다른 어플리케이션들을 쿠버네티스 위에서 실행시키고 있다면 오히려 물리 서버 위에서 실행시키는 것보다 훨씬 쉬운 일이 될 수 있다. 특히 대규모 조직에서는 Kafka를 Kubernetes 외부에서 배포하는 것이 많은 승인과정을 포함하여 조직적인 문제를 야기할 수 있기 때문에 쿠버네티스 위에서 빠르게 카프카를 설치하고 실행해볼 수 있다.

 

또한 많은 조직들이 배포할 클러스터 수를 간과하는데 쿠버네티스를 이용하면 스케일링 아웃, 모니터링, 재시작, 업그레이드 등을 훨씬 간편하게 할 수 있다. 쿠버네티스를 사용하는 것에 익숙해지면 카프카 관리가 훨씬 쉬워질 수 있다. 새 브로커를 추가하는 것은 단일 명령이나 구성 파일의 한 줄로 가능하며, 모든 브로커와 클러스터에 대한 구성 변경, 업그레이드 및 재시작이 쉬워진다.

쉽지 않은 kafka on k8s

장점만 있다면 아마 모두가 카프카를 쿠버네티스 위에서 사용했을 것이다. 하지만 분명히 단점도 존재하기 때문에 많은 사용자들이 물리 서버에서 카프카를 사용할 것인데 어떤 점이 카프카를 쿠버네티스 위에서 사용하게 하는데 어렵게 하는지 알아보자.

 

먼저 기본적으로 카프카는 stateful한 서비스이다. stateful이란 상태를 유지해야 하는 서비스를 말하며 카프카 같은 경우는 데이터를 전송하고 저장하기 때문에 현재 자신의 상태(데이터를 어디까지 저장했지? 어디까지 처리했지 같은)를 기억하고 있어야 한다. 하지만 쿠버네티스는 반대로 stateless 서비스를 위한 아키텍처로 구축되어 있다. 그러다보니 스토리지나 네트워크 설정을 잘 해주지 않으면 데이터 정합성이 무너질 수도 있는 최악이 상황이 생길 수 있다.

 

따라서 쿠버네티스를 잘 이해하고 다룰 수 있는 팀이 있지 않다면 카프카를 운영하는 첫번째 선택지를 쿠버네티스로 결정하는 것은 그렇게 권장되지 않는다고 한다. 처음에는 stateless한 카프카 스트림즈 같은 것들을 통해 먼저 경험을 해보고 결정하는 것이 좋다고 한다.

 

특히 카프카 브로커는 연관된 어플리케이션들이 쿠버네티스에서 실행중일 때 가장 이점이 있고 가장 신중하게 쿠버네티스를 도입해야 한다.

다양한 툴

쿠버네티스 위에서 카프카를 운영하는게 쉽지 않아보이는데 다행히도 많은 좋은 개발자들이 쉽게 쿠버네티스 위에서 카프카를 배포할 수 있도록 툴을 만들어두었다. 대표적으로 2가지가 있다.

 

• Confluent for Kubernetes (CFK): Confluent 클라우드 네이티브용 Operator
• Strimzi: 오픈소스 Kafka를 위한 쿠버네티스 Operator

둘 다 각자의 장단점이 있는데 아래 링크에 둘의 특징을 비교해놓은 글을 첨부해놓았으니 참고하면 좋을 것 같다.

참고

https://www.confluent.io/blog/apache-kafka-kubernetes-could-you-should-you/

Apache Kafka on Kubernetes – Could You? Should You? | Confluent

https://medium.com/@yimin.zheng/kafka-on-kubernetes-strimzi-vs-confluent-operators-df5ea81df5c8

Kafka on Kubernetes: Strimzi vs Confluent Operators