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

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 ベストプラクティスの展開

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

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に分割されて保存される

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、など

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 など）

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

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

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

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados(20)

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

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

Mais de NTT DATA OSS Professional Services

Mais de NTT DATA OSS Professional Services(20)

Último

Último(14)

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