Ch02. Apache Kafka 심화 개념 및 이해 - Partition Assignment Strategy

Consumer의 설정 파라미터 중에서 partition.assignment.strategy로 할당 방식 조정

• org.apache.kafka.clients.consumer.RangeAssignor: Topic별로 작동하는 Default Assignor
• org.apache.kafka.clients.consumer.RoundRobinAssignor: Round Robin 방식으로 Consumer에게 Partition을 할당
• org.apache.kafka.clients.consumer.StickyAssignor: 최대한 많은 기존 Partition 할당을 유지하면서 최대 균형을 이루는 할당을 보장
• org.apache.kafka.clients.consumer.CooperativeStickyAssignor: 동일한 StickyAssignor 논리를 따르지만 협력적인 Rebalance을 허용
• org.apache.kafka.clients.consumer.ConsumerPartitionAssignor: 인터페이스를 구현하면 사용자 지정 할당 전략을 사용할 수 있음

RangeAssignor

RangeAssignor

• partition.assignment.strategy 파라미터의 Default Assignor
• 동일한 Key를 가지고 있는 메시지들에 대한 Topic들 간에 “co-partitioning” 하기 유리
  • 예) Delivery ID를 key로 가지고 있는 delivery_status 메시지와 delivery_location 메시지
• Topic의 Partition 개수가 동일한 경우, Co-partitioning 가능

RoundRobinAssignor

RoundRobinAssignor

• Round Robin 방식으로 Partition들과 Consumer들을 분배하여 할당
• Reassign(재할당) 후 Consumer가 동일한 Partition을 유지한다고 보장하지 않음
  • 예) Consumer 0 이 지금 Topic0의 Partition0 에 할당되어 있지만, 재할당이 발생하면 Topic0의 Partition0 이 다른 Consumer에게 할당될 수 있음

할당 불균형이 발생할 가능성 존재

• Consumer간 Subscribe 해오는 Topic 이 다른 경우, 할당 불균형이 발생할 가능성 있음
  • 3개의 Consumer C0, C1, C2 와 3개의 Topic T0, T1, T2를 가정
  • T0은 Partition 1개, T1는 Partition 2개, T2은 Partition 3개 를 가정
  • C0은 T0만, C1는 T0 과 T1만, C2은 T0, T1 및 T2를 Subscribe한다고 가정

StickyAssignor

1) 가능한 한 균형적으로 할당을 보장

• Consumer들에게 할당된 Topic Partition의 수는 최대 1만큼 다름
• 특정 Consumer(예, Consumer A)가 다른 Consumer들(예, Consumer B)에 비해 2개 이상 더 적은 Topic Partition이 할당된 경우, A에 할당된 Topic의 나머지 Partition들은 B에 할당될 수 없음

2) 재할당이 발생했을 때, 기존 할당을 최대한 많이 보존하여 유지

• Topic Partition이 하나의 Consumer에서 다른 Consumer로 이동할 때의 오버헤드를 줄임

stickyAssignor 상세 설명

• Round Robin 방식과 비슷하지만 다른 방식으로 동작
  • 3개의 Consumer C0, C1, C2와 4개의 Topic T0, T1, T2, T3를 가정
  • T0, T1, T2, T3는 모두 Partition 2 개를 가정
  • C0, C1, C2 모두 T0, T1, T2, T3를 Subscribe 한다고 가정

C1이 제거되고 재할당이 발생한다고 가정

 

할당 불균형이 발생할 가능성을 줄임

• Round Robin 방식에서 설명했던 할당 불균형이 발생했던 시나리오는 아래와 같음
  • 3개의 Consumer C0, C1, C2 와 3개의 Topic T0, T1, T2를 가정
  • T0은 Partition 1개, T1는 Partition 2개, T2은 Partition 3개 를 가정
  • C0은 T0만, C1는 T0 과 T1만, C2은 T0, T1 및 T2를 Subscribe한다고 가정
• Sticky : 특정 Consumer(예, Consumer A)가 다른 Consumer들(예, Consumer B)에 비해 2개 이상 더 적은 Topic Partition이 할당된 경우, A에 할당된 Topic의 나머지 Partition들은 B에 할당될 수 없음

CooperativeStickyAssignor

Consumer Rebalancing Process 시간 흐름에 따른 Consumer Rebalance 과정

1. Consumer들이 JoinGroup 요청을 Group Coordinator 에 보내면서 리밸런싱이 시작되며,
2. JoinGroup의 응답이 Consumer들에 전송되고(Group Leader는 Consumer들 정보를 수신),
3. 모든 구성원은 Broker에 SyncGroup 요청을 보내야 하며(Group Leader는 각 Consumer의 Partition 할당을 계산해서 Group Coordinator에게 전송),
4. Broker는 SyncGroup 응답에서 각 Consumer별 Partition 할당을 보냄

Eager Rebalancing 프로토콜

• Eager Rebalancing 프로토콜은 최대한 단순하게 유지하기 위해 만들어짐
  • 각 구성원은 JoinGroup 요청을 보내고 재조정에 참여하기 전에 소유한 모든 Partition을 취소해야 함
  • 안전면에서는 좋지만 이 “Stop-the-World” 프로토콜은 그룹의 구성원이 재조정 기간 동안 작업을 수행할 수 없는 단점
• Revoke 할 Partition만 Revoke 하면 되지 않는가!!!
  • 변하지 않는것도 바꾸는 것이 이상하다.

Incremental Cooperative Rebalancing 프로토콜

Incremental Cooperative Rebalancing Protocol

• Consumer A, B가 Consume하고 있는 상태에서 처리량을 늘이기 위해서 Consumer C를 추가하는 경우를 가정
  • Consumer A에 할당된 Partition중 하나만 Consumer C로 이동하는 것이 가장 이상적임
  • 전체 재조정 동안 모두 정지 상태로 있는 대신, Consumer A만 하나의 Partition을 취소하는 동안만 가동 중지

Cooperative Sticky Assignor

• JoinGroup 요청을 보내면서 시작하지만, 소유한 모든 Partition을 보유하고, 그 정보를 Group Coordinator에게 보냄
• Group Leader는 원하는 대로 Consumer에 Partition을 할당하지만, 소유권을 이전하는 Partition들만 취소함
• Partition을 취소한 구성원은 그룹에 ReJoin하여 취소된 Partition을 할당할 수 있도록 두 번째 재조정을 트리
• Basic Cooperative Rebalancing 프로토콜은 ApacheKafka2.4에서 도입(간단한 형태의 알고리즘이 도입된 프로토콜)
• Incremental Cooperative Rebalancing 프로토콜은 ApacheKafka2.5에서 추가
• 빈번하게 Rebalancing 되는 상황이거나 스케일인/아웃으로 인한 다운 타임이 우려가 된다면, 최신 버전의 Kafka(2.5 이상)기반으로 사용하는 것을 권