오늘은 지금까지 RabbitMQ 를 통해 메세지 브로커를 사용했었는데 더 대규모 단위로 가서 대용량 메세지가 발생하게 되면 RabbitMQ 가 장애가 날 수 있다. 이렇게 RabbitMQ로도 부족한 상황이 오면 보통 Kafka 를 도입한다. 그렇기에 오늘은 Kafka에 대해서 알아보겠다.
kafka
- 분산 스트리밍 플랫폼으로, 실시간 데이터 스트리밍을 처리하고 관리하는 데 최적화된 시스템
- 링크드인(LinkedIn)에서 개발되었으며, 현재는 아파치 재단의 오픈 소스 프로젝트로 관리
- 높은 처리 성능과 확장성을 제공하며, 대용량의 데이터를 신뢰성 있게 전송하고 처리하는 데 강점
- 로그 수집, 메트릭 처리, 실시간 이벤트 스트리밍, 데이터 파이프라인 구축 등 다양한 분야에서 사용
docker-compose 를 통해 kafka 도입
- 명령어 docker compose -f kafka-docker-compose.yml
up -d

docker 에 잘 떴다.

제공되는 ui 포트가 8080 이기에 서버 8080이면 종료 후 눌러보면
- ui로 볼 수 있게 제공된다.

테스트용으로 Topic 만들어 보고

kafka 는 메세지를 푸쉬할 때 파티션 단위로 간다.
- 1번 파티션으로 test/123 이라는 key/value 값 형태로 퍼블리쉬 해보면

test 2까지 만들어서 봐도 잘 발송이 된게 확인 가능

Intellij Kafka Plugin 설치
플러그인에서 kafka 쳐보면 JetBrains 에 제공하는 친구 뜬다.

연결하는 법은 왼쪽 아래에 보면 kafka 버튼 생겼을 것이다. 누르고

kafka는 docker 내부에서 쓰는 9092 포트가 있지만 외부에서 접속 할려면 9094 로 접속해야 한다.

나는 외부에서 접속할 거기 때문에 9094는 10000 으로 붙기 때문에 10000으로 붙으면 된다.

그러면 아까 만든 친구들 잘 보인다.

보이는 test 의 마우스 오른쪽 누르고 뜨는 프로듀서 생성을 눌러서 메세지 보낼 수 있다.

파티션 1번에 메세지 수가 1개 늘어난 것이 잘 보인다.

아키텍처 설명(Broker, Topic, Partition,shard)
kafka
- 브로커(broker)
- Kafka 클러스터는 일반적으로 다수의 브로커로 구성
- 각 브로커는 클러스터 내에서 특정 토픽의 데이터를 저장하고 관리
- 토픽(topic)
- 데이터를 저장하고 관리하는 논리적인 단위. 생산된 데이터가 저장되는 장소
- 파티션(partition)
- 토픽의 데이터를 분산 처리할 수 있게 하는 단위
- 토픽의 각 파티션은 고유한 순서를 유지하며, 그 안에서 메시지는 순차적으로 기록

RabbitMQ 와 다르게 토픽만 바라보는 것이 아닌 토픽 내부의 파티션도 바라봐야한다.
- 소비자(consumer) 입장에서 중요함
- 생산하는 입장에서는 그냥 토픽에 던지면 된다.
- 그러면 어떤 파티션에 넣을지는 kafka 가 정한다.
- kafka 는 파티션 레벨에서 순서가 보장됨!!
kafka replication
- 파티션(partition)의 종류
- 리더(Leader): 읽기/쓰기
- 팔로워(Follower): 복제 + 읽기 + Failover
- kafka에선 shard 용어를 직접 사용하지 않음
- 토픽을 여러 partition으로 나누는 방식 = shard
- sharding = partitioning

그러면 kafka는 어떻게 분산처리할까?
- 리더에게 메세지 써지면
- 팔로워는 복제해서 컨슈머에게 제공
- Failover: 만약 리더가 죽으면 팔로워가 승격해서 리더가 됨 --> 안전성 보장
kafka ZooKeeper -> kRaft
- 버전별 변화
- 2.8: kRaft early acess
- 3.3: kRaft production-ready
- 3.5: ZooKeeper deprecated
- 4.0: ZooKeeper not supported
- ZooKeeper를 안쓰는 이유
- 분산 시스템의 단순화와 효율성 향상(kafka는 kafka만으로 운영)
- ZooKeeper의 의존성 이슈(메타데이터, failover 관리)

ZooKeeper 를 걷어내고 3.5이후 부터 kRaft 로 넘어감

정리 : 원래 kafka Cluster 의 node들을 관리해주는 ZooKeeper 라는 친구가 있었는데 3.5 이후 부터 ZooKeeper 가 없어지고 각각의 Broker에서 Controller 라는 프로세스가 한 3개정도 뜨고 이 친구들끼리 통신하게 되었다.
- 즉 kafka의 브로커 역할도 하면서 node들을 관리하는 controller의 역할도 수행한다.
- kakfa를 운영하기 위한 별도의 node를 운영하지 않아도 됨
RabbitMQ, Redis(queue), Kafka 비교
메세지 브로커 역할을 하는 친구들 비교
