すべてのプロダクト
Search

このプロダクト

    ApsaraMQ for RabbitMQ:Migrating from open-source

    ドキュメントセンター

    ApsaraMQ for RabbitMQ:Migrating from open-source

    最終更新日:Sep 18, 2026

    セルフマネージド RabbitMQ クラスターを Message Queue for RabbitMQ に移行することで、メッセージの滞留やスプリットブレインなどの安定性の問題を解決し、高い同時実行性、分散アーキテクチャ、柔軟なスケーリングを実現します。

    事前準備

    Message Queue for RabbitMQ は、Alibaba Cloud が独自の分散メッセージストレージ技術に基づいて開発したメッセージキューサービスです。AMQP 0-9-1 プロトコルに準拠していますが、単なるオープンソース RabbitMQ のマネージド版ではありません。そのアーキテクチャは、メッセージの滞留によるメモリリークやサーバー障害などの安定性の問題を回避し、分散システムにおけるスプリットブレインの問題を解消します。また、高いスケーラビリティと柔軟な従量課金制により、コストを削減します。

    ただし、Message Queue for RabbitMQ は、一部の機能においてオープンソース RabbitMQ とは異なります。移行する前に、技術的な実現可能性と費用対効果の評価を行い、このサービスがお客様のニーズを満たすことを確認してください。

    移行前の評価

    技術評価

    • Message Queue for RabbitMQ とオープンソース RabbitMQ は、特徴、サービス、パフォーマンス、エクスチェンジ、キューにおいて異なります。移行する前に、これらの違いを確認し、Message Queue for RabbitMQ がお客様のニーズを満たすかどうかを判断してください。詳細な比較については、「オープンソース RabbitMQ との比較」をご参照ください。

    • Message Queue for RabbitMQ は、クラスター、API 呼び出し、文字数に制限を設けています。移行する前に、これらの制限がお客様のビジネス要件を満たすかどうかを評価してください。詳細については、「インスタンスタイプ」をご参照ください。

    • 専用サーバーレスインスタンスを選択することを推奨します。これらのインスタンスはオープンソースの認証と権限をサポートしており、オープンソース RabbitMQ からクラウドへのシームレスな移行を可能にします。

    コスト評価

    Message Queue for RabbitMQ は、さまざまな仕様のサブスクリプションインスタンスとサーバーレスインスタンスの両方を提供しています。仕様の違いについては、「インスタンスタイプ」をご参照ください。

    サブスクリプションインスタンスと比較して、サーバーレスインスタンスはより優れた弾力性とコスト効率を提供します。課金ルールについては、「サーバーレスインスタンスの課金」をご参照ください。

    以下の方法で、セルフマネージド RabbitMQ クラスターの送受信操作、キュー数、メッセージ量を推定できます。

    • キュー数：オープンソース RabbitMQ コンソールの概要ページで、グローバルカウントを確認し、キューやエクスチェンジなどのメタデータオブジェクトの数を取得します。

    • 送受信操作数とメッセージ量：

      • 方法 1：オープンソース RabbitMQ 管理コンソールの概要ページで、メッセージレートを確認し、Publish、Deliver (manual ack)/Deliver (auto ack)、Redelivered のメトリックの合計を計算します。image

      • 方法 2：Prometheus Grafana ダッシュボードを使用して、クラスター全体の QPS と、インバウンドおよびアウトバウンドのメッセージトラフィックのメッセージ量を確認します。

    移行手順

    メタデータの移行

    メタデータを移行するには、オープンソース RabbitMQ クラスターからエクスポートし、ご利用の Message Queue for RabbitMQ インスタンスにインポートします。インポートが成功すると、Message Queue for RabbitMQ は、ターゲットの Message Queue for RabbitMQ インスタンスに対応する vhost、キュー、エクスチェンジ、バインディングを作成します。詳細な手順については、「メタデータのクラウドへの移行」をご参照ください。

    ユーザーの作成

    オープンソースのクライアントが Message Queue for RabbitMQ のブローカーで認証を行うには、ユーザー名とパスワードを使用する必要があります。接続は認証が成功した後にのみ確立されます。Message Queue for RabbitMQ は、以下の 2 つの ID と権限管理モードをサポートしています。詳細については、「ユーザーと権限の管理」をご参照ください。

    • オープンソースの認証と権限付与

      メタデータをインポートすることで、カスタムのユーザー名とパスワードを作成し、権限を管理できます。

    • Resource Access Management (RAM)

      RAM ユーザーの AccessKey ID と AccessKey Secret からユーザー名とパスワードを生成できます。

    ネットワーク接続の確立

    Message Queue for RabbitMQ は、Cloud Enterprise Network (CEN) を介してクラウドに接続できる PrivateLink エンドポイントを提供します。

    オープンソースの認証と権限付与モードを使用しており、すでに PrivateLink エンドポイントを設定している場合は、このステップをスキップしてください。

    メッセージデータの移行

    移行戦略

    スムーズな移行を確実にするために、クライアントの接続設定を切り替え、RabbitMQ Shovel プラグインを使用して、vhost ごとにメッセージデータを移行します。

    メリット

    • スムーズなビジネス移行を保証します。

    • データ損失がないことを保証します。

    • アプリケーション間の呼び出しの複雑なメッシュトポロジーをマッピングする必要がありません。

    移行ステップ

    シナリオに応じて適切な移行ステップを選択してください：

    • ゼロダウンタイム移行の場合：

      • キューのプロデューサーとコンシューマーが同じアプリケーション内にある場合は、「シナリオ 1」をご参照ください。

      • キューのプロデューサーとコンシューマーが別々のアプリケーションにある場合は、「シナリオ 2」をご参照ください。

      • セルフマネージド RabbitMQ クラスターがすでに Shovel タスクを実行している複雑なシナリオの場合は、「シナリオ 3」をご参照ください。

    • メンテナンスウィンドウを伴う移行の場合：ビジネスが短時間のダウンタイムを許容できる場合は、「シナリオ 4」をご参照ください。

    シナリオ 1：ゼロダウンタイム移行 (アプリケーションが統一されている場合)

    1. カナリアリリースから始めます：クライアント設定を更新して、いくつかのサービスノードをクラウドインスタンスに切り替えます。以下を確認します：

      1. プロデューサーがクラウドキューにメッセージを送信できること。

      2. コンシューマーはクラウドキューからメッセージを消費できます。

      3. エンドツーエンドの機能とパフォーマンスが期待どおりであること。

    2. カナリアノードが正しく動作していることを確認した後、セルフマネージド RabbitMQ クラスターで Shovel プラグインを設定し、有効にします。これにより、指定された vhost 内のキューから既存の滞留メッセージが、クラウドインスタンスの対応するキューに移行されます。

    3. ローリングアップデートを使用して、残りのすべてのサービスノードの RabbitMQ 接続設定をクラウドインスタンスに切り替えます。この時点で：

      1. すべての新しいメッセージは直接クラウドキューに書き込まれます。

      2. すべてのコンシューマーはクラウドキューからメッセージをフェッチします。

      3. セルフマネージドクラスターは新しいメッセージを受信しなくなり、残りの滞留メッセージを排出するための Shovel のソースとしてのみ機能します。

    4. セルフマネージドクラスターのキューのメッセージ滞留を監視します。滞留が解消されたら、Shovel タスクを停止します。

    5. セルフマネージド RabbitMQ クラスターの管理コンソールで、vhost のキューの滞留を確認できます。キューの準備完了メッセージ数と未確認メッセージ数が両方とも 0 になると、キューの滞留は解消されたことになります。

      RabbitMQ 管理コンソールで、[Queues] ページに移動します。[Messages] グループの [Ready] 列に準備完了メッセージ数が、[Unacked] 列に未確認メッセージ数が表示されます。

      重要

      コードが x-delayed-message エクスチェンジに遅延メッセージを送信する場合、これらのメッセージは遅延期間が終了するまでキューに入らず、滞留数にもカウントされません。Shovel タスクを停止する前に、すべての遅延メッセージがキューに入るように、設定されている最大のメッセージ遅延時間以上待機してください。

    シナリオ 2：ゼロダウンタイム移行 (アプリケーションが分離されている場合)

    1. セルフマネージド RabbitMQ クラスターで Shovel プラグインを設定し、有効にして、ターゲット vhost 内のすべての関連キューから既存の滞留メッセージをクラウドインスタンスの対応するキューに移行します。

    2. クラウド RabbitMQ インスタンスのコンシューマーサービスを開始し、クラウドキューからのメッセージのフェッチを開始させます。

    3. クラウドのコンシューマーが正しく動作していることを確認した後、セルフマネージドクラスターに接続されているコンシューマーサービスを停止します。

    4. クラウド RabbitMQ インスタンスのプロデューサーサービスを開始します。新しいメッセージが正常にクラウドキューに公開され、コンシューマーによって処理されることを確認します。

    5. 新しいメッセージがクラウドキューに流れ込み、正しく消費されていることを確認した後、セルフマネージドクラスターに接続されているプロデューサーサービスを停止します。

    6. この時点で、すべての新しいメッセージは直接クラウドキューに送られ、Shovel はセルフマネージドクラスターから残りのメッセージを移動し続けます。

    7. セルフマネージドクラスターのキューのメッセージ滞留を監視します。滞留が解消されたら、Shovel タスクを停止します。

    シナリオ 3：ゼロダウンタイム移行 (既存の Shovel タスクがある場合)

    1. セルフマネージドクラスターに接続されているプロデューサーおよびコンシューマーサービスを停止し、それらの設定を更新してクラウド RabbitMQ インスタンスを指すようにします。

    2. クラウドインスタンスに接続されているプロデューサーおよびコンシューマーサービスを開始し、それらが正しく動作していることを確認します。

    3. セルフマネージドクラスターで、新しい Shovel タスク (Shovel A) を設定し、vhost A のすべての関連キューからメッセージの滞留をクラウドインスタンスの対応するキューに移行します。

    4. vhost B から vhost A にメッセージを移動する既存の Shovel タスク (Shovel B) を一時停止します。Shovel B の送信先をクラウド RabbitMQ インスタンスの対応するキューを指すように変更し、その後 Shovel B を再度有効にします。

    5. セルフマネージドクラスター上の vhost B のキューのメッセージ滞留を監視します。滞留が解消されたら、Shovel B タスクを削除します。

    6. セルフマネージドクラスター上の vhost A のキューのメッセージ滞留を監視します。滞留が解消されたら、Shovel A タスクを削除します。

    シナリオ 4：ダウンタイムを伴う移行

    1. セルフマネージドクラスターに接続されているプロデューサーおよびコンシューマーサービスを停止します。

    2. サービス内の RabbitMQ 設定を更新して、クラウド RabbitMQ インスタンスを指すようにします。

    3. クラウドインスタンスのプロデューサーおよびコンシューマーサービスを開始し、それらが正しく動作していることを確認します。

    4. セルフマネージド RabbitMQ クラスターで Shovel プラグインを設定し、有効にして、キューに残っているすべてのメッセージをクラウドインスタンスの対応するキューに移行します。

    5. セルフマネージドクラスターのキューのメッセージ滞留を監視します。滞留が解消されたら、Shovel タスクを停止します。

    Shovel プラグインの使用

    1. セルフマネージドクラスターにログインし、コマンドラインで次のコマンドを実行して Shovel プラグインを有効にします：

      rabbitmq-plugins enable rabbitmq_shovel rabbitmq_shovel_management

    1. セルフマネージド RabbitMQ クラスターの管理コンソールにログインします。上部のナビゲーションバーで [Admin] をクリックし、右側の [Shovel Management] をクリックします。[Add a new shovel] セクションで、[Source] と [Destination] を設定し、[Add shovel] をクリックします。

      1. ソース設定フォーマット：[URI] には、amqp://{username}:{password}@{ip}:{port}/{vhost} と入力します。この URI において、username と password は認証情報、ip はセルフマネージドクラスターの IP アドレス、port は通信ポート (通常は 5672)、vhost はソース vhost です。

      2. 送信先設定フォーマット：[URI] には、amqp://{username}:{password}@{endpoint}:{port}/{vhost} と入力します。この URI において、username と password は Message Queue for RabbitMQ コンソールで作成した静的認証情報、endpoint は Message Queue for RabbitMQ インスタンスのエンドポイントアドレス、port は 5672、vhost は送信先 vhost です。

      また、Virtual host、必須の Name、プロトコル (AMQP 0.9.1 など)、ソースと送信先のキュー名も設定する必要があります。その他のパラメーターには、Prefetch count、Auto-delete (デフォルトは Never)、Add forwarding headers (デフォルトは No)、Reconnect delay、Acknowledgement mode (デフォルトは On confirm) があります。

    2. Shovel を追加した後、[Shovel Status] ページに移動してそのステータスを確認します。実行中の状態は、タスクが正常に開始されたことを示します。

    3. セルフマネージド RabbitMQ クラスターのキューのメッセージ滞留が解消されたら、Shovel タスクを削除します。

      Shovel の詳細ページで、下部にある [Delete this shovel] セクションを展開し、[Delete this shovel] ボタンをクリックします。

    参考

    Shovel プラグインの詳細については、「Shovel Plugin」ドキュメントをご参照ください。