[Kafka] - 12. Cooperative Sticky Assignor

1. Consumer rebalancing Process by time

---

1. Consumer들이 Join Group Reqeust를 Group Coordinator에 보낸다.(Rebalance process start)

2. Join Group Response 및 Join Group 목록을 Group Leader(Consumer C)에게 전달한다. 

3. 모든 Consumer들은 Broker에게 Sync Group Request ( Group Leader는 각 Consumer의 Partition 할당(assignor)을 계산하여 Group Coordinator에게 전달)

4. Broker들은 Sync Group Response로 각 Consumer 별 Partition 할당을 보낸다.

 

 

2. Eager Rebalancing Protocol 

• 최근까지 사용된 방식
• 최대한 단순한 알고리즘을 사용하여 Rebalancing을 유지한다.
• 안전적인 측면에서는 좋지만, "Stop-the-world" Protocol이라 불리며, Group Consumer들이 Rebalancing하는 동안 Consume을 하지 못한다. (Synchronziation barrier)
• Consumer A - P1,P3 / Consumer B - P2가 존재한다고 하였을 때, Consumer C가 확장되어 들어온다고 하여보자.
• 기존 Consumer A,B와 Consumer C는 Join Group Request를 보내며 아래 그림과 같이 동작한다.

 

 

위 그림을 보면서, Consumer B는 별도로 Partition이 바뀌지 않고, Consumer A의 Partition1 도 변하지 않는데 이러한 Parition까지 Revoke하여 Consumer가 동작하지 못해야라는 의문이 생길 수 있다.

 

3. Incremental Cooperative Rebalancing Protocol

---

• 이상적인 Consumer Rebalancing으로 Version 2.5부터 사용이 가능하다.
• 위와 같이 Consumer A - P1,P3 / Consumer B - P2가 존재한다고 하였을 때, Consumer C가 확장되어 들어온다고 하여보자.
• Consumer A에 할당된 Partition 중 하나만 Consumer C로 이동하면 된다.
• Consumer A만 하나의 Partition 취소하는 동안만 중지하면 된다.

문제점 : Consumer는 자신의 Parition 중 어느 것이 다른곳으로 재할당되는지를 알 수 없다.

 

 

해결책 : Rebalancing을 2번하여 처리

• Join Group Request를 보내면서 시작, 소유한 Partition은 모두 보유 및 정보를 Group Coordinator에게 보낸다.
• Group Leader는 원하는대로 Consumer에 Partition 할당하지만, 소유권을 이전하는 Parition들은 취소한다(Revoke).
• Partition을 취소한 Consumer A는 Group에 Rejoin하여 취소된 Partition을 할당 할 수 있도록 2번쨰 Rebalance Trigger를 만든다.
• 빈번하게 Rebalancing되는 상황(Scale in/out, Rolling start, 등)으로 인한 Timeout이 우려되면 2.5 Version을 통해 Incremental Cooperative Rebalancing Protocol을 사용하는 것이 좋다.

결국 Stick Assignor를 2번 실행시킴으로써, 처음에는 Revoke 두번째는 Assign시키는 것이다.