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

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

Amazon MQ は ActiveMQ と RabbitMQ のマネージドブローカーサービスです。SQS と SNS が AWS ネイティブのメッセージングサービスであるのに対し、MQ は業界標準のメッセージブローカーをマネージドに運用します。新規アプリケーションでは SQS/SNS を推奨しますが、既存アプリケーションが JMS API、AMQP プロトコル、複雑なルーティングルール (トピックセレクタ、メッセージフィルタ) に依存している場合、SQS/SNS への書き換えは大きなコストを伴います。MQ はこれらの既存アプリケーションをコード変更なしで AWS に移行するためのサービスです。

この分野について体系的に学びたい方は、関連書籍 (Amazon) も参考になります。

ActiveMQ と RabbitMQ の選定

ActiveMQ は Java エコシステムとの親和性が高く、JMS 2.0 をフルサポートします。Java EE アプリケーションや Spring Framework ベースのアプリケーションからの移行に最適です。STOMP、MQTT、OpenWire など複数のプロトコルを同時にサポートし、IoT デバイスとエンタープライズアプリケーションの橋渡しにも使えます。RabbitMQ は AMQP 0-9-1 をネイティブサポートし、Exchange と Binding による柔軟なルーティングが特徴です。Python、Ruby、Go、.NET など多言語のクライアントライブラリが充実しており、ポリグロットな環境に適しています。管理 UI が標準で提供され、キューの状態やメッセージレートをブラウザから監視できます。

高可用性構成と移行パターン

ActiveMQ のアクティブ/スタンバイ構成では、2 つのブローカーインスタンスが異なる AZ に配置され、EFS 上の共有ストレージでメッセージを永続化します。プライマリ障害時にスタンバイが自動的に引き継ぎ、フェイルオーバーは数十秒で完了します。RabbitMQ のクラスタデプロイメントでは 3 ノードのクラスタが構成され、キューのミラーリングでメッセージの耐久性を確保します。オンプレミスからの移行では、まず MQ ブローカーを作成し、アプリケーションの接続先 URL を MQ のエンドポイントに変更するだけで移行が完了します。VPN または Direct Connect 経由でオンプレミスと MQ を接続し、段階的にワークロードを移行するパターンが一般的です。

さらに詳しく知りたい方は、関連書籍 (Amazon) で理解を深められます。

まとめ

Amazon MQ は既存のメッセージブローカーを AWS にリフト&シフトするためのサービスです。ActiveMQ と RabbitMQ の業界標準プロトコルをサポートし、コード変更なしでの移行を実現します。新規開発では SQS/SNS を、既存アプリケーションの移行では MQ を選択する判断基準が重要です。