ストリーム処理はデータを失うから怖い？それ、何とかできますよ！〜Apahe Kafkaを用いたストリーム処理における送達保証〜 (Open Source Conference 2025 Osaka 講演資料)

© 2025 NTT DATA 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 / 佐々⽊徹, 倉本健

© 2025 NTT DATA 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

このセッションでお話しするトピック
の
送達保証
データを確実に送受信し
データがなくなったりしないことを
保証すること

Section.1
Apache Kafkaについて

分散メッセージングシステム Apache Kafka
ストリーム処理/リアルタイム処理の処理基盤の中⼼となるOSSのプロダクト(ミドルウェア)で、
処理・活⽤基盤内でのストリームデータ(都度送受信される⼩さなデータの列)の適切な受け渡しを仲介してくれます
Apache Kafkaの詳細については公式のドキュメントも参考にしてください
https://kafka.apache.org/
データの生成データの活用
Apache
Kafka データの処理
(この流れをデータが⽣成されたときなど必要な時に都度実施する)
⽣成される
データを
順次受信
必要な時に
データを後続に
送信(連携)
これらを適切に/安定的に⾏ってくれることで
都度処理/リアルタイム処理の実現や拡張性の確保が
容易に⾏えるようになる
ストリーム/リアルタイム処理中のMQ(メッセージングキュー)相当の役割
※かなり乱暴な説明です

Kafkaによるストリーム処理の構成要素 (外部構造)
Kafkaによるストリーム処理のコンポーネントはBroker/Producer/Consumerによって構成されています
“ Producer ” “ Consumer ”
・・・
・・・
“ Broker ”
Kafkaにメッセージを送信する
クライアント
Kafkaからメッセージを受信する
クライアント
Kafkaのデータ送受信を担当する
サーバ

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作成時に指定します
・・・

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障害に備えます

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から送信

Kafkaへのメッセージ送信/Kafkaからのメッセージ受信の簡単なコード例 (2/2)
Kafkaが標準で提供しているAPI(Kafka API)を⽤いてのメッセージ受信は以下のようなコードで⾏います
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つずつ処理していく構造

補⾜: 本資料中の⽂⾔や図の記載
以降、この資料中では関係する⽂⾔や図を以下の通り記載します
関連する⽤語
図中の要素
⽤語意味補⾜など
メッセージロスト
Kafkaで取り扱っているデータが何らかの
原因で正しく処理されず失われること
Kafkaで取り扱う⼩さいデータ1つ1つをメッセージと呼び、
このデータが失われることを(データロスト)Kafkaではメッセージロストと呼称することが多いです
Kafkaクラスタ / Broker Producer / Consumer メッセージ
Prod.
Cons.
Producer
Consumer
Broker
※ クラスタの構成要素は他にKRaft(Controller)がありますが、
本資料では扱いません
※ 図中に同じ⾊のものが複数存在する場合、
同⼀メッセージの時系列の移動/変化などを意味します
(⾊にはそれぞれを識別する以上の意味はありません)

Section.2
Apache Kafkaの基本的な送達保証の機構
(Ack/Offset Commit)

基本的な課題: ストリーム処理におけるメッセージの取り扱いの難しさ
処理構造上、常時メッセージの送受信を⾏うためにサーバ障害時などの契機で重複や⽋損が起こりやすくなっています
Kafkaには送達保証の機構が備わっており、これを正しく利⽤することでそれらの影響を制御することができます
ストリーム処理にて
Kafkaを利⽤する
理由の1つに
なっています
Producer
Consumer
送信される
メッセージ
Kafkaクラスタ
受信される
メッセージ
Brokerに送信されたメッセージは
レプリケーションされ、それぞれディスクに記録されるが、
それら⼀連の処理の途上でいずれかの要素に障害が発⽣すると
メッセージの受け渡し/複製が期待通りに⾏えず⽋損や重複になる
Brokerが保持/記録しているメッセージを
順に受け取って後続の処理を⾏っていくが、
いずれかの要素に障害が発⽣すると、
処理の漏れや意図しない再処理が発⽣して⽋損や重複になる
Kafkaの送達保証はこうした障害時にもメッセージの受け渡しやメッセージの処理が正しく⾏えるように
双⽅の状態の確認や、処理の状況の記録が⾏えるような機構によって成り⽴っている

Kafkaに備わる基本的な送達保証のしくみ
Kafkaにはメッセージの送信時/受信〜処理時の確実なメッセージの取り扱いを保証するために以下の機構が備わっています
送達保証の機構対象とする区間動き⽬的
Ack Producer → Broker
(Brokerへのメッセージ送信)
Brokerが正しくメッセージを受け取れた際に
Producerに返答(Ack)を返す
メッセージのBrokerへの到達を保証し、
必要に応じて再送などを⾏えるようにする
Offset Commit Broker → Consumer
(Brokerからのメッセージ受信)
ConsumerがBrokerからメッセージを受け取れて、
必要な処理を終えたことを記録できる
どのメッセージまで受信・処理が完了したかを保証し、
処理漏れを防ぐ

メッセージ送信時のメッセージロストの背景
Producerは送ったが、Brokerは受け取れて/記録できていないという両者の状態の不整合でメッセージロストが発⽣します
典型的なケース: Brokerの障害とF/O
Prod.
同期
同期
Prod. 同期
停⽌
サーバなどの障害の発⽣時にはメッセージの再送など必要な対処を⾏う必要があるものの、
対処が必要な状況の検知⽅法と、送信したメッセージが影響を受けたかどうかの確認⽅法がないと対処できない
①
①
Producerがメッセージを送信し、
送信先PartitionのLeader Replicaを保持する
Brokerがメッセージを受信する
②
Leader Replicaにメッセージを送信した後、
同期が完了する前にBrokerに障害が発⽣すると
同期が不完全な状態になる
③
他の正常なBrokerがLeader Replicaを引き継ぐが、
このときに同期が不完全だったメッセージは失われる
②
②
③

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のとき
①
②
③
②

KafkaのAckのしくみを利⽤したメッセージの確実な送信
ProducerはBrokerから送信成功の応答(Ack)が返されることを期待してのメッセージ送信を⾏います
送信成功の応答が返らない場合は、メッセージの再送などの適切な処理を⾏うことでメッセージロストすることはありません
BrokerからのAckの返答を前提としたProducerの処理の流れ
Prod.
同期
同期
Prod. 同期
停⽌
Ack
Ack返らない
×
Ack
メッセージの送信〜Brokerからメッセージ送信成功のAckが返されるまでは
Producer側にメッセージ取り扱いの責任があり、
再送やなど適切な取り扱うようにしなければならないということ
①
Leader Replicaにメッセージを送信した後、
同期が完了する前にBrokerに障害が発⽣すると
同期が不完全な状態になる
同期が完了していないのでAckは返っていない
②
Brokerから成功のAckが返ってこないメッセージを
Producerは再送する
③ 再送のおかげでBrokerの障害による⽋損は発⽣しない
①
②
③
①

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から判断できないのが根本の問題
④ 最初に送信できたものと再送のものとでメッセージが重複する

Ackを利⽤した送達保証の限界 (2/2)
前項のようにAckが返らないことでBroker側の状態が分からない時の対応としては以下の2パターンがあります
業務要件を踏まえて重複または⽋損のどちらかを許容してもらうことになります
許容するものメッセージの重複メッセージの⽋損
セマンティクス At Least Once
(⽋損はしないが重複の可能性がある)
At Most Once
(重複はしないが⽋損の可能性がある)
Ackが返らないときに
Producerに求められる処理
当該メッセージの再送を⾏う当該メッセージについては何もしない
典型的な
選択される業務要件
⽋損すると価値がなくなるような
重要なデータを扱う場合など
同⼀メッセージに対する処理が
複数回⾏われては困る場合など
前項の例は
こちら

Ackの対応を考慮したKafkaへのメッセージ送信コードの例
KafkaProducer#sendのCallbackでAck返答時の処理を記述します
Ackに対する処理を追加したメッセージ送信
KafkaProducerのメッセージ送信は⾮同期で⾏われ、send呼び出し完了時点では送信が必ずしも完了いない
そのため、送信が完了しAckを受け取った際に⾏う処理をCallbackで記述することになっている
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の設定を追加
※デフォルト設定ですが敢えて明⽰的に指定しています

メッセージ受信〜処理時のメッセージロストの背景
Consumerの障害などの契機で、Broker上に本来存在し処理すべきメッセージを⾶ばして受信/処理してしまうことで
メッセージロストまたはメッセージ重複が発⽣することがあります
典型的なケース: Consumerの障害とF/O
Cons.
Cons.
① ConsumerがBrokerからメッセージを受信して処理を⾏っている
②
Consumerに障害が発⽣し、
別のConsumerにフェイルオーバされる
③
フェイルオーバされたConsumerは元のConsumerが
障害前(②まで)にどのメッセージまで受信・処理していたかわからず、
適当なメッセージから処理を再開して処理漏れが発⽣する
①
②
③
※ 再開位置がすでに受信・処理済みのメッセージからだったら重複が発⽣
※ Kafka外部の機構を利⽤したF/OやGroupRebalanceが該当します
Broker上にはメッセージは存在するため厳密にはデータを失ったわけではないが、
ストリーム処理のEnd-to-Endでは⼀部処理結果が不⾜するため
広義のメッセージロストに該当するという考え

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ごとに記録します

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はセットだが、
別の処理のため、⽚⽅だけが⾏われてしまうケースが避けられないことが原因

Offset Commitによる送達保証の限界 (2/2)
Consumerの障害時のメッセージの取り扱いとしては以下の2パターンが考えられます
ProducerのAckと同様に業務要件を踏まえて重複または⽋損のどちらかを許容してもらうことになります
許容するものメッセージの重複メッセージの⽋損
セマンティクス At Least Once
(⽋損はしないが重複の可能性がある)
At Most Once
(重複はしないが⽋損の可能性がある)
Offset Commitの
対応
受信メッセージに対する処理が
完全に完了した時にOffset Commit
メッセージを受信次第すぐにOffset Commit
典型的な
選択される業務要件
⽋損すると価値がなくなるような
重要なデータを扱う場合など
同⼀メッセージに対する処理が
複数回⾏われては困る場合など
前項の例は
こちら

Offset Commitを考慮したメッセージ受信〜処理のコード例
冒頭の基本的な処理にOffset Commitの処理を追加します
At Least Onceのときはメッセージの処理後に、At Most Onceのときはメッセージの受信直後/処理前にそれぞれ⾏います
consumer.subscribe(Collections.singletonList(topic));
Offset Commitを⾏うメッセージ受信 Offset Commitは⼀定のコスト(処理時間/Brokerの負荷)がかかる処理であることから、
1メッセージの処理ごとのCommitは避け、pollで返された複数メッセージの処理ごとに
1回などある程度まとめての実⾏が推奨される
while (true) {
for (ConsumerRecord<String, String> record : records) {
}
consumer.commitSync();
}
Offset Commitの処理
ここではAt Least Onceを実現すべく、
受信メッセージの処理が全て終わった後にCommitしている
props.setProperty("bootstrap.servers", "broker1:9092");
props.setProperty("enable.auto.commit", "false");
... Auto Offset Commitの無効設定
※後述
※⾚の網掛けの箇所が前述の基本コードとの変更点

整理: 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
送達保証の機構
実現できる送達保証 (セマンティクス)

Section.3
さらに⾼度なKafkaの送達保証の機構
(Transactional Producer/Idempotent Producer)

理想のセマンティクス 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が実現できます

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を⾏う

前項のKafkaからの/Kafkaへの送受信において、Exactly Onceの実現にあたっての課題は以下です
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つの処理は⾏うことになるため、問題は軽減されても解決はしない

前述の2つの課題を解決してExactly Onceを実現するために、Kafkaには2つの機構が⽤意されています
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

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)に⾏うことができる

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し、トランザクション開始時の整合が取れていた状態に戻すことで不整合による重複/⽋損を防⽌する
×

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内部のリトライに起因する重複を検知/排除する

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の保証はできない

Kafkaからの受信/Kafkaへの送信でのExactly Onceのコード例
前述のProducer/Consumerの処理を統合し、Transactional Producerに関する処理を追加します
producer.initTransactions();
consumer.subscribe(Collections.singletonList(srcTopic));
while (true) {
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を⾏います
トランザクションの初期化
※最初に⼀度だけ実⾏が必要
※記載スペースの都合で簡素に記載しているため、本番Appへの利⽤は注意してください
トランザクションの開始
Idempotent Producerは設定のみで機能するため、
コード上の対応は不要です
処理結果のKafkaへの送信

Section.4
Kafkaの送達保証に関連するトピック

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 の場合は失敗せずメッセージの送信が可能です
同期
されてない
同期
されてない

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では①のメモリへの記録の完了まででデータ記録/同期の完了とみなす

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不在となって処理が停⽌する
①
②
③
②

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の
周期
周期
周期
周期
周期
⼀定周期でOffset Commitを⾏うため、
処理のタイミングと合わせることができず、
特定のセマンティクスを実現できない

Closing
本セッションのクロージング

振り返り: このセッションで紹介した送達保証に関するキーワード
本セッションでは以下のキーワードとともに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の利⽤で実現

本資料に掲載されている商品名、会社名、サービス名は各社の商標または登録商標です

ストリーム処理はデータを失うから怖い？それ、何とかできますよ！〜Apahe Kafkaを用いたストリーム処理における送達保証〜 (Open Source Conference 2025 Osaka 講演資料)

Recommended

More Related Content

What's hot (20)

Similar to ストリーム処理はデータを失うから怖い？それ、何とかできますよ！〜Apahe Kafkaを用いたストリーム処理における送達保証〜 (Open Source Conference 2025 Osaka 講演資料) (20)

More from NTT DATA Technology & Innovation (20)