SlideShare a Scribd company logo
© 2019 NTT DATA Corporation
2019/3/14
株式会社NTTデータ 技術革新統括本部 システム技術本部 方式技術部 データプロフェッショナルサービス
土橋 昌
Apache Kafkaって本当に大丈夫?
~故障検証のオーバービューと興味深い挙動の紹介~
Hadoop/Spark Conference Japan 2019
© 2019 NTT DATA Corporation 2
[目次]
1. 自己紹介
2. Apache Kafkaの基本の振り返り、オーバービュー
3. 故障検証のオーバービュー
4. 故障検証の中からピックアップして紹介
© 2019 NTT DATA Corporation 3
自己紹介
© 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)
© 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年以上
© 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
ベストプラクティスの展開
© 2019 NTT DATA Corporation 7
今回のApache Kafkaの故障検証もチームで営んでいます
田中 酒井 吉田 土橋 都築 佐々木
KafkaのR&Dや案件に携わっているメンバたち(のうち、その場にいた人を集めて)
© 2019 NTT DATA Corporation 8
Apache Kafkaの基本の振り返り、オーバービュー
© 2019 NTT DATA Corporation 9
 複数台のサーバで多くのストリームデータを処理する分散メッセージングシステム
Apache Kafka(以降、Kakfa)とは
都度送られてくる
メッセージ(データ)を
受け取り、
必要に応じて
受け取ったメッセージを
都度送る
・
・
・
・
・
・
Kafka
クラスタ
© 2019 NTT DATA Corporation 10
 Kafkaには実際の利用シーンで有効な機能/しくみが複数存在
Apache Kafkaの特徴的な機能やしくみ 他にもたくさん
ありますが、
特に代表的な
もののみ記載
スケールアウト  利用するサーバ台数を増やすことで、全体の性能を上げられる
メッセージの到達保証  送受信するメッセージが正しく送信/受信されたかを確認できる
 そのため、送受信するデータを失いにくい
データをディスクに
永続化する  ディスク容量に応じて長期間の過去データを保存できる
連携できるプロダクトが
多く存在  他のプロダクトと連携して、便利にデータの送受信や処理が行える
Kafka
Kafka
Kafka
💛Kafka
Spark
Fluentd
© 2019 NTT DATA Corporation 11
 Kafkaは幅広いユースケースに適用することができる
Apache Kafkaのユースケース 他にもたくさん
ありますが、
特に代表的な
もののみ記載
データハブの
中心として
 複数の場所で発生・生成するデータを1か所に集め、
データの保存・処理を行う場所に受け渡すデータ基盤の
中核として利用
ストリーム処理の
パイプラインとして
 ストリーム処理を行うパイプラインの中の、
処理データのバッファリングを行う役割として利用
 障害時などの再処理のために一定期間データを保持する
スケーラブルな
メッセージングキューとして
 スケールアウトによって将来の拡張が容易である
メッセージングキューとして利用
Kafka
Kafka
Kafka
Spark Streaming
© 2019 NTT DATA Corporation 12
 複数台のサーバで多くのストリームデータを処理する分散メッセージングシステム
Kafkaの構成要素
・
・
・
・
・
・
ZooKeeper
(Kafkaクラスタ管理で利用)
Kafka
クラスタ
© 2019 NTT DATA Corporation 13
Kafkaの構成要素
 Broker: Kafkaクラスタを構成するサーバ
 Producer: Kafkaにメッセージを送信するクライアント
 Consumer: Kafkaからメッセージを受信するクライアント
…
Producer
(メッセージを送信)
Consumer
(メッセージを受信)
Broker
(クラスタを構成)
ZooKeeper
(Kafkaクラスタ管理で利用)
… Kafka
クラスタ
© 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クラスタ
© 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
メッセージメッセージ
送信
新しい 古い
© 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クラスタ
© 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クラスタ
© 2019 NTT DATA Corporation 18
ZooKeeperで管理される情報と連係について
Kafkaは、クラスタの状態やトピック等の管理情報をZooKeeperに保存し、それを利用して内部イベント
を発生させたり、状態変化を検知したりする。したがってKafkaを利用する際にはZooKeeperが必須。
トピック作成時のZooKeeperとの連係イメージ ZooKeeperに保存される情報の例
Topic・Partition情報
Logに関するイベント通知
Broker情報
ISRに関するイベント通知
Controller情報
など① クライアントが作成するトピックの情報をZooKeeperに書き込む
② 代表のBroker(Controller)が検知し、トピック作成処理を開始
③ トピックのデータを保持するBrokerに作成のリクエストを送信
クライアント
トピック
作成情報
ZooKeeper
① ②
③
Kafkaクラスタ
© 2019 NTT DATA Corporation 19
Kafkaが受け取ったメッセージのディスクへの記録
• Kafkaはメッセージのディスクへの記録に3種類のファイルを使用
Broker
Kafka用のデータディレクトリ
logファイル
Indexファイル
TimeIndexファイル
あるTopicのPartition用のディレクトリ
別のTopicのPartition用のディレクトリ
…
※実際にはスナップショットやファイルローテーションなどによりほかにもファイルが存在する
Producerから受け取った
メッセージを記録
ログファイルのインデックス、タイム
スタンプのインデックス情報を記
録
ログファイルのインデックス、タイム
スタンプのインデックス情報を記
録
© 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に分割されて保存される
© 2019 NTT DATA Corporation 21
故障検証のOverview
© 2019 NTT DATA Corporation 22
故障検証の動機
• X年前からのストリーム処理への期待の高まり、データハブの需要の高
まりとともに用いられることが多くなったKafka
• 「データを流す」役割はシステム全体の中で見ても重要な役割
• スケールアウトする構成を前提としており、部分故障への耐性を持って
いるとはいうものの、実際のところどういう挙動を示すのかは把握しておき
たい。
• 【当たり前】のことからコツコツと。最終的に機械化するにしても、基本的
な仕様を実装、挙動の両面から押さえておこう。
© 2019 NTT DATA Corporation 23
故障検証の前提
• 秘孔をつくパターンを完全に網羅するのは事実上不可能だが、プロダク
トの仕様、構造から故障可能性を類推したり、ブラックボックス的に試
すことは可能
– Kafkaはある程度シンプルなので
• Kafkaに関連する環境情報
– Kafkaのバージョン:1.1.0※検証当時の最新
– Broker4台(うち、3台がZooKeeper同居)
© 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
関連する物理コンポーネントの故障を想定
関連する論理コンポーネントの故障を想定
© 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リソース
マシンのリソース不足を再現
© 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の動作に必要な情報の故障を再現
© 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のリクエストキュー内の要素が規定値を超える
マシンのリソース不足を再現
© 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: 単一障害のみを想定
※ 試験を実施した条件下での結果であり、条件が異なると挙動が異なる場合があります
© 2019 NTT DATA Corporation 29
故障検証のサマリ
• 公式ドキュメント※1に記載されたアーキテクチャから想像される挙動とお
おむね合致する
– なお、本検証ではExactly Onceセマンティクス関連の機能は使用しなかったの
で、 メッセージ重複したケースも想定通り存在した
• ただし実際の挙動を確認した結果、運用する際には注意したい項目も
いくつか見られた
⇒例:ZKアンサンブル故障、データファイル(ログファイル)の異常
※1 https://kafka.apache.org/documentation/#introduction、など
© 2019 NTT DATA Corporation 30
故障検証の中からピックアップして紹介
© 2019 NTT DATA Corporation 31
今回ピックアップしたトピック
• 1. ZooKeeperアンサンブル故障
– 動機:
Kafkaの管理情報を保持するZooKeeperのサービスが利用不可になった時に
何が起き、運用上どういうインパクトが考えられるかを把握する。
• 2. データファイル(ログファイル)の異常
– 動機:
Kafkaの重要要素であるデータをストレージに保存する仕組みに問題が生じたら
どうなるのかを把握する。
© 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系の動作も確認
© 2019 NTT DATA Corporation 33
1. ZooKeeperアンサンブル故障:検証結果サマリ
旧APIのConsumerは故障後はメッセージの受信ができなくなるが、
新APIのクライアントは故障後※1もメッセージの送受信が共に継続できた
• 確認項目と確認結果
コンポーネント メッセージ送受信開始のタイミング 確認内容
Producer
アンサンブル障害前から継続して送信 エラーなくメッセージの送信が継続できた
アンサンブル障害後から送信開始 エラーなくメッセージの送信が開始でき、正常に送信できた
Consumer
(旧API)
アンサンブル障害前から継続して受信 ZooKeeperへの接続エラーが発生し、正常に受信できず
アンサンブル障害後から受信開始 ZooKeeperへの接続エラーが発生し、正常に受信できず
Consumer
(新API)
アンサンブル障害前から継続して受信 エラーなくメッセージの受信が継続できた
アンサンブル障害後から受信開始 エラーなくメッセージの受信が開始でき、正常に受信できた
※1:少なくとも、本検証において故障後数十分程度では、という意味
© 2019 NTT DATA Corporation 34
1. ZooKeeperアンサンブル故障:新旧APIによる挙動の違い
• APIの違いごとにZooKeeperの使い方が異なることが挙動に影響
– 旧APIのConsumer: クラスタ情報の取得、Offsetの記録などにZooKeeperを
利用している
– Producer/新APIのConsumer: BrokerのみがZooKeeperを利用し、Client
はBrokerのみと通信
• 同様にTopic情報の取得などもアンサンブル故障後は行えなくなる
– Topic情報の取得など一部の操作もZooKeeperを利用しているため
© 2019 NTT DATA Corporation 35
1. ZooKeeperアンサンブル故障: 新APIで故障後に一部のBrokerが停止した場合
• 一部のBrokerが停止した際からメッセージの送受信が行えなくなる
– Brokerの生死監視やリーダレプリカの再選出などの機構もZooKeeperに依存しているが、Brokerの停止
後に動作を継続するために必要なこれらの処理がアンサンブル故障のため実施されないことから
Brokerの生死監視の仕組み
エフェメラルノード
エフェメラルノード
エフェメラルノード
各BrokerがZooKeeper上にエフェメラルノードを作成し、
それらのノードの変化を監視することで行っている
※エフェメラルノード:
ZooKeeperとコネクションを張っている間のみ有効なノード(情報の記録場所)
障害などでコネクションが失われるとエフェメラルノードも削除される
ZooKeeper
Broker群
© 2019 NTT DATA Corporation 36
1. ZooKeeperアンサンブル故障:考察
• 結果: ZooKeeperを直接利用しないAPI・機構はアンサンブル故障後の刹那に停止
するわけではない
– ZooKeeperを直接利用していないProducerや新APIのConsumerはアンサンブル故障後も、そ
れ自身が例外を発することなく、またメッセージの送受信が継続される
– その後Broker故障などクラスタ状態に変化を及ぼす事象が生じた場合はその限りではない
• 考察: ZooKeeperアンサンブル故障時の挙動を考慮した対応方法がベター
– 利用しているAPIによっては直ちに動作を停止するわけではないので、監視の仕組みや運用手順
上で考慮するのがよい(安全に止めて切り替えるなど)
© 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を利用
© 2019 NTT DATA Corporation 38
2. データファイル(ログファイル)の異常:検証結果サマリ(非Graceful Shutdown
時)
BrokerがGracefulでない停止の後の起動では
可能な限りのリカバリ処理が行われ、いずれのケースでもBrokerが起動する
• 検証中に確認した障害パターンと結果概要
故障ファイル 故障内容 確認された事象
Indexファイル
存在すべきファイルが存在しない 対応するLogファイルを読み込んで、正常な状態にリカバリされる
ファイルが破損(規定サイズ) 対応するLogファイルを読み込んで、正常な状態にリカバリされる
ファイルが破損(規定サイズ以外) 対応するLogファイルを読み込んで、正常な状態にリカバリされる
Logファイル
存在すべきファイルが存在しない
対応するIndexファイルが存在する場合はIndexファイルが削除され、
正常な位置までOffsetが戻されるか、欠番になる。起動後のメッセージの送受信は可能
ファイルが破損
破損しているLogファイルに含まれるメッセージのOffsetは欠番となり、読み込めなくなる
Brokerは起動し、メッセージの送受信は可能
© 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ファイル以外のメッセージは読める
© 2019 NTT DATA Corporation 40
2. データファイル(ログファイル)の異常: 考察
• 故障の仕方や挙動のバリエーションが多数存在する
– 総じて、発生した故障に対して極力Kafka側でリカバリするような挙動を見せた
– なお、本講演では触れていないがsnapshotファイルなど複数ファイルが欠損した場合
などはさらに挙動が異なる
– 運用上想定されるパターンについてあらかじめ考慮しておくのが望ましい
• LogSegment#sanityCheck 周りの実装は1.1.0 → 3/14現在のtrunkに
至るまでそこそこ変わっているので、バージョンに注意したい(KAFKA-7283
など)
© 2019 NTT DATA Corporation 41
クロージング
© 2019 NTT DATA Corporation 42
本セッションのまとめ
• NTTデータのチーム紹介 & Kafkaのオーバービュー紹介
• Kafkaの故障検証のオーバービュー紹介
– 概ね想定通りの挙動だが、一部注意した方が望ましい挙動も見られた
• ZooKeeperアンサンブルの故障とデータファイル(ログファイル)の異常の
トピックを例として紹介
– ZooKeeperを直接利用しない読み書きは、ZooKeeperアンサンブル故障発
生刹那に動作を停止するわけではない。監視と運用で考慮したい。
– Logファイルの故障の仕方によってはBrokerが起動しない。運用で考慮したい。
© 2019 NTT DATA Corporation

More Related Content

What's hot

分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
 
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
NTT DATA Technology & Innovation
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
 
Kuberneteの運用を支えるGitOps
Kuberneteの運用を支えるGitOpsKuberneteの運用を支えるGitOps
Kuberneteの運用を支えるGitOps
shunki fujiwara
 
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
NTT DATA OSS Professional Services
 
超実践 Cloud Spanner 設計講座
超実践 Cloud Spanner 設計講座超実践 Cloud Spanner 設計講座
超実践 Cloud Spanner 設計講座
Samir Hammoudi
 
KafkaとPulsar
KafkaとPulsarKafkaとPulsar
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
 
噛み砕いてKafka Streams #kafkajp
噛み砕いてKafka Streams #kafkajp噛み砕いてKafka Streams #kafkajp
噛み砕いてKafka Streams #kafkajp
Yahoo!デベロッパーネットワーク
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
 
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Noritaka Sekiyama
 
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
 
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
Kohei Tokunaga
 
containerdの概要と最近の機能
containerdの概要と最近の機能containerdの概要と最近の機能
containerdの概要と最近の機能
Kohei Tokunaga
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
Etsuji Nakai
 
マイクロサービスにおける 結果整合性との戦い
マイクロサービスにおける 結果整合性との戦いマイクロサービスにおける 結果整合性との戦い
マイクロサービスにおける 結果整合性との戦い
ota42y
 

What's hot (20)

分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
 
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Kuberneteの運用を支えるGitOps
Kuberneteの運用を支えるGitOpsKuberneteの運用を支えるGitOps
Kuberneteの運用を支えるGitOps
 
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
Apache Sparkに手を出してヤケドしないための基本 ~「Apache Spark入門より」~ (デブサミ 2016 講演資料)
 
超実践 Cloud Spanner 設計講座
超実践 Cloud Spanner 設計講座超実践 Cloud Spanner 設計講座
超実践 Cloud Spanner 設計講座
 
KafkaとPulsar
KafkaとPulsarKafkaとPulsar
KafkaとPulsar
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
 
噛み砕いてKafka Streams #kafkajp
噛み砕いてKafka Streams #kafkajp噛み砕いてKafka Streams #kafkajp
噛み砕いてKafka Streams #kafkajp
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
 
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
 
containerdの概要と最近の機能
containerdの概要と最近の機能containerdの概要と最近の機能
containerdの概要と最近の機能
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
 
マイクロサービスにおける 結果整合性との戦い
マイクロサービスにおける 結果整合性との戦いマイクロサービスにおける 結果整合性との戦い
マイクロサービスにおける 結果整合性との戦い
 

Similar to Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~

Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform(db tech showcase 2019 Tok...
Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform(db tech showcase 2019 Tok...Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform(db tech showcase 2019 Tok...
Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform(db tech showcase 2019 Tok...
NTT DATA Technology & Innovation
 
大量のデータ処理や分析に使えるOSS Apache Sparkのご紹介(Open Source Conference 2020 Online/Kyoto ...
大量のデータ処理や分析に使えるOSS Apache Sparkのご紹介(Open Source Conference 2020 Online/Kyoto ...大量のデータ処理や分析に使えるOSS Apache Sparkのご紹介(Open Source Conference 2020 Online/Kyoto ...
大量のデータ処理や分析に使えるOSS Apache Sparkのご紹介(Open Source Conference 2020 Online/Kyoto ...
NTT DATA Technology & Innovation
 
Project Hydrogen and Spark Graph - 分散処理 × AIをより身近にする、Apache Sparkの新機能 - (NTTデ...
Project Hydrogen and Spark Graph - 分散処理 × AIをより身近にする、Apache Sparkの新機能 - (NTTデ...Project Hydrogen and Spark Graph - 分散処理 × AIをより身近にする、Apache Sparkの新機能 - (NTTデ...
Project Hydrogen and Spark Graph - 分散処理 × AIをより身近にする、Apache Sparkの新機能 - (NTTデ...
NTT DATA Technology & Innovation
 
Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...
Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...
Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...
NTT DATA Technology & Innovation
 
Spark + AI Summit 2020セッションのハイライト(Spark Meetup Tokyo #3 Online発表資料)
Spark + AI Summit 2020セッションのハイライト(Spark Meetup Tokyo #3 Online発表資料)Spark + AI Summit 2020セッションのハイライト(Spark Meetup Tokyo #3 Online発表資料)
Spark + AI Summit 2020セッションのハイライト(Spark Meetup Tokyo #3 Online発表資料)
NTT DATA Technology & Innovation
 
大量のデータ処理や分析に使えるOSS Apache Spark入門 - Open Source Conference2020 Online/Fukuoka...
大量のデータ処理や分析に使えるOSS Apache Spark入門 - Open Source Conference2020 Online/Fukuoka...大量のデータ処理や分析に使えるOSS Apache Spark入門 - Open Source Conference2020 Online/Fukuoka...
大量のデータ処理や分析に使えるOSS Apache Spark入門 - Open Source Conference2020 Online/Fukuoka...
NTT DATA Technology & Innovation
 
NTTデータが考えるデータ基盤の次の一手 ~AI活用のために知っておくべき新潮流とは?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTTデータが考えるデータ基盤の次の一手 ~AI活用のために知っておくべき新潮流とは?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)NTTデータが考えるデータ基盤の次の一手 ~AI活用のために知っておくべき新潮流とは?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTTデータが考えるデータ基盤の次の一手 ~AI活用のために知っておくべき新潮流とは?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTT DATA Technology & Innovation
 
OpenStack Swiftとそのエコシステムの最新動向
OpenStack Swiftとそのエコシステムの最新動向OpenStack Swiftとそのエコシステムの最新動向
OpenStack Swiftとそのエコシステムの最新動向
NTT Software Innovation Center
 
大量のデータ処理や分析に使えるOSS Apache Spark入門(Open Source Conference 2021 Online/Kyoto 発表資料)
大量のデータ処理や分析に使えるOSS Apache Spark入門(Open Source Conference 2021 Online/Kyoto 発表資料)大量のデータ処理や分析に使えるOSS Apache Spark入門(Open Source Conference 2021 Online/Kyoto 発表資料)
大量のデータ処理や分析に使えるOSS Apache Spark入門(Open Source Conference 2021 Online/Kyoto 発表資料)
NTT DATA Technology & Innovation
 
NTT Communications' Initiatives to Utilize Infrastructure Data
NTT Communications' Initiatives to Utilize Infrastructure DataNTT Communications' Initiatives to Utilize Infrastructure Data
NTT Communications' Initiatives to Utilize Infrastructure Data
DataWorks Summit
 
Apache Sparkの基本と最新バージョン3.2のアップデート(Open Source Conference 2021 Online/Fukuoka ...
Apache Sparkの基本と最新バージョン3.2のアップデート(Open Source Conference 2021 Online/Fukuoka ...Apache Sparkの基本と最新バージョン3.2のアップデート(Open Source Conference 2021 Online/Fukuoka ...
Apache Sparkの基本と最新バージョン3.2のアップデート(Open Source Conference 2021 Online/Fukuoka ...
NTT DATA Technology & Innovation
 
Apache spark 2.3 and beyond
Apache spark 2.3 and beyondApache spark 2.3 and beyond
Apache spark 2.3 and beyond
NTT DATA Technology & Innovation
 
[Modern Cloud Day Tokyo 2019] オラクルクラウド移行を完了したゲストに聞くOracle Cloudを選択する理由&次世代インフ...
[Modern Cloud Day Tokyo 2019] オラクルクラウド移行を完了したゲストに聞くOracle Cloudを選択する理由&次世代インフ...[Modern Cloud Day Tokyo 2019] オラクルクラウド移行を完了したゲストに聞くOracle Cloudを選択する理由&次世代インフ...
[Modern Cloud Day Tokyo 2019] オラクルクラウド移行を完了したゲストに聞くOracle Cloudを選択する理由&次世代インフ...
オラクルエンジニア通信
 
【旧版】Oracle Exadata Cloud Service:サービス概要のご紹介
【旧版】Oracle Exadata Cloud Service:サービス概要のご紹介【旧版】Oracle Exadata Cloud Service:サービス概要のご紹介
【旧版】Oracle Exadata Cloud Service:サービス概要のご紹介
オラクルエンジニア通信
 
[db tech showcase Tokyo 2016] B31: Spark Summit 2016@SFに参加してきたので最新事例などを紹介しつつデ...
[db tech showcase Tokyo 2016] B31: Spark Summit 2016@SFに参加してきたので最新事例などを紹介しつつデ...[db tech showcase Tokyo 2016] B31: Spark Summit 2016@SFに参加してきたので最新事例などを紹介しつつデ...
[db tech showcase Tokyo 2016] B31: Spark Summit 2016@SFに参加してきたので最新事例などを紹介しつつデ...
Insight Technology, Inc.
 
What happens in Spring Cloud Netflix
What happens in Spring Cloud NetflixWhat happens in Spring Cloud Netflix
What happens in Spring Cloud Netflix
apkiban
 
Oracle Cloud PaaS & IaaS:2019年10月度サービス情報アップデート
Oracle Cloud PaaS & IaaS:2019年10月度サービス情報アップデートOracle Cloud PaaS & IaaS:2019年10月度サービス情報アップデート
Oracle Cloud PaaS & IaaS:2019年10月度サービス情報アップデート
オラクルエンジニア通信
 
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
Masanori Itoh
 
Apache Spark超入門 (Hadoop / Spark Conference Japan 2016 講演資料)
Apache Spark超入門 (Hadoop / Spark Conference Japan 2016 講演資料)Apache Spark超入門 (Hadoop / Spark Conference Japan 2016 講演資料)
Apache Spark超入門 (Hadoop / Spark Conference Japan 2016 講演資料)
NTT DATA OSS Professional Services
 
20180319 ccon sync kintone
20180319 ccon sync kintone20180319 ccon sync kintone
20180319 ccon sync kintone
CData Software Japan
 

Similar to Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~ (20)

Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform(db tech showcase 2019 Tok...
Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform(db tech showcase 2019 Tok...Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform(db tech showcase 2019 Tok...
Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform(db tech showcase 2019 Tok...
 
大量のデータ処理や分析に使えるOSS Apache Sparkのご紹介(Open Source Conference 2020 Online/Kyoto ...
大量のデータ処理や分析に使えるOSS Apache Sparkのご紹介(Open Source Conference 2020 Online/Kyoto ...大量のデータ処理や分析に使えるOSS Apache Sparkのご紹介(Open Source Conference 2020 Online/Kyoto ...
大量のデータ処理や分析に使えるOSS Apache Sparkのご紹介(Open Source Conference 2020 Online/Kyoto ...
 
Project Hydrogen and Spark Graph - 分散処理 × AIをより身近にする、Apache Sparkの新機能 - (NTTデ...
Project Hydrogen and Spark Graph - 分散処理 × AIをより身近にする、Apache Sparkの新機能 - (NTTデ...Project Hydrogen and Spark Graph - 分散処理 × AIをより身近にする、Apache Sparkの新機能 - (NTTデ...
Project Hydrogen and Spark Graph - 分散処理 × AIをより身近にする、Apache Sparkの新機能 - (NTTデ...
 
Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...
Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...
Hadoop/Spark を使うなら Bigtop を使い熟そう! ~並列分散処理基盤のいま、から Bigtop の最近の取り組みまで一挙ご紹介~(Ope...
 
Spark + AI Summit 2020セッションのハイライト(Spark Meetup Tokyo #3 Online発表資料)
Spark + AI Summit 2020セッションのハイライト(Spark Meetup Tokyo #3 Online発表資料)Spark + AI Summit 2020セッションのハイライト(Spark Meetup Tokyo #3 Online発表資料)
Spark + AI Summit 2020セッションのハイライト(Spark Meetup Tokyo #3 Online発表資料)
 
大量のデータ処理や分析に使えるOSS Apache Spark入門 - Open Source Conference2020 Online/Fukuoka...
大量のデータ処理や分析に使えるOSS Apache Spark入門 - Open Source Conference2020 Online/Fukuoka...大量のデータ処理や分析に使えるOSS Apache Spark入門 - Open Source Conference2020 Online/Fukuoka...
大量のデータ処理や分析に使えるOSS Apache Spark入門 - Open Source Conference2020 Online/Fukuoka...
 
NTTデータが考えるデータ基盤の次の一手 ~AI活用のために知っておくべき新潮流とは?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTTデータが考えるデータ基盤の次の一手 ~AI活用のために知っておくべき新潮流とは?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)NTTデータが考えるデータ基盤の次の一手 ~AI活用のために知っておくべき新潮流とは?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTTデータが考えるデータ基盤の次の一手 ~AI活用のために知っておくべき新潮流とは?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
 
OpenStack Swiftとそのエコシステムの最新動向
OpenStack Swiftとそのエコシステムの最新動向OpenStack Swiftとそのエコシステムの最新動向
OpenStack Swiftとそのエコシステムの最新動向
 
大量のデータ処理や分析に使えるOSS Apache Spark入門(Open Source Conference 2021 Online/Kyoto 発表資料)
大量のデータ処理や分析に使えるOSS Apache Spark入門(Open Source Conference 2021 Online/Kyoto 発表資料)大量のデータ処理や分析に使えるOSS Apache Spark入門(Open Source Conference 2021 Online/Kyoto 発表資料)
大量のデータ処理や分析に使えるOSS Apache Spark入門(Open Source Conference 2021 Online/Kyoto 発表資料)
 
NTT Communications' Initiatives to Utilize Infrastructure Data
NTT Communications' Initiatives to Utilize Infrastructure DataNTT Communications' Initiatives to Utilize Infrastructure Data
NTT Communications' Initiatives to Utilize Infrastructure Data
 
Apache Sparkの基本と最新バージョン3.2のアップデート(Open Source Conference 2021 Online/Fukuoka ...
Apache Sparkの基本と最新バージョン3.2のアップデート(Open Source Conference 2021 Online/Fukuoka ...Apache Sparkの基本と最新バージョン3.2のアップデート(Open Source Conference 2021 Online/Fukuoka ...
Apache Sparkの基本と最新バージョン3.2のアップデート(Open Source Conference 2021 Online/Fukuoka ...
 
Apache spark 2.3 and beyond
Apache spark 2.3 and beyondApache spark 2.3 and beyond
Apache spark 2.3 and beyond
 
[Modern Cloud Day Tokyo 2019] オラクルクラウド移行を完了したゲストに聞くOracle Cloudを選択する理由&次世代インフ...
[Modern Cloud Day Tokyo 2019] オラクルクラウド移行を完了したゲストに聞くOracle Cloudを選択する理由&次世代インフ...[Modern Cloud Day Tokyo 2019] オラクルクラウド移行を完了したゲストに聞くOracle Cloudを選択する理由&次世代インフ...
[Modern Cloud Day Tokyo 2019] オラクルクラウド移行を完了したゲストに聞くOracle Cloudを選択する理由&次世代インフ...
 
【旧版】Oracle Exadata Cloud Service:サービス概要のご紹介
【旧版】Oracle Exadata Cloud Service:サービス概要のご紹介【旧版】Oracle Exadata Cloud Service:サービス概要のご紹介
【旧版】Oracle Exadata Cloud Service:サービス概要のご紹介
 
[db tech showcase Tokyo 2016] B31: Spark Summit 2016@SFに参加してきたので最新事例などを紹介しつつデ...
[db tech showcase Tokyo 2016] B31: Spark Summit 2016@SFに参加してきたので最新事例などを紹介しつつデ...[db tech showcase Tokyo 2016] B31: Spark Summit 2016@SFに参加してきたので最新事例などを紹介しつつデ...
[db tech showcase Tokyo 2016] B31: Spark Summit 2016@SFに参加してきたので最新事例などを紹介しつつデ...
 
What happens in Spring Cloud Netflix
What happens in Spring Cloud NetflixWhat happens in Spring Cloud Netflix
What happens in Spring Cloud Netflix
 
Oracle Cloud PaaS & IaaS:2019年10月度サービス情報アップデート
Oracle Cloud PaaS & IaaS:2019年10月度サービス情報アップデートOracle Cloud PaaS & IaaS:2019年10月度サービス情報アップデート
Oracle Cloud PaaS & IaaS:2019年10月度サービス情報アップデート
 
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
「hbstudy#23 OpenStack祭!!」資料 ~OpenStackプロジェクトの全体像~
 
Apache Spark超入門 (Hadoop / Spark Conference Japan 2016 講演資料)
Apache Spark超入門 (Hadoop / Spark Conference Japan 2016 講演資料)Apache Spark超入門 (Hadoop / Spark Conference Japan 2016 講演資料)
Apache Spark超入門 (Hadoop / Spark Conference Japan 2016 講演資料)
 
20180319 ccon sync kintone
20180319 ccon sync kintone20180319 ccon sync kintone
20180319 ccon sync kintone
 

More from NTT DATA OSS Professional Services

Global Top 5 を目指す NTT DATA の確かで意外な技術力
Global Top 5 を目指す NTT DATA の確かで意外な技術力Global Top 5 を目指す NTT DATA の確かで意外な技術力
Global Top 5 を目指す NTT DATA の確かで意外な技術力
NTT DATA OSS Professional Services
 
Spark SQL - The internal -
Spark SQL - The internal -Spark SQL - The internal -
Spark SQL - The internal -
NTT DATA OSS Professional Services
 
Hadoopエコシステムのデータストア振り返り
Hadoopエコシステムのデータストア振り返りHadoopエコシステムのデータストア振り返り
Hadoopエコシステムのデータストア振り返り
NTT DATA OSS Professional Services
 
HDFS Router-based federation
HDFS Router-based federationHDFS Router-based federation
HDFS Router-based federation
NTT DATA OSS Professional Services
 
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイントPostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
NTT DATA OSS Professional Services
 
Apache Hadoopの新機能Ozoneの現状
Apache Hadoopの新機能Ozoneの現状Apache Hadoopの新機能Ozoneの現状
Apache Hadoopの新機能Ozoneの現状
NTT DATA OSS Professional Services
 
Distributed data stores in Hadoop ecosystem
Distributed data stores in Hadoop ecosystemDistributed data stores in Hadoop ecosystem
Distributed data stores in Hadoop ecosystem
NTT DATA OSS Professional Services
 
Structured Streaming - The Internal -
Structured Streaming - The Internal -Structured Streaming - The Internal -
Structured Streaming - The Internal -
NTT DATA OSS Professional Services
 
Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?
NTT DATA OSS Professional Services
 
Apache Hadoop and YARN, current development status
Apache Hadoop and YARN, current development statusApache Hadoop and YARN, current development status
Apache Hadoop and YARN, current development status
NTT DATA OSS Professional Services
 
HDFS basics from API perspective
HDFS basics from API perspectiveHDFS basics from API perspective
HDFS basics from API perspective
NTT DATA OSS Professional Services
 
SIerとオープンソースの美味しい関係 ~コミュニティの力を活かして世界を目指そう~
SIerとオープンソースの美味しい関係 ~コミュニティの力を活かして世界を目指そう~SIerとオープンソースの美味しい関係 ~コミュニティの力を活かして世界を目指そう~
SIerとオープンソースの美味しい関係 ~コミュニティの力を活かして世界を目指そう~
NTT DATA OSS Professional Services
 
20170303 java9 hadoop
20170303 java9 hadoop20170303 java9 hadoop
20170303 java9 hadoop
NTT DATA OSS Professional Services
 
ブロックチェーンの仕組みと動向(入門編)
ブロックチェーンの仕組みと動向(入門編)ブロックチェーンの仕組みと動向(入門編)
ブロックチェーンの仕組みと動向(入門編)
NTT DATA OSS Professional Services
 
Application of postgre sql to large social infrastructure jp
Application of postgre sql to large social infrastructure jpApplication of postgre sql to large social infrastructure jp
Application of postgre sql to large social infrastructure jp
NTT DATA OSS Professional Services
 
Application of postgre sql to large social infrastructure
Application of postgre sql to large social infrastructureApplication of postgre sql to large social infrastructure
Application of postgre sql to large social infrastructure
NTT DATA OSS Professional Services
 
Apache Hadoop 2.8.0 の新機能 (抜粋)
Apache Hadoop 2.8.0 の新機能 (抜粋)Apache Hadoop 2.8.0 の新機能 (抜粋)
Apache Hadoop 2.8.0 の新機能 (抜粋)
NTT DATA OSS Professional Services
 
データ活用をもっともっと円滑に! ~データ処理・分析基盤編を少しだけ~
データ活用をもっともっと円滑に!~データ処理・分析基盤編を少しだけ~データ活用をもっともっと円滑に!~データ処理・分析基盤編を少しだけ~
データ活用をもっともっと円滑に! ~データ処理・分析基盤編を少しだけ~
NTT DATA OSS Professional Services
 
商用ミドルウェアのPuppet化で気を付けたい5つのこと
商用ミドルウェアのPuppet化で気を付けたい5つのこと商用ミドルウェアのPuppet化で気を付けたい5つのこと
商用ミドルウェアのPuppet化で気を付けたい5つのこと
NTT DATA OSS Professional Services
 
今からはじめるPuppet 2016 ~ インフラエンジニアのたしなみ ~
今からはじめるPuppet 2016 ~ インフラエンジニアのたしなみ ~今からはじめるPuppet 2016 ~ インフラエンジニアのたしなみ ~
今からはじめるPuppet 2016 ~ インフラエンジニアのたしなみ ~
NTT DATA OSS Professional Services
 

More from NTT DATA OSS Professional Services (20)

Global Top 5 を目指す NTT DATA の確かで意外な技術力
Global Top 5 を目指す NTT DATA の確かで意外な技術力Global Top 5 を目指す NTT DATA の確かで意外な技術力
Global Top 5 を目指す NTT DATA の確かで意外な技術力
 
Spark SQL - The internal -
Spark SQL - The internal -Spark SQL - The internal -
Spark SQL - The internal -
 
Hadoopエコシステムのデータストア振り返り
Hadoopエコシステムのデータストア振り返りHadoopエコシステムのデータストア振り返り
Hadoopエコシステムのデータストア振り返り
 
HDFS Router-based federation
HDFS Router-based federationHDFS Router-based federation
HDFS Router-based federation
 
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイントPostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
 
Apache Hadoopの新機能Ozoneの現状
Apache Hadoopの新機能Ozoneの現状Apache Hadoopの新機能Ozoneの現状
Apache Hadoopの新機能Ozoneの現状
 
Distributed data stores in Hadoop ecosystem
Distributed data stores in Hadoop ecosystemDistributed data stores in Hadoop ecosystem
Distributed data stores in Hadoop ecosystem
 
Structured Streaming - The Internal -
Structured Streaming - The Internal -Structured Streaming - The Internal -
Structured Streaming - The Internal -
 
Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?
 
Apache Hadoop and YARN, current development status
Apache Hadoop and YARN, current development statusApache Hadoop and YARN, current development status
Apache Hadoop and YARN, current development status
 
HDFS basics from API perspective
HDFS basics from API perspectiveHDFS basics from API perspective
HDFS basics from API perspective
 
SIerとオープンソースの美味しい関係 ~コミュニティの力を活かして世界を目指そう~
SIerとオープンソースの美味しい関係 ~コミュニティの力を活かして世界を目指そう~SIerとオープンソースの美味しい関係 ~コミュニティの力を活かして世界を目指そう~
SIerとオープンソースの美味しい関係 ~コミュニティの力を活かして世界を目指そう~
 
20170303 java9 hadoop
20170303 java9 hadoop20170303 java9 hadoop
20170303 java9 hadoop
 
ブロックチェーンの仕組みと動向(入門編)
ブロックチェーンの仕組みと動向(入門編)ブロックチェーンの仕組みと動向(入門編)
ブロックチェーンの仕組みと動向(入門編)
 
Application of postgre sql to large social infrastructure jp
Application of postgre sql to large social infrastructure jpApplication of postgre sql to large social infrastructure jp
Application of postgre sql to large social infrastructure jp
 
Application of postgre sql to large social infrastructure
Application of postgre sql to large social infrastructureApplication of postgre sql to large social infrastructure
Application of postgre sql to large social infrastructure
 
Apache Hadoop 2.8.0 の新機能 (抜粋)
Apache Hadoop 2.8.0 の新機能 (抜粋)Apache Hadoop 2.8.0 の新機能 (抜粋)
Apache Hadoop 2.8.0 の新機能 (抜粋)
 
データ活用をもっともっと円滑に! ~データ処理・分析基盤編を少しだけ~
データ活用をもっともっと円滑に!~データ処理・分析基盤編を少しだけ~データ活用をもっともっと円滑に!~データ処理・分析基盤編を少しだけ~
データ活用をもっともっと円滑に! ~データ処理・分析基盤編を少しだけ~
 
商用ミドルウェアのPuppet化で気を付けたい5つのこと
商用ミドルウェアのPuppet化で気を付けたい5つのこと商用ミドルウェアのPuppet化で気を付けたい5つのこと
商用ミドルウェアのPuppet化で気を付けたい5つのこと
 
今からはじめるPuppet 2016 ~ インフラエンジニアのたしなみ ~
今からはじめるPuppet 2016 ~ インフラエンジニアのたしなみ ~今からはじめるPuppet 2016 ~ インフラエンジニアのたしなみ ~
今からはじめるPuppet 2016 ~ インフラエンジニアのたしなみ ~
 

Recently uploaded

「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
嶋 是一 (Yoshikazu SHIMA)
 
Generating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language ModelsGenerating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language Models
harmonylab
 
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
Toru Tamaki
 
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
Osaka University
 
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライドHumanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
tazaki1
 
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
sugiuralab
 
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobodyロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
azuma satoshi
 
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMMハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
osamut
 
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
Yuki Miyazaki
 

Recently uploaded (9)

「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
 
Generating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language ModelsGenerating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language Models
 
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
 
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
 
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライドHumanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
 
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
 
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobodyロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
 
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMMハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
 
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
 

Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~

  • 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