Apache RocketMQ、クラウドネイティブのユニファイドメッセージングエンジンを構築

データから大規模モデルのアプリケーションまで、開発のヒントを共有する杭州元創会議が 11 月 25 日に開催されました。

この記事は、2023 Yunqi Conference で Lin Qingshan が行った基調講演「Apache RocketMQ Cloud Native Unified Messaging Engine」を編集したものです。

Apache RocketMQ の概要

メッセージキューの進化の傾向

オペレーティングシステム、データベース、ミドルウェアは基本ソフトウェアのトロイカであり、メッセージキューは最も古典的なミドルウェアの1つであり、30年以上の歴史があります。彼の開発は主に次の段階を経ました。

第一段階、2000年以前。最初のメッセージキューは 1980 年代の情報バスであり、ソフトウェア間の通信問題を解決するためにパブリッシュ/サブスクライブモデルが最初に提案されました。1990 年代には、IBM、Oracle、Microsoft が立ち上げた国際的な商用ソフトウェア巨人の時代でした。彼らは独自の MQ を開発しており、その最も代表的なのが IBM MQ です。これは高価で、主に大規模な金融、電気通信、その他の企業などのハイエンド企業を対象としています。このタイプの商用 MQ は通常、ハイエンドのハードウェアを使用し、次の形式で提供されます。オールインワンのソフトウェアとハードウェアマシン、および MQ 独自のソフトウェアこのアーキテクチャはスタンドアロンアーキテクチャです。

フェーズ II、2000 ～ 2007 年。2000 年代に入ると、第 1 世代のオープンソースメッセージキューが登場し、JMS と AMQP という 2 つの主要な標準が誕生し、対応する 2 つの実装として ActiveMQ と RabbitMQ が誕生し、初期のオープンソースメッセージキューテクノロジを主導しました。オープンソースはメッセージキューの人気を大幅に高め、使用の敷居を下げ、テクノロジーを誰でもアクセスできるようにして、徐々にエンタープライズレベルのアーキテクチャの標準構成になりました。現在と比較すると、このタイプの MQ は主に従来のエンタープライズレベルのアプリケーションや小規模なトラフィックシナリオを対象としており、水平方向の拡張機能は比較的弱いです。

第 3 段階は 2007 年から 2017 年までです。PCインターネットとモバイルインターネットが爆発的に発展しています。従来のメッセージキューでは数億ユーザーのアクセストラフィックと大量のデータの送信に耐えられないため、分散アーキテクチャを完全に採用し、強力な水平拡張機能を備えたインターネットメッセージミドルウェアが誕生しました。 Kafka と RocketMQ が含まれます。また、クローズドソースとして Taobao Notify もあります。また、Kafka の誕生により、メッセージングミドルウェアはメッセージング分野からストリーミング分野に拡張され、分散アプリケーションの非同期デカップリングシナリオからビッグデータ分野のストリームストレージおよびストリームコンピューティングのシナリオまで拡張されました。

第4期、2014年～現在。クラウドコンピューティング、IoT、ビッグデータが新たな波をもたらします。

Apache RocketMQ 開発の歴史

メッセージキュー業界の発展に伴い、Apache RocketMQ 自体も 10 年間にわたって発展しており、「インターネットで誕生」と「クラウドコンピューティングで成長」の 2 つの段階に分けることができます。

最初の段階は、RocketMQ の 0 から 1 への開発と、Alibaba 内での大規模な実装です。2012 年に超大規模電子商取引インターネットアーキテクチャをサポートするために、Alibaba ミドルウェアが RocketMQ を開発し、製品誕生の初期段階でオープンソース化し、2017 年に RocketMQ が Alibaba のメッセージングテクノロジシステムを統合しました。

第 2 段階はクラウドコンピューティングです。RocketMQ は 2016 年にクラウドに移行しました。これは、パブリッククラウド SaaS 形式を提供する業界初のオープンソースメッセージキューでもあります。2016 年に Alibaba は RocketMQ を Apache に寄贈し、2017 年に開発されて卒業し、中国初の TLP インターネットミドルウェアとなりました。RocketMQ は、クラウドコンピューティングとオープンソースの両輪によって推進され、Alibaba の外でも本格的なスケールを実現し、数千の業界のデジタル変革の完了を支援し、その製品機能もさらに飛躍しました。5.0 は 2022 年に正式にリリースされ、Apache RocketMQ は正式にクラウドネイティブ時代に突入します。

Apache RocketMQ 5.x ユニファイドメッセージングエンジン

Apache RocketMQ 5.X ビジネスパノラマ

クラウド時代の多様なユーザーニーズに応えるために、RocketMQ 5.0 は、元のインターネットビジネスメッセージミドルウェアから「メッセージ、イベント、ストリーム」のハイパーコンバージド処理プラットフォームに拡張し、より包括的な機能を解放しました。

メッセージング分野では、クラウドネイティブテクノロジー、より優れた弾力性のあるアーキテクチャ、高可用性機能を全面的に採用しています。

イベント分野では、CloudEvent 仕様と新しいイベント中心の製品インターフェイスをサポートし、顧客がビジネス間および組織間を越えたデジタルビジネスエコシステムを構築できるようにします。

ストリーミング分野では、ストリーミングストレージによりバッチ機能が強化され、データスループットが大幅に向上します。論理キュー機能が追加され、論理リソースと物理リソースが分離され、ストリーミングシナリオでのシームレスなスケーラビリティが実現します。新しいストリーミングデータベース RSQLDB を追加して、リアルタイムイベントを提供します。ストリーム処理ストリーム分析機能。

RocketMQ は、統合されたデバイスクラウドアーキテクチャに基づいて、元の接続アプリケーションから IoT デバイスの接続に至るまで、完全な IoT メッセージキュー機能を実装します。同時に、RocketMQ 5.0 は、最小限のリソース消費と運用保守コストでサービスを構築でき、エッジコンピューティングに適したミニマリストアーキテクチャの原則も維持し続けます。

メッセージとフローの統合

Apache RocketMQ がユニファイドメッセージングエンジンであるのはなぜですか? Apache RocketMQ は主に次の点で統合されています。

最初の統合は、Apache RocketMQ がメッセージとストリームを統合するシナリオです。この比較表から、メッセージとフローの違いがわかります。一般的に言及されるメッセージシナリオとキューシナリオは、ビジネス統合に焦点を当てています。このシナリオでは、RocketMQ の主な役割は、ビジネスアプリケーションを接続し、トランザクションシステムの分離など、ビジネスアーキテクチャの上流と下流のシステムを分離することです。このタイプのシナリオは主にオンラインビジネスであり、ユーザーが購入などの特定のビジネスプロセスをトリガーします。

ユーザーエクスペリエンスを確保するために、メッセージングシステムは低遅延を優先する必要があります。このシナリオでは、同期通信 RPC に対応し、メッセージングシステムが非同期通信を担当します。メッセージ消費レベルでは、メッセージデータに基づいて対応するビジネスロジックを実行し、次のビジネスプロセスをトリガーすることが重要です。各メッセージは独立してステートレスに処理されます。ビジネスのデジタルシナリオに焦点を当てたデータベース OLTP と比較することができ、1 回の操作でのデータ量が少なく、オンライントランザクションに使用されます。

ストリーミングシナリオを見ると、主にデータ統合、さまざまなデータコンポーネントの接続、データ分散、データアーキテクチャの上流システムと下流システムの分離に重点が置かれています。たとえば、ログソリューションはログデータを収集し、ETL を実行してログデータを検索エンジン、ストリームコンピューティング、データウェアハウスなどに配信します。ログに加えて、データベースの Binlog 配布とページのクリックストリームも一般的なデータソースです。このシナリオでは、オフラインビジネスであるため、低遅延に対する要求は弱く、大量のスループット負荷に重点を置いています。さらに、メッセージ消費段階では、もはや単一のメッセージ処理の問題ではなく、バッチダンプまたはバッチフロー計算の問題になります。デジタルビジネスシナリオに焦点を当て、データベースにおける OLAP に相当し、1 回の操作でのデータ量が多く、オフライン分析シナリオで使用されます。

具体的には、RocketMQ はどのようにしてメッセージとストリームの統合を実現するのでしょうか?

これは主に、プロデューサー、コンシューマー、トピック、トピック論理パーティション MessageQueue を含むドメインモデルの統合に反映されます。メッセージとフローのさまざまなシナリオに対応するために、統合ドメインモデルの下でさまざまなアクセスモードが使用されます。

メッセージシナリオでは、クライアントはトピックのみを認識し、トピックにメッセージを送信し、サブスクリプション関係に基づいてトピックメッセージを消費し、対応するビジネスロジックをトリガーし、消費の成功または失敗を返します。消費が失敗した場合は、再試行されます。

ストリーミングシナリオでは、メッセージデータのアクセスモードが異なります。データ統合シナリオで使用されるため、大規模なデータ統合には必然的にデータシャーディングが必要となり、上流と下流のデータシステムはデータシャーディングに基づいて接続されます。メッセージの読み取りと書き込みの方法では、読み取りと書き込みのトピックを指定するのではなく、トピックのシャード、つまり読み取りと書き込み操作のキューを指定します。ストリームストレージシステムとして、ダウンストリームコンシューマは通常、ステートフルコンピューティング用のストリームコンピューティングエンジンです。ストリームコンピューティングエンジンのフォールトトレラントな処理をサポートするには、チェックポイントメカニズムをサポートする必要があります。これは、ストリームコンピューティングエンジンに redolog を提供するのと同様で、キューの位置に従ってメッセージを再生し、メッセージの状態を復元できます。ストリームコンピューティング。また、シャード内での順序付けも必要であり、同じキーを持つデータは同じシャードにハッシュされ、keyby 操作の実装に使用されます。

これは、ストリームストレージアクセスモードとメッセージアクセスモードの違いです。メッセージングシナリオでは、ユーザーはトピックリソースに注意を払うだけでよく、キューや場所などの概念を理解する必要はありません。

ストリーミングシナリオでは、データ型の変更という非常に重要な変更がもう 1 つあります。簡単に比較すると、業務統合シナリオでは、メッセージデータは受注業務や物流業務などのビジネスイベントを伝達するものであり、データ規模は小さいものの、特に各データの価値が高いのが特徴です。単一トランザクションに対して、オンライン、短くて高速なアクセスモードを優先します。

ストリーミングシナリオでは、より非トランザクションデータになります。たとえば、ユーザーログ、システムモニタリング、一部の IoT センサーデータ、Web サイトのクリックストリームなどです。データ規模は桁違いに増大しているが、1個のデータの価値が相対的に低く、アクセス形態がオフライン一括送信に偏っているのが特徴である。したがって、ストリーミングシナリオでは、RocketMQ ストレージを高スループットのためにさらに最適化する必要があります。

RocketMQ 5.0 では、エンドツーエンドのバッチメッセージが導入されています。クライアントから開始される送信フェーズでは、メッセージがクライアント上で特定の数にバッチ処理され、1 つの RPC リクエストでブローカーに直接送信されます。ブローカーのストレージ段階では、メッセージのバッチ全体が直接保存され、バッチインデックス作成テクノロジを使用すると、メッセージのバッチに対して 1 つのインデックスのみが構築されるため、インデックスの構築速度が大幅に向上します。消費段階では、データのバッチ全体も消費者側に読み取られ、最初に解凍操作が実行され、最後に消費ロジックが実行されます。このようにして、ブローカーのメッセージ全体の TPS を元の 100,000 レベルから 100 万レベルに増やすことができます。

端末とクラウドの一元化

2つ目の統合は、エンドとクラウドの統合で、エンドはIoTデバイスやモバイル端末を指し、クラウドはクラウドサービスやアプリケーションを指します。まず、モノのインターネットのシナリオとは何なのか、そしてモノのインターネットにおいてメッセージがどのような役割を果たすのかを理解しましょう。モノのインターネットは間違いなく近年最も注目されている技術トレンドの 1 つであり、多くの研究機関や業界レポートがモノのインターネットの急速な発展を提案しています。

IoT デバイスの規模は爆発的に増加し、2025 年には 200 億台以上に達すると予想されています。
モノのインターネットのデータ規模、モノのインターネットからのデータの増加率は 28% 近くに達しており、将来的にはリアルタイムデータの 90% 以上がモノのインターネットシナリオからのものになるでしょう。これは、将来的にリアルタイムストリームデータ処理のデータ型に大量の IoT データが存在することを意味します。
重要なトレンドはエッジコンピューティングです。将来的には、データの 75% が従来のデータセンターやクラウド環境の外で処理されるようになります。ここでのエッジとは、データソースに近い店舗、工場、電車などの場所を指します。。

この図から、モノのインターネットのシナリオにおけるメッセージの役割がわかります。

1 つ目の役割は接続であり、通信を担当し、センサーデータのレポート、クラウドコマンドの発行など、デバイス間の通信、およびデバイスとクラウドアプリケーション間の通信をサポートし、IoT アプリケーションアーキテクチャをサポートし、クラウドとエッジデバイスを接続します。

2 番目の機能はデータ処理です。IoTデバイスは継続的にデータストリームを生成します。機器のメンテナンスや高温警告など、リアルタイムのストリーム処理が必要なシナリオが多数あります。MQ のイベントストリームストレージとストリームコンピューティング機能に基づいて、モノのインターネットシナリオのデータアーキテクチャを構築できます。

完全な IoT ソリューションでは、エンドとクラウドの両方の連携が必要になります。エンドはデータの収集とデバイス命令の実行に使用され、クラウドはデータの保存、データの分析、複雑なビジネスロジックの実行に使用されます。したがって、デバイスとクラウドの統合を実現するために、MQTT サブ製品が RocketMQ 5.0 でリリースされました。3 つの主要な機能があります。

IoTの標準プロトコルであるMQTTを採用しており、IoTの脆弱なネットワーク環境や低い計算能力を考慮して設計された、非常に合理的なプロトコルです。同時に、複数のサブスクリプションモードと複数のメッセージ QoS (最大 1 回、少なくとも 1 回、1 回のみ、1 回のみなど) をサポートする多くの機能を備えています。そのドメインモデル設計には、メッセージ、トピック、パブリッシュとサブスクライブなどの概念も含まれており、特に RocketMQ と一致し、クラウド統合 RocketMQ 製品フォームを構築するための基盤を築きます。
デバイスとクラウドの統合アーキテクチャを採用しており、ドメインモデルが近く、RocketMQ がストレージ層として使用されているため、各メッセージのコピーが 1 つだけ保存され、このメッセージは IoT デバイスとクラウドアプリケーションの両方で使用できます。さらに、RocketMQ 自体は自然なストリームストレージであり、ストリームコンピューティングエンジンは IoT データのリアルタイム分析をシームレスに実行できます。メッセージはさまざまなアクセスシナリオ (サーバー側の RocketMQ、デバイス側の MQTT など) から送信されますが、コピーが 1 つだけ書き込まれてコミットログに保存され、その後、複数の需要シナリオのキューインデックスが配布されます。、サーバーシナリオ (RocketMQ) はレベルに従うことができます。トピックキューは従来のサーバー側の消費に使用され、デバイス側のシナリオは MQTT マルチレベルトピックおよびワイルドカードサブスクリプションに従ってメッセージを消費できます。このようにして、同じストレージエンジンに基づいて、IoT シナリオでのサーバーアプリケーションの統合とメッセージの送受信をサポートし、エンドクラウドの統合を実現できます。
オリジナルの RocketMQ の 10,000 レベルのキュー機能を 100 万レベルのキュー機能に改善しました。たとえば、Kafka のようなメッセージキューでは、各トピックは独立したファイルですが、トピックの数が増えるとメッセージファイルの数も増加し、シーケンシャルな書き込みがランダムな書き込みに変質し、パフォーマンスが大幅に低下します。RocketMQ は Kafka に基づいて改良されています。Commitlog ファイルを使用してすべてのメッセージコンテンツを保存し、CQ インデックスファイルを使用して各トピック内のメッセージキューを表します。CQ インデックスデータは比較的小さいため、ファイルの増加はIO への影響は大きくなりますが、はるかに小さいため、キューの数は 100,000 に達する可能性があります。ただし、この端末デバイスのキューシナリオでは、100,000 レベルのキューの数はまだ少なすぎます。さらに数を一桁増やして、100 万レベルのキューの数に達することを期待しています。 CQインデックス配信を行い、100万レベルを達成するために導入されたエンジンです。

メッセージとイベントの統合

メッセージとイベントの統一である 3 番目の統一があります。

その前に、まずイベント駆動とは何かを理解しましょう。イベント駆動型は本質的に、異なるモジュールと異なるシステム間の結合を最小限に抑えることができるソフトウェア設計パターンです。

以下は、一般的なイベント駆動型のアーキテクチャ図です。まず、イベントプロデューサーがイベントを EventBroker に送信し、次に EventBroker がイベントをイベント処理のために対応するコンシューマーにルーティングします。イベント処理は柔軟に拡張でき、イベントコンシューマはいつでも追加または削除でき、イベントプロデューサーはこれについて透過的です。

さまざまなイベント駆動テクノロジーが数十年前に登場したため、イベント駆動アーキテクチャは実際には非常に古典的な設計パターンです。たとえば、デスクトップクライアントプログラミングフレームワークでは、ボタンをクリックすると onclick イベントをトリガーでき、開発者はイベントに応答するビジネスロジックを作成します。プログラミング言語では、コールバックや関数などのイベント駆動型のコードパターンが採用されることがよくあります。ハンドラー; 分散への参入システムの時代には、システム間の通信とコラボレーションにもイベント駆動型のアプローチが採用されるでしょう。

この図から、イベントドリブンアーキテクチャは実際にはメッセージベースのアプリケーションデカップリングとそれほど変わらないことがわかり、本質的にデカップリングの問題を解決します。メッセージのパブリッシュとサブスクリプションであっても、イベントの生成と消費であっても、それはすべてコードの分離とシステムの分離のためです。メッセージキューは技術的な実装であり、ほとんどの EventBroker はメッセージキューに基づいて実装されていますが、イベントドリブンはアーキテクチャ上の概念です。

イベントドリブンとメッセージドリブンの最大の違いは、イベントは特別な種類のメッセージであり、特定の特性を満たすメッセージのみをイベントと呼ぶことができるということです。

たとえば、上の図を考えてみましょう。メッセージは、多くのサブクラスを持つ抽象クラスのようなもので、最も重要なものはコマンドとイベントです。信号機を例にとると、信号機にオープンメッセージを送信することは一種のコマンドであり、信号機はこのコマンドを受け付けて信号機を点灯させます。信号灯が点灯した後、信号灯が青に変わったというメッセージを送信するのは一種のイベントです。

イベントには、次の 4 つの主な特徴があります。

それは、すでに起こって事実になったことを表す不変の出来事です。
イベントには時間の概念があり、同じエンティティに対してイベントの送信は連続的に行われます。たとえば、信号灯は緑、黄、赤などのイベントを順番に送信します。
イベントは予測不可能です。これが、EDA アーキテクチャが最大限の分離を達成できる理由です。イベントジェネレーターは、誰がイベントコンシューマであるか、またはイベントをどのように消費するかを気にしません。
イベントドライバーは完全に分離されており、下流のコンシューマーがイベントをどのように利用するかは予想できないため、イベントは具体的であり、下流のコンシューマーが必要なものを取得できるように、できるだけ詳細な情報を含める必要があります。これがメッセージとイベントの違いです。

サーバーレス化

サーバーレスのトレンド

サーバーレスは、次世代のクラウドネイティブの代表的なテクノロジーであると考えられています。クラウドネイティブの本質は、一連の技術システムと方法論を通じて顧客がクラウドをより良く利用できるように支援し、クラウドコンピューティングの恩恵を完全に解放し、顧客が次のことを実現できるようにすることです。クラウドコンピューティングを使用して、より効率的で低コストのデジタルトランスフォーメーションを実現します。クラウドネイティブテクノロジーに関しては、マイクロサービスやコンテナ化などについてよく耳にします。マイクロサービスは、アプリケーションアーキテクチャの概念の革新に焦点を当てており、マイクロサービスを使用して高いビジネスの凝集性と低結合を実現し、それによって研究開発の効率、コラボレーションの効率、ビジネスの機敏性を向上させます。一方、コンテナ化はアプリケーションの運用と保守のレベルに関係し、コンテナ化は相違点を保護するために使用されます。 K8s プラットフォームの助けを借りて、アプリケーションの運用保守効率とリソース使用率も改善できます。

クラウドネイティブにおけるサーバーレスの意味は、基本的なテクノロジーが沈下し、クラウドサービスインターフェイスが上昇する傾向にあるため、基本的に顧客は基盤となるテクノロジーや物理リソースを気にせずにビジネスの研究開発に集中できるようになるということです。

下の図に示すように、クラウドコンピューティングが登場する前、ユーザーはビジネスの研究開発を行う前に、独自の IDC を構築し、物理マシンを購入し、仮想化し、ミドルウェアを構築する必要があり、多くの時間、エネルギー、リソースが費やされます。ビジネスとは何の関係もないプロジェクト。クラウド参入後はクラウドベンダーがインフラを提供することが多くなり、初期のIaaSではクラウドベンダーのコンピューティング、ストレージ、ネットワークリソースを直接利用し、PaaSでは自社でデータベースやミドルウェアを構築する必要がなくなりました基本的なソフトウェアサービス: クラウドコンピューティングがサーバーレス段階に進化した現在、顧客はビジネスコードの開発にエネルギーの大部分を完全に集中させています。

クラウドサービスベンダーにとって、サーバーレスクラウド製品も、オブジェクトストレージ、ファンクションコンピューティングなどの初期のいくつかの製品から、サーバーレスメッセージキュー、マイクロサービス、データベース、検索、ビッグデータ製品など

包括的なサーバーレスアプリケーションシナリオ

サーバーレス時代に入り、サーバーレスをフルに活用する顧客はメッセージキューにどのようなシナリオの変化をもたらすでしょうか?

たとえば、アプリケーション側では、ますます多くのアプリケーションが自己購入した ECS にデプロイされるのではなく、サーバーレスコンテナー、アプリケーションエンジン、およびファンクションコンピューティング上で直接ホストされ、クラウドサービスはビジネストラフィックやビジネストラフィックに基づいて柔軟なスケーリングを自動的に実行します。対応するメッセージングサービスも、メッセージトラフィックに応じて柔軟に拡張できなければなりません。
車両のインターネットメッセージングソリューションのシナリオでは、自動車には毎日朝と夕方のピークがあり、上流と下流のメッセージトラフィックにも明らかなピークと谷があります。車両のインターネットの顧客は、ピークに備えてメッセージングリソースを事前購入する必要はありません。トラフィックは発生しますが、実際のメッセージ量に応じて支払います。
モバイルアプリのプッシュシナリオでは、多数の接続を維持する必要性、時折ピークに達するメッセージプッシュ、極度に小さいメッセージストレージスペースなど、リソース指標のより多くの側面にも直面することになります。、ストレージ、およびネットワークバインディングメッセージの代わりに、接続数、メッセージトラフィック、ストレージ容量に対して個別に支払います。
コアの弾力性機能に加えて、メッセージキューのコアアーキテクチャシナリオ「イベントドリブン」が、サーバーレス時代の最も重要なアーキテクチャパターンになりました。イベントドリブンアーキテクチャは、より機敏でスケーラブルで回復力のあるサーバーレスアプリケーションの開発に役立ちます。サーバーレス R&D パラダイム。したがって、サーバーレスオールクラウド開発モデルでは、顧客はメッセージキューのサービスインターフェイスを上位に移動し、「イベントバス」の機能を持たせる必要があることを望んでいます。お客様は、すぐに使用できるサーバーレスクラウドサービスだけでなく、すぐに使用できるイベント駆動型の統合サービスも必要としており、これまでのように統合されたグルーコードを記述する必要がなくなり、研究開発の効率がさらに向上します。ローコードとノーコードへの移行。たとえば、クラウド製品イベント統合では、OSS ファイルアップロードイベントがイベントバスに送信され、ユーザーはこのイベントをサブスクライブし、関数コンピューティングに基づいてファイル処理と応答イベントを実行して、サーバーレスコンピューティング能力を推進します。

サーバーレスのトレンドに直面して、RocketMQ 5.0 は製品形式から技術アーキテクチャに至るまで大幅な進化を遂げました。

サーバーレスアプリケーション用の新しい SDK

アプリケーションがサーバーレステクノロジを広範囲に使用すると、トラフィックの変化に応じてアプリケーションのインスタンスの数が動的かつ弾力的に拡張されます。過去のシナリオと比較して、インスタンスの数は非常に頻繁に変化するため、メッセージの負荷分散がより大きな課題になります。送受信です。

まず、実動リンクの負荷分散を見てみましょう。プロデューサは、サービス検出メカニズムを通じて、トピックのデータ断片化と対応するブローカーアドレスを知っています。そのサービス検出メカニズムは比較的シンプルで、デフォルトでは RoundRobin を使用してポーリングし、各トピックキューに送信し、Broker クラスタのトラフィックバランスを確保します。プロデューサは完全にステートレスであるため、どれほど柔軟なスケーリングであっても大きな影響はありません。

コンシューマの負荷分散を見てみましょう。比較的言えば、それはプロデューサーよりも複雑です。古いモデルはキューレベルの負荷分散です。コンシューマはトピック内のキューの合計数と、同じ ConsumerGroup の下にあるインスタンスの数を知っています。分散アルゴリズムは一貫したハッシュ方式に似ており、各コンシューマインスタンスが対応するキューをバインドし、そのキューにバインドされたメッセージのみを消費することができます。各キュー内のメッセージは 1 つのコンシューマインスタンスによってのみ消費されます。このモデルの最大の欠点は負荷の不均衡であり、コンシューマインスタンスはキューにバインドされ、一時的なステータスを持つ必要があります。アプリケーションインスタンスの数が頻繁に変化すると、この負荷の不均衡によりアプリケーションのサーバーレス拡張が非効率になり、拡張の新しい段階でメッセージトラフィックを共有できなくなります。図に示すように、トピックには 2 つのパーティションがあります。3 番目のノードを拡張すると、空の実行が発生します。トピックが 3 つのパーティションに拡張され、その後、コンシューマインスタンスが 2 にスケールバックされると、コンシューマインスタンスの 1 つが 3 つのポイントを持ちます。 2 番目に、トラフィックが過負荷になっています。

したがって、RocketMQ5.0 では、メッセージ粒度の負荷分散メカニズムが導入され、キューをバインドする必要がなく、メッセージがコンシューマクラスタ内でランダムに分散されるため、コンシューマクラスタの負荷分散が確保されます。さらに重要なことは、このモデルはフルリンクサーバーレスシナリオにより一致しており、ブローカーマシンの数、トピックキューの数、およびコンシューマインスタンスの数は完全に分離されており、個別に拡張および削減できることです。

サーバーレスのイベント駆動型の課題

前の章では、メッセージとイベントの統合について説明しましたが、イベントとはビジネスセマンティクスを含むメッセージです。典型的なイベント駆動のケースを見てみましょう。

下図はメッセージキュー RocketMQ をベースに実装された取引システムで、イベント駆動型アーキテクチャを採用しており、「注文」イベントを中心に取引業務を完結させます。イベントプロデューサーはトランザクションセンターであり、コンシューマーはトランザクションの下流システムです。たとえば、注文作成イベントが送信されると、ショッピングカートがイベントに応答し、以前の追加購入が削除されます。注文支払いイベントが発生すると、会員システムがイベントに応答して顧客にポイントを追加し、物流システムはイベントに応答し、その後の配送とフルフィルメントのリンクを実行します。取引システム全体は「イベント駆動型」マイクロサービスから構築されています。

従来のメッセージキューに基づくイベント駆動型のソリューションは、組織や部門内での適切な選択です。しかし、サーバーレス時代には多くの新たな課題に直面しています。

SaaS プラットフォーム (DingTalk) とそのパートナーなど、複数の異なる組織の連携によってビジネスデジタルソリューションが完成するケースが増えています。DingTalk プラットフォームでは、ビデオ会議、スケジュール、アドレス帳、承認などのさまざまなイベントが公開されます。ストリーミングとピン留めは、下流パートナーによってこれらのイベントを消費し、業界アプリケーションを開発するために使用されます。この種の新しいデジタルソリューションでは、イベントのプロデューサーとコンシューマーが別の企業に属していることが多く、開発者は集中的なコミュニケーションを行うことができず、低コストで「イベント」の定義、形式、使用法を理解することができません。現在のモデルは、開発者間のコミュニケーションと会社の内部ドキュメントに過度に依存しています。
企業が異なれば、異なるメッセージキューを使用する、イベントプロデューサーが RocketMQ を使用する、イベントコンシューマーが RabbitMQ を使用するなど、異なるメッセージ送信プロトコル (HTTP または AMQP など) を使用するなど、異なるテクノロジシステムが使用されることがよくあります。
イベントコンシューマは多様で、同じビジネスイベントであっても、イベントコンシューマは特定のサブタイプのみを必要とする場合や、同じイベントであっても、一部のフィールドにしかアクセスできない場合があります。
すぐに使用できるイベント統合機能の欠如: 顧客はクラウドを十分に使用した後、OSS アップロードイベントへの応答や、ファイル処理のための関数コンピューティングの使用など、さまざまなクラウド製品イベントに応答する必要があります。この機能は、従来のメッセージキューにはありません。

サーバーレスのイベント駆動型テクノロジーでは、「イベント」自体のみに焦点を当て、伝送プロトコル、SDK、生産モデルと消費モデルなどのテクノロジー実装の詳細を分離する、より徹底的な分離が必要です。

サーバーレスのイベント駆動型設計

メッセージキューに基づいたサーバーレスイベントドリブンを実現するために、「イベントドリブン」シナリオのサービスインターフェイスが上位に移動され、「イベント」ドメインモデルを中心に再設計されます。

一番左はイベントソースです。イベントにはプラットフォーム間で生成および消費できる機能が必要であるため、CNCF の CloudEvents がイベントフォーマットとして使用されます。これは業界のイベントの事実上の標準であり、この標準によってイベントの宣言が簡素化され、サービスやプラットフォーム間でのイベントの相互運用性が向上します。

イベントは組織全体で使用される可能性があるため、これらのさまざまなイベントソースをこのイベントセンターに登録できるようにするには、統合されたイベントセンターが必要です。消費者にとって、これはイベントストアのようなもので、興味のあるイベントを選択して購読することができます。

イベントコンシューマが消費ロジックを書き始めるとき、開発者もイベントの形式をより明確に理解する必要があり、イベントのコンテンツが何であるか、そこにどのようなフィールドがあるか、そしてそれらの意味が何であるかを知る必要があります。正しい消費ビジネスロジックです。そのため、イベントバスにはスキーマセンターも提供されており、このスキーマセンターにより、コンシューマーはイベントソースのイニシエーターと通信することなく、イベントの形式を一目で理解することができ、全体の効率が大幅に向上しました。

さらに遡って、イベント消費段階に至ります。イベントコンシューマには多くの種類があり、異なるコンシューマが異なるイベントタイプに注目するため、イベントバスは豊富なフィルタリングルールを提供する必要があります。複数のコンシューマが同じイベントに興味がある場合でも、必要なのはイベントの一部だけである可能性があり、イベントバスはイベントを変換する機能も提供します。これは RocketMQ5.0 のイベント駆動型機能の抽象化です。

サーバーレスイベントドリブンの新しい形式

上記の新しい設計に基づいて、RocketMQ をイベントストレージのコアとして使用して、新しいイベントバス EventBridge が実装されます。

製品インターフェイスでは、イベント駆動型ビジネス向けに抽象化レイヤーが実装され、コアドメインオブジェクトがメッセージから CloudEvents に変わります。統一されたイベント標準に基づいて、イベント駆動型のデジタルエコシステムを構築します。

イベントソースは多様で、クラウド製品イベント、データフローイベント、SaaS プラットフォームイベント、アプリケーションカスタムイベント、または一般的な WebHook などがあります。もちろん、そのイベントターゲットも多様です。イベントは、イベントルールエンジンを通じてさまざまなコンシューマにルーティングされます。典型的なコンシューマには、関数コンピューティングおよびメッセージシステム (さまざまなメッセージキューテクノロジを使用してプロデューサとコンシューマを分離するために使用されます)、ストレージシステム、ストリームコンピューティングが含まれますエンジン、一般的な Webhook、さらには音声、SMS、メールなどのメッセージ通知まで。イベント駆動型アーキテクチャは、ハイブリッドクラウドおよびマルチクラウドデジタルシステムの構築に適しています。

EventBridge を通じて、徹底したイベント駆動型のアーキテクチャが実現され、真に「イベント」自体のみを考慮し、プロデューサーとコンシューマーは、組織的なデカップリングと技術的なシステムのデカップリングを含む、より完全なデカップリングを実現します。

サーバーレスメッセージングカーネルの再構築

前述のものは主に、一部のサーバーレスアプリケーション、サーバーレスイベント駆動型アーキテクチャ、RocketMQ の製品形式とユーザーインターフェイスの変更など、サーバーレスアプリケーションシナリオを対象としています。次に、技術アーキテクチャの進化の観点から、RocketMQ がサーバーレスメッセージングクラウドサービスをどのように実装するかを見てみましょう。サーバーレスシナリオでは、顧客が必要とするのは宣言型の論理リソースであり、さまざまな論理リソースをバンドルせずに、ボリュームごとに弾力的に提供できます。

サーバーレスシナリオの場合、RocketMQ は 3 層のストレージとコンピューティングの分離アーキテクチャに進化しました。

最初の層は RocketMQ プロキシで、主にマルチプロトコルとマルチドメインのシナリオをカバーします。ここでのドメインシナリオには、従来のサーバー側アプリケーション統合である RocketMQ シナリオ、IoT 指向アプリケーションである MQTT、イベント駆動型アプリケーションである EventBridge が含まれます。プロキシは、コンピューティングリソースの主要なキャリアと考えることができ、完全にステートレスなゲートウェイです。接続数、メッセージ TPS、メッセージの読み取りと書き込みの比率が異なる顧客に対して、コンピューティングリソースとネットワークリソースに独立した柔軟性を提供できます。このようにして、サーバーレスシナリオで複数のリソースを柔軟に分離するというお客様のニーズに応えることができます。
2 番目の層は RocketMQ のストレージエンジンで、主にメッセージの複数のコピーの実装と、複数のコピー間で高可用性スイッチングを実行する方法に焦点を当てています。同時に、ローカルストレージとクラウドストレージの統合された抽象化も担当します。メッセージは主にクラウドディスクとオブジェクトストレージに保存され、メッセージデータのほとんどはオブジェクトストレージに保存されるため、ストア自体の状態が弱くなり、弾力性効率も向上します。RocketMQ ストアは、メッセージスループット、TPS、メッセージサイズ、バッチ係数などの顧客のメッセージトラフィック特性に基づいてストレージリソースの IOPS、帯域幅、ストレージスペースを柔軟に一致させ、メッセージストレージとコンピューティングの分離を実現します。
3 番目の層はクラウドストレージ層で、ほとんどのメッセージはオブジェクトストレージ (パブリッククラウドインフラストラクチャレベルのストレージプーリング) に保存されます。コールドデータをオブジェクトストレージにオフロードすることで、RocketMQ ストアのライフサイクルが短縮され、低コストで無制限のメッセージストレージスペースも確保されます。

RocketMQ5.0 は柔軟なアーキテクチャを備えており、クラウドサービスの形式の RocketMQ はクラウドインフラストラクチャとさらに統合して、クラウドコンピューティングの恩恵を最大限に引き出すことができます。

コンピューティングレベルでは、RocketMQ 5.0 はコンテナサービスを通じて ECS の弾力性機能を最大限に活用し、エラスティックリソースプール + HPA 関連テクノロジーを採用してコンピューティング機能の迅速な弾力性をサポートすると同時に、ACK 独自のクロスアベイラビリティゾーン展開機能により十分な機能を提供します。クラウド製品の高可用性保証。

ネットワークレベルでは、RocketMQ 5.0 は、多様なネットワークに対するユーザーのニーズを満たすために、さまざまなクラウドネイティブネットワーク機能にアクセスできます。パブリックネットワークはいつでもオープンして使用でき、さまざまなプライベートネットワーク形式をサポートし、グローバルなネットワークを構築します。 CEN に基づく相互運用可能なメッセージングネットワークにより、さまざまな場所でのより多くの生活が実現します。

ストレージに関しては、Pangu DFS とオブジェクトストレージに基づくマルチレベルストレージアーキテクチャにより、低コストで無制限のストレージ機能が提供され、ホットデータリンクとコールドデータリンクが分離され、より高い SLA が提供されます。

イベント駆動型のサーバーレス技術スタックを強化

最後に、Apache RocketMQ に基づくメッセージング製品システムはイベント駆動型であり、2 つの主要なシナリオを統合して、包括的なサーバーレステクノロジースタックを強化します。

上記は典型的なサーバーレス製品システムです。一部の大手クラウドベンダーは、コア製品の包括的なサーバーレス化を実現しています。コンピューティング、ストレージ、ビッグデータ分析など、すべてのベンダーがサーバーレスサービス機能を備えています。これらの機能に基づいて、顧客はエンドサービスを構築できます。ツーエンドのサーバーレスアプリケーションはコアビジネスに焦点を当て、コスト削減と効率向上を最大限に高めます。

講演者:

Lin Qingshan (愛称: Longji) 氏、Apache RocketMQ の共同創設者、Alibaba Cloud の上級技術専門家、Alibaba Cloud メッセージング製品ラインの責任者。メッセージング分野の国際的な専門家である彼は、メッセージング、リアルタイムコンピューティング、イベント駆動型およびその他の方向の研究と探求に熱心に取り組んでおり、RocketMQ クラウドネイティブアーキテクチャとハイパーコンバージドアーキテクチャの進化を推進しています。

元のリンク

この記事は Alibaba Cloud のオリジナルコンテンツであり、許可なく複製することはできません。