Amazon MQ

Apache ActiveMQ および RabbitMQ をフルマネージドで提供し、既存のメッセージングアプリケーションを最小限のコード変更でクラウドに移行できるメッセージブローカーサービス

概要

Amazon MQ は、Apache ActiveMQ と RabbitMQ の 2 つのオープンソースメッセージブローカーエンジンをフルマネージドで提供するサービスです。JMS、AMQP、STOMP、MQTT、OpenWire などの業界標準プロトコルに対応しており、オンプレミスで稼働している既存のメッセージングアプリケーションを、コードの大幅な書き換えなしにクラウドへ移行できます。ブローカーのプロビジョニング、パッチ適用、障害検知、フェイルオーバーが自動化されており、運用負荷を大幅に削減します。マルチ AZ 配置によるアクティブ/スタンバイ構成で高可用性を確保し、EBS ボリュームへのメッセージ永続化でデータの耐久性を担保します。

ブローカーエンジンの選択とデプロイ構成

Amazon MQ では ActiveMQ と RabbitMQ の 2 つのエンジンから選択します。ActiveMQ は JMS (Java Message Service) API を使用する既存の Java アプリケーションとの互換性が高く、エンタープライズ統合パターン (EIP) に基づく複雑なルーティングやメッセージ変換をブローカー側で処理できます。RabbitMQ は AMQP 0-9-1 プロトコルを中心に、柔軟な Exchange タイプ (Direct、Topic、Fanout、Headers) によるメッセージルーティングが強みです。デプロイ構成は、単一インスタンス、アクティブ/スタンバイ (マルチ AZ)、RabbitMQ のクラスターデプロイの 3 パターンがあります。本番環境ではアクティブ/スタンバイ構成が推奨され、プライマリブローカーの障害時に自動的にスタンバイへフェイルオーバーします。フェイルオーバー時間は通常 60 秒以内で、クライアント側の再接続ロジック (failover:// トランスポート) で透過的に切り替わります。インスタンスタイプは mq.m5.large から mq.m5.4xlarge まで選択でき、メッセージスループットと同時接続数に応じてサイジングします。

ActiveMQ のネットワークオブブローカーと永続化

ActiveMQ エンジンでは、ネットワークオブブローカー (Network of Brokers) 構成により、複数のブローカーインスタンスを論理的に接続してメッセージを転送できます。この構成は、地理的に分散したシステム間でメッセージを中継する場合や、ブローカーの負荷を分散する場合に有効です。各ブローカーはローカルのキューとトピックを持ちつつ、ネットワークコネクタを通じて他のブローカーのコンシューマーにメッセージを転送します。メッセージの永続化は EBS ボリュームに対して行われ、ブローカーの再起動やフェイルオーバー後もメッセージが失われません。ActiveMQ の KahaDB ストアがデフォルトの永続化エンジンとして使用され、ストレージ容量は 20 GB から 200 GB まで設定可能です。デッドレターキュー (DLQ) の設定は運用上重要で、処理に失敗したメッセージを DLQ に退避させることで、メインキューの滞留を防ぎます。DLQ に溜まったメッセージを CloudWatch メトリクスで監視し、閾値超過時にアラートを発報する運用パターンが実務では標準的です。

認証・暗号化とメンテナンスウィンドウ

Amazon MQ のセキュリティは、ネットワーク層、認証層、暗号化層の 3 層で構成されます。ブローカーは VPC 内のプライベートサブネットにデプロイされ、セキュリティグループでアクセス元を制限します。パブリックアクセスを有効にすることも可能ですが、本番環境では VPC 内配置が推奨されます。認証は ActiveMQ の場合 SimpleAuthenticationPlugin によるユーザー名/パスワード認証、RabbitMQ の場合はネイティブのユーザー管理機能を使用します。LDAP 統合は ActiveMQ エンジンでのみサポートされています。通信の暗号化は TLS で保護され、保管時の暗号化は AWS KMS のカスタマーマネージドキーまたは AWS マネージドキーで実施されます。メンテナンスウィンドウは週 1 回、2 時間の枠を指定し、この間にエンジンのパッチ適用やマイナーバージョンアップが実行されます。アクティブ/スタンバイ構成ではローリングアップデートにより、メンテナンス中もサービスの中断を最小限に抑えられます。CloudWatch メトリクスで CpuUtilization、HeapUsage、StorePercentUsage を監視し、容量逼迫を早期に検知することが安定運用の鍵です。

共有するXB!