More Related Content
![[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは？ by Taichi Umeda](https://cdn.slidesharecdn.com/ss_thumbnails/c16hitachikvsumeda-131215203911-phpapp02-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
Similar to ストリーム処理はデータを失うから怖い？それ、何とかできますよ！ 〜Apahe Kafkaを用いたストリーム処理における送達保証〜 (Open Source Conference 2025 Osaka 講演資料)
More from NTT DATA Technology & Innovation
ストリーム処理はデータを失うから怖い？それ、何とかできますよ！ 〜Apahe Kafkaを用いたストリーム処理における送達保証〜 (Open Source Conference 2025 Osaka 講演資料)
- 1. © 2025 NTTDATA Group Corporation © 2025 NTT DATA Group Corporation 2025/01/25 (Sat.) 15:00 – 15:45 Open Source Conference 2025 Osaka ストリーム処理はデータを失うから怖い︖ それ、何とかできますよ︕ 〜Apache Kafkaを⽤いたストリーム処理における送達保証〜 NTT DATA Group Corporation Innovation Technology Department, OSS Professional Services Sasaki Toru, Kuramoto Takeru / 佐々⽊ 徹, 倉本 健
- 2. © 2025 NTTDATA Group Corporation 2 ⾃⼰紹介 佐々⽊ 徹 (ささき とおる) 倉本 健 (くらもと たける) NTTデータグループ 技術⾰新統括本部 Innovation技術部 ⾼度OSS⽀援担当 NTTデータグループ 技術⾰新統括本部 Innovation技術部 ⾼度OSS⽀援担当 OSSの並列分散処理の技術⽀援/サポート業務に従事 特に最近では並列分散のストリーム処理(Apache Kafka)を担当 これらの技術について外部講演や技術書の執筆なども実施 ⼊社以来OSSのサポート業務に従事 これまでにKRaft(Kafkaの新しい管理機構) や 個別事情に特化したKafkaに関する検証の技術⾯も担当 これまでに執筆した書籍など l 翔泳社 Apache Spark⼊⾨ l 翔泳社 Apache Kafka l Software Design 2024/10
- 3. © 2025 NTTDATA Group Corporation 3 このセッションでお話しするトピック の 送達保証 データを確実に送受信し データがなくなったりしないことを 保証すること
- 4. © 2025 NTTDATA Group Corporation 4 Section.1 Apache Kafkaについて
- 5. © 2025 NTTDATA Group Corporation 5 分散メッセージングシステム Apache Kafka ストリーム処理/リアルタイム処理の処理基盤の中⼼となるOSSのプロダクト(ミドルウェア)で、 処理・活⽤基盤内でのストリームデータ(都度送受信される⼩さなデータの列)の適切な受け渡しを仲介してくれます Apache Kafkaの詳細については公式のドキュメントも参考にしてください https://kafka.apache.org/ データの生成 データの活用 Apache Kafka データの処理 (この流れをデータが⽣成されたときなど必要な時に都度実施する) ⽣成される データを 順次受信 必要な時に データを後続に 送信(連携) これらを適切に/安定的に⾏ってくれることで 都度処理/リアルタイム処理の実現や拡張性の確保が 容易に⾏えるようになる ストリーム/リアルタイム処理中のMQ(メッセージングキュー)相当の役割 ※かなり乱暴な説明です
- 6. © 2025 NTTDATA Group Corporation 6 Kafkaによるストリーム処理の構成要素 (外部構造) Kafkaによるストリーム処理のコンポーネントはBroker/Producer/Consumerによって構成されています “ Producer ” “ Consumer ” ・・・ ・・・ “ Broker ” Kafkaにメッセージを送信する クライアント Kafkaからメッセージを受信する クライアント Kafkaのデータ送受信を担当する サーバ
- 7. © 2025 NTTDATA Group Corporation 7 Kafkaによるストリーム処理の構成要素 (内部構造 1/2) ProducerからKafkaに送信されたメッセージは指定されたTopicのいずれかのPartitionに記録されます 各Replicaが Brokerに分散配置される Kafkaクラスタ Topic C Topic B Topic A Partition 1 Replica1 Replica2 Replica3 同期 Partition 0 Replica1 Replica2 Replica3 part.1 part.1 part.1 part.0 part.0 part.0 ・・・ P.0 R.1 P.1 R.1 P.0 R.2 P.1 R.2 P.0 R.3 P.1 R.3 Kafkaクラスタ上に作られる メッセージの論理的な入れもの 分散処理のために Topicを分割する単位 耐障害性のために作られる 各Partitionの複製 Topic Partition Replica 同期 同期 同期 ※Replicaの数はTopic作成時に指定します ※Partitionの数はTopic作成時に指定します ・・・
- 8. © 2025 NTTDATA Group Corporation 8 Kafkaによるストリーム処理の構成要素 (内部構造 2/2) 各PartitionのReplicaはLeader/Followerのいずれかの役割を担い、外部との送受信または同期を⾏います Topic Partition 2 Partition 1 Partition 0 Replica1 part.0 Replica2 part.0 Replica3 part.0 ・・・ LeaderReplica FollowerReplica FollowerReplica Producer Consumer メッセージ 送信 メッセージ 受信 同期 同期 LeaderReplica 各PartitionのReplicaの中から⾃動的に1つのみが選ばれてLeaderReplicaとして扱われます LeaderReplicaがProducer/Consumerとのメッセージの送受信を⾏います FollowerReplica 各PartitionのReplicaのうち、LeaderReplicaに選ばれなかったReplicaで、常にLeaderReplicaと同期を⾏っています Producer/Consumerとのメッセージの送受信は原則⾏わず、Broker障害に備えます
- 9. © 2025 NTTDATA Group Corporation 9 Kafkaへのメッセージ送信/Kafkaからのメッセージ受信の簡単なコード例 (1/2) Kafkaが標準で提供しているAPI(Kafka API)を⽤いてのメッセージ送信は以下のようなコードで⾏います Properties props = new Properties(); props.setProperty("bootstrap.server", "broker1:9092"); ... Producer<String, String> producer = new KafkaProducer<>(props); while (true) { (メッセージ送信前の処理...) ProducerRecord<String, String> record = new ProducerRecord<>(topic, key, value); producer.send(record); } 最もシンプルなKafkaへのメッセージ送信 Producerの設定 KafkaProducerオブジェクトの⽣成 KafkaProducer: Producerがメッセージ送信に利⽤するクラス メッセージ送信の処理 送信データ(Key/Value)をProducerRecordクラスに収め、 KafkaProducerから送信
- 10. © 2025 NTTDATA Group Corporation 10 Kafkaへのメッセージ送信/Kafkaからのメッセージ受信の簡単なコード例 (2/2) Kafkaが標準で提供しているAPI(Kafka API)を⽤いてのメッセージ受信は以下のようなコードで⾏います Properties props = new Properties(); props.setProperty("bootstrap.servers", "broker1:9092"); ... Consumer<String, String> consumer = new KafkaConsumer<>(props); consumer.subscribe(Collections.singletonList(topic)); while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(300L)); for (ConsumerRecord<String, String> record : records) { (受信メッセージの処理...) } } 最もシンプルなKafkaからのメッセージ受信 Consumerの設定 KafkaConsumerオブジェクトの⽣成と 受信Topicの設定(subscribe) KafkaConsumer: Consumerがメッセージ受信に利⽤するクラス メッセージ受信と受信メッセージの処理 KafkaConsumerのpollで複数のメッセージを受信し、 これをループで1つずつ処理していく構造
- 11. © 2025 NTTDATA Group Corporation 11 補⾜: 本資料中の⽂⾔や図の記載 以降、この資料中では関係する⽂⾔や図を以下の通り記載します 関連する⽤語 図中の要素 ⽤語 意味 補⾜など メッセージロスト Kafkaで取り扱っているデータが何らかの 原因で正しく処理されず失われること Kafkaで取り扱う⼩さいデータ1つ1つをメッセージと呼び、 このデータが失われることを(データロスト)Kafkaではメッセージロストと呼称することが多いです Kafkaクラスタ / Broker Producer / Consumer メッセージ Prod. Cons. Producer Consumer Broker ※ クラスタの構成要素は他にKRaft(Controller)がありますが、 本資料では扱いません ※ 図中に同じ⾊のものが複数存在する場合、 同⼀メッセージの時系列の移動/変化などを意味します (⾊にはそれぞれを識別する以上の意味はありません)
- 12. © 2025 NTTDATA Group Corporation 12 Section.2 Apache Kafkaの基本的な送達保証の機構 (Ack/Offset Commit)
- 13. © 2025 NTTDATA Group Corporation 13 基本的な課題: ストリーム処理におけるメッセージの取り扱いの難しさ 処理構造上、常時メッセージの送受信を⾏うためにサーバ障害時などの契機で重複や⽋損が起こりやすくなっています Kafkaには送達保証の機構が備わっており、これを正しく利⽤することでそれらの影響を制御することができます ストリーム処理にて Kafkaを利⽤する 理由の1つに なっています Producer Consumer 送信される メッセージ Kafkaクラスタ 受信される メッセージ Brokerに送信されたメッセージは レプリケーションされ、それぞれディスクに記録されるが、 それら⼀連の処理の途上でいずれかの要素に障害が発⽣すると メッセージの受け渡し/複製が期待通りに⾏えず⽋損や重複になる Brokerが保持/記録しているメッセージを 順に受け取って後続の処理を⾏っていくが、 いずれかの要素に障害が発⽣すると、 処理の漏れや意図しない再処理が発⽣して⽋損や重複になる Kafkaの送達保証はこうした障害時にもメッセージの受け渡しやメッセージの処理が正しく⾏えるように 双⽅の状態の確認や、処理の状況の記録が⾏えるような機構によって成り⽴っている
- 14. © 2025 NTTDATA Group Corporation 14 Kafkaに備わる基本的な送達保証のしくみ Kafkaにはメッセージの送信時/受信〜処理時の確実なメッセージの取り扱いを保証するために以下の機構が備わっています 送達保証の機構 対象とする区間 動き ⽬的 Ack Producer → Broker (Brokerへのメッセージ送信) Brokerが正しくメッセージを受け取れた際に Producerに返答(Ack)を返す メッセージのBrokerへの到達を保証し、 必要に応じて再送などを⾏えるようにする Offset Commit Broker → Consumer (Brokerからのメッセージ受信) ConsumerがBrokerからメッセージを受け取れて、 必要な処理を終えたことを記録できる どのメッセージまで受信・処理が完了したかを保証し、 処理漏れを防ぐ
- 15. © 2025 NTTDATA Group Corporation 15 メッセージ送信時のメッセージロストの背景 Producerは送ったが、Brokerは受け取れて/記録できていないという両者の状態の不整合でメッセージロストが発⽣します 典型的なケース: Brokerの障害とF/O Prod. 同期 同期 Prod. 同期 停⽌ サーバなどの障害の発⽣時にはメッセージの再送など必要な対処を⾏う必要があるものの、 対処が必要な状況の検知⽅法と、送信したメッセージが影響を受けたかどうかの確認⽅法がないと対処できない ① ① Producerがメッセージを送信し、 送信先PartitionのLeader Replicaを保持する Brokerがメッセージを受信する ② Leader Replicaにメッセージを送信した後、 同期が完了する前にBrokerに障害が発⽣すると 同期が不完全な状態になる ③ 他の正常なBrokerがLeader Replicaを引き継ぐが、 このときに同期が不完全だったメッセージは失われる ② ② ③
- 16. © 2025 NTTDATA Group Corporation 16 KafkaのAck 設定に基づいてProducerから送信されたメッセージをBrokerが正常に受け取った時に応答を返す機構です メッセージ送信〜Ack返答までの処理の流れ ※ 確実な送受信と速度との要求のバランスから選択しますが、 特別な要求/事情がなければacks=allでの利⽤が推奨されます Prod. 同期 同期 Ack Ack返答のタイミングはProducerの設定(acks)によって変更可能 設定 Ackの返却タイミング acks = 0 (BrokerからAckの返却をしない) acks = 1 Leader Replicaがメッセージを受信したとき acks = all 全ての正常なReplicaに同期が完了したとき Ack ① Producerがメッセージを送信し、 送信先PartitionのLeader Replicaを保持する Brokerがメッセージを受信する ② 他のReplicaにメッセージが同期される ③ 正常に動作している全てのReplicaに同期が完了したら ProducerにAckを返す ※acks=allのとき ① ② ③ ②
- 17. © 2025 NTTDATA Group Corporation 17 KafkaのAckのしくみを利⽤したメッセージの確実な送信 ProducerはBrokerから送信成功の応答(Ack)が返されることを期待してのメッセージ送信を⾏います 送信成功の応答が返らない場合は、メッセージの再送などの適切な処理を⾏うことでメッセージロストすることはありません BrokerからのAckの返答を前提としたProducerの処理の流れ Prod. 同期 同期 Prod. 同期 停⽌ Ack Ack返らない × Ack メッセージの送信〜Brokerからメッセージ送信成功のAckが返されるまでは Producer側にメッセージ取り扱いの責任があり、 再送やなど適切な取り扱うようにしなければならないということ ① Leader Replicaにメッセージを送信した後、 同期が完了する前にBrokerに障害が発⽣すると 同期が不完全な状態になる 同期が完了していないのでAckは返っていない ② Brokerから成功のAckが返ってこないメッセージを Producerは再送する ③ 再送のおかげでBrokerの障害による⽋損は発⽣しない ① ② ③ ①
- 18. © 2025 NTTDATA Group Corporation 18 Ackを利⽤した送達保証の限界 (1/2) 何らかの理由でAckの応答が届かず、Brokerのメッセージ受信状況がProducer側でわからなくなることがあります このときはメッセージの重複の発⽣を覚悟して再送処理などを⾏うことになります BrokerからのAckの応答が返らない時に再送にて重複が発⽣してしまうケース Prod. 同期 同期 Prod. 同期 停⽌ Ack返らない × Ack ① ③ ③ ① ② 同期完了後、Ackの返却までにLeader Replicaを保持する Brokerに障害が発⽣するとAckを返せない ③ Ackが返ってこないのでProducerはメッセージを再送する ProducerがLeader Replicaにメッセージを送信し、 全てのReplicaにメッセージが同期される ② Ackが返されないときに l 同期完了前にBrokerに障害が発⽣したのか l 同期完了後でAck返却前に障害が発⽣したのか のどちらかがProducerから判断できないのが根本の問題 ④ 最初に送信できたものと再送のものとでメッセージが重複する
- 19. © 2025 NTTDATA Group Corporation 19 Ackを利⽤した送達保証の限界 (2/2) 前項のようにAckが返らないことでBroker側の状態が分からない時の対応としては以下の2パターンがあります 業務要件を踏まえて重複または⽋損のどちらかを許容してもらうことになります 許容するもの メッセージの重複 メッセージの⽋損 セマンティクス At Least Once (⽋損はしないが重複の可能性がある) At Most Once (重複はしないが⽋損の可能性がある) Ackが返らないときに Producerに求められる処理 当該メッセージの再送を⾏う 当該メッセージについては何もしない 典型的な 選択される業務要件 ⽋損すると価値がなくなるような 重要なデータを扱う場合など 同⼀メッセージに対する処理が 複数回⾏われては困る場合など 前項の例は こちら
- 20. © 2025 NTTDATA Group Corporation 20 Ackの対応を考慮したKafkaへのメッセージ送信コードの例 KafkaProducer#sendのCallbackでAck返答時の処理を記述します Producer<String, String> producer = new KafkaProducer<>(props); Ackに対する処理を追加したメッセージ送信 KafkaProducerのメッセージ送信は⾮同期で⾏われ、send呼び出し完了時点では送信が必ずしも完了いない そのため、送信が完了しAckを受け取った際に⾏う処理をCallbackで記述することになっている Properties props = new Properties(); props.setProperty("bootstrap.server", "broker1:9092"); props.setProperty(”acks", ”all"); ... while (true) { (メッセージ送信前の処理...) ProducerRecord<String, String> record = new ProducerRecord<>(topic, key, value); producer.send(record, (metadata, exception) -> { if (exception == null) { (送信成功のAckの受信時の処理...) } else { (それ以外の時の処理...) } }); } ※⾚の網掛けの箇所が前述の基本コードとの変更点 Ackに関する処理(Callback)を追加 送信に失敗したときはexceptionに該当する例外が含まれるため、 nullかそうでないかで、成功Ackの受信時とそれ以外で分岐している このそれ以外(失敗)の処理の中でメッセージ再送などの処理を⾏う Producerの設定にAckの設定を追加 ※デフォルト設定ですが敢えて明⽰的に指定しています
- 21. © 2025 NTTDATA Group Corporation 21 メッセージ受信〜処理時のメッセージロストの背景 Consumerの障害などの契機で、Broker上に本来存在し処理すべきメッセージを⾶ばして受信/処理してしまうことで メッセージロストまたはメッセージ重複が発⽣することがあります 典型的なケース: Consumerの障害とF/O Cons. Cons. ① ConsumerがBrokerからメッセージを受信して処理を⾏っている ② Consumerに障害が発⽣し、 別のConsumerにフェイルオーバされる ③ フェイルオーバされたConsumerは元のConsumerが 障害前(②まで)にどのメッセージまで受信・処理していたかわからず、 適当なメッセージから処理を再開して処理漏れが発⽣する ① ② ③ ※ 再開位置がすでに受信・処理済みのメッセージからだったら重複が発⽣ ※ Kafka外部の機構を利⽤したF/OやGroupRebalanceが該当します Broker上にはメッセージは存在するため厳密にはデータを失ったわけではないが、 ストリーム処理のEnd-to-Endでは⼀部処理結果が不⾜するため 広義のメッセージロストに該当するという考え
- 22. © 2025 NTTDATA Group Corporation 22 KafkaのOffset Commit Consumerがメッセージを受信し処理を終えた時に、次に処理すべきメッセージの情報を記録する機構/機能です 起動後などにConsumerはこの記録を参照して、適切な位置から処理を開始/再開します Kafkaで取り扱うメッセージ1つ1つにはPartitionごとに Offsetという通番が付与されておりこれがOffset Commitの名前の由来です メッセージ処理〜処理再開時のOffset Commitの役割 ① Cons. Offset Commit 次は ② 次は Cons. Cons. ④ ③ ① ConsumerがBrokerからメッセージを受信して処理を⾏っている ② メッセージの受信・処理が完了したときに都度 Offset Commitを⾏い、次に受信・処理するメッセージを記録する ③ Consumerに障害が発⽣するなどし、 フェイルオーバなどで別のConsumerが処理を引き継ぐ ④ 処理を引き継いだConsumerは最後のOffset Commitの記録で どのメッセージから受信・処理すべきかを確認して処理再開 ※図中には明記していませんが、実際にはGroup/Partitionごとに記録します
- 23. © 2025 NTTDATA Group Corporation 23 Offset Commitによる送達保証の限界 (1/2) Offset CommitとConsumerの障害のタイミングによってはメッセージの重複/⽋損のどちらかが避けられないケースがあります こうしたケースにおける重複/⽋損の対応をあらかじめ決め、Offset Commitの実⾏タイミングを考慮しておく必要があります Offset Commitを利⽤してもメッセージの重複が発⽣してしまうケースの例 ① Cons. Offset Commitできず 次は ② 次は Cons. Cons. ④ ③ × × ① ConsumerがBrokerからメッセージを受信して処理を⾏っている ここでは と まで受信し、処理を終えているものとする ② と の受信・処理完了後、Offset Commitを⾏う前に Consumerに障害が発⽣し、古いOffset Commitの記録が残る ③ フェイルオーバなどで別のConsumerが処理を引き継ぐ ④ 処理を引き継いだConsumerはOffset Commitの記録を確認し、 と から処理の再開を⾏うべきと理解して処理再開 ※①よりさらに前の処理の際に⾏ったOffset Commitの記録が存在している前提 メッセージの受信・処理とOffset Commitはセットだが、 別の処理のため、⽚⽅だけが⾏われてしまうケースが避けられないことが原因
- 24. © 2025 NTTDATA Group Corporation 24 Offset Commitによる送達保証の限界 (2/2) Consumerの障害時のメッセージの取り扱いとしては以下の2パターンが考えられます ProducerのAckと同様に業務要件を踏まえて重複または⽋損のどちらかを許容してもらうことになります 許容するもの メッセージの重複 メッセージの⽋損 セマンティクス At Least Once (⽋損はしないが重複の可能性がある) At Most Once (重複はしないが⽋損の可能性がある) Offset Commitの 対応 受信メッセージに対する処理が 完全に完了した時にOffset Commit メッセージを受信次第すぐにOffset Commit 典型的な 選択される業務要件 ⽋損すると価値がなくなるような 重要なデータを扱う場合など 同⼀メッセージに対する処理が 複数回⾏われては困る場合など 前項の例は こちら
- 25. © 2025 NTTDATA Group Corporation 25 Offset Commitを考慮したメッセージ受信〜処理のコード例 冒頭の基本的な処理にOffset Commitの処理を追加します At Least Onceのときはメッセージの処理後に、At Most Onceのときはメッセージの受信直後/処理前にそれぞれ⾏います Consumer<String, String> consumer = new KafkaConsumer<>(props); consumer.subscribe(Collections.singletonList(topic)); Offset Commitを⾏うメッセージ受信 Offset Commitは⼀定のコスト(処理時間/Brokerの負荷)がかかる処理であることから、 1メッセージの処理ごとのCommitは避け、pollで返された複数メッセージの処理ごとに 1回などある程度まとめての実⾏が推奨される while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(300L)); for (ConsumerRecord<String, String> record : records) { (受信メッセージの処理...) } consumer.commitSync(); } Offset Commitの処理 ここではAt Least Onceを実現すべく、 受信メッセージの処理が全て終わった後にCommitしている Properties props = new Properties(); props.setProperty("bootstrap.servers", "broker1:9092"); props.setProperty("enable.auto.commit", "false"); ... Auto Offset Commitの無効設定 ※後述 ※⾚の網掛けの箇所が前述の基本コードとの変更点
- 26. © 2025 NTTDATA Group Corporation 26 整理: Kafkaに備わる基本的な送達保証 送信時にはAck/受信時にはOffset Commitをそれぞれ利⽤して、⼀定の送達保証を実現できます 送達保証の機構 対象とする区間 動き ⽬的 Ack Producer → Broker (Brokerへのメッセージ送信) Brokerが正しくメッセージを受け取れた際に Producerに返答(Ack)を返す メッセージのBrokerへの到達を保証し、 必要に応じて再送などを⾏えるようにする Offset Commit Broker → Consumer (Brokerからのメッセージ受信) ConsumerがBrokerからメッセージを受け取れて、 必要な処理を終えたことを記録できる どのメッセージまで受信・処理が完了したかを保証し、 処理漏れを防ぐ 実現できる送達保証 保証されること 許容する必要があること 実現⽅法 At Least Once メッセージが⽋損しないこと メッセージの重複 送信時: 成功のAckを受信するまでメッセージを再送 受信時: 受信メッセージの処理を全て終えてOffset Commit At Most Once メッセージが重複しないこと メッセージの⽋損 送信時: Ackの返答がない場合でもメッセージの再送はしない 受信時: メッセージの受信後すぐにOffset Commit 送達保証の機構 実現できる送達保証 (セマンティクス)
- 27. © 2025 NTTDATA Group Corporation 27 Section.3 さらに⾼度なKafkaの送達保証の機構 (Transactional Producer/Idempotent Producer)
- 28. © 2025 NTTDATA Group Corporation 28 理想のセマンティクス Exactly Once 前述のAck/Offset Commitでは送達保証に限界があり、特定のケースで重複または⽋損を確保する必要がありました ⼀⽅であらゆるケースで重複も⽋損も起こらない理想的なセマンティクスをExactly Onceと⾔います 実現できる送達保証 保証されること 許容する必要があること 実現⽅法 At Least Once メッセージが⽋損しないこと メッセージの重複 送信時: 成功のAckを受信するまでメッセージを再送 受信時: 受信メッセージの処理を全て終えてOffset Commit At Most Once メッセージが重複しないこと メッセージの⽋損 送信時: Ackの返答がない場合でもメッセージの再送はしない 受信時: メッセージの受信後すぐにOffset Commit Exactly Once メッセージが⽋損も重複もしないこと ー Kafkaからのメッセージ受信/Kafkaへのメッセージ送信において Idempotent ProducerとTransactional Producerを利⽤ KafkaにはAck/Offset Commit以外にもより⾼度な送達保証に関する機能が備わっており、 Kafkaからのメッセージの受信 + 処理結果のKafkaへの送信という限定的な条件下ながらExactly Onceが実現できます
- 29. © 2025 NTTDATA Group Corporation 29 Kafkaからの受信/Kafkaへの送信でExactly Onceの実現の課題 (1/3) Producer/Consumerの処理を組み合わせ、Kafkaからの受信/Kafkaへの送信の処理の流れは以下の通りです Kafkaからの/Kafkaへの送受信を⾏う処理の流れ アプリケーション Cons. Prod. 受信メッセージの処理 処理結果の メッセージ メッセージ送信 Ack メッセージ受信 Offset Commit メッセージ送信 Ack ① ② ③ ④ ⑤ ① Brokerからメッセージを受信 (複数受信される場合もある) ② 受信したメッセージの処理を⾏う ③ ②の処理結果をBrokerに送信し、BrokerからのAckを受け取る ④ ①で複数のメッセージを受信した場合はそれぞれ 処理結果をBrokerに送信し、BrokerからのAckを受け取る ※①よりさらに前の処理の際に⾏ったOffset Commitの記録が存在している前提 ⑤ ②で受信した全てのメッセージの処理・結果送信が完了したら Offset Commitを⾏う
- 30. © 2025 NTTDATA Group Corporation 30 Kafkaからの受信/Kafkaへの送信でExactly Onceの実現の課題 (2/3) 前項のKafkaからの/Kafkaへの送受信において、Exactly Onceの実現にあたっての課題は以下です Kafkaからの/Kafkaへの送受信を⾏う処理の流れ アプリケーション Cons. Prod. 受信メッセージの処理 処理結果の メッセージ メッセージ送信 Ack メッセージ受信 Offset Commit メッセージ送信 Ack 課題2 Producerが⾃動で⾏う再送に伴うメッセージ重複 課題1 複数回のメッセージ送信・Offset Commitの不整合 Kafkaが提供するProducerのAPIは設定によって Ackが返ってこないときに⾃動でリトライ(再送)を⾏う 前述の説明の通り、Ackが返らないときのBrokerの状態によって メッセージの重複が発⽣するケースがあり、 この⾃動リトライがメッセージ重複の原因となることがある ※ 設定で⾃動リトライを無効にできるが、⼀過性の問題に対処できなくなるためあまり望ましくない 1回の処理で複数のメッセージ受信、複数の結果の送信、 Offset Commitと複数の処理を⾏うことになる この過程でBrokerまたはアプリケーションに障害が発⽣すると 両者の状態に何らかの不整合が⽣じ、⽋損/重複の原因となる ※ 1度に受信するメッセージを1つに限定しても、結果の送信とOffset Commitという 2つの処理は⾏うことになるため、問題は軽減されても解決はしない
- 31. © 2025 NTTDATA Group Corporation 31 Kafkaからの受信/Kafkaへの送信でExactly Onceの実現の課題 (3/3) 前述の2つの課題を解決してExactly Onceを実現するために、Kafkaには2つの機構が⽤意されています Kafkaからの/Kafkaへの送受信を⾏う処理の流れ アプリケーション Cons. Prod. 受信メッセージの処理 処理結果の メッセージ メッセージ送信 Ack メッセージ受信 Offset Commit メッセージ送信 Ack 課題2 Producerが⾃動で⾏う再送に伴うメッセージ重複 課題1 複数回のメッセージ送信・Offset Commitの不整合 Kafkaが提供するProducerのAPIは設定によって Ackが返ってこないときに⾃動でリトライ(再送)を⾏う 前述の説明の通り、Ackが返らないときのBrokerの状態によって メッセージの重複が発⽣するケースがあり、 この⾃動リトライがメッセージ重複の原因となることがある ※ 設定で⾃動リトライを無効にできるが、⼀過性の問題に対処できなくなるためあまり望ましくない 1回の処理で複数のメッセージ受信、複数の結果の送信、 Offset Commitと複数の処理を⾏うことになる この過程でBrokerまたはアプリケーションに障害が発⽣すると 両者の状態に何らかの不整合が⽣じ、⽋損/重複の原因となる ※ 1度に受信するメッセージを1つに限定しても、結果の送信とOffset Commitという 2つの処理は⾏うことになるため、問題は軽減されても解決はしない Transactional Producer Idempotent Producer
- 32. © 2025 NTTDATA Group Corporation 32 Exactly Onceのための機構1: Transactional Producer (1/2) Kafkaへの複数のメッセージ送信とOffset Commitを原⼦的(Atomic)に⾏えるようにする機構です RDBMSなどに備わるトランザクションを 意識した機構です Transactional Producerのしくみによる原⼦的な処理 (Commit) アプリケーション Prod. メッセージ送信 Cons. 受信メッセージの処理 Ack Offset Commit Begin (トランザクション開始) Commit (トランザクション確定) メッセージ受信 ① ConsumerがBrokerからメッセージを受信する ② 受信したメッセージの処理を⾏う ③ Producerでトランザクションを開始(Begin)する ④ Producerからトランザクション中でメッセージを送信する 必要に応じて複数のメッセージをトランザクション中で送信する ⑤ Producerからトランザクション中でOffset Commitを⾏う ※ 本来はConsumerの操作だが、 トランザクション中で処理を⾏うためProducerがOffset Commitを⾏う トランザクションを確定(Commit)する ⑥ ① ③ ④ ⑤ ② ⑥ トランザクション中でメッセージ送信・Offset Commitを⾏うことで、 これらの操作(上記④〜⑤)を原⼦的(Atomic)に⾏うことができる
- 33. © 2025 NTTDATA Group Corporation 33 Exactly Onceのための機構1: Transactional Producer (2/2) メッセージ送信/Offset Commitの複数の処理を原⼦的(Atomic)に扱うことでBroker/アプリケーション間の不整合を防ぎます RDBMSなどに備わるトランザクションを 意識した機構です Transactional Producerのしくみによる原⼦的な処理 (Abort) アプリケーション Prod. メッセージ送信 Cons. 受信メッセージの処理 Ack Begin (トランザクション開始) Abort (トランザクション破棄) メッセージ受信 ① ConsumerがBrokerからメッセージを受信する ② 受信したメッセージの処理を⾏う ③ Producerでトランザクションを開始(Begin)する ④ Producerからトランザクション中でメッセージを送信する 必要に応じて複数のメッセージをトランザクション中で送信する ⑤ 何らかの理由でBrokerからAckが返されない ※Brokerの障害・F/OやNWの障害など Ackが返されないことを受けてトランザクションを破棄(Abort)する これにより④で送信したメッセージは破棄される ⑥ ① ③ ④ ⑤ ② ⑥ Ackが返されない場合やアプリケーションがフェイルオーバした場合など不整合が⽣じた可能性が疑われるときは、 トランザクションをAbortし、トランザクション開始時の整合が取れていた状態に戻すことで不整合による重複/⽋損を防⽌する ×
- 34. © 2025 NTTDATA Group Corporation 34 Exactly Onceのための機構2: Idempotent Producer Producerのリトライ機構のために同じメッセージを2度送信してしまったときに、それを検知し取り除きます Idempotentは冪等を意味します ※元々Exactly Once実現のために導⼊された機構ですが、現在ではAt Least Once/At Most Onceの際にも有効にしておくのが⼀般的です Idempotent Producerのしくみによる重複除去 Prod. 同期 同期 Ack返らない × ① ② 最新の通し番号: 101 通し番号101 Prod. × ③ 最新の通し番号: 101 通し番号101 ① メッセージ送信の際にメッセージごとにインクリメント(1ずつ増加)する 通し番号を⼀緒に送信し記録する ② 何らかの理由でAckが返らず、 Producerは⾃動でリトライ(同じメッセージの再送)を試みる ③ 通し番号が期待と違うメッセージをBrokerが拒否する (インクリメントして本来は通し番号102が期待されるが⼀致しないため) ※ 実際には通し番号はProducer/Partitionごとに個別にカウントされる ※ 通し番号はProducer内部で⾃動で付与され、明⽰的な設定は⾏わない ※ Producerの設定でリトライが有効に設定されている場合 通し番号(Sequence Number)を利⽤する Idempotent Producerによって Transactional Producerでは対応できない Producer内部のリトライに起因する重複を検知/排除する
- 35. © 2025 NTTDATA Group Corporation 35 Transactional Producer/Idempotent ProducerによるExactly Onceの限界 これらの機構で保証されるExactly Onceは処理結果としてKafkaに格納されるメッセージ/記録に対してであり、 途中の処理は複数回実⾏される可能性があることから、Kafka以外に副作⽤を及ぼす処理ではExactly Onceにはなりません KafkaのしくみによるExactly Onceで処理が2回⾏われる例 App Cons. Prod. 外部の データストア トランザクション開始 / 処理結果の送信 受信メッセージの処理 追加/更新 ×Ack返らない トランザクション破棄 App Cons. Prod. トランザクション開始 / 処理結果の送信 受信メッセージの処理 Ack返る Offset Commit/ トランザクション確定 冒頭で説明したExactly Onceの制約の「Kafkaからの受信/Kafkaへの送信」は 既存のKafkaの機構ではKafka以外に副作⽤を及ぼす処理に対処できないことに起因している 追加/更新 ① メッセージを受信し、受信したメッセージの処理で 外部のデータストアへの追加・更新を⾏う ② トランザクションを開始して処理結果を送信する ③ Ackが返らないなど不整合が⽣じた可能性があるときに トランザクションを破棄する ④ トランザクションを破棄したため、 同じメッセージをもう⼀度受信して再度処理を⾏う ⑤ 同じメッセージの処理の過程で 外部のデータストアへの追加・更新を再び⾏い①と重複する ① メッセージ受信 メッセージ受信 ⑤ ④ ② ③ ※ RDBの⼀意性制約などで重複を検知/回避できる場合もあるが、 適⽤可否は業務処理によるため、汎⽤のExactly Onceの保証はできない
- 36. © 2025 NTTDATA Group Corporation 36 Kafkaからの受信/Kafkaへの送信でのExactly Onceのコード例 前述のProducer/Consumerの処理を統合し、Transactional Producerに関する処理を追加します producer.initTransactions(); consumer.subscribe(Collections.singletonList(srcTopic)); while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(300L)); producer.beginTransaction(); for (ConsumerRecord<String, String> record: records) { (受信メッセージの処理...) ProducerRecord<String, String> result = new ProducerRecord<>(destTopic, key, value); producer.send(record, (metadata, exception) -> { if (exception == null) { (送信成功のAckの受信時の処理...) } else { (それ以外の時の処理...) } }) } producer.sendOffsetsToTransaction(offsets, consumer.groupMetadata()); producer.commitTransaction(); } Offset Commitとトランザクションの確定 ※前述の通りKafkaProducerからOffset Commitを⾏います Consumer<String, String> consumer = new KafkaConsumer<>(props); Producer<String, String> producer = new KafkaProducer<>(props); トランザクションの初期化 ※最初に⼀度だけ実⾏が必要 ※記載スペースの都合で簡素に記載しているため、本番Appへの利⽤は注意してください トランザクションの開始 Idempotent Producerは設定のみで機能するため、 コード上の対応は不要です 処理結果のKafkaへの送信
- 37. © 2025 NTTDATA Group Corporation 37 Section.4 Kafkaの送達保証に関連するトピック
- 38. © 2025 NTTDATA Group Corporation 38 min.insync.replicas (1/2) 同期が取れているReplicaが指定数以上でないと、当該Partitionに対して送受信させないようにするBrokerの設定 取り扱われるメッセージの安全性の確保を⽬的としています 以前はProduce時のみ影響を与えるパラメタでしたが、 KIP-966の対応でConsume時にも影響を受けるパラメタになりました min.insync.replicasによる送受信の制限の例 (min.insync.replicas=2のとき) Prod. 同期 できない 同期 できない Broker障害などで 正常なReplicaがmin.insync.replicasを下回る時には Producerからのメッセージ送信は失敗(拒否)する ※ 必要なReplica数が存在するかどうかはPartition単位で判断されるため、 クラスタを構成するBrokerの台数によっては 送信が失敗するPartition/問題ないPartitionがそれぞれ⽣じることがあります Brokerの障害などでBrokerのメッセージの受信後に メッセージの同期がmin.insync.replicasに満たない場合は 当該メッセージをConsumerは受信できない Cons. × × ※ Producerの設定が acks=all の場合のみで、 acks=0 または 1 の場合は失敗せずメッセージの送信が可能です 同期 されてない 同期 されてない
- 39. © 2025 NTTDATA Group Corporation 39 min.insync.replicas (2/2) Kafkaではメッセージをディスクに記録しますが、⾼スループット実現のためにProducerから送信後に即座にFlushはされません 複数Brokerの保持で安全性を確保する思想になっており、min.insync.replicasはこれを保証するためのパラメタです BrokerがProducerからメッセージを受け取った時の処理の流れ Prod. 同期 同期 受信メッセージ ① ② ① ディスクに記録するメッセージを⼀旦メモリ上におく ※ ディスクキャッシュ・ページキャッシュと呼ばれる機構 ② ①の後で明⽰的にFlushされたとき、メモリのキャッシュ領域の解放 が必要になった時などにディスクに記録 ※ Linuxなどの⼀般的な挙動でKafka特有の挙動ではない 同左 同左 KafkaはProducerから受け取った 全てのメッセージをディスクに記録する 前提 メモリ上にのみ存在するデータは電源断などの障害によって失われるが、 Kafkaは複数のBrokerのメモリ上に保持されているから安全という考え この安全性思想のために、Broker障害などで同期が規定数に満たないときは メッセージを受け取らないようにするのが min.insync.replicas の⽬的 Kafkaでは①のメモリへの記録の完了まででデータ記録/同期の完了とみなす
- 40. © 2025 NTTDATA Group Corporation 40 Unclean Leader Election Brokerに障害が発⽣した時に同期が取れているReplicaが存在しない時に ⼀定のメッセージロストを覚悟して同期の取れていないReplicaをLeaderに選出することができる機構です Unclean Leader Electionを起因とするメッセージロストの発⽣ 設計時の限度を超える障害が発⽣したときにメッセージの保全を優先するか、処理継続を優先するかのトレードオフ データロストが許容できないときは本機能は無効にして利⽤する Unclean Leader Electionは unclean.leader.election.enable を Brokerの設定に追加します (true/false) Cons. × 同期 されてない 同期 されてない メッセージを保持してないので 受信できない ① 他のReplicaに同期できてないメッセージを保持した Brokerが障害で停⽌する ② 本来は完全に同期ができているBrokerのReplicaが Leaderを引き継ぐが、ここでは該当するReplicaが存在しない ③ 同期できておらず本来LeaderになれないReplicaが メッセージロストを覚悟して別のLeaderになり、処理を引き継ぐ この③の挙動をUnclean Leader Electionと呼び、 この機能を無効にしているときは、 Leader不在となって処理が停⽌する ① ② ③ ②
- 41. © 2025 NTTDATA Group Corporation 41 Auto Offset Commit ConsumerのOffset Commitを⼀定間隔ごとに⾃動で⾏う機能です 処理完了や受信直後などの処理の状況を考慮せずにCommitするため、利⽤には⼀定のデメリットもあります 現時点のApache Kafka(バージョン3.9.0)では デフォルトで有効となっているため、明⽰的に無効に設定する必要があります Auto Offset CommitによるOffset Commitとセマンティクス Auto Offset Commitは enable.auto.commit を Consumerの設定に追加します (true/false) AP処理記述の簡素化と、Offset Commitのタイミングの厳格な制御のトレードオフ 特定のセマンティクス(At Least Once/At Most Once)の実現のためには本機能は無効にして利⽤する Cons. 受信〜処理の流れ メッセージ受信 処理 処理 メッセージ受信 処理 処理 At Most Onceのとき Offset Commit At Most Onceのとき Offset Commit At Least Onceのとき Offset Commit At Least Onceのとき Offset Commit Offset Commit Offset Commit Offset Commit Offset Commit Auto Offset Commitの 周期 Auto Offset Commitの 周期 Auto Offset Commitの 周期 Auto Offset Commitの 周期 Auto Offset Commitの 周期 ⼀定周期でOffset Commitを⾏うため、 処理のタイミングと合わせることができず、 特定のセマンティクスを実現できない
- 42. © 2025 NTTDATA Group Corporation 42 Closing 本セッションのクロージング
- 43. © 2025 NTTDATA Group Corporation 43 振り返り: このセッションで紹介した送達保証に関するキーワード 本セッションでは以下のキーワードとともにKafkaの送達保証について紹介しました キーワード キーワードのサマリ Ack BrokerがProducerからメッセージを送信され、設定に応じた同期まで完了したときに、Producerに応答を返すしくみ Offset Commit ConsumerがBrokerからメッセージを受信し必要な処理を完了したときに、次に処理すべきメッセージをBroker側に記録するしくみ Transactional Producer Producerが複数のメッセージ送信とOffset Commitを原⼦的(Atomic)に扱うためのしくみ Idempotent Producer Producerがメッセージ送信での内部機構による送信のリトライ時に、通し番号の照合で重複を検知・排除するしくみ At Least Once メッセージ送受信時のセマンティクスの1つで、重複の可能性はあるが⽋損が起こらないことを保証するもの KafkaではProducerのAck⾮受信時の再送、Consumerの受信メッセージの処理完了時のOffset Commitで実現 At Most Once メッセージ送受信時のセマンティクスの1つで、⽋損の可能性はあるが重複が起こらないことを保証するもの KafkaではProducerのAck⾮受信時に再送しない、Consumerのメッセージ受信直後のOffset Commitで実現 Exactly Once メッセージ送受信時のセマンティクスの1つで、重複も⽋損も起こらないことを保証するもの KafkaではKafkaからの受信/への送信の限定的な条件下でTransactional ProducerとIdempotent Producerの利⽤で実現
- 44.