「MQ シリーズをマスターする」 - カフカの謎を解き明かす

[[390063]]

みなさんこんにちは。私はウー兄弟です。これは「MQ マスタリーシリーズ」の第 2 弾です。少し遅くなりましたが、何人かの読者から更新を促されました。本当にごめんなさい！

この記事は数週間遅れています。私の最初のアイデアは、それぞれの特定のメッセージミドルウェアについて徹底的に記述するだけでなく、長さも制御することでした。しかし、書き出してみたら難しすぎて、両方を同時に持つのは難しいと分かりました。

最終的に、複数回に分けて書くことにしました。一方では、出力周波数を高速化することができます。その一方で、誰にとっても理解しやすいものとなっています。

さっそく、第二波が始まります。

01 なぜ Kafka から始めるのですか?

「Mastering MQ」の冒頭では、MQ の本質である「1 つの送信、1 つの保存、1 つの消費」を中心に、MQ の一般的な知識を説明し、体系的に「MQ の設計をどのように開始するか」に答えます。

この記事から、具体的なメッセージミドルウェアについて説明していきます。私が Kafka から始めることにした理由は 3 つあります。

まず、RocketMQ と Kafka は現在最も人気のある 2 つのメッセージミドルウェアであり、インターネット企業で最も広く使用されています。彼らがこのシリーズの焦点となります。

第二に、MQの開発の歴史から見ると、KafkaはRocketMQより前に誕生しており、AlibabaチームはRocketMQを実装する際にKafkaの設計思想を全面的に借用しました。 Kafka の設計原則を習得すると、後で RocketMQ を理解するのがはるかに簡単になります。

3 番目に、Kafka は実際には軽量の MQ です。 MQ の最も基本的な機能を備えていますが、遅延キューや再試行メカニズムなどの高度な機能はサポートしていないため、実装の複雑さが軽減されます。 Kafka から始めると、誰もが MQ の中核をすぐに理解できるようになります。

背景を説明した上で、私の考えに沿ってカフカを浅くから深く分析してみてください。

02 カフカの公開

テクノロジーを詳細に分析する前に、アーキテクチャや技術的な詳細をすぐに理解するのではなく、まずそれが何であるかを把握することが推奨されます。それはどのような問題を解決するために作られたのでしょうか?

この背景知識を習得すると、デザインの考慮事項とその背後にあるアイデアを理解するのに役立ちます。

この記事を書くにあたり、多くの情報を参考にしました。カフカの定義は多様であると言えます。よく考えないと混乱してしまいます。全員にそれを経験させる必要があると思います。

まず、Kafka の公式 Web サイトで提供されている定義を見てみましょう。

Apache Kafka はオープンソースの分散イベントストリーミングプラットフォームです。

中国語に翻訳: Apache Kafka はオープンソースの分散ストリーム処理プラットフォームです。

Kafka はメッセージングシステムではないのですか?なぜ分散ストリーム処理プラットフォームと呼ばれるのでしょうか?これら2つは同じものですか？

読者の中には、このような疑問を持つ人もいるかもしれません。この疑問を説明するには、まずカフカの誕生の背景から始める必要があります。

Kafka はもともと Linkedin 内で育成されたプロジェクトでした。これは、次の 2 つのシナリオを処理するための「データパイプライン」として設計されました。

1. 運用アクティビティシナリオ: ユーザーの閲覧、検索、クリック、アクティビティ、その他の動作を記録します。
2. システム運用および保守シナリオ: サーバーの CPU、メモリ、要求期間、その他のパフォーマンス指標を監視します。

どちらのタイプのデータもログのカテゴリに属し、データがリアルタイムで生成され、データ量が大きいという特徴があることがわかります。

Linkedin は当初、データ転送の問題を解決するために ActiveMQ を使用しようとしましたが、パフォーマンスが要件を満たさなかったため、独自に Kafka を開発することにしました。

そのため、Kafka は最初からリアルタイムのログストリーミングのために誕生しました。このような背景を知れば、Kafka とストリーミングデータの関係、そしてなぜ Kafka がビッグデータの分野で広く使用されているのかを理解するのは難しくありません。これは、もともとビッグデータのパイプライン問題を解決するために作成されたためです。

説明させてください: Kafka がストリーム処理プラットフォームとして正式に定義されているのはなぜでしょうか?データチャネル機能を提供するだけではないでしょうか?プラットフォームとどのように関係しているのでしょうか?

これは、Kafka がバージョン 0.8 以降、次のようなデータ処理に関連するコンポーネントを提供しているためです。

1. Kafka Streams: Spark や Flink に似た軽量のストリームコンピューティングライブラリ。
2. Kafka Connect: Kafka からリレーショナルデータベース、Hadoop、検索エンジンにデータをインポートできるデータ同期ツール。

Kafka の野望は単なるメッセージングシステムではないことがわかります。長年にわたり「リアルタイムストリーム処理プラットフォーム」に向けて開発が進められてきました。

この時点で、Kafka の公式 Web サイトに記載されている 3 つの機能を理解するのは難しくありません。

1. データの公開およびサブスクリプション機能（メッセージキュー）
2. 分散データストレージ機能（ストレージシステム）
3. リアルタイムデータ処理機能（ストリーム処理エンジン）

このように、Kafka の開発履歴と定義は基本的に明確です。もちろん、このシリーズでは Kafka の最初の 2 つの機能にのみ焦点を当てています。どちらの機能も MQ と密接に関連しているためです。

03 Kafkaのメッセージモデルから始める

Kafka の位置付けと背景がわかったところで、Kafka の設計哲学を分析してみましょう。

前回の記事では、MQ を完全に理解するには、技術的な詳細に直接進むことは言うまでもなく、すぐに技術的なアーキテクチャを見るのではなく、「メッセージモデル」などの最もコアとなる理論レベルから始めることを推奨すると述べました。

いわゆるメッセージモデルは、論理構造として理解できます。これは技術アーキテクチャの上にある抽象レイヤーであり、多くの場合、中核となる設計アイデアを意味します。

次に、Kafka のメッセージモデルを分析して、それがどのように進化してきたかを見てみましょう。

まず、メッセージデータを複数のコンシューマーに配布し、各コンシューマーがメッセージの全量を受信できるようにするには、ブロードキャストを考えるのが自然です。

ここで問題が発生します。メッセージが届くと、すべての消費者にブロードキャストされますが、すべての消費者がすべてのメッセージを望んでいるわけではありません。たとえば、コンシューマー A はメッセージ 1、2、3 のみを希望し、コンシューマー B はメッセージ 4、5、6 のみを希望しているとします。この場合、どうすればよいでしょうか。

この問題の重要な点は、MQ がメッセージのセマンティクスを理解しておらず、メッセージを分類して配信することができないことです。

この時点で、MQ は非常に巧妙な解決策を思いつきました。つまり、問題を直接プロデューサーに投げかけ、プロデューサーがメッセージを送信するときにメッセージを論理的に分類することを要求し、私たちがよく知っているトピックとパブリッシュサブスクライブモデルに進化したのです。

この方法では、消費者は興味のあるトピックをサブスクライブし、そのトピックからメッセージを取得するだけで済みます。

しかし、これを実行した後でも、まだ問題が残ります。複数の消費者が同じトピックに関心を持っている場合 (下の図の消費者 C など)、どのように解決すればよいのでしょうか。

従来のキューモード (ユニキャスト) を使用すると、コンシューマーがキューからメッセージを取得すると、そのメッセージは削除され、別のコンシューマーはそれを取得できなくなります。

このとき、次のような解決策を考えるのが自然です。

つまり、トピックに新しいコンシューマーが追加されるたびに、同一のデータキューが「コピー」されます。

これにより問題は解決されますが、下流の消費者の数が増えると、MQ のパフォーマンスは急速に低下します。特に、最初からビッグデータシナリオを処理するように設計された Kafka の場合、このレプリケーション操作は明らかにコストがかかりすぎます。

現時点では、Kafka が最も簡潔なソリューションを提供しています。Kafka はすべてのメッセージを永続的に保存し、コンシューマーはメッセージのオフセットを渡すだけで、いつでも必要なもの、つまり任意のメッセージを取得できます。

このような根本的な変更により、複雑な消費の問題が完全に消費者に戻され、Kafka 自体の複雑さが大幅に軽減され、高いパフォーマンスと高いスケーラビリティの優れた基盤が築かれます。 (これが Kafka と ActiveMQ と RabbitMQ の根本的な違いです)

最後に、簡略化すると次の図のようになります。

これは Kafka のオリジナルのメッセージモデルです。