Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,327 views

Published on

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

Published in: Technology

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

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

×