Haonly's Blog

Kafka consumer group 모니터링 중 "Preparing rebalance" 상태가 떠서 정확히 알아볼 겸 consumer state 에 대한 정리...

(기초는 차차 정리하고 일단 당장 궁금한 것부터!)

Rebalancing 정의

• 카프카 컨슈머 그룹을 구성하여 데이터를 처리할 때 운영상황에서 마주치는 다양한 경우의 수에 대해
• 그룹에 참여하는 컨슈머 클라이언트 구성에 변화가 생길 경우 이 변화를 반영하기 위한 과정
• 컨슈머 클라이언트를 사용하여 필요한 논리적인 그룹을 형성하고, 그 그룹 멤버들끼리 리소스(파티션)을 적절히 분배하는 프로세스

Consumer Group

• 특정 토픽에 발행된 메시지를 consumer group이라는 논리적 멤버십을 제공함으로서 각 그룹에서 목적에 맞게 읽고 처리할 수 있도록 함
• consumer group과 그 멤버 인스턴스, 토픽의 파티션과의 관계는 복잡함
• 컨슈머 인스턴스 제약
  • 카프카에서 1개 파티션은 consumer group 내의 최대 1개 인스턴스까지만 접근 가능
  • 즉, 1개 consumer group 인스턴스 수가 토픽이 가진 파티션 갯수보다 많을 수 없음
  • 다시 적자면, 파티션 수가 consumer group내에서 실제 컨슈밍을 진행하고 있는, 최대 active consumer 갯수를 제한함
  • (consumer group과 파티션 사이의 관계가 있다는 것이며 이런 맥락에 기반하여 분산 처리 및 로드 밸런싱이 이루어짐)

Kafka Rebalance Protocol

• 토픽을 컨슈밍할 논리적인 그룹을 형성하고 파티션을 재분배하는 과정
• Group management를 사용하여 카프카 클라이언트들을 논리적인 그룹에 참여시킴으로서 cooperating 하며
• Cooperating 과정에서 그룹 코디네이터(Group Coordinator)는 GroupCoordinator 인스턴스를 백그라운드 프로세스로 실행하며 consumer group을 관리하는 역할을 가진 카프카 브로커임
• Kafka Rebalancing Protocol에서 코디네이터의 역할 대신 클라이언트 단의 역할이 크게 작용하게 되며, 이에 따른 장점이 있음
  • 클라이언트 자체로 로드밸런싱 알고리즘을 수행: autonomy → 클라이언트가 로드벨런싱 자체의 디테일 작업에 집중하며 브로커의 코드가 단순화됨

카프카 토픽 파티션 갯수 설정

토픽을 새로 생성했는데 파티션을 몇개로 설정할지 고민에 빠졌다.
파티션 갯수를 늘리면 로드가 줄어들기는 하지만 늘리는 만큼 복제 지연 이슈가 있을 수 있으니 적당히 나눠야 한다.

바람직한 갯수는 아래와 같다.
#partitions = desired throughput / partition speed

예를 들어 하루에 1TB 의 throughput을 원한다고 하고 하나의 파티션 속도가 10MB/s 라면
1TB/24h = 11.5MB/s 이므로
대략 1개~2개 정도면 원하는 throughput을 만족할 수 있는 속도가 나온다.