RocketMQ 5.0: ストレージとコンピューティングの分離への新しいアプローチ

著者 | 林青山

Apache RocketMQは、2012年のオープンソースリリース以来、そのシンプルなアーキテクチャ、豊富なビジネス機能、そして高い拡張性により広く採用されてきました。Alibabaグループでは、RocketMQは数千台のマシンからなるクラスターを構築し、毎日数兆件ものメッセージを処理しています。Alibaba Cloudでは、RocketMQの商用製品も、世界中の数万人のユーザーに、弾力性のあるクラウドサービスとしてエンタープライズグレードのメッセージングソリューションを提供しています。インターネット、ビッグデータ、モバイルインターネット、IoTといった分野のビジネスシナリオで広く利用されており、ビジネス開発におけるメッセージングミドルウェアとして選ばれています。メッセージングミドルウェアRocketMQは、Alibabaおよびオープンソースコミュニティにおいて10年以上前から存在していましたが、クラウドネイティブコンピューティングの急速な発展により、そのアーキテクチャを見直す必要に迫られました。

問題点とジレンマ

アリババはRocketMQの豊富な運用経験を有しています。2016年の商用化以来、RocketMQはグループのメッセージングミドルウェアと同じアーキテクチャを一貫して採用し、クラウド顧客にフルマネージドメッセージングサービスを提供してきました。現在、RocketMQメッセージキューはクラウドにおいて大きなビジネス規模を達成しています。しかし、ビジネスの成長に伴い、このミニマリスト的な分散アーキテクチャは、運用コストの増加や効率性の低下など、クラウドネイティブ環境におけるいくつかの欠点を徐々に明らかにしてきました。

当グループのメッセージングミドルウェアは、ストレージとコンピューティングを統合したデプロイメントアーキテクチャを通じて、グループのeコマース事業に高性能、低レイテンシ、低コストのメッセージングサービスを提供しています。クラウドの進化に伴い、クラウドはより弾力的になり、ネットワーク環境はより複雑になり、クラウドネイティブ時代はより高い効率性を求めています。これは、クラウドベースのメッセージングアーキテクチャをクラウドネイティブ形式に変革する機会を生み出しています。上図は、クラウドにデプロイされたRocketMQの簡略化されたアーキテクチャ（コアコンポーネントのみを含む）を示しています。このデプロイメントアーキテクチャが近年クラウドで直面した主な問題点は次のとおりです。

1. リッチクライアント形式

RocketMQユーザーは、クラウドサービスにアクセスするために公式SDKを使用する必要があります。これは比較的重量級のリッチクライアントであり、シーケンシャルコンシューム、ブロードキャストコンシューム、コンシューマーロードバランシング、メッセージキャッシュ、メッセージリトライ、ポジション管理、プッシュプル統合、フロー制御、診断、フェイルオーバー、異常ノード分離など、エンタープライズレベルの幅広い機能を提供します。RocketMQのリッチクライアントは、グループ内の顧客の統合コストを大幅に削減し、高い耐障害性と高性能を備えたメッセージ駆動型アプリケーションを構築するためのワンストップソリューションを提供します。ただし、クラウドベースのリッチクライアントにはいくつかの欠点があります。

リッチクライアントはクラウドネイティブなテクノロジースタックと互換性がありません。例えば、サービスメッシュとの統合が難しく、Daprのような新興のクラウドネイティブアプリケーションフレームワークとも互換性がありません。また、物理リソースを大量に消費し、サーバーレスの弾力性にもあまり適していません。
多言語クライアントの調整は困難です。クラウドでは多言語サポートの需要が非常に高いものの、リッチクライアントのロジックは複雑で、多言語クライアントの品質を確保するための人材が不足しています。そのため、GraalVMとHTTPプロトコルをベースとした多言語SDKがクラウド上で登場していますが、いずれも限界があります。
クライアントは完全にステートレスではなく、メモリ内に状態を保持しています。再起動するとリバランスがトリガーされ、消費ジッターとレイテンシが発生します。このリバランス設計はパフォーマンス要件を満たしていますが、機密性の高いサービスの場合、このジッターが過去数年間にわたり多数のサービスリクエストの大きな要因となってきました。
パーティションレベルでの消費粒度と、パーティションレベルでのクライアント負荷分散粒度により、1つのパーティションを複数のコンシューマーが同時に消費することはできません。これは、低速コンシューマーのシナリオでは大きな影響を及ぼし、スケールアップによって低速コンシューマーへの負荷を軽減することは不可能です。

2. 統合コンピューティングとストレージ

ブローカーはRocketMQの中核ノードであり、サーバー側のすべての計算とストレージロジックを担います。その主な機能は次のとおりです。

計算タスクには、認証と署名、商用計測、リソース管理、クライアント接続管理、消費者制御とガバナンス、クライアント RPC 処理、メッセージのエンコード/デコードが含まれます。
ストレージ: パーティションベースの WAL ストレージ、複数のインデックスタイプ (通常、時間指定、トランザクションなど)、コアの受信、送信、クエリ機能、マルチレプリカのレプリケーション機能など。

コンピューティングとストレージを統合したブローカーには、いくつかの利点があります。シンプルな導入構造、オープンソースユーザーはすぐに使用可能、導入ノード数が少ない、独身の日のような大規模イベントで数兆件ものメッセージを低コストでサポート、データは仲介なしにローカルで処理されるため、高パフォーマンスと低レイテンシを実現できます。しかし、統合ブローカーにはクラウド環境における制限もあります。

ビジネスイテレーション効率の低さ：デプロイメント単位はブローカーです。メータリングロジックの1行を調整したとしても、ネットワーク全体に反映させるには数千ものブローカーノードをデプロイする必要があり、ビジネスイノベーションとイテレーション速度の低下につながります。
高い安定性リスク：コンピューティングとストレージは統合されていますが、ビジネス要件の大部分はコンピューティングロジックに向けられています。ストレージノードは比較的安定しており、価値の低いリリースを頻繁に行うと、安定性リスクと運用・保守コストが発生します。コンピューティングロジックの変更に伴うリリースは、キャッシュの再構築、消費遅延、クライアントの異常検出などの問題を引き起こします。
リソース利用率が低い：BrokerはディスクI/Oとメモリを大量に消費するアプリケーションであり、コンピューティングリソースの消費量は比較的低いです。しかし、Brokerとストレージノードを統合すると、スケールアップとスケールダウンも統合されます。コンピューティングノードとストレージノードを個別にサーバーレスかつ柔軟にすることは不可能であり、Brokerクラスター全体のリソース利用率が低くなります。

複雑な制御チェーン：データと状態はブローカー上に完全に分散して保存されるため、制御ノードは各ブローカーと通信する必要があります。例えば、クエリ操作は複数のブローカーにアクセスし、結果を集約する必要があるため、制御チェーンのロジックは複雑になります。

3. クライアントとブローカーの直接接続

現在、RocketMQユーザーはクライアントを介してブローカーと直接通信することで、最短リンク、シンプルな運用・保守、低レイテンシを実現しています。しかし、この設計では、クラシックネットワーク、VPCネットワーク、パブリックネットワークを含む非常に複雑なクラウド環境に柔軟に対応できません。さらに、導入環境にはOXSゾーンとリセールゾーンが含まれており、各ブローカーノードが顧客に公開され、運用負荷が増加します。

ブローカーはクライアントに対して透過的ではありません。クライアントは各ブローカーノードを認識しており、ブローカーの操作アクションは多くの場合クライアントに明確に認識できます。
ブローカーは外部に直接サービスを提供するため、ブローカーごとにクラシックVIP、VPC VIP、さらにはパブリックIPアドレスを含むVIPの申請が必要でした。数千ものVIPがオンラインで維持されていました。ブローカーごとに複数のVIPが存在するため運用コストが高く、長年にわたりVIPの手動申請がRocketMQの自動導入の妨げとなっていました。
複数のアクセスポイントをサポートすることはできません。ブローカーはネームサーバーを通じてユーザーに1つのアクセスポイントのみを公開します。ユーザーは通常、クラシックネットワーク、VPCネットワーク、パブリックネットワークの3つのアクセスポイントのいずれか1つしか選択できません。

このような背景から、Alibaba Cloud Messaging チームはクラウド上の RocketMQ 向けに特別なクラウドネイティブアーキテクチャアップグレードを実施し、ストレージとコンピューティングを分離する新しいアーキテクチャを実装するとともに、gRPC に基づくまったく新しい多言語ソリューションを導入して、メッセージミドルウェアのクラウドネイティブ化を加速しました。

ストレージとコンピューティングの分離への新しいアプローチ

クラウドにおけるストレージとコンピューティングの分離をどのように実装するか、そしてRocketMQに適した新しい3-in-1アーキテクチャをどのように探求するかは、RocketMQのクラウドネイティブアーキテクチャのアップグレードにおける主要な考慮事項です。これには、多くの実用的な要素が関係します。

RocketMQは既にAlibabaグループ内でその優れたアーキテクチャを実証しています。クラウド要件に合わせてストレージとコンピューティングを分離する必要があるのでしょうか？その結果生じるレイテンシと追加コストは、新しいアーキテクチャがもたらす新たな価値を上回るのでしょうか？
Alibaba Cloud の多くのメッセージング製品（Message Queue RabbitMQ や Message Service MNS など）では、既にストレージとコンピューティングを分離したアーキテクチャが採用されています。新しいアーキテクチャは、これらの製品のアーキテクチャとどのように統合できるでしょうか？

最初の質問に関して言えば、実用結果からシンプルなアーキテクチャの優位性が実証されています。しかしながら、クラウドで直面する問題点は、ストレージとコンピューティングを分離する必要性を明確に示しています。したがって、ストレージとコンピューティングを分離することは二者択一ではなく、アーキテクチャの観点から両方を実現することは可能でしょうか？私たちの解決策は、ストレージとコンピューティングを分離可能かつ統合可能にすることです。

「分離」という言葉には2つの解釈があります。1つ目は、モジュールと責任を明確に分離することを意味します。コンピューティングに属するロジックはコンピューティングモジュールに統合し、ストレージに属するロジックはストレージモジュールに分散させる必要があります。2つ目は、コンピューティングとストレージは別々のデプロイメントをサポートする必要があるということです。クラウドにおけるマルチテナントシナリオで直面する様々な問題を効果的に解決するためには、コンピューティングはステートレスなデプロイメントアプローチを採用し、ストレージはステートフルなデプロイメントアプローチを採用する必要があります。
「マージ」の前提は、コード設計が最初から分離されている必要があるということです。個別にデプロイするか、マージしてデプロイするかは、完全にビジネス上の選択です。新しいアーキテクチャは、スループット重視のビジネスシナリオのニーズを満たすために、マージされたデプロイメントをサポートする必要があります。例えば、Alibaba Groupの超大規模メッセージフローシナリオや、サービス指向アーキテクチャを必要としない小規模なシングルテナントシナリオでは、マージされたデプロイメントによってRocketMQを迅速に本番環境に導入できます。

2つ目の質問についてですが、Alibaba Cloudは、異なるプロトコル標準を持つ複数の自社開発メッセージングサービスを有しています。ビジネス価値を高めるためには、単一のアーキテクチャで複数の製品形態をサポートし、RocketMQの中核となるビジネスメッセージング機能を複数の製品にシームレスに複製することが重要です。

まとめると、アーキテクチャレベルのコアコンセプトは、ストレージとコンピューティングアーキテクチャの分離を出発点とし、単一アーキテクチャのマルチプロダクト形態をさらに探求することで、メッセージサブプロダクトの重複を削減することです。最終的には、クラウドの運用・保守の柔軟性、オープンソース、グループなどのシンプルな導入と高性能のニーズを満たしながら、ストレージとコンピューティングを分離・統合できる導入形態を実現することも必要です。

1. ストレージとコンピューティングの分離アーキテクチャ

RocketMQ 5.0における最初のアーキテクチャアップグレードは、ストレージと計算処理の分離です。計算処理を担うステートレスなProxyクラスタを導入することで、従来のBrokerノードは、ストレージを中核とするステートフルなクラスタへと徐々に進化していきます。同時に、リッチクライアントがもたらす多くの問題を解決するため、多言語対応シンクライアント群が再開発されます。

上の図は、ストレージとコンピューティングの分離アーキテクチャを簡略化して表したものです。サービスメッシュの制御プレーンとデータプレーンの分離、そしてxDSの概念を借用して、このアーキテクチャを説明しています。アーキテクチャ内の各コンポーネントの役割は次のとおりです。

多言語シンクライアントは、gRPCプロトコルに基づいて再構築された多言語クライアントの集合体です。gRPCを採用する際の主な考慮事項は、その標準化、互換性、そしてクラウドネイティブ時代における多言語トランスポート層コード生成能力です。
ナビゲーションサーバーは、ロードバランサーグループ（LBグループ）を介してクライアントに公開されます。クライアントはナビゲーションサーバーを介してデータプレーンのエンドポイント情報を取得し、コンピューティングクラスタプロキシのLBグループを介してメッセージを送受信します。DNSベースのロードバランシングによるルーティングと比較して、EDSを介してプロキシのエンドポイント情報を公開することで、よりインテリジェントできめ細かなテナントおよびトラフィック制御、ロードバランシングの決定、その他の関連機能が可能になります。
RocketMQ のコアコンポーネントである NameServer は、主にストレージのブローカークラスター検出 (CDS) とストレージユニットトピックのルート検出 (RDS) を提供し、さらに操作コンソールコンポーネント、ユーザーコンソールコンポーネント、コンピューティングクラスタープロキシに xDS サービスも提供します。
新しく開発されたステートレスコンピューティングクラスターである Proxy は、データトラフィックのエントリポイントとして機能し、認証と署名、商用メータリング、リソース管理、クライアント接続管理、コンシューマー制御とガバナンス、クライアント RPC 処理、メッセージのエンコードとデコード、トラフィック制御、およびマルチプロトコルサポートを提供します。
従来のBrokerモジュールのストレージ部分は、新しいストレージノードに分離され、競争力の高い高性能・低レイテンシのストレージサービスの提供に注力しています。ストレージとコンピューティングの分離により、ストレージ機能のイノベーションも加速します。従来のBrokerモジュールのコンピューティング部分は、段階的にProxyクラスタに移行しています。
LB グループは、Classic VIP、VPC VIP、インターネット VIP、シングルトンネル、PrivateLink など、ユーザーのニーズを満たすさまざまなアクセス機能を提供しています。

ストレージとコンピューティングを分離することに関連する追加コストは、主にレイテンシとコストです。

レイテンシに関しては、ストレージノードとコンピューティングノードをローカルメソッド呼び出しからリモート呼び出しに変換すると、必然的にレイテンシが増加します。レイテンシは通常、ミリ秒単位です。Alibaba Cloudでは、AZ間のネットワーク通信であっても、レイテンシは通常2ミリ秒未満です。このレベルのレイテンシの増加は、ほとんどの企業にとって全く許容範囲内です。

コスト面では、ストレージとコンピューティングを分離すると、ネットワーク伝送層とシリアル化・デシリアル化層で必然的にCPUリソースが必要になります。しかし一方で、ストレージはディスクI/Oとメモリを集中的に使用するのに対し、コンピューティングはCPUを集中的に使用します。これらを分離することで、より適切な仕様設計が可能になり、断片化されたリソースをより有効に活用できるようになり、リソース利用率の向上が容易になり、クラウドの弾力性も活用できるため、コスト削減にもつながります。
つまり、クラウド環境では、クラウドサービスとしての RocketMQ は、ストレージとコンピューティングを分離するアーキテクチャに非常に適しています。

2. ストレージとコンピューティングを統合したアーキテクチャ

しかし、根本的に、ストレージとコンピューティングの分離は、近接コンピューティングや近接ストレージの概念と矛盾します。ストレージとコンピューティングを統合したアーキテクチャは、クラウドにおいて問題を引き起こしてきました。これは主に、クラウドがマルチテナント環境であり、ストレージとコンピューティングを統合したアーキテクチャはマルチテナントのシナリオにおいて柔軟性に欠けるからです。しかし、多くのシナリオは小規模でシングルテナントであることが多く、実際にはストレージとコンピューティングを統合したアーキテクチャの方が適しています。

オープンソースのシナリオにおいて、ユーザーはRocketMQが使いやすく、すぐに導入できるメッセージミドルウェアであることを期待しています。ストレージとコンピューティングを分離したアーキテクチャは、特定の複雑さをもたらし、オープンソースエコシステムの発展に影響を及ぼす可能性があります。
何千台もの物理マシンを備えた大規模な企業環境では、ストレージとコンピューティングを分離すると追加のマシンコストが発生します。
プライベートクラウドのシナリオでは、多くのプライベートクラウドではノード数が限られており、統合アーキテクチャを採用する傾向があります。

クラウド内外で統一された技術ソリューションを確保するため、ストレージとコンピューティングを個別に、あるいは組み合わせて導入できるアーキテクチャを推奨します。個別に導入することでステートレスなコンピューティングノードが実現し、運用と保守が極めて容易になります。一方、組み合わせて導入することで、元のアーキテクチャとの一貫性を維持できます。

採用される展開アーキテクチャに関係なく、ストレージとコンピューティングを分離することは優れたモジュール設計アプローチであり、プログラミングレベルでの分離が不可欠です。

上の図に示すように、左側はクラウド内の独立したデプロイメントを表し、右側はマージされたデプロイメントを表しています。マージされたデプロイメントでは、コンピューティングノードはストレージノードのサイドカーとして機能し、グリッドのようなデプロイメントアプローチを採用するか、コンピューティングとストレージを同じプロセスに統合することができます。実際には、徹底したコード設計により、コンストラクターを使用してプロキシノードを構築し、「ローカル」と「クラスター」という2つのデプロイメントモデルを作成できます。これらはそれぞれ、マージされたデプロイメントアーキテクチャと個別のデプロイメントアーキテクチャに対応しています。

3. 複数の製品形態を備えた単一のアーキテクチャ

「クラウドネイティブ時代のメッセージングミドルウェアの進化ロードマップ」という記事では、Alibaba Cloudのメッセージングチームが現在、RocketMQ、Kafka、MQTT、AMQP、MNS、EventBridgeなど、業界で最も包括的なメッセージング製品マトリックスを誇っていることが言及されています。この豊富な製品マトリックスは、チームが長年にわたり、多様かつ標準化された進化の道筋に注力してきた成果です。現在、すべてのメッセージングサブ製品はRocketMQストレージカーネル上に構築されており、統一されたアーキテクチャのための強固な基盤を提供しています。

単一のストレージとコンピューティングを分離したアーキテクチャを通じて複数の製品ビジネスモデルをサポートすることは、クラウドネイティブメッセージングを探求する上で重要な方向性です。複数の製品モデルを単一のアーキテクチャで実現することで、コンピューティングノードの共同構築、モデル抽象化による複数のビジネスモデルと通信プロトコルのサポート、冗長構築にかかる人員削減など、多くのメリットが得られます。ストレージノードをプールすることで、さまざまな製品が内部ストレージノードを接続してリソースプールを形成できるため、統一された運用管理が可能になり、コスト削減、効率向上、ストレージイノベーションの加速、そしてメッセージングプラットフォームのインキュベーションに貢献します。

上図に示すように、複数の製品形態を持つ単一アーキテクチャの中核は、まずストレージとコンピューティングを統合し、さらに管理と運用保守を統合することで、真に単一のアーキテクチャで複数のクラウド製品をサポートすることです。

ストレージクラスターは、一般的なメッセージアクセスのニーズを満たすのに十分抽象化されています。
コンピューティングクラスターは多機能で、高度にモジュール化され、プラグ可能であり、さまざまな権限システム、プロトコル、抽象モデルを備えた複数製品の展開のニーズを満たします。

要約

現在、アリババクラウドのRocketMQメッセージキューは最初の移行フェーズにあり、ストレージとコンピューティングを完全に分離したアーキテクチャを実装しています。今後の道のりは長く、このアーキテクチャをパブリッククラウド環境に完全に実装するには、少なくとも1年を投資する予定です。これにより、メッセージサービスの弾力性とクラウドネイティブ性が向上し、チームの効率性が向上し、ビジネスイノベーションが加速します。新しいアーキテクチャは、少なくとも今後5年間は安定的にビジネスの成長を支えると期待しています。同時に、ストレージとコンピューティングの分離と統合により、さまざまな規模のオープンソースユーザーの個別のニーズを効果的にサポートし、Apache RocketMQオープンソースコミュニティがこの新しいアーキテクチャの恩恵を受けることができます。

DUICUO