写真と文章による詳細な説明: 私がカフカをこれほど愛する秘密は何でしょうか?

[[357091]]

序文

さて、本題に入りましょう。今日皆さんにお話しするのは、私たちの古い友人であるカフカの死後の世界と現在の生活についてです。

リアルタイムパフォーマンスに対する要件がますます高まる中、膨大な量のデータを送信する際に、データの高速転送をどのように確保できるでしょうか?そのため、メッセージキューが作成されました。

「メッセージ」とは、2 台のコンピュータ間で送信されるデータの単位です。メッセージは、単なるテキスト文字列のような非常に単純なものから、埋め込みオブジェクトを含むような複雑なものまであります。

メッセージはキューに送信されます。メッセージキューは、送信中のメッセージを保存するコンテナーです。 Kafka は分散メッセージキューであり、これを習得することは不可欠です。

この記事では、Kafka の基本コンポーネントと基本アプリケーションの実装の詳細について詳しく説明します。同時に、私はカフカの核となる知識を皆さんにもっと深く理解してもらえるよう、何晩も徹夜して図を描きました。最後に、実際のビジネスにおける Kafka の応用についてもまとめます。 Xiaoyu さんと一緒に、Kafka の小さな秘密を学びましょう。

Kafka の概念

Kafka は、LinkedIn によって最初に開発され、Scala で記述され、現在は Apache オープンソースプロジェクトとなっている、高スループットの分散型パブリッシュ/サブスクライブベースのメッセージングシステムです。

Kafka の主要コンポーネント

ブローカー: メッセージの保存と転送を担当する Kafka サーバー
トピック: メッセージカテゴリ。Kafka はトピックに従ってメッセージを分類します。

パーティション: トピックパーティション。トピックには複数のパーティションを含めることができます。トピックメッセージは各パーティションに保存されます。

オフセット: ログ内のメッセージの位置。パーティション上のメッセージのオフセットとして理解でき、またメッセージを表す一意のシリアル番号としても理解できます。

プロデューサー: メッセージプロデューサー
コンシューマー: メッセージコンシューマー
消費者グループ: 消費者のグループ化。各消費者はグループに属している必要があります。
Zookeeper: クラスターブローカー、トピック、パーティション、その他のメタデータを保存します。さらに、ブローカーの障害検出、パーティションリーダーの選出、負荷分散などの機能も担当します。

Kafka の利点

分離: メッセージングシステムは、暗黙的なデータベースインターフェイスレイヤーを処理プロセスに挿入し、処理プロセスの両側でこのインターフェイスを実装する必要があります。これにより、同じインターフェース制約に準拠している限り、両側での処理を個別に拡張または変更できます。
冗長性: メッセージキューは、データが完全に処理されるまでデータを保持するため、データ損失のリスクを回避できます。多くのメッセージキューで採用されている「挿入、取得、削除」パラダイムでは、キューからメッセージを削除する前に、処理システムはメッセージが処理されたことを明確に示し、使用が完了するまでデータが安全に保存されるようにする必要があります。
スケーラビリティ: メッセージキューは処理を分離するため、追加の処理を追加するだけで、メッセージのエンキューと処理の頻度を簡単に増やすことができます。コードの変更やパラメータの調整は必要ありません。スケーリングは電源ボタンを押すだけで簡単に行えます。
柔軟性とピーク処理能力: メッセージキューを使用すると、突然の過負荷要求によって主要コンポーネントが完全にクラッシュすることなく、突然のアクセス圧力に耐えることができます。
回復可能性: メッセージキューはプロセス間の結合を減らすため、メッセージを処理するプロセスがクラッシュした場合でも、キューに追加されたメッセージはシステムの回復後に引き続き処理できます。
順序の保証: ほとんどのメッセージキューは本質的にソートされており、データが特定の順序で処理されることを保証できます。 Kafka はパーティション内のメッセージの順序を保証します。
バッファリング: メッセージキューはバッファリングレイヤーを使用して、タスクを最大限の効率で実行できるようにします。キューへの書き込みは可能な限り迅速に処理されます。このバッファは、システムがデータを通過する速度を制御および最適化するのに役立ちます。
非同期通信: メッセージキューは、ユーザーがメッセージをキューに入れてもすぐには処理しない、非同期処理メカニズムを提供します。必要な数のメッセージをキューに入れて、必要なときに処理することができます。

Kafka アプリケーションシナリオ

アクティビティ追跡: ウェブサイトのPV/UV分析など、ウェブサイトユーザーとフロントエンドアプリケーション間のインタラクションを追跡します。
メッセージ送信: マーケティング活動(登録後のクーポンコードや特典の送信)などのシステム間の非同期情報交換
ログ収集: アプリケーションの監視やアラートなどのシステムとアプリケーションのメトリックとログを収集します。
ログの送信: トランザクション統計などのデータベース更新を Kafka に公開します。

Kafka データストレージ設計

パーティションデータファイル

パーティション内の各メッセージには、オフセット、MessageSize、データの 3 つの属性が含まれます。オフセットは、このパーティション内のメッセージのオフセットを示します。オフセットは、パーティションデータファイル内のメッセージの実際の保存場所ではなく、パーティション内のメッセージを一意に識別する論理値です。オフセットは、パーティション内のメッセージの ID と見なすことができます。 MessageSize はメッセージコンテンツデータのサイズを示します。データはメッセージの具体的な内容です。

データファイルセグメントセグメント

パーティションは物理的に複数のセグメントファイルで構成されます。各セグメントは同じサイズで、順番に読み書きされます。各セグメントデータファイルの名前はセグメント内の最小オフセットにちなんで付けられ、ファイル拡張子は .log です。このように、指定されたオフセットを持つメッセージを検索する場合、バイナリ検索を使用して、メッセージが配置されているセグメントデータファイルを見つけることができます。

データファイルインデックス

Kafka は、セグメント化されたデータファイルごとにインデックスファイルを作成します。ファイル名はデータファイルと同じですが、ファイル拡張子は .index です。インデックスファイルは、データファイル内の各メッセージのインデックスを作成しません。代わりに、スパースストレージ方式を使用して、一定数のデータごとにインデックスを作成します。これにより、インデックスファイルが多くのスペースを占有することがなくなり、インデックスファイルをメモリ内に保持できるようになります。

Kafka における Zookeeper の役割

Kafka クラスター、プロデューサー、コンシューマーはいずれも、システムの可用性を確保し、クラスター内にメタ情報を保存するために Zookeeper に依存しています。

Kafka は、分散調整フレームワークとして Zookeeper を使用します。これは、メッセージの生成、メッセージの保存、メッセージの消費のプロセスを非常にうまく組み合わせたものです。

同時に、Zookeeper の助けを借りて、Kafka はプロデューサー、コンシューマー、ブローカーを含むすべてのコンポーネントに対してステートレスな方法でプロデューサーとコンシューマー間のサブスクリプション関係を確立し、プロデューサーとコンシューマー間の負荷分散を実現できます。

プロデューサーデザイン

負荷分散

メッセージトピックは複数のパーティションで構成され、パーティションは異なるブローカーに均等に分散されるため、ブローカークラスターのパフォーマンスを効果的に活用し、メッセージのスループットを向上させるために、プロデューサーはランダムメソッドまたはハッシュメソッドを使用して複数のパーティションにメッセージを均等に送信し、負荷分散を実現できます。

一括送信

これは、メッセージのスループットを向上させる重要な方法です。プロデューサーはメモリ内の複数のメッセージをマージし、1 つのリクエストでブローカーにメッセージのバッチを送信できるため、ブローカーがメッセージを保存するための IO 操作の数が大幅に削減されます。ただし、これはメッセージのリアルタイム性にもある程度影響を及ぼし、これはレイテンシのコストと引き換えにスループットを向上させることに相当します。

圧縮

Kafka はバッチでのメッセージの送信をサポートしています。これに基づいて、Kafka はメッセージバッチの圧縮もサポートします。プロデューサーは、メッセージバッチを GZIP または Snappy 形式で圧縮できます。プロデューサー側で圧縮した後、コンシューマー側で解凍する必要があります。圧縮の利点は、送信されるデータの量が削減され、ネットワーク送信の負荷が軽減されることです。ビッグデータを処理する場合、ボトルネックは CPU ではなくネットワークに反映されることが多いです (圧縮と解凍によって CPU リソースが消費されます)。

では、メッセージが圧縮されているか圧縮されていないかをどのように区別するのでしょうか? Kafka はメッセージヘッダーに圧縮属性バイトを追加します。このバイトの最後の 2 桁は、メッセージ圧縮に使用されるエンコードを示します。最後の 2 桁が 0 の場合、メッセージは圧縮されていないことを意味します。

消費者向けデザイン

消費者団体

同じコンシューマーグループ内の複数のコンシューマーインスタンスは、同時に同じパーティションを消費しません。これはキューモードと同等です。パーティション内のメッセージは順序付けられ、コンシューマーはプル方式でメッセージを消費します。 Kafka は、パーティションの使用済みメッセージを削除せず、ディスクデータを順番に読み書きし、O(1) の時間計算量でメッセージの永続化機能を提供します。

実用化

メッセージングシステムとしての Kafka

トピック (パーティション) 内に並列処理の概念を持たせることで、Kafka はコンシューマープロセスのプール全体にわたって順序の保証と負荷分散を提供できます。これは、トピック内のパーティションをコンシューマーグループ内のコンシューマーに割り当て、各パーティションがグループ内の 1 つのコンシューマーによってのみ消費されるようにすることで実現されます。こうすることで、コンシューマーがそのパーティションの唯一のリーダーとなり、データを順番に使用することが保証されます。パーティションが多数あるため、多くのコンシューマーインスタンス間で負荷を分散できます。ただし、コンシューマーグループ内のパーティション数よりも多くのコンシューマーインスタンスは存在できないことに注意してください。

ストレージシステムとしての Kafka

Kafka は非常に優れたストレージシステムです。 Kafka に書き込まれたデータはディスクに書き込まれ、フォールトトレランスのために複製されます。 Kafka では、プロデューサーが確認応答を待機できるため、書き込みは完全に複製されるまで完了とは見なされず、書き込み先のサーバーに障害が発生しても書き込みが存続することが保証されます。

Kafka のディスク上の構造はスケールを非常にうまく利用しており、サーバー上に 50 KB の永続データがあっても 50 TB の永続データがあっても、Kafka は同じように動作します。

Kafka はストレージを重視し、クライアントが読み取り位置を制御できるようにするため、高パフォーマンスで低レイテンシのコミットログのストレージ、レプリケーション、および伝播用に設計された特殊な分散ファイルシステムと考えることができます。

ストリーム処理のための Kafka

複雑な変換のために、Kafka は完全に統合された Streams API を提供します。これにより、ストリームの集計を計算したり、ストリームを結合したりするなど、重要な処理を実行するアプリケーションを構築できます。

このツールは、順序どおりでないデータの処理、コード変更時の入力の再処理、ステートフルな計算の実行など、このようなアプリケーションが直面する課題に対処するのに役立ちます。

Streams API は、Kafka によって提供されるコア原則に基づいて構築されています。つまり、入力にはプロデューサー API とコンシューマー API を使用し、ステートフルストレージには Kafka を使用し、フォールトトレランス* にはストリームプロセッサインスタンス間で同じグループメカニズムを使用します。

<<: ガートナーは強力なエンタープライズクラウド戦略を構築するための7つのステップを概説

>>: インサイト: VUCA時代のデジタル人材管理を考える