Kafkaのファイル保存メカニズムについて

  [[282846]]

カフカとは何か

Kafka はもともと Linkedin によって開発されました。これは、Zookeeper 調整に基づいた分散型、パーティション化、マルチレプリカ、マルチサブスクライバーの分散ログ システムです (MQ システムとしても使用できます)。これは、Web/nginx ログ、アクセス ログ、メッセージング サービスなどによく使用されます。Linkedin は 2010 年にこれを Apache Foundation に寄贈し、トップ オープン ソース プロジェクトになりました。

商用メッセージ キューのパフォーマンスとそのファイル ストレージ メカニズムの設計は、メッセージ キュー サービスの技術レベルを測定するための最も重要な指標の 1 つです。以下では、Kafka のファイル保存の仕組みと物理構造の観点から、Kafka がどのように効率的なファイル保存を実現するのか、また実際の適用効果について分析します。

Kafka の用語のいくつかは次のように説明されています。

• ブローカー: メッセージ ミドルウェア処理ノード。 Kafka ノードはブローカーであり、複数のブローカーが Kafka クラスターを形成できます。
• トピック: ページ ビュー ログ、クリック ログなどのメッセージの種類は、トピックの形式で存在できます。 Kafka クラスターは、複数のトピックの配信を同時に担当できます。
• パーティション: トピックの物理的なグループ化。トピックは複数のパーティションに分割でき、各パーティションは順序付けられたキューです。
• セグメント: パーティションは物理的に複数のセグメントで構成されます。詳細については、以下の 2.2 および 2.3 で説明します。
• オフセット: 各パーティションは、パーティションに継続的に追加される一連の順序付けられた不変のメッセージで構成されます。パーティション内の各メッセージには、オフセットと呼ばれる連続したシーケンス番号があり、これを使用してパーティション内のメッセージを一意に識別します。

分析プロセスは次の 4 つのステップに分かれています。

• トピックのパーティションストレージ分散
• パーティション内のファイル保存方法
• パーティション内のセグメントファイルストレージ構造
• パーティション内のオフセットでメッセージを検索する方法

上記の 4 つのプロセスを詳細に分析することで、Kafka のファイル保存メカニズムの謎をはっきりと理解することができます。

2.1 トピックのパーティションストレージの分散

実験環境の Kafka クラスターにはブローカーが 1 つだけ存在し、xxx/message-folder がデータ ファイル ストレージのルート ディレクトリであると想定します。 Kafka ブローカーで、server.properties ファイル (パラメーター log.dirs=xxx/message-folder) を構成します。たとえば、report_push と launch_info という名前の 2 つのトピックを作成し、パーティションの数はパーティション = 4 です。保存パスとディレクトリのルールは次のとおりです: xxx/message-folder

 | --report_push-0  
 | --レポートプッシュ-1  
 | --レポートプッシュ2  
 | --レポートプッシュ3  
 | --launch_info-0  
 | --launch_info-1  
 | --launch_info-2  
 | --launch_info-3  

Kafka ファイル ストレージでは、同じトピックの下に複数の異なるパーティションが存在します。各パーティションはディレクトリです。パーティションの命名規則は、トピック名 + 順序付けられたシーケンス番号です。最初のパーティションシーケンス番号は 0 から始まり、最大シーケンス番号はパーティション数から 1 を引いた数になります。ブローカーが複数ある場合は、Kafka クラスターのパーティション分散原則の分析を参照してください。

2.2 パーティション内のファイル保存方法

次の図は、パーティションにファイルがどのように保存されるかを示しています。

• 各パーティション (ディレクトリ) は、同じサイズの複数のセグメント データ ファイルに均等に分割された巨大なファイルに相当します。ただし、各セグメント ファイル内のメッセージの数は必ずしも同じではありません。この機能を使用すると、古いセグメント ファイルをすばやく簡単に削除できます。
• 各パーティションは順次読み取りと書き込みのみをサポートする必要があり、セグメント ファイルのライフ サイクルはサーバー構成パラメータによって決まります。

これを行う利点は、不要なファイルをすばやく削除し、ディスク使用率を効果的に向上できることです。

2.3 パーティション内のセグメントファイル格納構造

読者はセクション 2.2 で Kafka ファイル システムのパーティション ストレージ方法について学習しました。このセクションでは、パーティション内のセグメント ファイルの構成と物理構造を詳細に分析します。

• セグメント ファイルの構成: インデックス ファイルとデータ ファイルの 2 つの部分で構成されます。これら 2 つのファイルは互いに対応しており、ペアで表示されます。サフィックス「.index」と「.log」は、それぞれセグメント インデックス ファイルとデータ ファイルを表します。
• セグメント ファイルの命名規則: グローバル パーティションの最初のセグメントは 0 から始まり、後続の各セグメント ファイルは、前のセグメント ファイルの最後のメッセージのオフセット値に基づいて名前が付けられます。最大値は 64 ビット長、19 桁で、埋められていない桁には 0 が埋め込まれます。

以下のファイルリストは、Kafka ブローカーで行った実験です。 1 つのパーティションを持つ topicXXX を作成し、各セグメントのサイズを 500 MB に設定し、プロデューサーを起動して大量のデータを Kafka ブローカーに書き込みました。以下の図 2 に示すセグメント ファイル リストは、上記の 2 つのルールを示しています。

上記の図 2 のセグメント ファイルのペアを例にとると、セグメント内のインデックス <—-> データ ファイル間の対応関係の物理構造は次のようになります。

上記の図において、 3 、インデックス ファイルには大量のメタデータが格納され、データ ファイルには大量のメッセージが格納されます。インデックス ファイル内のメタデータは、対応するデータ ファイル内のメッセージの物理オフセット アドレスを指します。インデックス ファイル内のメタデータ 3,497 を例にとると、これはデータ ファイル内の 3 番目のメッセージ (グローバル パーティション内の 368772 番目のメッセージ) を表し、メッセージの物理オフセット アドレスは 497 です。

上の図 3 から、セグメント データ ファイルは多数のメッセージで構成されていることがわかります。メッセージの物理構造の詳細な説明は次のとおりです。

2.4 パーティション内のオフセットでメッセージを検索する方法

たとえば、offset=368776 のメッセージを読み取るには、次の 2 つの手順で検索する必要があります。

• 最初のステップは、セグメント ファイルを見つけることです。上記の図 2 を例にとると、000000000000000000000.index は最初のファイルを表し、開始オフセット (offset) は 0 です。2 番目のファイル 000000000000000368769.index の開始オフセットは 368770 = 368769 + 1 です。同様に、3 番目のファイル 000000000000000737337.index の開始オフセットは 737338 = 737337 + 1 であり、後続のファイルについても同様です。これらのファイルは開始オフセットによって名前が付けられ、並べ替えられます。ファイルリストをオフセットに従ってバイナリ検索する限り、特定のファイルをすばやく見つけることができます。オフセット=368776の場合、00000000000000368769.index|logに移動します。
• 2 番目のステップは、セグメント ファイルを通じてメッセージを見つけることです。セグメント ファイルは最初のステップで見つかります。 offset = 368776 の場合、000000000000000368769.index のメタデータの物理的な場所と 000000000000000368769.log の物理オフセット アドレスが順番に配置されます。次に、オフセット = 368776 になるまで、00000000000000368769.log が順番に検索されます。

上の図 3 から、これを行う利点がわかります。セグメント インデックス ファイルはスパース インデックス ストレージを採用しており、インデックス ファイルのサイズが削減され、mmap を通じてメモリを直接操作できます。スパース インデックスは、データ ファイルの対応する各メッセージのメタデータ ポインターを設定します。高密度インデックスよりも多くのストレージスペースを節約できますが、検索に時間がかかります。

3 Kafkaのファイル保存の仕組み – 実際の運用効果

実験環境:

• Kafka クラスター: 2 つの仮想マシンで構成
• CPU: 4コア
• 物理メモリ: 8GB
• ネットワークカード: ギガビットネットワークカード
• JVM ヒープ: 4GB

Kafka サーバーの構成と最適化の詳細については、kafka server.properties 構成の詳細を参照してください。

上記の図 5 からわかるように、Kafka の実行中に大規模なディスク読み取り操作が行われることはほとんどなく、主な操作はディスクへの定期的なバッチ書き込みであるため、ディスク操作は非常に効率的です。これは、Kafka ファイル ストレージでのメッセージの読み取りと書き込みの設計に密接に関連しています。 Kafka でのメッセージの読み取りと書き込みには、次の特徴があります。

メッセージを書く

• メッセージは Java ヒープからページ キャッシュ (つまり物理メモリ) に転送されます。
• 非同期スレッドは、ページ キャッシュからディスクにメッセージをフラッシュします。

メッセージを読む

• メッセージはページ キャッシュからソケットに直接転送され、送信されます。
• ページ キャッシュ内に対応するデータが見つからない場合、ディスク IO が生成され、メッセージがディスクからページ キャッシュにロードされ、ソケットから直接送信されます。

Kafka の効率的なファイルストレージ設計機能

• Kafka はトピック内のパーティション化された大きなファイルを複数の小さなファイル セグメントに分割します。複数の小さなファイル セグメントを使用すると、消費されたファイルを定期的にクリアまたは削除することが容易になり、ディスク使用量が削減されます。
• インデックス情報を使用すると、メッセージをすばやく見つけ、応答の最大サイズを判断できます。
• すべてのインデックス メタデータをメモリにマッピングすることで、セグメント ファイル IO ディスク操作を回避できます。
• インデックス ファイルをまばらに保存することで、インデックス ファイルのメタデータが占めるスペースを大幅に削減できます。