「MQ シリーズのマスター」 - Kafka アーキテクチャ設計の Ren 子午線と Du 子午線

[[404881]]

みなさんこんにちは。私はウー兄弟です。これは、Kafka のアーキテクチャ設計に関する「Mastering MQ Series」の 3 番目の記事です。

この記事では、Kafka アーキテクチャ設計の 2 つの子午線について説明します。

この重要なポイントを把握することで、Kafka のアーキテクチャ設計をより深く理解し、Kafka のコアとなる技術ソリューションを習得できるようになると信じています。

さっそく、旅を始めましょう。

1. Kafka の技術的な難しさは何ですか?

前回の記事「カフカの謎を解き明かす」では、2 つの重要な情報を説明しました。

1. Kafka はリアルタイム ログ ストリーム用に生まれたため、同時実行性と処理するデータ量が非常に大きくなります。 Kafka 自体は高同時実行システムであり、高同時実行シナリオでは、高パフォーマンス、高可用性、高スケーラビリティという 3 つの典型的な大きな課題に必然的に直面することがわかります。

2. 実装の複雑さを簡素化するために、Kafka は最終的に非常に巧妙なメッセージ モデルを採用しました。このモデルでは、すべてのメッセージが永続的に保存されるため、コンシューマーは必要なもの、つまり必要なメッセージをいつでも取得でき、取得するにはメッセージ オフセットを渡すだけで済みます。

最終的に、Kafka は「ストレージ システム」へと退化しました。したがって、大量のメッセージの保存問題は、Kafka アーキテクチャ設計における最大の技術的難しさです。

2. カフカのアーキテクチャ設計の2つの子午線

さらに分析してみましょう: Kafka はストレージの問題をどのように解決するのでしょうか?

膨大な量のデータに直面すると、単一のマシンのストレージ容量と読み取り/書き込みパフォーマンスは確かに限られているため、データをシャードに保存するというストレージ ソリューションを誰もが簡単に思いつきます。この解決策は、私たちの実際の仕事でも非常に一般的です。

1. 例えば、データベース設計では、一つのテーブル内のデータ量が数千万、数億に達すると、複数のライブラリや複数のテーブルに分割します。

2. 例えば、キャッシュ設計において、単一の Redis インスタンスのデータ量が数十 GB に達し、パフォーマンスのボトルネックが発生する場合は、単一マシン アーキテクチャをシャード クラスター アーキテクチャに変更します。

同様の分割の考え方は、HDFS や ElasticSearch などのミドルウェアでも見られます。

Kafka も例外ではなく、この水平分割ソリューションを採用しています。 Kafka の用語では、分割されたデータのサブセットはパーティションと呼ばれ、各パーティションのデータ コレクションは完全なデータと呼ばれます。

Kafka のパーティションがどのように機能するかを見てみましょう。非常に鮮明な例を見てみましょう。 「カフカ」を「高速道路」に例えると、

1. 北京広州高速道路という名前を聞くと、誰もがそれが北京から広州までの高速道路であることを知っています。これは論理名であり、Kafka のトピックとして理解できます。

2. 高速道路には通常、迂回用の複数の車線があります。各車線の車は同じ目的地（同じトピックに属する）に向かいます。ここの車線はパーティションです。

このように、メッセージのフローパスは以下の図のようになります。まずトピック ルーティングを実行し、次にパーティション ルーティングを実行して、最後にどのパーティションにメッセージを送信するかを決定します。

パーティション ルーティングは、ハッシュ関数として簡単に理解できます。メッセージを送信するときに、プロデューサーはこの関数をカスタマイズしてパーティション ルールを決定できます。パーティション分割ルールが適切に設定されていれば、すべてのメッセージが異なるパーティションに均等に分散されます。

これらの 2 つの関係層を通じて、最終的にトピック「パーティション」の下に新しい分割単位が作成されます。まず、メッセージはトピックを通じて論理的に分類され、次にパーティションを通じて物理的にさらに分割されます。最後に、複数のパーティションがクラスター内の各マシンに均等に分散されるため、ストレージのスケーラビリティの問題が効果的に解決されます。

したがって、パーティションは Kafka の最も基本的なデプロイメント単位です。この記事では、次の 2 つの理由から、パーティションを Kafka アーキテクチャ設計の Ren 子午線と Du 子午線と呼びます。

1. パーティションはストレージの鍵です。 MQ のコアプロセス「1 回の送信、1 回の保存、1 回の消費」は、これを中心に展開する必要があります。

2. Kafka の高並行性設計における最も困難な 3 つの問題はすべて、パーティションに関連しています。

したがって、パーティションをルートとして、Kafka アーキテクチャ設計におけるさまざまな知識ポイントを自然に関連付け、信頼性の高い知識システムを形成できます。

次に、私の考えに沿って、Partition を手がかりに Kafka のマクロアーキテクチャを分析してください。

3. Kafka のマクロアーキテクチャ設計

次に、Partition の分散機能がどのように実装されているかを見てみましょう。これは Kafka の全体的なアーキテクチャとどのように関係しているのでしょうか?

前述のように、パーティションはトピックの下の分割単位です。これは Kafka の最も基本的なデプロイメント ユニットであり、Kafka クラスターの構成を決定します。

2 つのトピックがあり、それぞれに 2 つのパーティションがあるとします。 Kafka クラスターが 2 台のマシンで構成されている場合、デプロイメント アーキテクチャは次のようになります。

同じトピックの 2 つのパーティションが異なるメッセージ サーバーに分散されており、メッセージの分散ストレージが可能になっていることがわかります。ただし、Kafka のような高同時実行システムの場合、スケーラブルなストレージだけでは不十分です。メッセージも並行して取得する必要があります。そうしないと、パフォーマンスに大きなボトルネックが発生します。

次に消費者側を見てみましょう。パーティションと組み合わせて並列処理を実現するにはどうすればよいでしょうか?

消費者の観点からすると、まず 2 つの基本的な要求を満たす必要があります。

1. ブロードキャスト消費機能: 同じトピックを複数のコンシューマーがサブスクライブでき、メッセージを複数回消費できます。

2. クラスター消費能力: コンシューマー自体もクラスターである場合、各メッセージはクラスター内の 1 つのコンシューマーにのみ配布され、処理されます。

これら 2 つの要件を満たすために、Kafka はコンシューマ グループの概念を導入します。各コンシューマーには対応するコンシューマー グループがあり、グループ間でブロードキャスト消費が実行され、グループ内でクラスター消費が実行されます。さらに、Kafka では、各パーティションはコンシューマー グループ内の 1 つのコンシューマーのみが使用できることも規定されています。

最終的な消費関係は、次の図に示されています。トピック A に 4 つのパーティションがあり、コンシューマー グループ 2 には 2 つのコンシューマーしかないと仮定すると、2 つのコンシューマー グループは最終的に全体の負荷を共有し、それぞれ 2 つのパーティションからのメッセージを消費します。

メッセージ処理を高速化したい場合はどうすればよいでしょうか?非常にシンプルです。コンシューマー グループ 2 に新しいコンシューマーを追加するだけで、Kafka はパーティションに基づいて負荷分散を再度実行します。コンシューマーの数が 4 に増えると、各コンシューマーは 1 つのパーティションのみを処理する必要があり、処理速度は 2 倍になります。

この時点で、スケーラブルなストレージと並列メッセージ処理という 2 つの困難な問題が解決されました。しかし、高同時実行アーキテクチャの設計には、高可用性設計という非常に重要な問題がまだ残っています。

Kafka クラスターでは、各マシンにいくつかのパーティションが保存されます。マシンがダウンした場合、そのマシン上のデータは失われませんか?

この時点で、メッセージを永続化することを間違いなく考えるでしょうが、永続化によって解決できるのは問題の一部だけです。マシンの再起動後に履歴データが失われないようにすることしかできません。ただし、マシンが復元されるまでこのデータにはアクセスできません。これは、高同時実行システムでは耐えられないことです。

したがって、マシンに障害が発生した場合でもサービスが引き続き利用可能であることを保証するには、Kafka にフェイルオーバー機能が必要です。

ElasticSearch や Redis Cluster などの信頼性の高い分散システムを分析すると、それらはすべてマルチコピー冗長メカニズムを備えていることがわかります。

そうです、Kafka は Partition のマルチコピー メカニズムを通じて高可用性の問題を解決します。 Kafka クラスターでは、各パーティションに複数のレプリカがあり、同じメッセージは同じパーティションの異なるレプリカに保存されます。

レプリカ間の関係は「1 つのマスターと複数のスレーブ」であり、リーダー レプリカは読み取りおよび書き込み要求を担当し、フォロワー レプリカはリーダー レプリカとのメッセージの同期のみを担当します。リーダー レプリカに障害が発生した場合、新しいリーダー レプリカとして選出され、外部にサービスを提供する機会が与えられます。それ以外の場合は、常にスタンバイ状態になります。

ここで、Kafka クラスターには 4 台のサーバーがあり、トピック A とトピック B の両方に 2 つのパーティションがあり、各パーティションに 2 つのレプリカがあると想定します。最終的なマルチレプリカ アーキテクチャは次の図のようになります。

当然ながら、このクラスター内のいずれかのマシンに障害が発生しても、Kafka の可用性には影響せず、データはそのまま残ります。

上記を理解した上で、Kafka の全体的なアーキテクチャを見てみましょう。

1. プロデューサー: プロデューサーは、メッセージを作成し、それを Kafka クラスターに配信する役割を担います。配信するときは、メッセージが属するトピックを指定し、送信先のパーティションを決定する必要があります。

2. コンシューマー: コンシューマーは、サブスクライブしているトピックと所属するコンシューマー グループに基づいて、どのパーティションからメッセージをプルするかを決定します。

3. ブローカー: 水平方向に拡張可能で、パーティション管理、メッセージの永続化、自動フェイルオーバーなどを担当するメッセージ サーバー。

4. Zookeeper: クラスター内のブローカー ノードとトピック、各トピックのパーティションなど、クラスターのメタデータ管理やその他の機能を担当します。

明らかに、Kafka の全体的なアーキテクチャでは、パーティションはメッセージを送信、保存、および消費するためのリンクです。それを徹底的に理解し、全体の構造を理解すると、文脈がより明確になります。

4. 最後に

この記事では、Partition を出発点として、マクロの観点から Kafka の全体的なアーキテクチャを分析します。この記事の内容を簡単に要約してみましょう。

1. 巧妙なモデル設計により、Kafka は大量のメッセージを格納するストレージ システムへと変貌しました。

2. ストレージのスケーラビリティ問題を解決するために、Kafka はデータを水平に分割し、パーティションを導入します。パーティションは、Kafka デプロイメントの基本単位であり、Kafka の同時処理の最小粒度でもあります。

3. 高同時実行システムでは、高可用性も必要です。 Kafka は、パーティションのマルチコピー冗長メカニズムを使用してフェイルオーバーを実行し、高い信頼性を確保します。

この記事が、暗記モードから抜け出し、まず支点を見つけ、次に Kafka アーキテクチャ設計の詳細について考え、その理由を理解するのに役立つことを願っています。

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