2019年3月14日に開催されたHadoop / Spark Conference Japan 2019での講演資料です。 

1. © 2019 NTT DATA Corporation
2019/3/14
株式会社NTTデータ 技術革新統括本部 システム技術本部 方式技術部 データプロフェッショナルサービス
土橋 昌
Apache Kafkaって本当に大丈夫？
～故障検証のオーバービューと興味深い挙動の紹介～
Hadoop/Spark Conference Japan 2019

2. © 2019 NTT DATA Corporation 2
[目次]
1. 自己紹介
2. Apache Kafkaの基本の振り返り、オーバービュー
3. 故障検証のオーバービュー
4. 故障検証の中からピックアップして紹介

3. © 2019 NTT DATA Corporation 3
自己紹介

4. © 2019 NTT DATA Corporation 4
Who am I?
• Bio
– Engineering and researching about the distributed computing, open source
software, and so on.
– Consulting about IT infrastructure for the data processing and data
utilization
– Leading technical teams
• Presentations / Publications
– Spark Summit, Strata Data Conference, Kafka Summit, DataWorks
(Hadoop) Summit, Developer Summit, and so on.
– Shoeisha “Apache Spark入門”, ”Apache Kafka”
Masaru Dobashi
(Manager,
IT Arhchitect)

5. © 2019 NTT DATA Corporation 5
データプロフェッショナルサービスチームの経歴
• Expert / professional team of Open-Source Software for over 15 years
• Hadoop
• Over 10 years of experience
• Over 100 production cases
• Solution that covers security, application development,
cluster construction etc.
• Deep and wide knowledge of enterprise customers’ requirements
• Design, integrate, deploy, and operate clusters in the range of 10 - 1200+ servers
• Customers in telecommunication, finance, automobile, and corporate fields
• Support service to resolve troubles related to Hadoop / Spark / Open-Source Software
OSSのスペシャリストとして15年以上活動
Hadoopは10年以上

6. © 2019 NTT DATA Corporation 6
Hadoop / Sparkプロフェッショナルサービスを提供するチームです
• Deliver “Best Practices” of Hadoop / Spark at every step in the life cycle enabling customer
success
• Vendor neutral expertise from the source and best IT architecture for “Total Data Utilization”
Planning & Design Deployment Migration Operation
Hadoop / Spark
Consulting
Hadoop / Spark
System Integration
Hadoop / Spark
Evaluation and Verification Support
Hadoop / Spark Training Service
Hadoop / Spark
Support
Platform &
Application
Hadoop / Spark
PoC
Data Integration,
Data Analytics
Middleware
Support Services
ベストプラクティスの展開

7. © 2019 NTT DATA Corporation 7
今回のApache Kafkaの故障検証もチームで営んでいます
田中 酒井 吉田 土橋 都築 佐々木
KafkaのR&Dや案件に携わっているメンバたち（のうち、その場にいた人を集めて）

8. © 2019 NTT DATA Corporation 8
Apache Kafkaの基本の振り返り、オーバービュー

9. © 2019 NTT DATA Corporation 9
 複数台のサーバで多くのストリームデータを処理する分散メッセージングシステム
Apache Kafka(以降、Kakfa)とは
都度送られてくる
メッセージ(データ)を
受け取り、
必要に応じて
受け取ったメッセージを
都度送る
・
・
・
・
・
・
Kafka
クラスタ

10. © 2019 NTT DATA Corporation 10
 Kafkaには実際の利用シーンで有効な機能/しくみが複数存在
Apache Kafkaの特徴的な機能やしくみ 他にもたくさん
ありますが、
特に代表的な
もののみ記載
スケールアウト  利用するサーバ台数を増やすことで、全体の性能を上げられる
メッセージの到達保証  送受信するメッセージが正しく送信/受信されたかを確認できる
 そのため、送受信するデータを失いにくい
データをディスクに
永続化する  ディスク容量に応じて長期間の過去データを保存できる
連携できるプロダクトが
多く存在  他のプロダクトと連携して、便利にデータの送受信や処理が行える
Kafka
Kafka
Kafka
💛Kafka
Spark
Fluentd

11. © 2019 NTT DATA Corporation 11
 Kafkaは幅広いユースケースに適用することができる
Apache Kafkaのユースケース 他にもたくさん
ありますが、
特に代表的な
もののみ記載
データハブの
中心として
 複数の場所で発生・生成するデータを1か所に集め、
データの保存・処理を行う場所に受け渡すデータ基盤の
中核として利用
ストリーム処理の
パイプラインとして
 ストリーム処理を行うパイプラインの中の、
処理データのバッファリングを行う役割として利用
 障害時などの再処理のために一定期間データを保持する
スケーラブルな
メッセージングキューとして
 スケールアウトによって将来の拡張が容易である
メッセージングキューとして利用
Kafka
Kafka
Kafka
Spark Streaming

12. © 2019 NTT DATA Corporation 12
 複数台のサーバで多くのストリームデータを処理する分散メッセージングシステム
Kafkaの構成要素
・
・
・
・
・
・
ZooKeeper
(Kafkaクラスタ管理で利用)
Kafka
クラスタ

13. © 2019 NTT DATA Corporation 13
Kafkaの構成要素
 Broker: Kafkaクラスタを構成するサーバ
 Producer: Kafkaにメッセージを送信するクライアント
 Consumer: Kafkaからメッセージを受信するクライアント
…
Producer
(メッセージを送信)
Consumer
(メッセージを受信)
Broker
(クラスタを構成)
ZooKeeper
(Kafkaクラスタ管理で利用)
… Kafka
クラスタ

14. © 2019 NTT DATA Corporation 14
Kafka内部の論理構造 1/2
 Topic: Kafkaクラスタの上のメッセージの論理的な入れもの
 Partition: Topicを分割する単位
 Replica: 各Partitionの複製でBrokerに記録される実体
…P.0
R.1
P.1
R.1
P.0
R.2
P.1
R.2
P.0
R.3
P.1
R.3
各Replicaが
それぞれ違うBrokerに
配置される
Topic C
Topic B
…
Topic A
…
Partition 0 part. 0
Replica1
part. 0
Replica2
part. 0
Replica3複製 複製
Partition 1 part. 1
Replica1
part. 1
Replica2
part. 1
Replica3複製 複製
Kafkaクラスタ

15. © 2019 NTT DATA Corporation 15
Kafka内部の論理構造 2/2
 Offset: Partition内の各メッセージに付与された通番
 送信されたメッセージは順番にいずれかのPartitionに入れられ、順番にOffsetが付与される
 Topic名、Partition番号、Offsetの組み合わせでKafkaクラスタ内のメッセージが一意に特定
Topic C
Topic B
…
Topic A
…
Partition 0 part. 0
Replica1
part. 0
Replica2
part. 0
Replica3複製 複製
Partition 1 part. 1
Replica1
part. 1
Replica2
part. 1
Replica3複製 複製
・・・
1234NN+1N+2
Offset
メッセージメッセージ
送信
新しい 古い

16. © 2019 NTT DATA Corporation 16
基本動作: Kafkaへのメッセージ送信の流れ
 あるメッセージをProducerから送る場合
※ LeaderReplica: Producer/Cosumerのメッセージのやり取りを行うReplicaのこと
各PartitionのReplica内で1つずつ選出される。LeaderReplica以外のReplicaのことをFollowerReplicaという
Producer
Replica
Replica
Replica
①Producerがメッセージを送る ※LeaderReplica
※FollowerReplica
※FollowerReplica
②メッセージが
すべてのReplicaに
同期される
③Ackを返す ④ディスクに記録
④ディスクに記録
④ディスクに記録
※メッセージは1つずつ送られるわけではないが、
ここでは記載簡素化のために1つとして記載
Kafkaクラスタ

17. © 2019 NTT DATA Corporation 17
基本動作: Kafkaからのメッセージ受信の流れ
 あるメッセージをConsumerが取得する場合
※ LeaderReplica: Producer/Cosumerのメッセージのやり取りを行うReplicaのこと
各PartitionのReplica内で1つずつ選出される。LeaderReplica以外のReplicaのことをFollowerReplicaという
Consumer
Replica
Replica
Replica
①メッセージ取得リクエストを送る ※LeaderReplica
※FollowerReplica
※FollowerReplica
④メッセージを受け取り、処理をしたら
OffsetCommitを行う
③メッセージを送る
②ディスクから
読み出す
メッセージ読み出しに
対しては何もしない
※メッセージは1つずつ送られるわけではないが、
ここでは記載簡素化のために1つとして記載
Kafkaクラスタ

18. © 2019 NTT DATA Corporation 18
ZooKeeperで管理される情報と連係について
Kafkaは、クラスタの状態やトピック等の管理情報をZooKeeperに保存し、それを利用して内部イベント
を発生させたり、状態変化を検知したりする。したがってKafkaを利用する際にはZooKeeperが必須。
トピック作成時のZooKeeperとの連係イメージ ZooKeeperに保存される情報の例
Topic・Partition情報
Logに関するイベント通知
Broker情報
ISRに関するイベント通知
Controller情報
など① クライアントが作成するトピックの情報をZooKeeperに書き込む
② 代表のBroker(Controller)が検知し、トピック作成処理を開始
③ トピックのデータを保持するBrokerに作成のリクエストを送信
クライアント
トピック
作成情報
ZooKeeper
① ②
③
Kafkaクラスタ

19. © 2019 NTT DATA Corporation 19
Kafkaが受け取ったメッセージのディスクへの記録
• Kafkaはメッセージのディスクへの記録に3種類のファイルを使用
Broker
Kafka用のデータディレクトリ
logファイル
Indexファイル
TimeIndexファイル
あるTopicのPartition用のディレクトリ
別のTopicのPartition用のディレクトリ
…
※実際にはスナップショットやファイルローテーションなどによりほかにもファイルが存在する
Producerから受け取った
メッセージを記録
ログファイルのインデックス、タイム
スタンプのインデックス情報を記
録
ログファイルのインデックス、タイム
スタンプのインデックス情報を記
録

20. © 2019 NTT DATA Corporation 20
ログを構成するSegment（ファイル）
0 1 2 3 4 5
0 1 2 3 4 5 6 7 …
0 1 2 3 4
メッセージが増えていき、
ひとつのSegmentがいっぱい
（※）になると…
新しいSegmentに書き込むよ
うになる
t
t + 1
t + α
※ここでは簡単化のために3オフセットずつSegmentを区切っている
Segment0 Segment3 Segment6
※サイズ以外にも時間トリガも存在
時刻t + αにおいてメッセージが
書き込まれているActive Segment
時刻
ログは1個の長いファイルではなく、Segmentに分割されて保存される

21. © 2019 NTT DATA Corporation 21
故障検証のOverview

22. © 2019 NTT DATA Corporation 22
故障検証の動機
• X年前からのストリーム処理への期待の高まり、データハブの需要の高
まりとともに用いられることが多くなったKafka
• 「データを流す」役割はシステム全体の中で見ても重要な役割
• スケールアウトする構成を前提としており、部分故障への耐性を持って
いるとはいうものの、実際のところどういう挙動を示すのかは把握しておき
たい。
• 【当たり前】のことからコツコツと。最終的に機械化するにしても、基本的
な仕様を実装、挙動の両面から押さえておこう。

23. © 2019 NTT DATA Corporation 23
故障検証の前提
• 秘孔をつくパターンを完全に網羅するのは事実上不可能だが、プロダク
トの仕様、構造から故障可能性を類推したり、ブラックボックス的に試
すことは可能
– Kafkaはある程度シンプルなので
• Kafkaに関連する環境情報
– Kafkaのバージョン：1.1.0※検証当時の最新
– Broker4台（うち、3台がZooKeeper同居）

24. © 2019 NTT DATA Corporation 24
想定される故障の例 (1/4)
# 大分類 小分類 故障する箇所/故障モード 状況の詳細(補足があるもののみ)
0 kernel panic
1 電源断
2 CPU故障
3 メモリ故障
4 HDD故障
5 RAIDコントローラ故障
6 NIC故障
7 teaming異常
8 1台のサーバの接続先ポート故障 LinkUp
9 1台のサーバの接続先ポート故障 LinkDown
10 複数台(4台とか)接続先ポート故障 LinkDown
11 スイッチ1台故障 LinkDown
12 断線
13 ControllerのBrokerが死んだ場合
14 Controller以外のBrokerが死んだ場合
15 ZooKeeper プロセス死亡(3台中1台ダウン)
16 ZooKeeperアンサンブル死亡(3台中2台同時にダウン)
17 ZooKeeper全台ダウン
Kafka brokerプロセス死亡
ZooKeeper
Brokerサーバ故障 物理障害
スイッチ系障害 物理故障
プロセス障害 Kafka Broker
関連する物理コンポーネントの故障を想定
関連する論理コンポーネントの故障を想定

25. © 2019 NTT DATA Corporation 25
想定される故障の例 (2/4)
18 Kafka以外のプロセスによるCPU100%使用
19 Kafka broker GC祭り
20 Kafka以外でのネットワーク100%使用による輻輳
21 1台だけネットワークレイテンシが著しく劣化
22 log.dir/log.dirsで指定したディレクトリ(ディスク)の一部がフル
23 log.dir/log.dirsで指定したディレクトリ(ディスク)の全てがフル
24 KAFKA_LOG_DIRで指定してディレクトリ(ディスク)がフル
25 OS領域などKafkaが使用していないディスクがフル
26 log.dir/log.dirsで指定したディレクトリ(ディスク)
27 KAFKA_LOG_DIRで指定したディレクトリ(ディスク)
28 OS領域などKafkaが使用していないディスク
29 著しくSWAPしている
30 Memory full
31 Kafka broker OOM
32 mmap枯渇
33 log.dir/log.dirsで指定したディレクトリ(ディスク)の一部がフル
34 log.dir/log.dirsで指定したディレクトリ(ディスク)の全てがフル
35 KAFKA_LOG_DIRで指定してディレクトリ(ディスク)がフル
36 OS領域などKafkaが使用していないディスクがフル
37 fd枯渇
inode枯渇
リソース不足 CPU
NW
ディスク Disk full
Kafka以外のプロセスによるDisk帯域100%使用
メモリ
OSリソース
マシンのリソース不足を再現

26. © 2019 NTT DATA Corporation 26
想定される故障の例 (3/4)
38 Indexファイルが破損している
39 Indexファイルが存在しない
40 想定しないIndexファイルが存在する
41 ログファイルが破損している
42 ログファイルが存在しない
43 想定しないログファイルが存在する
44 Timestampファイルが破損している
45 Timestampファイルが存在しない
46 想定しないTimestampファイルが存在する
47 存在するはずのディレクトリが存在しない
48 存在しないはずのディレクトリが存在する
49 既存のディレクトリをコピーしたディレクトリが存在する
50 不要なディレクトリが存在している
51 Kafkaが使用しないファイルがディレクトリに存在(同一拡張子)
52 Kafkaが使用しないファイルがディレクトリに存在(異なる拡張子)
53 GracefulShutdown後にBrokerを再起動
54 異常終了後にBrokerを再起動
55 IDの重複 同一のBroker IDをもつBrokerが起動した場合の挙動
Broker準正常系動作 ログファイル Indexファイルの異常
ログファイルの異常
Timestampファイルの異常
ディレクトリ異常
規定ファイル以外が存在
Broker ID 自動採番が有効の場合の再起動
データの実態やメタデータを保持するファイルの故障を再現
Brokerの動作に必要な情報の故障を再現

27. © 2019 NTT DATA Corporation 27
想定される故障の例 (4/4)
56 Live Broker(正常に動作しているBroker)の挙動
57 Producerの挙動
58 Consumerの挙動
59 ディスク容量が不足
60 Partition数をReassignment前よりも増やす
61 Partition数をReassignment前よりも減らす
62 Replica数をReassignment前よりも増やす
63 Replica数をReassignment前よりも減らす
64 Preferred Replicaの偏り Auto Leader Relabalaceの挙動
65 Brokerの挙動
66 Producerの挙動
67 Consumerの挙動
68 周辺ツールの挙動
69 Brokerの挙動
70 Producerの挙動
71 Consumerの挙動
72 Brokerの挙動
73 重複したメッセージの扱い
Unclean Leader Election 発生時の挙動
Offsetの重複
Broker準正常系動作 ISRの縮退 ISRがmin.insync.replicasを下回る
Partiton Reassignment
Partition数を変動させる
Replica数を変動させる
リクエストキュー溢れ Brokerのリクエストキュー内の要素が規定値を超える
マシンのリソース不足を再現

28. © 2019 NTT DATA Corporation 28
検証結果オーバービュー
故障種別 故障箇所/項目 観測された挙動概要
物理障害 Brokerサーバ物理故障 故障したBrokerは停止するかクラスタから切り離される
クラスタ全体でデータ欠損などは発生しなかった(※1)
論理障害 Brokerプロセス障害 他のBrokerが処理を引継ぎ、クラスタは動作を継続
クラスタ全体でデータ欠損などは発生しなかった(※1)
ZooKeeper関連故障 アンサンブル故障が生じた時はZooKeeperに直接依存しない処理は
動作を継続したが、クラスタ状態変化には追従できなくなる。
Brokerサーバなどのリソース不足 不足するリソースによってはBrokerが停止することがある
クラスタ全体に影響は波及せず、動作は継続された(※1)
データファイル(ログファイル)の異常 欠損・破損の条件によってはBrokerが停止する（起動しない）ことが
ある
準正常系 クラスタの縮退
(min.insync.replicasを下回る)
メッセージの送受信が停止するケースがある
他のBrokerの縮退をトリガとしてBrokerが停止することはなかった
Partition Reassignment 移動中もメッセージの送受信が可能
移動先のBrokerがディスクフルの場合、移動に失敗しBrokerが停止
Auto Leader Rebalance Preferred ReplicaがISRから離脱しているときは、Replicaリストの先
にあるものが優先される
※1: 単一障害のみを想定
※ 試験を実施した条件下での結果であり、条件が異なると挙動が異なる場合があります

29. © 2019 NTT DATA Corporation 29
故障検証のサマリ
• 公式ドキュメント※1に記載されたアーキテクチャから想像される挙動とお
おむね合致する
– なお、本検証ではExactly Onceセマンティクス関連の機能は使用しなかったの
で、 メッセージ重複したケースも想定通り存在した
• ただし実際の挙動を確認した結果、運用する際には注意したい項目も
いくつか見られた
⇒例：ZKアンサンブル故障、データファイル(ログファイル)の異常
※1 https://kafka.apache.org/documentation/#introduction、など

30. © 2019 NTT DATA Corporation 30
故障検証の中からピックアップして紹介

31. © 2019 NTT DATA Corporation 31
今回ピックアップしたトピック
• 1. ZooKeeperアンサンブル故障
– 動機：
Kafkaの管理情報を保持するZooKeeperのサービスが利用不可になった時に
何が起き、運用上どういうインパクトが考えられるかを把握する。
• 2. データファイル(ログファイル)の異常
– 動機：
Kafkaの重要要素であるデータをストレージに保存する仕組みに問題が生じたら
どうなるのかを把握する。

32. © 2019 NTT DATA Corporation 32
1. ZooKeeperアンサンブル故障：検証前提
• 以下の環境で検証を実施
• ZooKeeperアンサンブルの動作が停止(3台中2台が停止)した際の以下の挙動を確認
項目 利用した環境
Kafkaバージョン Confluent Platform4.1 (Apache Kafka 1.1.0がベース)※1
クラスタ構成 Broker4台構成(うち3台はZooKeeperと同居)
Kafkaクライアント 付属のConsole Producer, Console Consumerを利用
コンポーネント メッセージ送受信開始のタイミング 確認内容
Producer
アンサンブル障害前から継続して送信
エラーなくメッセージの送信が行えるかどうか
アンサンブル障害後から送信開始
Consumer
(旧API)
アンサンブル障害前から継続して受信
エラーなくメッセージの受信が行えるかどうか
アンサンブル障害後から受信開始
Consumer
(新API)
アンサンブル障害前から継続して受信
アンサンブル障害後から受信開始
注: 旧APIを利用した
Consumerは最新の2系では
コードベースで削除されている
※1: 一部追試では2系の動作も確認

33. © 2019 NTT DATA Corporation 33
1. ZooKeeperアンサンブル故障：検証結果サマリ
旧APIのConsumerは故障後はメッセージの受信ができなくなるが、
新APIのクライアントは故障後※1もメッセージの送受信が共に継続できた
• 確認項目と確認結果
コンポーネント メッセージ送受信開始のタイミング 確認内容
Producer
アンサンブル障害前から継続して送信 エラーなくメッセージの送信が継続できた
アンサンブル障害後から送信開始 エラーなくメッセージの送信が開始でき、正常に送信できた
Consumer
(旧API)
アンサンブル障害前から継続して受信 ZooKeeperへの接続エラーが発生し、正常に受信できず
アンサンブル障害後から受信開始 ZooKeeperへの接続エラーが発生し、正常に受信できず
Consumer
(新API)
アンサンブル障害前から継続して受信 エラーなくメッセージの受信が継続できた
アンサンブル障害後から受信開始 エラーなくメッセージの受信が開始でき、正常に受信できた
※1：少なくとも、本検証において故障後数十分程度では、という意味

34. © 2019 NTT DATA Corporation 34
1. ZooKeeperアンサンブル故障：新旧APIによる挙動の違い
• APIの違いごとにZooKeeperの使い方が異なることが挙動に影響
– 旧APIのConsumer: クラスタ情報の取得、Offsetの記録などにZooKeeperを
利用している
– Producer/新APIのConsumer: BrokerのみがZooKeeperを利用し、Client
はBrokerのみと通信
• 同様にTopic情報の取得などもアンサンブル故障後は行えなくなる
– Topic情報の取得など一部の操作もZooKeeperを利用しているため

35. © 2019 NTT DATA Corporation 35
1. ZooKeeperアンサンブル故障: 新APIで故障後に一部のBrokerが停止した場合
• 一部のBrokerが停止した際からメッセージの送受信が行えなくなる
– Brokerの生死監視やリーダレプリカの再選出などの機構もZooKeeperに依存しているが、Brokerの停止
後に動作を継続するために必要なこれらの処理がアンサンブル故障のため実施されないことから
Brokerの生死監視の仕組み
エフェメラルノード
エフェメラルノード
エフェメラルノード
各BrokerがZooKeeper上にエフェメラルノードを作成し、
それらのノードの変化を監視することで行っている
※エフェメラルノード:
ZooKeeperとコネクションを張っている間のみ有効なノード(情報の記録場所)
障害などでコネクションが失われるとエフェメラルノードも削除される
ZooKeeper
Broker群

36. © 2019 NTT DATA Corporation 36
1. ZooKeeperアンサンブル故障：考察
• 結果: ZooKeeperを直接利用しないAPI・機構はアンサンブル故障後の刹那に停止
するわけではない
– ZooKeeperを直接利用していないProducerや新APIのConsumerはアンサンブル故障後も、そ
れ自身が例外を発することなく、またメッセージの送受信が継続される
– その後Broker故障などクラスタ状態に変化を及ぼす事象が生じた場合はその限りではない
• 考察: ZooKeeperアンサンブル故障時の挙動を考慮した対応方法がベター
– 利用しているAPIによっては直ちに動作を停止するわけではないので、監視の仕組みや運用手順
上で考慮するのがよい（安全に止めて切り替えるなど）

37. © 2019 NTT DATA Corporation 37
2. データファイル(ログファイル)の異常：検証前提
• 以下の環境で検証を実施
• 以下の故障パターンにおける挙動を確認
大項目 小項目 検証実施方法
Indexファイル
存在すべきファイルが存在しない 当該のIndexファイルを削除してBrokerを起動
ファイルが破損(規定サイズ) 8*N Byteのダミーファイルで実際のIndexファイルを置き換えてBrokerを起動
ファイルが破損(規定サイズ以外) 8*N Byte以外のダミーファイルで実際のIndexファイルを置き換えてBrokerを起動
Logファイル
存在すべきファイルが存在しない 当該のLogファイルを削除してBrokerを起動
ファイルが破損 容量が同じダミーファイルで実際のLogファイルを置き換えてBrokerを起動
項目 利用した環境
Kafkaバージョン Confluent Platform4.1 (Apache Kafka 1.1.0がベース)
クラスタ構成 Broker4台構成(うち3台はZooKeeperと同居)
Kafkaクライアント 付属のConsole Producer, Console Consumerを利用

38. © 2019 NTT DATA Corporation 38
2. データファイル(ログファイル)の異常：検証結果サマリ(非Graceful Shutdown
時)
BrokerがGracefulでない停止の後の起動では
可能な限りのリカバリ処理が行われ、いずれのケースでもBrokerが起動する
• 検証中に確認した障害パターンと結果概要
故障ファイル 故障内容 確認された事象
Indexファイル
存在すべきファイルが存在しない 対応するLogファイルを読み込んで、正常な状態にリカバリされる
ファイルが破損(規定サイズ) 対応するLogファイルを読み込んで、正常な状態にリカバリされる
ファイルが破損(規定サイズ以外) 対応するLogファイルを読み込んで、正常な状態にリカバリされる
Logファイル
存在すべきファイルが存在しない
対応するIndexファイルが存在する場合はIndexファイルが削除され、
正常な位置までOffsetが戻されるか、欠番になる。起動後のメッセージの送受信は可能
ファイルが破損
破損しているLogファイルに含まれるメッセージのOffsetは欠番となり、読み込めなくなる
Brokerは起動し、メッセージの送受信は可能

39. © 2019 NTT DATA Corporation 39
2. データファイル(ログファイル)の異常：検証結果サマリ(Graceful Shutdown
時)
BrokerがGracefulに停止した後の起動では
一部の状況において正常にリカバリされないケースが存在する
• 検証中に確認した障害パターンと結果概要
故障ファイル 故障内容 確認された事象
Indexファイル
存在すべきファイルが存在しない 空のIndexファイルが再度生成される(内容の復元はされない)
ファイルが破損(規定サイズ)
Active SegmentのIndexファイルが破損している場合Broker起動失敗することがあ
る。Non-Active SegmentのIndexファイルが破損している場合はメッセージ送受信
は可能。
ファイルが破損(規定サイズ以外) 対応するLogファイルを読み込んで、正常な状態にリカバリされる
Logファイル
存在すべきファイルが存在しない
対応するIndexファイルが存在する場合は削除され、
正常な位置までOffsetが戻されるか、欠番になる。メッセージの送信は可能
ファイルが破損
Active SegmentのLogファイルが破損している場合Brokerの起動に失敗する
それ以外の場合Brokerは起動し、破損しているLogファイル以外のメッセージは読める

40. © 2019 NTT DATA Corporation 40
2. データファイル(ログファイル)の異常: 考察
• 故障の仕方や挙動のバリエーションが多数存在する
– 総じて、発生した故障に対して極力Kafka側でリカバリするような挙動を見せた
– なお、本講演では触れていないがsnapshotファイルなど複数ファイルが欠損した場合
などはさらに挙動が異なる
– 運用上想定されるパターンについてあらかじめ考慮しておくのが望ましい
• LogSegment#sanityCheck 周りの実装は1.1.0 → 3/14現在のtrunkに
至るまでそこそこ変わっているので、バージョンに注意したい（KAFKA-7283
など）

41. © 2019 NTT DATA Corporation 41
クロージング

42. © 2019 NTT DATA Corporation 42
本セッションのまとめ
• NTTデータのチーム紹介 ＆ Kafkaのオーバービュー紹介
• Kafkaの故障検証のオーバービュー紹介
– 概ね想定通りの挙動だが、一部注意した方が望ましい挙動も見られた
• ZooKeeperアンサンブルの故障とデータファイル(ログファイル)の異常の
トピックを例として紹介
– ZooKeeperを直接利用しない読み書きは、ZooKeeperアンサンブル故障発
生刹那に動作を停止するわけではない。監視と運用で考慮したい。
– Logファイルの故障の仕方によってはBrokerが起動しない。運用で考慮したい。

43. © 2019 NTT DATA Corporation