RocketMQはKosmosをベースにAZレベルの高可用性を実現

1. 背景

RocketMQ がマスター/スレーブモードを採用するか、Dledger マルチコピーモードを採用するかにかかわらず、RocketMQ クラスターの高可用性を確保できます。ただし、コンピュータ室の停電、コンピュータ室の火災、地震、その他の不可抗力要因などの極端なシナリオでは、IDC アベイラビリティゾーンの RocketMQ クラスターは通常のメッセージサービス機能を提供できません。したがって、リスク耐性を強化するためには、メッセージキュー RocketMQ クラスターにマルチアクティブおよびリモート災害復旧機能を持たせることが非常に重要です。

2. リモート災害復旧ソリューションの物理的な展開

図2-1 物理的展開リモート災害復旧ソリューション

Mobile Cloud に導入された RocketMQ はマスター/スレーブモデルを使用します。このモデルでは、リモートディザスタリカバリソリューションの物理的な導入に次の部分が含まれます。

（1）ネームサーバーコンポーネントは、ステートレスな軽量登録センターであり、ブローカーサービスの更新と検出を担当します。 Namesrv 間の通信はありません。単一の Namesrv に障害が発生しても、他の Namesrv ノードやクラスターの機能には影響しません。 2 つの Namesrv が異なる可用性ゾーンにデプロイされています。 1 つのアベイラビリティゾーンに障害が発生した場合でも、他のアベイラビリティゾーンの Namesrv は外部にサービスを提供し続けることができます。

（２）ブローカーコンポーネントはメッセージ転送エージェントとして機能し、メッセージの保存と転送を担当します。マスター/スレーブデプロイメントモードを採用し、2 つのアベイラビリティゾーンにクロスデプロイされます (たとえば、ブローカー a のマスターはアベイラビリティゾーン 1 にデプロイされ、スレーブノードはアベイラビリティゾーン 2 にデプロイされます。ブローカー b のマスターはアベイラビリティゾーン 2 にデプロイされ、スレーブノードはアベイラビリティゾーン 1 にデプロイされます)。メッセージはマスターノードに送信された後、各アベイラビリティゾーンにメッセージの全量が保存されるように、スレーブノードにリアルタイムで同期されます。 1 つのアベイラビリティゾーンに障害が発生した場合でも、外部に対してメッセージの読み取りと書き込みの機能が引き続き提供されます。

3. クラウド版リモート災害復旧シングルクラスタソリューション

物理マシンに導入された RocketMQ の運用、保守、移行、スケーリングには時間がかかり、労力がかかり、操作が複雑です。ビジネスが拡大するにつれて、リソースは弾力的に対応できなくなり、手動でのスケーリングではリアルタイムのパフォーマンスが低下します。基盤となるリソースの使用率が低く、ユーザーリソースの分離とトラフィック制御には追加の投資が必要です。 K8S オペレーターを使用できます。 Operator の動作原理は、実際には Kubernetes のカスタム API リソース (CRD、CustomResourceDefinition など) を使用して、デプロイするアプリケーションを記述することです。次に、カスタムコントローラーで、カスタム API オブジェクトの変更に応じて、具体的な展開と運用および保守作業を完了します。 Operator を実現するための鍵となるのは、CRD (カスタムリソース) と Controller (コントローラー) の設計です。

図3-1 オペレータ概略図

RocketMQ Operator を開発することで、数秒でのクラスターのデプロイメント、スケーリング、仕様変更など、一連の一般的な運用・保守操作を実現し、物理的なデプロイメントによって発生する問題を解決しました。次の図は、RocketMQ Operator の設計と実装を示しています。

図3-2 RocketMQオペレータアーキテクチャ図

このソリューションでは、3 つのリモートアベイラビリティゾーンを使用して K8S クラスターをデプロイし、各アベイラビリティゾーンにマスターノードをデプロイします。図のブローカーは、クロスデプロイメントを備えた 2 つのマスターと 2 つのスレーブの高可用性ソリューションであり、各可用性ゾーンに 1 つの namesrv インスタンスがデプロイされています。

図3-3 クラウドベースのリモート災害復旧単一クラスタソリューション

このソリューションにはいくつかの問題があります。大規模な単一の K8S クラスターに障害が発生すると、クラスター全体に影響が及ぶ可能性があり、コンポーネントのアップグレードは困難でリスクが伴います。ビジネスが拡大するにつれて、コアコンポーネントへの圧力が高まり、パフォーマンスが低下します。単一のクラスターの構築は、特定の地理的位置と事前の計画によって制限される可能性があり、柔軟性に欠けます。

4. クラウド版リモート災害復旧クラスタフェデレーションソリューション

上記のソリューションの欠点を考慮して、RocketMQ クラウドバージョンのメッセージキューのマルチゾーンバージョンは現在次のように最適化されています。

図4-1 クラウドベースのリモート災害復旧マルチフェデレーションクラスタソリューション

K8S クラスターは、クラウドネイティブの Kosmos を使用して複数のクラスターを統合します。もはや単一の K8S クラスターだけに依存することはありません。 RocketMQ サービスリソースは、Kosmos CluterTree を介してフェデレーションクラスター間で svc、pod、およびその他のリソースを同期し、フェデレーションクラスター間のネットワークは Kosmos ClusterLink によって接続されます。

5. コスモスの紹介

Kosmos は、モバイルクラウド向けの分散型クラウドネイティブフェデレーションクラスターテクノロジーのコレクションです。 2023 年 8 月にオープンソース化されました。プロジェクトアドレスは https://github.com/kosmos-io/kosmos です。 Kosmos には、マルチクラスターネットワークツール ClusterLink、クロスクラスターオーケストレーションツール ClusterTree などが含まれています。

図5-1 Kosmosモジュールとコンポーネント

ClusterLink の機能は、複数の Kubernetes クラスターを接続することです。 CNI上位層に実装されます。ユーザーはインストールされた CNI プラグインをアンインストールしたり再起動したりする必要がなく、実行中のポッドには影響しません。 ClusterLink の主な機能は次のとおりです。

 ✓ 提供跨集群PodIP、ServiceIP互访能力✓ 提供P2P、Gateway多种网络模式✓ 支持全局IP分配✓ 支持IPv4、IPv6双栈

ClusterTree の役割は、Kubernetes のツリー状の拡張とアプリケーションのクラスター間オーケストレーションを実装することです。 ClusterTree は基本的にコントローラーのグループです。ユーザーは、追加のコード変更を必要とせずに、単一のクラスターを使用する場合と同じように、コントロールプレーン kube-apiserver と直接対話できます。現在、ClusterTree の主な機能は次のとおりです。

 ✓提供创建跨集群应用能力✓兼容k8s api，用户零改造✓支持有状态应用✓支持k8s-native（需要访问kube-apiserver的）应用

さらに、Kosmos はいくつかの補助ツールも提供しており、その中で kosmos-operator は Kosmos の展開を簡素化します。 Kosmosctl は、ネットワーク接続テスト、クラスター管理、Kosmos の展開とインストールなどの機能をユーザーに提供するコマンドラインツールです。

6. Kosmos マルチクラスターネットワーク ClusterLink

1. ClusterLink のワークフローと原則

ClusterLink は、Linux トンネルテクノロジーを使用してクラスター間ネットワークを接続します。トンネルタイプは、VxLAN や IPSec など、構成可能です。 ClusterLink には、次の図の水色部分に示すように、Network-Manager や Agent などの複数のコンポーネントが含まれています。さまざまなコンポーネントが連携して、トンネル、ルーティングテーブル、fdb などのネットワーク構成を完了します。

図6-1 ClusterLinkアーキテクチャ

ワークフローは次のとおりです。

まず、各サブクラスターにある Controller-Manager コンポーネントは、podCIDR、serviceCIDR、ノード情報などのクラスター情報を収集する役割を担います。この情報は、異なる CNI プラグインの下の異なる場所に保存されるため、Controller-Manager には CNI に適応するためのプラグインがいくつか含まれています。収集されたクラスター情報は、Cluster と ClusterNode という 2 つのカスタムリソースに保存されます。
次に、Network-Manager コンポーネントは、これら 2 つの CR の変更を監視し、ネットワークカード情報、ルーティングテーブル、iptables、arp など、各ノードに必要なネットワーク構成をリアルタイムで計算します。対応するノードのネットワーク構成情報は、NodeConfig カスタムリソースオブジェクトに保存されます。
次に、ネットワーク構成の特定の実装者として、デーモンセットであるエージェントは、対応するノードのネットワーク構成を読み取り、基礎となるネットワーク構成を実行する責任を負います。ネットワーク構成が完了すると、podIP と serviceIP を介してクラスター間でポッドにアクセスできるようになります。

(II) ClusterLinkネットワークモードの紹介

図6-2 ClusterLinkネットワークモード

現在、ClusterLink にはゲートウェイと P2P の 2 つのネットワークモードが含まれています。ゲートウェイモードでは、データパケットは左側のポッドから送信された後、まずクラスター内の vx-local トンネルを介してクラスターゲートウェイノードに到達します。次に、クラスター間トンネルを使用してピアクラスターに到達します。データパケットがピアクラスターに到達すると、CNI によって処理され、単一のクラスターネットワークを介してターゲットポッドに到達します。このモデルには利点と欠点の両方があります。その利点は、外部アクセスを提供するために各クラスターで必要なノードが 1 つだけ (HA を考慮すると 2 つ) であり、これはクロスクラウドハイブリッドクラウドシナリオに適していることです。欠点は、ネットワークパスが長いため、パフォーマンスが多少低下することです。この問題に対処するために、ClusterLink は、より高いネットワークパフォーマンスが必要なシナリオで使用できる P2P モードを提供します。このモードでは、データパケットの制御粒度がより細かくなり、ピアポッドが配置されているノードに直接送信されます。さらに、P2P モードとゲートウェイモードは混合使用をサポートします。

7. Kosmos クロスクラスターオーケストレーション ClusterTree

(I) ClusterTree のコンポーネントと原理の紹介

ClusterTree は、Kubernetes のツリー拡張とアプリケーションのクラスター間オーケストレーションを実装します。ユーザーは、単一のクラスターを使用しているかのように、ルート kube-apiserver にアクセスできます。リーフクラスターはルートクラスター内のノードとして追加されます。ユーザーは、labelSelector、アフィニティ/アンチアフィニティ、テイントと許容度、トポロジ分散制約などのポッド分散を制御するために、k8s ネイティブメソッドを使用できます。

図7-1 ClusterTreeアーキテクチャ

ClusterTree は基本的にコントローラーのグループです。各コントローラーの機能は次のとおりです。

ノードコントローラ: ノードリソースの計算。ノードステータスの維持。ノードリースの更新
pod-controller: ルートクラスターのポッド作成を監視し、リーフクラスターの kube-apiserver を呼び出してポッドを作成します。ポッドステータスを維持します。環境変数を変換します。権限を注入する
storagecopy-controller: pv/pvc リソースの同期とステータス管理
mcs-controller: サービスリソースの同期とステータス管理

(II) ClusterTree 高可用性の紹介

AZ レベルの障害が発生したり、AZ 間のネットワークが中断されたりした場合に、ユーザーが RocketMQ クラスターインスタンスに正常にアクセスできることを確認することが非常に重要です。上図に示すように、A でのネットワーク切断やコントロールプレーン障害に対処するために、ClusterTree はサービスとエンドポイントリソースの同期を実装し、ユーザーアクセストラフィックがサブクラスターを直接通過できるようにすることで、管理と業務を切り離し、ネットワークパスを短縮します。 RocketMQ のネームサーバーポッドはクラスター全体に分散されます。 B のネットワークが切断されたり、AZ に障害が発生したりした場合、ユーザーが nsv ポッドにアクセスできない可能性が 50% あります。この問題に対処するために、ClusterTree の eps-probe プラグインは、定期的にクラスター間の ep を検出し、失敗したエンドポイントを削除します。

図7-2 RocketMQクロスAZ高可用性

8. Kosmos クラスターの負荷とネットワークパフォーマンステスト

ClusterTree はいくつのノードとポッドを管理できますか? ClusterLink のパフォーマンスは、単一のクラスターネットワークと比較してどうですか?これらはユーザーが非常に懸念している問題であり、私たちも対応するテストを実施しました。

（I）クラスタ負荷テスト

試験基準
Kubernetes は、3 つの SLI (サービスレベルインジケーター) と対応する SLO (サービスレベル目標) 値を公式に提供します。 SLI には、読み取りおよび書き込みのレイテンシ、ステートレスポッドの起動時間 (イメージのプルと init コンテナの起動を除く) が含まれます。ドキュメントアドレス: https://github.com/kubernetes/community/blob/master/sig-scalability/slos/slos.md
テストツール

クラスタローダー2
ClusterLoader2 は、Kubernetes によって定義された SLI/SLO インジケーターをテストして、クラスターがさまざまなサービス品質基準を満たしているかどうかを確認できます。 ClusterLoader2 は最終的に、一連のパフォーマンスインジケーターのテスト結果を示す Kubernetes クラスターパフォーマンスレポートを出力します。 https://github.com/kubernetes/perf-tests/tree/master/clusterloader2
クォック
DocOpen オープンソースプロジェクト。大規模クラスターを迅速にシミュレートするために使用されます。 https://github.com/kubernetes-sigs/kwok

試験方法

図8-1 クラスタ負荷テスト - テスト方法

図に示すように、まず kwok を通じて 20 個の大規模クラスターを作成しました。各クラスターには 5,000 個のノードが含まれており、これらのクラスターは Kosmos を使用して管理されています。次に、clusterloader2 を使用してコントロールプレーン kube-apiserver に接続し、クラスターの負荷テストを実行します。主要なテストパラメータを図に示します。

テスト結果

図8-2 クラスタ負荷テスト - テスト結果

Kosmos を使用して k8s クラスターフェデレーションを管理すると、100,000 ノードと 200,000 ポッドのシナリオで公式の SLO 標準が満たされ、このスケールは Kosmos の上限に達しません。

（II）ネットワークパフォーマンステスト

テストツール
iperf3
評価基準パフォーマンスを評価するために、RTT (ラウンドトリップ時間) 遅延を使用します。 RTT は Round Trip Time の略で、送信者がデータの送信を開始してから送信者が受信者から確認を受信するまでの合計遅延を指します (受信者はデータを受信した後に確認を送信します)。
テスト方法では、次の図のパート 1 と 2 に示すように、単一クラスターネットワークとクラスター間ネットワークの RTT 遅延を比較します。

図8-3 ネットワークパフォーマンステスト - テスト方法