06.CooperativeStickyAssignor

Consumer Rebalancing Process

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” 프로토콜은 그룹의 구성원이 재조정 기간 동안 작업을 수행할 수 없는 단점

Incremental Cooperative Rebalancing Protocol

Eager Rebalancing 프로토콜의 단점을 보완한 프로토콜.

• Revoke될 Partition, 변하지 않는 Partition과 새로 할당할 Partition을 구분하여 관리

이상적인 Consumer Rebalancing 프로토콜

Consumer A, B가 Consume하고 있는 상태에서 처리량을 늘리기 위해 Consumer C를 추가하는 경우를 가정.

• Consumer A에 할당된 Partition중 하나만 Consumer C로 이동하는 것이 가장 이상적임

• 전체 재조정 동안 모두 정지 상태로 있는 대신, Consumer A만 하나의 Partition을 취소하는 동안만 가동 중지.

• Issue: Consumer는 자신의 Partition 중 어느 것이 다른 곳으로 재할당되어야 하는지 알지 못함.

Cooperative Sticky Assignor

• Rebalancing을 두 번 수행

• Basic Cooperative Rebalancing 프로토콜은 Apache Kafka 2.4 에서 도입

• Incremental Cooperative Rebalancing 프로토콜은 Apache Kafka 2.5에서 추가

• 빈번하게 Rebalancing되는 상황이거나 스케일 인/아웃으로 인한 다운타임이 우려가 된다면, 최신 버전의 Kafka(2.5 이상)기반으로 사용하는 것을 권장

• JoinGroup 요청을 보내면서 시작하지만, 소유한 모든 Partition을 보유하고, 그 정보를 Group Coordinator에게 보냄

• Group Leader는 원하는 대로 Consumer에 Partition을 할당하지만, 소유권을 이전하는 Partition들만 취소함

• Partition을 취소한 구성원은 그룹에 ReJoin하여 취소된 Partition을 할당할 수 있도록 두 번째 재조정을 트리거

• 1st rebalance에서 Consumer는 자신의 Partition 중 어느 것이 다른 곳으로 재할당되어야 하는지 알게 됨