ApsaraMQ for RabbitMQ は、AMQP 0-9-1 プロトコルをサポートする、高可用性で RabbitMQ 互換のメッセージングサービスを提供します。プロダクトの SLA はプラットフォーム側のサービス可用性を保証するものであり、お客様のビジネスにおける 100% のエンドツーエンドの可用性と同等ではありません。
プロダクト SLA とビジネスの可用性
公式の ApsaraMQ for RabbitMQ サービスレベル契約 (SLA) によると、サービス可用性はインスタンスごとに暦月単位で測定されます。現在の契約におけるベースラインのコミットメントは 99.95% 以上です。30 日間の暦月を基準にすると、99.95% は契約で定義されている約 21.6 分の利用不可時間に相当します。この値は SLA メトリックを示すものであり、お客様のビジネスで許容される障害ウィンドウを定義するものではありません。実際の計算は、サービスの利用不可の定義、除外事項、および購入時に有効な契約に従います。
ビジネスの可用性は、クライアントの再接続、ネットワークと DNS の状態、アプリケーションのデプロイ、消費処理能力、べき等処理能力、クロスリージョン災害、バージョンライフサイクル、およびお客様固有の構成にも影響を受けます。お客様の業務継続性の目標が単一インスタンスの SLA を超える場合は、アプリケーション側とリソースアーキテクチャ側の両方で、マルチインスタンス、マルチリージョン、フェールオーバー、およびメッセージのべき等性の機能を構築する必要があります。
SLA メトリックは、インスタンスタイプや仕様によって異なる場合があります。具体的な権利は、購入ページ、Alibaba Cloud の公式ウェブサイト、および購入時に有効な契約に従います。マルチインスタンスソリューションは、新しいプロダクト SLA を作成するものではなく、2 つのインスタンスの SLA を乗算することもできません。ビジネスの可用性は、障害分離、メッセージ同期、クライアントのフェールオーバー、および訓練の有効性に依存します。
アーキテクチャの境界
ApsaraMQ for RabbitMQ は AMQP 0-9-1 プロトコルと互換性があり、サーバー側でマネージド型のマルチノードアーキテクチャを使用します。パブリックエンドポイント、VPC、PrivateLink プライベートネットワーク接続アクセスポイントなどのアクセス方法は、コンソールと公式ドキュメントに従います。
ApsaraMQ for RabbitMQ は、マルチノードおよびマルチゾーン機能を通じてインスタンスの可用性を向上させます。サーバー側では、複数のノードを使用して接続とリクエストを処理します。単一のサーバー側ノードまたはゾーンで異常が発生した場合、マルチノード機能はインスタンスの可用性への影響を軽減するのに役立ちます。具体的な機能は、インスタンスタイプ、リージョン、および購入ページに従います。
クライアント接続は `Connection` の粒度で処理されます。複数の長寿命の `Connection` を確立すると、トラフィックは複数のノードに均等に分散されますが、各 `Connection` が異なるノードに着地することは保証されません。単一の AMQP `Connection` 上に複数の `Channel` を作成すると、その `Connection` 内の同時多重化は向上しますが、`Connection` レベルのサーバー側ノード分散を置き換えることはできません。高い同時実行数またはミッションクリティカルなワークロードの場合は、複数の長寿命の `Connection` を確立し、すべてのトラフィックが単一または少数の `Connection` に集中しないように、プロデューサーとコンシューマーを接続プール全体に分散させます。
以下のシナリオは、単一インスタンスのアーキテクチャでは対応できません。
リージョンレベルの障害、クロスリージョンネットワークの障害、またはお客様側の VPC、DNS、またはセキュリティグループの異常
自動再接続、チャネルの再構築、またはコンシューマーの再サブスクライブを設定していないクライアント
少数の長寿命の `Connection` のみを使用し、トラフィックがサーバー側のノードに十分に分散されていないクライアント
コンシューマーの処理が遅い、ビジネスプロセスの失敗、メッセージのバックログ、またはクォータ超過によるスロットリング
べき等処理の欠如による、フェールオーバーまたはリプレイ中の重複消費、順序不同の配信、またはビジネス上の副作用
クライアント側の改善
どのデプロイソリューションを選択するかにかかわらず、クライアントの実装が以下の要件を満たしていることを確認してください。完全なガイダンスについては、「SDK の使用上の注意」および「Spring Boot クライアントを使用するためのベストプラクティス」をご参照ください。
自動再接続 — 切断後に `Connection` を自動的に再構築します。使用する `SDK` に応じて、トポロジーとコンシューマーの回復機能を確認してください。詳細については、「クライアントの自動再接続を設定する」をご参照ください。
トラフィック分散のための複数の Connection — 本番環境とコンシューマーの同時実行数、およびインスタンスの `Connection` クォータに基づいて、複数の長寿命の `Connection` を設定します。本番環境とコンシューマーには別々の `Connection` を使用してください。すべての本番環境とコンシューマーを単一の `Connection` に集中させたり、頻繁に `Connection` を作成およびクローズしたりしないでください。一般的な推奨事項については、「Connection と Channel」をご参照ください。Spring クライアントについては、「Spring Boot クライアントを使用するためのベストプラクティス」をご参照ください。
チャネルの再構築 — RabbitMQ の `Channel` は永続的なリソースではありません。プロトコルの例外、リソース宣言の競合、またはスロットリングが発生した場合は、`Channel` を再構築してください。リソース宣言の競合の場合は、まず宣言パラメーターを修正してください。スロットリングのシナリオでは、再構築ループの作成を避けるために、再構築する前にバックオフと負荷分散を適用してください。`Channel` は `Connection` を再利用できますが、`Connection` レベルのサーバー側ノード分散を置き換えることはできません。詳細については、「インスタンスのスロットリングに関するベストプラクティス」をご参照ください。
コンシューマーの回復 — 再接続後、
basic.consumeとコンシューマーのコールバックを復元して、コンシューマーのサブスクリプションを再確立します。再接続後の排他的キュー、コンシューマータグ、およびその他のリソースの回復動作が期待どおりであることを確認してください。パブリッシャー確認 (Publisher Confirm) — プロデューサー側でパブリッシャー確認 (Publisher Confirm) を使用して、サーバーがメッセージを受信し、その責任を負ったかどうかを判断します。パブリッシャー確認 (Publisher Confirm) は、コンシューマーがメッセージを処理したことを意味するものではありません。確認がタイムアウトした場合や確認応答がない場合は、べき等性のルールに従って同じビジネスメッセージ ID でリトライしてください。
コンシューマー ACK とリトライ — ビジネス処理が成功した後にのみ ACK を返します。失敗した場合は、ビジネス戦略に基づいて、reject、nack、回数制限付きのリトライを実行するか、デッドレターキューにルーティングします。リトライ ループを作成する無限の再キューイングは避けてください。
べき等処理 — 本番、ルーティング、フェールオーバー、リプレイはすべて重複メッセージを生成する可能性があります。プロデューサーは同じビジネスメッセージに対して安定したビジネスメッセージ ID を維持し、コンシューマーはビジネス ID によって重複排除を行う必要があります。詳細については、「メッセージのべき等性」をご参照ください。
スロットリングとサーキットブレーカー — インスタンスが異常であるか、下流が不健康な場合、プロデューサーはリトライの増幅、バックログ、および連鎖障害を避けるために、スロットリングを行い、リトライの上限付きでバックオフを適用する必要があります。詳細については、「インスタンスのスロットリングに関するベストプラクティス」をご参照ください。
アクセスアドレスの更新 — 設定センターまたはお客様管理のドメイン名を通じてインスタンスを切り替える場合、クライアントは古いアドレスを無期限に保持することを避けるために、アクセスアドレスの更新をサポートする必要があります。お客様管理のドメイン名を使用する場合は、DNS キャッシュ、クライアントまたは JVM の DNS キャッシュ、および TLS ホスト名検証の動作を確認してください。
推奨ソリューション
以下のセクションでは、可用性階層を向上させる 4 つのデプロイソリューションについて説明します。次の表は、各ソリューションを要約したもので、ワークロードに適したソリューションを見つけるのに役立ちます。ソリューション固有の考慮事項に加えて、クライアントが「クライアント側の改善」で説明されている要件を満たしていることを確認してください。
より高い安定性、リソース分離、または容量の予測可能性を必要とするワークロードには、`Platinum Edition` または `Serverless Exclusive Edition` を選択してください。具体的な機能と SLA 条件は、インスタンスタイプの説明と購入ページに従います。
ソリューション | 適用範囲 | 主な前提条件 | 主な制限事項 |
単一インスタンスのベースライン | RTO/RPO 要件が緩和された非クリティカルパス | クライアントの再接続、モニタリング、アラート機能 | インスタンスタイプのプラットフォーム SLA のみ |
同一リージョン内デュアルインスタンススタンバイ | 同一リージョン内でのインスタンスレベルの障害回復が必要なコアワークロード | 設定センター、メッセージ同期、べき等処理 | クロスリージョンディザスタリカバリを置き換えるものではない |
クロスリージョンのプライマリ/スタンバイ | リージョンレベルの障害からの保護が必要なワークロード | クロスリージョンインスタンス、メッセージルーティング、定義された RTO/RPO およびスイッチバック条件 | デフォルトでは透過的なフェールオーバーはなし |
アクティブ/アクティブ | 成熟したべき等処理、重複排除、競合解決機能を備えたワークロード | グローバルメッセージ ID、重複排除、競合解決戦略 | デフォルトのソリューションとしては推奨されない |
単一インスタンスのベースラインソリューション
このソリューションは、非クリティカルパス、短い利用不可時間を許容できるワークロード、および RTO と RPO の要件が緩和されたシナリオに適用されます。
主な設計上の考慮事項
インスタンスタイプと制限に基づいて、TPS、キュー、接続数、メッセージサイズ、保持期間に関するビジネス要件を満たすインスタンス仕様を選択します。
クライアントで `Connection` の自動再接続を有効にし、クライアントにチャネルの再構築とコンシューマーの回復機能があることを確認します。
ビジネスの同時実行数に基づいて、アプリケーションインスタンスごとに複数の長寿命の AMQP `Connection` を確立し、接続プールを介して本番および消費トラフィックを分散させます。すべてのトラフィックを単一の `Connection` で処理し、`Channel` の数を増やすだけにしないでください。
パブリッシャー確認 (Publisher Confirm)、コンシューマー ACK、タイムアウトのリトライ、デッドレターキュー、およびアラートを設定します。
公式のバージョン管理ポリシーとアップグレード通知で要求されるインスタンスのバージョンアップグレードを完了します。期限切れまたはメンテナンス終了のバージョンを長期間実行しないでください。
モニタリングとアラートに基づいて、接続数、送受信スループット、エラーコード、キューのバックログ、消費レイテンシー、スロットリングなどの主要なメトリックに対するアラートを設定します。
リスクと制限事項
単一インスタンスのソリューションは、インスタンスタイプに対応するプロダクト SLA のみを提供し、これはビジネス側の 100% の可用性と同等ではありません。
お客様のビジネスが単一インスタンスの障害ウィンドウを許容できない場合は、マルチインスタンスのディザスタリカバリソリューションにアップグレードしてください。
同一リージョン内デュアルインスタンススタンバイソリューション
このソリューションは、同一リージョン内でのインスタンスレベルの障害回復を改善する必要があるが、クロスリージョンディザスタリカバリは必要としないコアワークロードに適用されます。
アーキテクチャの概要
主な設計上の考慮事項
同一リージョンに 2 つの RabbitMQ インスタンスを購入します。同一リージョン内のデュアルインスタンス構成は、クロスリージョンディザスタリカバリを置き換えるものではありません。
プライマリインスタンスとスタンバイインスタンスの `Vhost`、`Exchange`、`Queue`、`Binding`、アカウント権限、およびネットワークアクセスポリシーを機能的に同等に保ちます。(推奨) 設定ドリフトを避けるために、自動化された構成またはアプリケーションの起動時の宣言を通じてリソースを管理します。プライマリインスタンスとスタンバイインスタンスの認証情報を個別に管理し、セキュリティポリシーに従ってローテーションします。
メッセージ同期のオプション：
アプリケーションのデュアルライト — プロデューサーはプライマリインスタンスとスタンバイインスタンスの両方に同時に書き込みます。アプリケーションのデュアルライトは、単一パスの書き込み失敗によるデータギャップを減らすことができますが、クロスインスタンスの原子性の保証は提供しません。部分的な成功、確認のタイムアウト、べき等性のリトライ、および補償を処理します。
グローバルメッセージルーティング — グローバルメッセージルーティングを使用して、プライマリインスタンスのソースキューからスタンバイインスタンスのキューまたは `Exchange` にメッセージを非同期に転送します。この方法には同期遅延があり、RPO はルーティングのバックログとネットワークの状態に依存します。機能のサポートは、インスタンスタイプの説明とコンソールに従います。
グローバルメッセージルーティングは、ソースキューから消費し、ターゲットにメッセージを転送します。これはソースキューのサイドカーレプリケーションではありません。ビジネスコンシューマーがアクティブに消費しているキューをルーティングソースとして直接再利用しないでください。ソース `Exchange` をビジネスキューと専用のディザスタリカバリ同期キューの両方にバインドし、専用キューをルーティングソースとして使用します。セマンティクスについては、「グローバルメッセージルーティング」および「RabbitMQ Shovel」をご参照ください。
グローバルメッセージルーティングのターゲットタイプが `Exchange` に設定されている場合、ターゲット `Exchange` にメッセージを保存できるキューがバインドされていることを確認してください。そうしないと、`Exchange` にルーティングされたメッセージは、それらを受信するキューがない場合に失われる可能性があります。
コンシューマーはデフォルトでプライマリインスタンスからのみ消費します。フェールオーバー中は、スタンバイインスタンスでコンシューマーを開始またはスケールアップし、プライマリとスタンバイの両方が同時に同じビジネスストリームを消費して重複した副作用を引き起こすのを防ぎます。
ビジネスメッセージ ID によるべき等処理を実装し、フェールオーバー後の重複配信または補償配信を許可します。
推奨されるフェールオーバー手順
モニタリングを通じて、プライマリインスタンスが利用不可であるか、ビジネスの送信または消費操作に影響を与えるパフォーマンスの異常が発生しており、期待されるウィンドウ内で回復していないことを確認します。
障害ウィンドウ中にプライマリとスタンバイのデータギャップが広がるのを防ぐために、ビジネスのコンティンジェンシープランに従って、プロデューサー側の書き込みを一時停止、スロットリング、またはデグレードします。
設定センターまたはアプリケーションのアクセスアドレス設定を通じて、スタンバイインスタンスに切り替えます。お客様管理の DNS を使用する場合は、DNS キャッシュと TLS 検証がフェールオーバーを妨げないことを確認してください。
スタンバイインスタンスでコンシューマーを開始するか、スタンバイインスタンスの消費の重みを増やします。
送信成功率、消費率、キューのバックログ、およびビジネスの成功率を監視します。
プライマリインスタンスが回復した後、ビジネスの送受信記録、バックログメトリック、およびビジネスメッセージ ID に基づいて調整、補償、および重複排除を完了してから、制御された変更プロセスを通じてスイッチバックします。
クロスリージョンのプライマリ/スタンバイディザスタリカバリソリューション
このソリューションは、リージョンレベルの障害から保護する必要があるコアワークロード、または本質的にクロスリージョンでデプロイされているワークロードに適用されます。
アーキテクチャの概要
主な設計上の考慮事項
2 つの別々のリージョンに RabbitMQ インスタンスを作成します。トポロジー、アカウント権限、およびネットワークアクセスポリシーを機能的に同等に保ちます。各インスタンスの認証情報を個別に管理します。
重要なメッセージを同期するために、グローバルメッセージルーティング、アプリケーションのデュアルライト、またはビジネスの Outbox メカニズムを使用します。グローバルメッセージルーティングの機能サポートは、インスタンスタイプの説明とコンソールに従います。
グローバルメッセージルーティングを使用する場合、ビジネスコンシューマーとソースキューを競合させないように、同一リージョンソリューションと同じ専用のディザスタリカバリ同期キュー設計を適用します。
グローバルメッセージルーティングのターゲットタイプが `Exchange` に設定されている場合、ターゲット `Exchange` にメッセージを保存できるキューがバインドされていることを確認してください。
グローバルメッセージルーティングを使用する場合、`EventBridge` と `Cloud Enterprise Network (CEN)` のコスト、メッセージ同期の遅延、およびルーティングのバックログを評価します。アプリケーションのデュアルライトまたは Outbox を使用する場合、クライアントのネットワーキング、アクセスポイント、ホワイトリスト、リンクコスト、およびフェールオーバーアプローチを別途計画します。
ターゲットのメッセージサイズ制限は、ソースの制限以上でなければなりません。ターゲットの制限を超えるメッセージは、ルーティングに失敗する可能性があります。
グローバルメッセージルーティングは推移的ルーティングをサポートしていません。A から B を経て C へのルートは、A から B を通じて C へメッセージを自動的に転送しません。A から C へのルーティングが必要な場合は、直接 A から C へのルートを設定してください。
クロスリージョンディザスタリカバリは、デフォルトで完全に透過的なフェールオーバーを前提とすべきではありません。RTO、RPO、フェールオーバーの承認者、スイッチバックの条件、およびデータ補償メカニズムを明確に定義します。
アクティブ/アクティブソリューション
このソリューションは、すでに強力なべき等処理、重複排除、競合解決、および結果整合性の機能を備えており、両方のリージョンまたはインスタンスが同時にトラフィックを処理する必要があるワークロードに適用されます。アクティブ/アクティブは、お客様のアプリケーションアーキテクチャの設計であり、プロダクトが自動的にクロスインスタンスのアクティブ/アクティブまたはグローバルな整合性機能を提供することを意味するものではありません。
主な設計上の考慮事項
プロデューサーは、リトライ中に安定しているグローバルに一意なビジネスメッセージ ID を使用する必要があります。
コンシューマーは、ビジネスプライマリキーによるべき等処理と重複排除を実装する必要があります。RabbitMQ の配信回数を唯一の信頼できる情報源として依存しないでください。
双方向の同期ループや重複の増幅を避けるために、各メッセージのプライマリ書き込みパスと同期方向を明確に定義します。
順序セマンティクスの境界を明確に定義します。クロスインスタンスのアクティブ/アクティブは、通常、グローバルに厳密な順序保証を提供しません。
重複支払い、重複注文、在庫引き落とし、その他のビジネス上の副作用を含む、競合解決戦略を明確に定義します。
継続的なドリルと自動化された照合の機能を維持します。
リスクと制限事項
アクティブ/アクティブは、デフォルトのソリューションとしては推奨されません。ほとんどのワークロードは、複雑さによる安定性の低下を避けるために、プライマリ/スタンバイまたは階層的なデグレードを優先すべきです。
訓練と受け入れ基準
マルチインスタンスのディザスタリカバリソリューションを導入する前に、少なくとも以下の訓練を完了してください。
訓練項目 | 検証目標 |
プライマリインスタンスのアクセス障害 | クライアントは期待どおりにスタンバイインスタンスにフェールオーバーする。RTO が目標を達成する。 |
プライマリインスタンスの送信障害 | プロデューサーは障害を特定し、制御不能な重複なしにリトライまたは補償を行う。 |
マルチコネクションの分散 | アプリケーションインスタンスは設定どおりに複数の長寿命の `Connection` を確立する。再起動またはフェールオーバー後、接続プールは回復し、トラフィックは単一の `Connection` に集中したままにならない。 |
コンシューマーの再起動 | アプリケーションは `Channel` を再構築し、コンシューマーのサブスクリプションを再確立する。 |
グローバルメッセージルーティングの遅延 | ソースの専用キューのバックログ、ターゲットへの流入、および同期遅延が観測可能である。 |
スタンバイインスタンスの消費引き継ぎ | スタンバイインスタンスのコンシューマーは起動後に既存のメッセージを処理する。ビジネスのべき等性が有効である。 |
プライマリインスタンスへのスイッチバック | ビジネスの調整、補償、重複排除、およびカナリアスイッチバックが正常に完了する。 |
以下のメトリックは、ディザスタリカバリソリューションの受け入れ基準を定義します。
RTO — ビジネスが影響を受けるか、フェールオーバー条件が満たされてからビジネスが回復するまでの時間。
RPO — 障害ウィンドウ中に失われるか、補償が必要になる可能性のあるメッセージの最大範囲。
重複率 — フェールオーバーおよびリプレイ中の重複メッセージの割合とそのビジネスへの影響。
バックログ回復時間 — フェールオーバー後にキューのバックログが通常レベルに戻るまでの時間。
クライアント回復成功率 — `Connection` の再接続、`Channel` の再構築、およびコンシューマーの再サブスクライブの成功率。
Connection の分散 — アプリケーションの再起動、スケールアウト、またはフェールオーバー後、本番および消費トラフィックは複数の長寿命の `Connection` に分散され続けます。長期間にわたって単一の `Connection` のみを使用することは避けてください。