broker.id 0 broker.id N broker.id 1 . . . Kafka and the group management protocol 12 The maximum parallelism is determined by the number of partitions . . .
of partitions 13 topic-partition-0 topic-partition-1 topic-partition-2 topic-partition-N APP APP APP APP Kafka and the group management protocol kafka cluster
workload is splited 0 1 APP 2 3 2 3 17 Scale out for the 1st time topic-partition-0 topic-partition-1 topic-partition-2 topic-partition-3 kafka cluster
across instances when the workload is splited 0 1 2 2 topic-partition-0 topic-partition-1 topic-partition-2 topic-partition-3 kafka cluster Scale out for the 1st time 3 3
changelog topic, which is compacted my-application-state-partition-3-changelog Topic Partition Topic Segments Compacted Topic Segments 1 GB Streams as a changelog of states 19
group 2. JoinRequest: All active members ask to join the group 3. JoinResponse: Group Coordinator accepts 4. SyncGroup: All accepted new members ask for workload Rebalance Protocol 25 kafka broker Group Coordinator Streaming Application Consumer Group Rebalance 1 JoinRequest 2 JoinResponse 3 SyncGroup 4
appends, it impacts everyone This is sometime referred as stop the world effect Incremental rebalancing may be a solution Due to dynamic membership, we can not avoid rebalancing when scaling out or upgrading 31
of effort is put on the standardization of storage for Kubernetes ➢ StateFulSets is in beta and it’s already a game changer ❖ A few improvements are in developpement to make Scaling out for Kafka Streams easier: ➢ Static Membership ➢ Incremental rebalancing 33
with Docker and Kubernetes - by Gwen Shapira and Matthias J. Sax ◦ Everything You Always Wanted to Know About Kafka’s Rebalance Protocol but Were Afraid to Ask - by Matthias J. Sax ◦ Horizontal Pod Autoscaler Reloaded - Scale on Custom Metrics - Maciej Pytel & Solly Ross • Pictures: ◦ Photo by Shwetha Shankar on Unsplash ◦ Photo by chuttersnap on Unsplash ◦ Photo by Bonnie Kittle on Unsplash Resources 37