Kafka は読み取りと書き込みの分離をサポートしていません。今日初めて知りました！

[[263555]]

Kafka では、メッセージを書き込むプロデューサーとメッセージを読み取るコンシューマーの操作はすべてリーダー レプリカと対話し、プライマリ書き込み、プライマリ読み取りのプロダクションおよびコンシューム モデルを実現します。データベース、Redis などはすべて、マスター書き込み、マスター読み取りの機能を備えており、同時に、読み取りと書き込みの分離を意味するマスター書き込み、スレーブ読み取りの機能もサポートしています。マスター書き込み、マスター読み取りに対応するため、ここではマスター書き込み、スレーブ読み取りと呼ぶことにします。

Kafka はマスター書き込みとスレーブ読み取りをサポートしていません。なぜ？

コードの観点から見ると、コードの複雑さは増しますが、この機能は Kafka で完全にサポートされます。この問題については、「利益ポイント」の観点から具体的な分析を行うことができます。マスター書き込みとスレーブ読み取りにより、スレーブ ノードはマスター ノードの負荷圧力を共有できるため、スレーブ ノードがアイドル状態のときにマスター ノードが過負荷になるのを防ぐことができます。ただし、マスター書き込みスレーブ読み取りアプローチには、2 つの明らかな欠点もあります。

• データの一貫性の問題。マスターノードからスレーブノードにデータが転送されるときには、必然的に遅延時間ウィンドウが発生し、この時間ウィンドウによってマスターノードとスレーブノード間のデータの不整合が発生します。ある瞬間、マスターノードとスレーブノードの両方でデータ A の値は X です。その後、マスターノードの A の値が Y に変更されます。この変更がスレーブノードに通知される前に、アプリケーションによって読み取られたスレーブノードのデータ A の値は正しい Y ではなく、データの不整合が発生します。
• 遅延の問題。 Redis などのコンポーネントの場合、データがマスター ノードに書き込まれ、スレーブ ノードに同期されるプロセスは、ネットワーク → マスター ノード メモリ → ネットワーク → スレーブ ノード メモリという段階を経る必要があります。全体のプロセスにはある程度の時間がかかります。 Kafka では、マスターとスレーブの同期に Redis よりも時間がかかります。ネットワーク → マスターノードメモリ → マスターノードディスク → ネットワーク → スレーブノードメモリ → スレーブノードディスクという段階を経る必要があります。レイテンシに敏感なアプリケーションの場合、マスター書き込みスレーブ読み取り機能はあまり適していません。

実際には、多くのアプリケーションは、一定期間にわたって、ある程度の遅延とデータの不整合の両方を許容できます。

では、この場合、Kafka はマスター書き込みとスレーブ読み取りの機能をサポートする必要があるのでしょうか?

マスター書き込みとスレーブ読み取りは一定量の負荷を共有できますが、完全な負荷分散を実現することはできません。たとえば、データ書き込み圧力が非常に高く、読み取り圧力が非常に低い場合、スレーブ ノードは負荷圧力のごく一部しか共有できず、圧力の大部分はマスター ノードに残ります。ただし、Kafka は高度な負荷分散を実現でき、このバランスはプライマリ書き込み、プライマリ読み取りアーキテクチャで実装されます。次の図に示すように、Kafka の生産および消費モデルを見てみましょう。

Kafka クラスターには 3 つのパーティションがあり、各パーティションには 3 つのレプリカがあり、3 つのブローカーに均等に分散されています。灰色の陰影はリーダー レプリカを表し、灰色以外の陰影はフォロワー レプリカを表します。点線は、フォロワー レプリカがリーダー レプリカからメッセージをプルすることを示します。プロデューサーがメッセージを書き込むと、そのメッセージはリーダー コピーに書き込まれます。上の図の状況では、各ブローカーにはプロデューサーからのメッセージが流れ込んでいます。コンシューマーがメッセージを読み取ると、そのメッセージはリーダー コピーからも読み取られます。図 8-23 の状況では、各ブローカーからコンシューマーにメッセージが流れ出ています。

各ブローカーの読み取り負荷と書き込み負荷が同じであることが明確にわかります。これは、プライマリ書き込みとセカンダリ読み取りでは実現できない負荷分散を、Kafka がプライマリ読み取りを通じて実現できることを意味します。上図は理想的な展開状況を示しています。次のような状況（これらに限定されません）では、ある程度の負荷の不均衡が発生する可能性があります。

（１）ブローカー側のパーティションが不均等に分散されている。トピックを作成するときに、一部のブローカーにはより多くのパーティションが割り当てられ、他のブローカーにはより少ないパーティションが割り当てられる場合があり、当然、リーダー レプリカは不均等に割り当てられます。

（２）プロデューサーが書くメッセージにばらつきがある。プロデューサーは、一部のブローカーのリーダー コピーに対してのみ大量の書き込み操作を実行し、他のブローカーのリーダー コピーを無視する場合があります。

（３）消費者は情報を不均等に消費している。コンシューマーは、一部のブローカーのリーダー コピーに対してのみ大量のプル操作を実行し、他のブローカーのリーダー コピーを無視する場合があります。

（４）リーダーレプリカは不均一に切り替わる。実際のアプリケーションでは、ブローカーの障害により、マスター レプリカとスレーブ レプリカの切り替えや、パーティション レプリカの再配布などが発生する可能性があります。これらのアクションにより、各ブローカー内のリーダー レプリカの配布が不均一になる可能性があります。

これに対してはいくつかの予防策を講じることができます。

最初のケースでは、トピックを作成するときに、パーティションの分散をできるだけバランスよくするようにしてください。幸いなことに、Kafka の対応する分散アルゴリズムもこの目標を達成しようと努めています。開発者がディストリビューションをカスタマイズする場合は、この点に注意する必要があります。 2 番目と 3 番目の状況では、マスター書き込みとスレーブ読み取りでも解決できません。 4 番目のケースでは、Kafka はリーダー レプリカのバランスを実現するために優先レプリカ選択を提供します。同時に、対応する監視、警報、運用保守プラットフォームと連携して、バランスのとれた最適化を実現することもできます。

実際のアプリケーションでは、監視、アラーム、運用と保守を組み合わせたエコロジカル プラットフォームの助けを借りて、Kafka はほとんどの場合に高度な負荷分散を実現できます。

一般に、Kafka はプライマリ書き込みとプライマリ読み取りのみをサポートしており、これにはいくつかの利点があります。

コードの実装ロジックを簡素化し、エラーの可能性を減らすことができます。負荷の粒度を均等に分散できます。マスター書き込みスレーブ読み取りモデルと比較すると、負荷パフォーマンスが優れているだけでなく、ユーザーによる制御も可能です。遅延の影響はありません。

レプリカが安定している場合、データの不整合は発生しません。このため、Kafka は、何のメリットもないマスター書き込みスレーブ読み取り機能をなぜ実装する必要があるのでしょうか?これらすべては、カフカの優れたアーキテクチャ設計によるものです。ある意味、マスター書き込みスレーブ読み取り機能は、設計上の欠陥による暫定的な対策です。