Apache Kafka on Kubernetes基礎編 ワークショップ QA 2021.11.24 分

Strimzi ● Apache KafkaのクラスタをKubernetes上で管理するOperator ○ オープンソースプロジェクト（ Apache License 2.0） ○ Cloud Native Computing Foundation (CNCF) ● Strimzi で提供するもの: ○ Apache Kafka, Connect, Zookeeper, MirrorMaker2 の コンテナイメージ ○ Apache Kafka clusters, topics and users を管理するKubernetes Operators

QA

Note: 冪等性はありますか？ ● Kafkaと外部サービス（DBなど）とが接続する場合、冪等性を完全に保つことはでき ません。 ○ メッセージの重複が発生する可能性があります *。 ● Kafka StreamsにはExactly Once Semantics (EOS)があります。 ○ KIP-129: Streams Exactly-Once Semantics ● よって、メッセージの重複検知の仕組みが必要。 ○ ○ EIPのIdempotent Consumerパターン ○ Outboxパターン** Q. *O’Reilly, Designing Event-DriveSystems：Chapter 12: Transactions, but Not as We Know Them - What Can’t Transactions Do? **マイクロサービスとメッセージングのなぜ [疑問編]：https://rheb.hatenablog.com/entry/microservices_messaging_2

Kafkaにおける冪等性の関連設定 ● Kafka Producer ○ Kafka内のイベントの重複、順序性 *を保証する設定の追加 ■ “enable.idempotence=true” ○ Producerのゾンビプロセス対策として、ユニークなトランザクション IDを利用 ■ “transactional.id” (default null) ● Kafka Consumer ○ Commitされたレコードのみを poll ■ “isolation.level=read_commited” (default read_uncommited) ● Kafka Streams ○ Kafka Streams内のConsumer/Producerにトランザクション処理を行う設定の追加 ■ “processing.guarantee=exactly_once” (default at_least_once) * Consumerの障害時には順序性は保証されなくなるので注意。

Note: Partition 0 Partition 1 Partition 2 Partition 3 Topic T1 Consumer1 Consumer Group Consumer2 Consumer3 Consumer4 Partition 0 Partition 1 Partition 2 Partition 3 Topic T1 Consumer1 Consumer Group Consumer2 Consumer3 Consumer4 リバランシング 図 Consumer 追加変更・障害時のリバランシング ● Consumer グループ内のConsumerの設定変更や障害があった場合、該当パー ティションをその他のConsumerが引き継ぎます。 ● ConsumerリーダーとGroupCoordinatorの連携によって各Consumerへのパー ティション割り当てを行います。 リバランシングとは？ Q.

リバランシングConsumer グループ ● Consumer リーダー ○ Consumer Groupに最初に参加したConsumerはリーダー。 ○ Consumer リーダーは、Group Coordinator（後述）と連携し、各Consumerに パーティションのサブセットを割り当てます。 ○ 割り当て方には、パーティション割り当てポリシー（PartitionAssignor）が使われ ます。 ■ Defaultポリシーには、RangeとRoundRobinとStickyAssignorがある。 ■ 独自の割り当て戦略を実装することも可能。

リバランシングConsumer グループ ● GroupCoordinator ○ 各Consumerグループに対して、Kafka Brokerに一つ存在。 ○ GroupCoordinatorは、各Consumerとハートビートを行い、死活監視を行う。 ○ Consumerの離脱を検知した時、GroupCoordinatorは生きているConsumerの みのリストをConsumerリーダーに受け渡す。その後、Consumerリーダーを任せ れたConsumerが、グループ内のConsumerのアサインメントを決める（次の図）

新しいコンシューマが参加または離脱すると、パーティションを 再割り当てするリバランシングが行われている(Eager Rebalancing) リバランシング ● 動作の流れ 参考：Consumer Group Internals: Rebalancing, Rebalancing....　 Coordinatorから リーダーを任されている 各Consumerへの アサインメントの決定 メンバーのハートビートが切れるとリバ ランスのステートへ

Note: Eager Rebalancing = Stop-the-world Rebalancing ● Stop-the-world Rebalancing ○ リバランシングが起きるとパーティションをリリースしないといけない（すべてのグループメンバーを 停止） ○ 運用や障害時にこのリバランシングではコストが大きい ○ 例： ■ スケールアップ・ダウン ■ Kubernetes プロセスダウン ■ ローリングアップグレード/アップデート Note: ● Incremental Cooperative Rebalancing ○ 稼働しているプロセスやタスクはそのままに、リバ ランシングを行う。 ○ まだデフォルト設定になっていないようなので、利 用時の設定方法は要確認。 KIP Applied to Released in KIP-429 Kafka Consumer 2.4.0 KIP-415 Kafka Connect 2.3.0 KIP-441 Kafka Stream 2.6.0 そこで Incremental Cooperative Rebalancing Note:

その他

AMQ Streams ● Apache Kafka のエンタープライズ向けディストリビューション ○ 2018年から Kafka をサポート、Kubernetes 上でも提供 ○ Red Hat AMQ Streams としてローンチ ● 提供形態 ○ Red Hat Enterprise Linux ○ Red Hat OpenShift Container Platform Apache Kafka on Kubernetes 基礎編 ワークショップ： https://redhat-open.connpass.com/ 　　Strimzi/AMQ Streamsをハンズオンをしてみたい

Thank you