Amazon MQ で運用するメッセージブローカー - ActiveMQ と RabbitMQ の選定と移行

Amazon MQ の位置づけと SQS/SNS との使い分け

Amazon MQ は ActiveMQ と RabbitMQ のフルマネージドブローカーサービスです。SQS と SNS が AWS ネイティブのメッセージングサービスであるのに対し、MQ は業界標準のメッセージブローカーをマネージドに運用します。SQS は無制限のスループット、自動スケーリング、サーバーレスアーキテクチャとの統合に優れており、新規開発のクラウドネイティブアプリケーションでは第一選択です。一方、既存アプリケーションが JMS API、AMQP プロトコル、複雑なルーティングルール (トピックセレクタ、メッセージフィルタ) に依存している場合、SQS/SNS への書き換えは大きなコストを伴います。メッセージの優先度制御、トランザクション管理、複雑なルーティングパターンなど標準プロトコルの高度な機能が必要な場合も MQ が適しています。移行後に段階的に SQS や SNS へリファクタリングする戦略も有効です。

ActiveMQ と RabbitMQ の選定

ActiveMQ は Java エコシステムとの親和性が高く、JMS 1.1 に完全準拠します。1 ブローカーが受けられるワイヤレベル接続の数はインスタンス種別で決まり、公式ドキュメント記載値では mq.*.*large 系が 2,000、mq.*.micro が 300 で、いずれもワイヤレベルプロトコルごとの上限です (2026 年 8 月時点)。キュー、トピック、仮想トピック、コンポジットデスティネーションなど ActiveMQ の全機能をサポートします。ネットワークオブブローカー構成により、複数のブローカーを接続してスケーラブルなメッセージングトポロジーを構築できます。STOMP、MQTT、OpenWire など複数のプロトコルを同時にサポートし、IoT デバイスとエンタープライズアプリケーションの橋渡しにも使えます。RabbitMQ は AMQP 0-9-1 をネイティブサポートし、Exchange (Direct、Topic、Fanout、Headers) と Binding による柔軟なルーティングが特徴です。クラスタデプロイメントによりクォーラムキューを構成し、高可用性とデータの耐久性を確保します。Amazon MQ が同時にサポートする RabbitMQ は 2 メジャー系統で、公式ドキュメント記載値では 4.2 (推奨) と 3.13 の 2 つです。4.2 はインスタンスタイプが mq.m7g 系に限られ、3.13 は mq.t3・mq.m5・mq.m7g で使えます。ストリーム (streams) は Amazon MQ のサポート対象外で、作成するとデータ損失につながります (2026 年 8 月時点)。Python、Ruby、Go、.NET など多言語のクライアントライブラリが充実しており、ポリグロットな環境に適しています。管理 UI が標準で提供され、キューの状態やメッセージレートをブラウザから監視できます。

高可用性構成とセキュリティ

ActiveMQ のアクティブ/スタンバイ構成では、2 つのブローカーインスタンスが異なる AZ に配置され、EFS 上の共有ストレージでメッセージを永続化します。プライマリ障害時にスタンバイが自動的に引き継ぎ、フェイルオーバーは数十秒で完了します。RabbitMQ のクラスタデプロイメントでは 3 つの AZ にまたがる 3 ノードクラスタが構成され、クォーラムキューがノード間でメッセージを複製して耐久性を確保します。クラシックキューのミラーリングは RabbitMQ 4 系で廃止されているため、現行の冗長化はクォーラムキューが前提です。両エンジンとも、マルチ AZ デプロイメントによる自動フェイルオーバーと KMS による保存時暗号化を標準で提供します。メッセージを永続化するストレージはエンジンと構成で分かれ、ActiveMQ の単一インスタンス構成と RabbitMQ は EBS、ActiveMQ のアクティブ/スタンバイ構成は 2 つのブローカーが共有できる EFS を使います。この違いは後述のとおり課金次元にも表れます。CloudWatch メトリクスによるブローカーの健全性監視と、CloudTrail による API 操作の監査ログも利用可能です。以下は AWS CLI で RabbitMQ ブローカーを作成する例です。新規作成できるのはサポート対象の 2 メジャー系統だけで、3.12 以前 (3.12 は 2025 年 3 月 17 日にサポート終了) は指定できません。4.2 を使う場合は --host-instance-type も mq.m7g.large のように mq.m7g 系へ合わせます。

aws mq create-broker \
  --broker-name my-rabbitmq-broker \
  --engine-type RABBITMQ \
  --engine-version 3.13 \
  --host-instance-type mq.m5.large \
  --deployment-mode CLUSTER_MULTI_AZ \
  --users Username=admin,Password=MySecurePass123

オンプレミスからの移行戦略

オンプレミスの ActiveMQ から Amazon MQ への移行は、ブローカー設定の移行、クライアント接続先の変更、ネットワーク構成の調整の 3 ステップで進めます。Amazon MQ はオンプレミスの ActiveMQ と同じ設定ファイル形式 (activemq.xml) をサポートするため、既存の設定をほぼそのまま適用できます。VPN または Direct Connect を使用してオンプレミスとの接続を確保し、段階的にクライアントを Amazon MQ に切り替えるブルーグリーン移行が推奨されます。RabbitMQ の場合は、Shovel プラグインや Federation プラグインを活用してオンプレミスとクラウド間のメッセージ転送を設定し、ダウンタイムを最小化できます。移行後のパフォーマンスチューニングとして、インスタンスタイプの選定、ストレージタイプの選択、プリフェッチサイズの調整が重要です。さばけるメッセージ数はメッセージサイズ、永続化の有無、使用プロトコル、同時接続数で大きく変わるため、インスタンスタイプごとの秒間件数を一律の目安として扱わず、本番相当の負荷試験で確認します。

Amazon MQ の料金

Amazon MQ の料金はブローカーインスタンスの時間課金とストレージで構成されます (2026 年 8 月時点・バージニア北部 (us-east-1) と東京 (ap-northeast-1) の値)。単一インスタンスの mq.m5.large は、バージニア北部で ActiveMQ・RabbitMQ ともに 1 時間あたり 0.288 ドル (月 720 時間換算で約 207 ドル)、東京ではどちらも 0.372 ドル (同じ換算で約 268 ドル) です。エンジンによる単価差はありません。冗長構成では台数分だけインスタンス料金が増え、ActiveMQ のアクティブ/スタンバイは 2 倍 (バージニア北部で 1 時間あたり 0.576 ドル)、RabbitMQ の 3 ノードクラスタは 3 倍 (同 0.864 ドル) になります。ストレージは構成ごとに課金次元が分かれており、EBS を使う ActiveMQ 単一インスタンスと RabbitMQ は 1 GB あたり月額 0.10 ドル (東京 0.12 ドル)、EFS を使う ActiveMQ のアクティブ/スタンバイは 1 GB あたり月額 0.30 ドル (東京 0.36 ドル) です。つまりアクティブ/スタンバイにするとインスタンス料金が 2 倍になるだけでなくストレージ単価も 3 倍になるため、総額の見積もりでは両方を計算に入れます。SQS (標準キューで 100 万リクエストあたり 0.40 ドル) と比較するとコストは高いため、既存のメッセージブローカーからの移行以外では SQS/SNS を優先的に検討すべきです。

まとめ

Amazon MQ は既存のメッセージブローカーを AWS にリフト&シフトするためのフルマネージドサービスです。ActiveMQ と RabbitMQ の業界標準プロトコル (JMS、AMQP、STOMP、MQTT) をサポートし、コード変更なしでの移行を実現します。マルチ AZ 自動フェイルオーバー、KMS 暗号化、CloudWatch 監視を標準装備し、インフラ運用の負荷を最小化しながらメッセージングアプリケーションの信頼性を向上させます。新規開発では SQS/SNS を、既存アプリケーションの移行では MQ を選択する判断基準が重要です。