「MQ シリーズをマスターする」 - Kafka ストレージ選択の秘密

[[405722]]

みなさんこんにちは。私はウー兄弟です。これは、Kafka に関する「Mastering MQ Series」の 3 番目の記事です。最初の 2 つの記事を見逃した場合は、もう一度確認することをお勧めします。

カフカの謎を解く

カフカ建築デザインの仁と杜の子午線

この記事から、ミクロな視点から Kafka の設計原則を深く分析していきます。この記事では、Kafka の最も代表的な側面であるストレージ設計について説明します。

Kafka のストレージ設計について、あまり詳しくない学生は次のように疑問に思うかもしれません。「Kafka はなぜ、データベースや KV をストレージに使用せず、非常に原始的なログ記録方法 (ログ ファイル) を使用してメッセージを保存するのでしょうか?」

Kafka についてある程度の知識がある学生は、追加のみ、線形スキャン、ディスクの順次書き込み、ページ キャッシュ、ゼロ コピー、スパース インデックス、バイナリ検索などのいくつかの知識ポイントをすぐに挙げることができるはずです。

記事を2つ書く予定です。上記の疑問点を説明するだけでなく、Kafka ストレージ設計の重要なポイントをすばやく把握し、上記の散在する知識ポイントを結び付けるのに役立つコンテキストも提供します。

さらに、Kafka のストレージ設計を理解した後は、HBase、Cassandra、RocksDB など、業界で影響力のある多くのストレージ システムの成功を牽引してきた、Append Only Data Structures という古典的な基礎ストレージ原則について、より深く理解できるようになることを願っています。

1. Kafka のストレージの難しさは何ですか?

ストレージ設計が Kafka の本質であるのはなぜですか?この記事は以前にもこれを分析しました。メッセージ モデルを簡素化することで、Kafka は大量のメッセージを格納するストレージ システムへと変貌しました。

Kafka は他の機能的特徴を削減しているため、他の MQ が達成できないパフォーマンスを実現するために、ストレージに力を入れることは間違いありません。

図1: Kafkaのメッセージモデル

しかし、Kafka のストレージ ソリューションを説明する前に、Kafka がログ (ログ ファイル) ストレージを使用する理由を分析する必要があります。選択の基準は何ですか?

これは、このシリーズが達成したいことでもあります。つまり、思考力は記憶力よりも優れており、何を記憶するのではなく、なぜをもっと問うべきだということです。

Kafka のストレージ選択ロジックは、ビジネスニーズを開発するという考え方に似ていると思います。 MySQL、Redis、またはその他のストレージソリューションを使用する必要がありますか?特定のビジネス シナリオに応じて異なります。

次の2つの側面から分析してみましょう。

1. 機能要件: どのようなデータが保存されますか?音量はどのくらいですか？どれくらいの期間保管する必要がありますか? CRUD シナリオとは何ですか?

2. 非機能要件: パフォーマンスと安定性の要件は何ですか?スケーラビリティは考慮されていますか?

Kafka に戻ると、その機能要件には少なくとも次のものが含まれます。

1. 保存されるデータは主にメッセージ ストリームです。メッセージは、最も単純なテキスト文字列またはカスタムの複雑な形式にすることができます。

しかし、ブローカーにとっては、良いニュースの配信のみを処理すればよく、メッセージ自体の内容に注意を払う必要はありません。

2. データ量が非常に大きい：Kafka は Linkedin のインキュベーション プロジェクトとして誕生し、リアルタイムのログ ストリーム処理 (運用アクティビティのエントリ ポイント、運用および保守の監視指標など) に使用されるため、Linkedin の本来のビジネス規模によると、毎日処理されるメッセージの量は数千億に上ると推定されます。

3. CRUD シナリオは非常にシンプルです。メッセージ キューのコア機能はデータ パイプラインであり、ダンプ機能のみを提供するため、CRUD 操作は非常にシンプルです。

まず、メッセージは通知イベントと同等であり、すべて追加モードで書き込まれるため、更新をまったく考慮する必要はありません。第二に、コンシューマー側では、ブローカーはオフセット (消費変位) またはタイムスタンプ (タイムスタンプ) でメッセージを照会する機能のみを提供する必要があります。また、長期間消費されていないメッセージ（たとえば、7 日前のメッセージ）については、Broker は定期的に削除できます。

次に、非機能要件を見てみましょう。

1. パフォーマンス要件: 以前の記事で述べたように、Linkedin は当初、データ転送の問題を解決するために ActiveMQ を使用しようとしましたが、パフォーマンスが要件を満たすことができなかったため、Kafka を社内で開発することを決定しました。 ActiveMQ の単一マシンのスループットは約 10,000 TPS であり、Kafka のパフォーマンスは明らかに ActiveMQ よりも桁違いに高いはずです。

2. 安定性の要件: メッセージの永続性 (マシンの再起動後に履歴データが失われないようにする) と、単一のブローカーがクラッシュした後に迅速にフェイルオーバーして外部サービスの提供を継続する方法も、Kafka が考慮する必要がある 2 つの機能です。

3. スケーラビリティ要件: Kafka は大量のデータを保存するという問題に直面しているため、ストレージのスケーラビリティを考慮する必要があります。

簡単にまとめると、Kafka のストレージ要件は次のとおりです。

1. 機能要件: 実際には、追加の書き込み、更新の必要がなく、消費変位とタイムスタンプに基づいてメッセージを照会する機能、期限切れのメッセージを定期的に削除する機能など、十分にシンプルです。

2. 非機能要件: Kafka 自体は高並行性システムであるため、高パフォーマンス、高可用性、高スケーラビリティという典型的な課題に必然的に直面することになり、これが困難です。

2. Kafka ストレージ選択分析

上記のニーズを整理したので、分析を続けましょう。

Kafka が、最も一般的なリレーショナル データベースやキー値データベースではなく、ログ (ログ ファイル) を使用してメッセージを保存することを選択したのはなぜですか?

2.1 ストレージ分野の基礎知識

まず、今後の分析の理論的基礎となる、ストレージ分野における基本的な知識を普及させましょう。

1. メモリはアクセス速度は速いですが、容量が小さく価格が高いため、長期間保存する必要があるデータには適していません。

2. ディスクアクセス速度は比較的遅いですが、安価で永続的なストレージを提供できます。

3. ディスク IO の時間消費は、主にシーク時間とディスク回転時間によって決まります。ディスク IO パフォーマンスを向上させる最も効果的な方法は、ランダム IO を減らし、シーケンシャル IO を増やすことです。

4. ディスクの IO 速度は必ずしもメモリの IO 速度よりも遅いわけではありません。それはどのように使うかによります。

ディスクとメモリの IO 速度に関する比較テストは数多くあります。結果によると、ディスクのシーケンシャル書き込み速度は数百メガバイト/秒に達する可能性がある一方、ランダム書き込み速度はわずか数百 KB/秒であり、その差は数千倍にもなります。さらに、ディスクのシーケンシャル IO アクセスは、メモリのランダム IO のパフォーマンスを上回ることもあります。

図2: ディスクとメモリのIO速度の比較

データストレージ分野を見ると、2 つの「極端な」開発方向があります。

1. 読み取り速度の向上：インデックス（B+ツリー、バイナリ検索ツリーなど）によってクエリ速度が向上しますが、データの書き込み時にインデックスを維持する必要があるため、書き込み効率が低下します。

2. 書き込みの高速化: 純粋なログ型で、データはインデックスなしで追加モードで順次書き込まれるため、書き込み速度が非常に速くなります (理論的にはディスクの書き込み速度に近い)。ただし、インデックスのサポートがないため、クエリのパフォーマンスは低くなります。

これら 2 つの極端な例に基づいて、最も代表的な 3 つの基礎となるインデックス構造が導き出されます。

1. ハッシュ インデックス: キーはハッシュ関数を通じてデータの保存アドレスにマッピングされます。等値クエリなどの単純なシナリオには適していますが、比較クエリや範囲クエリなどの複雑なシナリオには無力です。

2. B/B+ ツリー インデックス: 読み取りパフォーマンスに重点を置いた最も一般的なインデックス タイプです。これは、MySQL や Oracle などの多くの従来のリレーショナル データベースの基礎となる構造です。

3. LSM ツリー インデックス: データは追加モードでログ ファイルに追加され、読み取りパフォーマンスを大幅に低下させることなく書き込みを最適化します。これは、BigTable、HBase、Cassandra、RocksDB などの多くの NoSQL ストレージ システムの基盤となる構造です。

2.2 Kafka ストレージの選択に関する考慮事項

上記の理論的基礎を踏まえて、Kafka のストレージ要件について考えてみましょう。

Kafka のビジネス シナリオの特徴は次のとおりです。

1. 書き込み操作: 同時実行性は非常に高く、TPS は数百万ですが、更新を考慮せずにすべて順番に書き込まれます。

2. クエリ操作: 要件は単純で、オフセットまたはタイムスタンプでメッセージをクエリできます。

数百万 TPS の Kafka の書き込み操作要件を満たすだけであれば、明らかに Append メソッドが最も理想的です。前述のように、ディスクのシーケンシャル書き込みのパフォーマンスは要件を完全に満たすことができます。

残っているのは、効率的なクエリの問題をどのように解決するかです。 B-Tree インデックス構造を使用する場合、データが書き込まれるたびにインデックスを維持する必要があり (ランダム IO 操作)、「ページ分割」などの時間のかかる操作も発生します。単純なクエリ要件のみを実装する必要がある Kafka にとって、これらのコストは非常に大きくなります。したがって、B-Tree インデックスは Kafka には適していません。

逆に、ハッシュ インデックスが適しているようです。読み取り操作を高速化するには、オフセットからログ ファイル オフセットへのマッピング関係をメモリ内で維持するだけでよい場合は、オフセットに基づいてメッセージを検索するたびに、ハッシュ テーブルからオフセットを取得してファイルを読み取ることができます。 (同じ考え方は、タイムスタンプに基づいてメッセージをクエリするためにも使用できます)

ただし、ハッシュ インデックスはメモリ内に常駐するため、大量のデータを処理することはできません。 Kafka は 1 秒あたり数百万のメッセージを書き込む可能性があり、メモリが確実にバーストします。

しかし、メッセージのオフセットは順序付けされるように設計できることがわかりました (実際には単調に増加する long 型のフィールドです)。そのため、メッセージはログ ファイル自体に順序どおりに格納されます。メッセージごとにハッシュインデックスを構築する必要はありません。メッセージを複数のブロックに分割し、各ブロックの最初のメッセージのオフセットのみをインデックスすることができます。まずサイズ関係に基づいてブロックを見つけ、次にブロック内を順番に検索します。これは Kafka の「スパース インデックス」のソースです。

図3: Kafkaスパースインデックス図

最終的に、次のことがわかりました: 追加ログ + スパース ハッシュ インデックスが Kafka の最終的なストレージ ソリューションを形成しました。これがLSM Treeの設計思想ではないでしょうか？

Kafka のソリューションは LSM ツリーとは異なり、ツリー インデックスと Memtable レイヤーを使用しないと主張する人もいるかもしれません。しかし、私個人としては、「デザイン思考」の観点から見ると、Kafka は LSM Tree の極端な応用とみなせるのではないかと考えています。

さらに、追加専用データ構造と LSM ツリーに関しては、QCon 2017 での Ben Stopford (Kafka の親会社の技術専門家) によるビデオ プレゼンテーションをお勧めします。プレゼンテーションは非常にエキサイティングで、見る価値があります。

https://www.infoq.com/presentations/lsm-append-data- Structures/

3. Kafka ストレージ設計

Kafka のストレージ選択の詳細を理解した後、その具体的なストレージ構造を見てみましょう。

図4: Kafkaのストレージ構造

ご覧のとおり、Kafka は「パーティション + セグメント + インデックス」の 3 層構造になっています。

1. 各トピックは複数のパーティションに分割されます。パーティションは物理的にはフォルダーとして理解できます。

前の記事で説明しました：パーティションは主に、Kafka ストレージの水平拡張問題を解決するために使用されます。トピックのすべてのメッセージが 1 つのブローカーにのみ存在する場合、このブローカーは必然的にボトルネックになります。したがって、トピック内のデータを複数のパーティションに分割し、それらをクラスター全体に分散するのが自然な設計アプローチです。

2. 各パーティションは複数のセグメントに分割されます。物理的には、セグメントは「データ ファイル + インデックス ファイル」として理解でき、この 2 つは 1 対 1 で対応しています。

読者の中には、「パーティションの後にセグメントが必要なのはなぜですか?」という疑問を持つ人もいるかもしれません。

セグメントが導入されていない場合、1 つのパーティションは 1 つのファイルのみに対応し、ファイルは大きくなり続けるため、必然的に単一のパーティション ファイルが大きくなりすぎて、検索や保守が不便になります。

さらに、履歴メッセージを削除する場合、ファイルの以前の内容を削除する必要があり、これは Kafka の順次書き込みの考え方に準拠していません。セグメントが導入された後は、古いセグメント ファイルを削除するだけで、各セグメントの順次書き込みが保証されます。

4. 最後に

この記事では、需要分析から選択比較、そして具体的なストレージ ソリューションに至るまで、Kafka がストレージ ソリューションとしてログ (ログ ファイル) を選択した謎を徐々に明らかにしていきます。

また、ログストレージを使用しているというだけの記憶ではなく、ストレージ選択における Kafka の難しさを、システム設計の問題として積極的に考えていただければと思います。

別の観点: レベルが低いほど、より普遍的になります。深く掘り下げていくと、この知識が多くの優れたオープンソース システムに共通していることがわかります。

次の記事では、Kafka のソースコードを組み合わせて、データを保存する際のさまざまなパフォーマンス最適化手法を分析します。また次回お会いしましょう！

この記事はWeChatの公開アカウント「Wu Ge Talks IT」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合は、Wu Ge の IT パブリック アカウントにご連絡ください。