Kafka Cluster(Broker), Zookeeper에 대해서 이해하기

Kafka란 무엇일까?

카프카는 요즘 MSA에 필수적으로 사용되는 기술입니다. 이 카프카란 뭐고 왜 필요할까요? 카프카는 링크드인이라는 회사에서 하루에 1조 몇천억이 넘는 대량의 메시지들을 처리하기 위해 개발되었습니다. 링크드인이 사용중이라면 대용량 메시지 처리를 할 수 있고 안정성 또한 높을 것이라고 기대가 됩니다.

카프카는 Messaging Queue라고도 합니다. 간단하게 말해서 메시지를 보내는 쪽이 있고 그 메시지를 관리하는 주체가 있고, 또 그 메시지를 수신하는 쪽이 있을 겁니다. Messaging Queue는 Pub/Sub Model을 의미하는데 카프카 말고도 여러 MQ들이 있는데 카프카의 차별화된 점은 무엇인지 알아보도록 하겠습니다.

Messaging Queue: 카프카를 알아보기 전에

https://ably.com/topic/pub-sub

Publish-Subscribe Model은 메시지를 만들어내는 Producer(생산자), 소비하는 Consumer(소비자) 이 둘을 중재하는 Broker(브로커)로 구성되어 있습니다.

Topic이라는 개념이 등장하는데, 우리가 유튜브의 어떤 채널을 구독하면 해당 채널 관리자(Producer)가 영상을 업로드하면 구독자들에게 알림이 오듯이 유튜브 채널은 Topic이 되고, 해당 채널을 구독하는 우리는 Consumer가 되는 것입니다. 특정 사용자에게 전송한다고 생각을 할 수 있지만 Pub/Sub Model에서는 구독자들의 대한 정보는 모르고 Topic에 대한 정보만 알고 있습니다.

Topic, Partition 그리고 Segment File

https://www.scaler.com/topics/kafka-tutorial/kafka-partitions/

메시지는 Topic이라는 개념을 통해 카테고리화 됩니다. 특정 Topic으로 들어온 메시지들은 Queue 같은 자료구조에 하나씩 순차적으로 쌓이게 되는데 이때 내부에는 좀 더 세부화된 Partition과 Offset이라는 개념이 있습니다.

Topic은 여러 개의 Partition으로 나눠질 수 있습니다. Partition 내의 한칸은 로그라고 불리고 메시지는 Partition에 순차적으로 쌓이게 됩니다. 순차적으로 쌓이는 메시지들의 인덱스를 나타내는것이 바로 Offset입니다.

왜 하나의 토픽의 메시지를 또 여러 개의 파티션으로 나누는 것일까?

일반적으로 카프카는 메시지의 순서를 보장하지 않습니다. Partition과 Offset이 있는데 왜 순서를 보장할 수 없을까요? 왜그런지는 아래 메시지가 어떤 방식으로 저장되는지 알면 이해가 되실 겁니다.

Partition이 하나만 있는 경우와 여러 개가 있는 경우를 생각해보면, 하나만 있다면 대용량의 메시지들이 발행된다면 저장하는데 꽤나 병목이 생길 것입니다. 하지만 여러 개가 있다면 병렬적으로 저장할 수 있어서 훨씬 수월하게 저장할 수 있을 것입니다.

기본적으로 카프카는 토픽으로 발행된 메시지는 라운드 로빈 방식으로 랜덤 Partition에 저장(물론 Partition Key를 이용하면 특정 파티션에 메시지를 적재 가능)되는데 해당 메시지들은 큐처럼 쌓이는 방식으로 저장됩니다. 그래서 특정 파티션에 들어온 메시지들은 Broker를 통해 Offset이라는 값이 계속 증가하는 인덱스를 부여받습니다.

이 Offset을 이용해서 Consumer는 해당 Topic내의 Partition의 메시지를 어디까지 읽었는지 북마크하여 Consumer가 죽었다 살아나도 다시 북마크된 부분부터 읽을 수가 있습니다. (장애 복구)

💡 위 내용을 정리하자면, 특정 Topic으로 들어온 메시지들은 Topic 내부의 파티션에 나눠서 저장되게 되고 파티션 내부에는 Offset이라는 정보를 통해 순서를 보장하지만, 파티션 간에는 보장하지 않습니다.

세그먼트 파일

파티션에 추가되는 메시지들을 로그 파일이라고 하는데 이 파일들은 실제 파일 시스템에 저장이 됩니다. 이때 만들어지는 파일이 바로 세그먼트 파일이고 브로커 설정을 통해 세그먼트 파일이 일정 용량이 초과되거나 시간이 지나게 되면 삭제 또는 압축을 할 수 있습니다. 이때 파일은 세그먼트 단위로 삭제됩니다.

Consumer Group: 메시지를 소비하는 방법

Consumer는 그룹이라는 개념이 있는데 특정 토픽을 소비하는 컨슈머들에게 Group-Id를 부여하고 그룹으로 묶은 것입니다.

이를 통해 파티션은 Consumer Group내의 하나의 컨슈머에 의해서만 메시지가 소비되는 것을 보장합니다.

case 1) Partition 3개 - Consumer 2개

• 파티션이 3개, 컨슈머가 2개일 경우 → 컨슈머 중 하나는 두개의 파티션을 소비
• 이런 경우 처리량이 많아질수록 컨슈머에 병목현상이 발생할 수 있음

case 2) Partition 3개 - Consumer 3개

• 파티션의 개수와 컨슈머의 개수가 동일하다면 → 파티션과 컨슈머가 1:1 매칭되어 메시지 소비
• 가장 이상적인 구성이라고 할 수 있습니다. 파티션 당 하나의 컨슈머가 붙어서 빠르게 메시지를 처리할 수 있습니다.

case 3) Partition 3개 - Consumer 4개

해당 토픽의 파티션이 3개이고 그룹내의 컨슈머도 3개인 경우에 여기에 하나를 더 추가한다면 어떻게 될까요? 총 4개의 컨슈머니까 처리 속도가 훨씬 빨라질 수 있을까요?

위 그림은 모든 파티션이 그룹내의 컨슈머와 매칭이 된 상황에 컨슈머를 하나 추가한 상황입니다. 파티션과 그룹 내 컨슈머는 1:1 매칭이 기본입니다. 그렇기 때문에 추가된 컨슈머는 자신에게 파티션이 배정되기를 기다리게 될 것입니다.

이는 자원 낭비가 될 수도 있지만 메시지를 실시간으로 놓치면 안되는 서비스 관점에서 바라본다면 다른 컨슈머의 장애를 즉시 대비할 수 있는 좋은 전략이 될 수 있습니다. 일반적으로는 파티션 개수와 동일하게 컨슈머를 구성하는게 권장됩니다.

Broker와 Zoopkeeper란?

https://double.cloud/blog/posts/2023/03/the-many-use-cases-of-apache-kafka/

 

브로커는 프로듀서와 컨슈머 간 메시지를 관리해주는 중간 관리자 역할을 합니다. 카프카 클러스터에는 여러 개의 브로커들로 구성되어 있는데요. 최소 3대 이상의 브로커들로 구성하는 것을 권장합니다. 주키퍼는 카프카 브로커들의 메타데이터들을 관리해줍니다.

Broker는 무슨일을 할까?

• Leader Broker
  • 하나의 토픽 파티션마다 존재하는 리더 브로커가 존재합니다. 리더 브로커는 0개 이상의 팔로워 브로커를 가집니다.
• Follwer Boker
  • 리더의 백업을 위해 존재하는 팔로워 브로커는 리더 브로커를 복제합니다.
  • 리더 브로커가 다운되면 Zookeeper에 의해서 팔로워 브로커 중 하나가 새로운 리더가 됩니다.
• Controller
  • 클러스터의 다수 브로커 중 한대는 컨트롤러의 역할을 합니다.
    • 리더 선정, 토픽 생성, 파티션 생성, 복제본 관리
  • 다른 브로커들의 상태를 체크하면서 브로커가 클러스터에서 빠지는 경우 해당 브로커에 존재하는 파티션들을 리밸런싱 하는 역할을 합니다.
• Cordinator
  • 하나의 컨슈머 그룹에서 해당 토픽의 파티션에 대해서 1대1로 consume하고 있다고 가정했을 때, 컨슈머 하나가 장애가 발생했을 때, 다른 컨슈머에게 해당 파티션을 Rebalance 합니다.
• 파티션 오프셋 관리
  • 특정 파티션으로 부터 데이터를 가져가면 해당 파티션의 오프셋을 커밋하고 관리합니다.

Zookeeper는 무슨일을 할까?

주키퍼는 아래와 같이 카프카 브로커들을 관리해주는 역할을 합니다.

• Controller 선정
  • Controller 장애 발생 시 새로운 Controller를 선출
• Broker, Consumer 관리
  • Broker 메타데이터 관리, 상태 정보 기록
  • 새로운 Broker 추가
  • Broker 장애 감지
    • Leader Broker 장애 시 새로운 Leader 선출
• Topic 메타데이터 관리
  • Partition 개수, 설정 관리
• 변경사항(토픽을 생성 또는 제거, 브로커 추가 또는 제거)들을 카프카 브로커들에게 알리는 역할
• 주키퍼는 최소 3대 이상(엔터프라이즈는 5대 이상)을 권장하고 있습니다.
  • 주키퍼 앙상블: 주키퍼 3대 이상으로 구성한 것을 의미

REFERENCES

• Kafka 이해하기
• [Apache Kafka] 카프카란 무엇인가?
• Kafka에 대해서 알아보자
• Apache Kafka 간략하게 살펴보기
• [Kafka] 넓고 얕게 카프카를 이해해보자
• Kafka에 대해서 알아보자
• Apache Kafka(아파치 카프카)란? 소개, 생성, 설치 및 성능
• [Kafka] Apache Kafka 이해하기 - SW Developer
• Apache Kafka란 무엇일까? [Kafka의 구조와 기초개념]
• [Kafka] Kafka 의 Topic 과 Partition
• Apache Kafka Topics, Partitions, and Offsets - Scaler Topics