翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon MQ for RabbitMQ の使用
Amazon MQ は、ニーズに適したコンピューティングおよびストレージリソースを使用したメッセージブローカーの作成を容易にします。ブローカーを作成、管理 AWS マネジメントコンソール、削除するには、、Amazon MQ REST API、または を使用します AWS Command Line Interface。
このセクションでは、ActiveMQ エンジンタイプと RabbitMQ エンジンタイプ向けのメッセージブローカーの基本的要素を説明し、利用可能な Amazon MQ ブローカーのインスタンスタイプとステータスをリストして、ブローカーのアーキテクチャと設定オプションの概要を説明します。
Amazon MQ REST API については、*[Amazon MQ REST API リファレンス](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/)*を参照してください。
## Amazon MQ for RabbitMQ ブローカーとは
*ブローカー*は、Amazon MQ で実行されるメッセージブローカー環境です。これは、Amazon MQ の基本的な構成要素です。ブローカーインスタンスの*クラス* (`m7g`) および*サイズ* (`large`、`medium`) を組み合わせた説明は、*ブローカーインスタンスタイプ* (`mq.m7g.large` など) と呼ばれます。
+ *単一インスタンスブローカー*は、Network Load Balancer (NLB) の背後にある 1 つのアベイラビリティーゾーンに 1 つのブローカーで構成されます。ブローカーは、アプリケーション、および Amazon EBS ストレージボリュームと通信します。
+ *クラスターデプロイ*は、ネットワークロードバランサーの内側にある 3 つの RabbitMQ ブローカーノードの論理グループで、それぞれがユーザー、キュー、および複数のアベイラビリティーゾーン (AZ) 間の分散状態を共有します。
詳細については、[RabbitMQ ブローカーのデプロイ」を参照してください。 ](rabbitmq-broker-architecture.md)
### リスナーポート
Amazon MQ マネージド RabbitMQ ブローカーは、 を介したアプリケーションレベルの接続のために次のリスナーポートをサポートしています`amqps`。RabbitMQ ウェブコンソールと 管理 API を使用して、クライアント接続にこれらのポートを使用することもできます。すべての接続では、セキュリティのために TLS 暗号化が使用されます。
+ リスナーポート `5671` - 安全な AMQP URL を介して行われる安全な AMQP 接続に使用されます。このポートは、RabbitMQ 4 で AMQP 0-9-1 プロトコルと AMQP 1.0 プロトコルの両方をサポートしています。例えば、`us-west-2` リージョンでデプロイされた、ブローカー ID が `b-c8352341-ec91-4a78-ad9c-a43f23d325bb` のブローカーの場合、ブローカーの完全な `amqps` URL は `b-c8352341-ec91-4a78-ad9c-a43f23d325bb.mq.us-west-2.amazonaws.com:5671` になります。
+ リスナーポート`443`と `15671`- 両方のリスナーポートを互換的に使用して、RabbitMQ ウェブコンソールまたは管理 API を介してブローカーにアクセスできます。ポート 443 は標準の HTTPS アクセスを提供しますが、ポート 15671 は TLS 暗号化を使用する従来の RabbitMQ 管理ポートです。
### 属性
RabbitMQ ブローカーには、いくつかの属性があります。
+ 名前。例えば、`MyBroker`。
+ ID。例えば、`b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9`。
+ Amazon リソースネーム (ARN)。例えば、`arn:aws:mq:us-east-2:123456789012:broker:MyBroker:b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9`。
+ RabbitMQ ウェブコンソール URL。例えば、`https://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-east-2.amazonaws.com`。
詳細については、RabbitMQ ドキュメントの「[RabbitMQ web console](https://www.rabbitmq.com/management.html)」を参照してください。
+ セキュアな AMQP エンドポイント。例えば、`amqps://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-east-2.amazonaws.com`。
ブローカー属性の完全なリストについては、*Amazon MQ REST API リファレンス*で以下を参照してください。
+ [REST オペレーション ID: ブローカー](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/rest-api-broker.html)
+ [REST オペレーション ID: ブローカー](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/rest-api-brokers.html)
+ [REST オペレーション ID: ブローカーの再起動](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/rest-api-broker-reboot.html)
# Amazon MQ for RabbitMQ エンジンバージョンの管理
RabbitMQ は、`X.Y.Z` 形式のセマンティックバージョニングに従ってバージョン番号を分類します。Amazon MQ for RabbitMQ の実装では、`X` はメジャーバージョンを示し、`Y` はマイナーバージョンを表し、`Z` はパッチバージョン番号を示します。Amazon MQ は、メジャーバージョン番号が変更される場合に、バージョン変更がメジャーであると見なします。例えば、バージョン **3**.13 から **4**.0 へのアップグレードはメジャーバージョンのアップグレードと見なされます。マイナーバージョン番号またはパッチバージョン番号のみが変わる場合、バージョン変更はマイナーと見なされます。たとえば、バージョン 3.**11**.28 から 3.**12**.13 へのアップグレードは、マイナーバージョンアップグレードと見なされます。
Amazon MQ for RabbitMQ では、すべてのブローカーがサポートされている最新バージョンの RabbitMQ 4.2 を使用することをお勧めします。ブローカーエンジンバージョンをアップグレードする手順については、「[Amazon MQ ブローカーエンジンバージョンのアップグレード](upgrading-brokers.md)」を参照してください。
新しい Amazon MQ for RabbitMQ ブローカーを作成するときは、メジャーバージョン番号とマイナーバージョン番号のみを指定する必要があります。例えば、RabbitMQ 4.2 などです。ブローカーの作成時にエンジンバージョンを指定しない場合、Amazon MQ は自動的に最新のエンジンバージョンにデフォルト設定されます。
**重要**
Amazon MQ では、[ストリーム](https://www.rabbitmq.com/streams.html)はサポートされません。ストリームを作成すると、データが失われます。
Amazon MQ は、JSON での構造化ログ記録の使用をサポートしていません。
Amazon MQ は RabbitMQ の 2 つのメジャーバージョンリリースをサポートしています。
+ [**RabbitMQ 4**](rabbitmq-4.md)
Amazon MQ は、RabbitMQ 4 リリースシリーズの RabbitMQ 4.2 を、サポートされているすべてのインスタンスサイズにわたって mq.m7g インスタンスタイプでのみサポートしています。
+ **RabbitMQ 3**
Amazon MQ は、サポートされているすべてのインスタンスサイズでRabbitMQmq.t3、mq.m5、および mq.m7g インスタンスタイプの RabbitMQ 3 リリースシリーズで RabbitMQ 3.13 をサポートしています。
## サポートされているエンジンバージョンのリスト化
[https://docs.aws.amazon.com/cli/latest/reference/mq/describe-broker-instance-options.html](https://docs.aws.amazon.com/cli/latest/reference/mq/describe-broker-instance-options.html) AWS CLI コマンドを使用して、サポートされているすべてのマイナーエンジンバージョンとメジャーエンジンバージョンを一覧表示できます。
```
aws mq describe-broker-instance-options
```
エンジンおよびインスタンスタイプで結果をフィルタリングするには、以下にあるように、`--engine-type` および `--host-instance-type` オプションを使用します。
```
aws mq describe-broker-instance-options --engine-type engine-type --host-instance-type instance-type
```
例えば、ActiveMQ と `mq.m7g.large` インスタンスタイプで結果をフィルタリングするには、*engine-type* を `RABBITMQ`、*instance-type* を `mq.m7g.large` に置き換えます。
# RabbitMQ 4
Amazon MQ は、RabbitMQ 4 リリースシリーズの RabbitMQ 4.2 を、サポートされているすべてのインスタンスサイズにわたって mq.m7g インスタンスタイプでのみサポートしています。
**重要**
RabbitMQ 4.2 では、新しいブローカーのみを作成できます。現在、RabbitMQ 3.13 からのインプレースアップグレードはサポートされていません。
**重要**
Amazon MQ for RabbitMQ 4.2 ブローカーのデフォルトのキュータイプは「クォーラム」になります。キューの作成時にキュータイプの引数を指定しない場合、クォーラムキューが作成されます。
RabbitMQ 4 では耐久性のニーズに応じてクォーラムキューを使用することを強くお勧めします。クラシックキューは、すべてのケースで耐久性が保証されるわけではないためです。
## Amazon MQ の RabbitMQ 4 では、次の変更が導入されました。
+ **コアプロトコルとしての AMQP 1.0:** 詳細については、[「プロトコル](rabbitmq-supported-protocols.md)」を参照してください。
+ **ローカルシャベル:** Shovels は、AMQP 0-9-1 および AMQP 1.0 に加えて、「local」と呼ばれる新しいプロトコルをサポートするようになりました。ローカルシャベルは内部的に AMQP 1.0 に基づいていますが、個別の TCP 接続を使用する代わりに、クラスターノードと内部 APIs 間のクラスター内接続を使用してメッセージの発行と消費を行います。これは、同じクラスター内での消費と公開にのみ使用でき、AMQP 0-9-1 および AMQP 1.0 よりも少ないリソースを使用しながら、より高いスループットを提供できます。
+ **クォーラムキューはメッセージの優先順位をサポート:** クォーラムキューメッセージの優先順位は常にアクティブであり、ポリシーが機能する必要はありません。クォーラムキューが優先順位が設定されたメッセージを受信するとすぐに、優先順位が有効になります。クォーラムキューは、内部的に高と通常の 2 つの優先順位のみをサポートします。優先順位が設定されていないメッセージは、優先順位 0～4 と同様に通常の にマッピングされます。優先度が 4 を超えるメッセージは高にマッピングされます。高優先度メッセージは、通常の優先度メッセージよりも 2:1 の比率で優先されます。つまり、キューは 2 つの高優先度メッセージごとに 1 つの通常の優先度メッセージ (利用可能な場合) を配信します。したがって、クォーラムキューは、厳格ではない「公平な共有」優先度処理の一種を実装します。これにより、通常の優先度メッセージで常に進行が保証されますが、高い優先度は 2:1 の比率で優先されます。
+ **Khepri:** Khepri は RabbitMQ 4 ブローカーのデフォルトのメタデータストアとして使用されます
+ **相互 TLS (mTLS):** Amazon MQ は RabbitMQ ブローカーの相互 TLS (mTLS) をサポートしているため、クライアントは証明書を使用して認証できます。詳細については、[mTLS 設定](configure-mtls.md)を参照してください。
+ **SSL 証明書認証プラグイン:** SSL 認証プラグインは mTLS 接続のクライアント証明書を使用してユーザーを認証し、ユーザー名とパスワード認証情報の代わりに X.509 クライアント証明書を使用した認証を許可します。詳細については、[「SSL 証明書認証](ssl-for-amq-for-rabbitmq.md)」を参照してください。
+ **HTTP 認証プラグイン:** HTTP 認証バックエンドプラグインを使用すると、認証と認可を外部 HTTP サービスに委任できます。詳細については、[「HTTP 認証と認可](http-for-amq-for-rabbitmq.md)」を参照してください。
+ **JMS サポート:** ブローカーは JMS トピック交換プラグインを有効にして JMS ワークロードをサポートするようになり、JMS アプリケーションが [RabbitMQ JMS クライアント](https://github.com/rabbitmq/rabbitmq-jms-client)を使用して接続できるようになりました。
## Amazon MQ では、以下の機能が RabbitMQ 4 から廃止されました。
+ **クラシックキューのミラーリング:** クラシックキューは、クライアントライブラリとアプリケーションに重大な変更を加えることなく引き続きサポートされますが、レプリケートされていないキュータイプになりました。クライアントは、任意のノードに接続して、レプリケートされていないクラシックキューに発行および消費できます。クォーラムキューは、レプリケーションとデータの安全性のために推奨されます。
+ **グローバル QoS の削除:** グローバル QoS の代わりに、コンシューマーごとの QoS (非グローバル) を設定することをお勧めします。この場合、チャネル全体に単一の共有プリフェッチが使用されます。
+ **一時的な非排他的キューのサポート: ** 一時的なキューは、宣言されているノードの稼働時間に有効期間がリンクされているキューです。単一のインスタンスブローカーでは、ノードの再起動時に削除されます。クラスターデプロイでは、ホストされているノードが再起動されると削除されます。キュー TTL は、アイドル状態の未使用キューをしばらく非アクティブ状態になった後に自動削除するために使用することをお勧めします。排他的キューは引き続きサポートされ、キューへのすべての接続が削除されると削除されます。
## Amazon MQ で RabbitMQ 4.2 にアップグレードすると、以下の重大な変更がアプリケーションに影響を与える可能性があります。
+ **デフォルトのキュータイプ:** RabbitMQ 4 ブローカーのデフォルトのキュータイプはクォーラムに設定されています。キューの作成時にキュータイプの引数を指定しない場合、クォーラムキューが作成されます。
+ **クォーラムキューのデフォルトの再配信制限は 20 に設定されています。**20 回以上再配信されたメッセージはデッドレターまたは削除 (削除) されます。メッセージあたり 20 回の配信がキューの一般的なシナリオである場合、データ損失を避けるために、このようなキューに対してデッドレターターゲットまたは上限を設定する必要があります。これを行うには、ポリシーを使用することをお勧めします。
+ **amqplib: ****0.10.7 より前のノード JS クライアント amqplib バージョン**、または **frame\$1max < 8192 を使用する AMQP クライアントライブラリ**は RabbitMQ に接続できません
+ [デフォルトのリソース制限:](rabbitmq-resource-limits-configuration.md) Amazon MQ for RabbitMQ では、接続、チャネル、チャネルあたりのコンシューマー、キュー、vhost、シャベル、交換、最大メッセージサイズにデフォルトのリソース使用制限が導入されました。これらはブローカーの可用性を保護するためのガードレールとして機能し、特定の要件に合わせて設定を使用してカスタマイズできます。
## Amazon MQ の RabbitMQ 4 では、以下の機能はサポートされていません。
+ **ローカルランダム交換:** Amazon MQ ノードはネットワークロードバランサーの背後にあるため、ローカルランダム交換は Amazon MQ ではサポートされていません。
+ **メッセージインターセプター:** [ RabbitMQ メッセージインターセプター](https://www.rabbitmq.com/docs/message-interceptors)は Amazon MQ ではサポートされていません。
+ **キューごとのメトリクス:** Amazon MQ は、 AWS CloudWatch を通じて RabbitMQ 4 ブローカーの RabbitMQ キューメトリクスを提供しません。Amazon MQ は引き続き AWS CloudWatch を通じてブローカーレベルのメトリクスを提供します。RabbitMQ 管理 API を使用してキューメトリクスをクエリできます。特定のキューのメトリクスを 1 分以上の頻度でクエリすることをお勧めします。
# RabbitMQ バージョンのサポート
以下の Amazon MQ バージョンサポートカレンダーは、ブローカーエンジンバージョンがサポートを終了するタイミングを示しています。あるバージョンがサポート終了に達すると、Amazon MQ は、そのバージョンのすべてのブローカーを、サポートされている次のバージョンに自動的にアップグレードします。このアップグレードは、ブローカーのスケジュールされたメンテナンス期間中に、end-of-supportから 45 日以内に行われます。
Amazon MQ は、バージョンがサポート終了に達する少なくとも 90 日前に通知を送信します。中断を防ぐために、サポート終了日より前にブローカーをアップグレードすることをお勧めします。また、サポート終了が 30 日以内に予定されているバージョンで新しいブローカーを作成することはできません。
| RabbitMQ バージョン | Amazon MQ でのサポート終了 |
| --- | --- |
| 4.2 (推奨) | |
| 3.13 | |
| 3.12 | 2025 年 3 月 17 日 |
# バージョンのアップグレード
ブローカーはいつでも、サポートされている次のメジャーバージョンまたはマイナーバージョンに手動でアップグレードできます。ブローカーの手動アップグレードの詳細については、[Amazon MQ ブローカーエンジンバージョンのアップグレード](upgrading-brokers.md)」を参照してください。
Amazon MQ は、バージョン 3.13 以降を使用して、すべての RabbitMQ ブローカーでサポートされている最新のパッチバージョンへのアップグレードを管理します。手動および自動のバージョンアップグレードは、どちらもスケジュールされたメンテナンスウィンドウ中、またはブローカーの再起動後に行われます。
**重要**
RabbitMQ では、バージョンの増分アップデート (例: 3.9.x から 3.10.x) のみが可能です。アップデートでマイナーバージョンをスキップすること (例: 3.8.x から 3.11.x) はできません。
再起動中、シングルインスタンスブローカーはオフラインになります。クラスターブローカーでは、ミラーキューは再起動時に同期する必要があります。キューが長い場合、キューの同期プロセスに時間がかかることがあります。キューの同期プロセス中、コンシューマーとプロデューサーはキューを利用できません。キューの同期プロセスが完了すると、ブローカーは再び利用可能になります。影響を最小限に抑えるために、トラフィックの少ない時間帯にアップグレードすることをお勧めします。バージョンアップグレードのベストプラクティスの詳細については、「[Amazon MQ for RabbitMQ のベストプラクティス](best-practices-rabbitmq.md)」を参照してください。
# Amazon MQ for RabbitMQ ブローカーのデプロイオプション
RabbitMQ ブローカーは、*単一インスタンスブローカー*として、または*クラスターデプロイ*で作成できます。どちらのデプロイモードでも、Amazon MQ はデータを冗長的に保存することによって優れた耐久性を提供します。
RabbitMQ ブローカーには、[RabbitMQ がサポートする任意のプログラミング言語](https://www.rabbitmq.com/devtools.html)を使用し、以下のプロトコルに対して TLS を有効にすることによってアクセスできます。
+ [AMQP (0-9-1)](https://www.rabbitmq.com/specification.html)
**Topics**
+ [
## オプション 1: Amazon MQ for RabbitMQ 単一インスタンスブローカー
](#rabbitmq-broker-architecture-single-instance)
+ [
## オプション 2: Amazon MQ for RabbitMQ クラスターデプロイ
](#rabbitmq-broker-architecture-cluster)
## オプション 1: Amazon MQ for RabbitMQ 単一インスタンスブローカー
*単一インスタンスブローカー*は、ネットワークロードバランサー (NLB) の内側にある 1 つのアベイラビリティーゾーン内の 1 つのブローカーで構成されます。ブローカーは、アプリケーション、および Amazon EBS ストレージボリュームと通信します。Amazon EBS は、低レイテンシーと高スループット向けに最適化されたブロックレベルのストレージを提供します。
ネットワークロードバランサーの使用は、メンテナンスウィンドウ中に、または基盤となる Amazon EC2 ハードウェア障害が理由でブローカーインスタンスが置き換えられた場合でも、Amazon MQ for RabbitMQ ブローカーエンドポイントがそのまま変更されないことを確実にします。ネットワークロードバランサーは、アプリケーションとユーザーが引き続き同じエンドポイントを使用してブローカーに接続できるようにします。
以下の図は、Amazon MQ for RabbitMQ の単一インスタンスブローカーを示しています。
![\[Diagram showing client, load balancer, Amazon MQ broker, and EBS volume in AWS クラウド.\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/amazon-mq-rabbitmq-broker-architecture-single-broker.png)
## オプション 2: Amazon MQ for RabbitMQ クラスターデプロイ
*クラスターデプロイ*は、ネットワークロードバランサーの内側にある 3 つの RabbitMQ ブローカーノードの論理グループで、それぞれがユーザー、キュー、および複数のアベイラビリティーゾーン (AZ) 間の分散状態を共有します。
クラスターデプロイでは、Amazon MQ がブローカーポリシーを自動的に管理してすべてのノードでクラシックミラーリングを有効にするため、高可用性 (HA) が確保されます。ミラーされたキューはそれぞれ、1 つの*メイン*ノードと、1 つ、または複数の*ミラー*で構成されます。各キューには独自のメインノードがあります。所定のキューに対するすべての操作は、まずキューのメインノードに適用されてから、ミラーに伝播されます。Amazon MQ は、`ha-mode ` を `all`、および `ha-sync-mode` を `automatic` に設定するデフォルトのシステムポリシーを作成します。これは、より優れた耐久性のために、異なるアベイラビリティーゾーンにまたがるクラスター内のすべてのノードにデータがレプリケートされることを確実にします。
**注記**
クラスターデプロイでアベイラビリティーゾーンの停止が発生した場合、Amazon MQ はクラスターサイズを維持するために、影響を受けた RabbitMQ ノードを別の AZ に自動的に再配置しようとします。停止が解決すると、クラスターは AZ 全体で自動的に再調整されます。
**注記**
*メンテナンスウィンドウ*中、クラスターに対するメンテナンスはすべて一度に 1 ノードずつ実行されるので、少なくとも 2 つのノードが常に実行され続けます。ノードへのクライアント接続は、ノードがダウンするたびに切断され、再確立されなければなりません。クライアントコードが、クラスターに自動的に再接続するように設計されていることを確認する必要があります。接続リカバリの詳細については、「[ステップ 1: ネットワーク障害から自動的に回復する](best-practices-network-resilience.md#automatically-recover-from-network-failures)」を参照してください。
Amazon MQ は `ha-sync-mode: automatic` を設定するため、メンテナンスウィンドウ中、各ノードがクラスターに再参加するときにキューが同期されます。キューの同期は、その他すべてのキュー操作をブロックします。メンテナンスウィンドウ中におけるキューの同期の影響は、キューを短くしておくことによって軽減できます。
デフォルトポリシーは削除しないようにしてください。このポリシーを削除しても、Amazon MQ によって自動的に再作成されます。また、Amazon MQ は、クラスターブローカーで作成するその他すべてのポリシーに HA プロパティが適用されることも確実にします。HA プロパティのないポリシーを追加すると、Amazon MQ がそれらのプロパティを追加します。異なる高可用性プロパティを持つポリシーを追加すると、Amazon MQ がプロパティを置き換えます。クラシックミラーリングの詳細については、「[Classic mirrored queues](https://www.rabbitmq.com/ha.html)」を参照してください。
以下の図は、それぞれが独自の Amazon EBS ボリュームと共有状態を持つ 3 つのアベイラビリティーゾーン (AZ) 内に 3 つのノードがある RabbitMQ クラスターブローカーデプロイを示しています。Amazon EBS は、低レイテンシーと高スループット向けに最適化されたブロックレベルのストレージを提供します。
![\[RabbitMQ ブローカー向けのクラスターデプロイのブローカーアーキテクチャを示しています。\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/amazon-mq-rabbitmq-broker-architecture-cluster-broker.png)
# Amazon MQ for RabbitMQ ブローカーのインスタンスタイプ
ブローカーインスタンスクラス (m7g) とサイズ (large、medium) を組み合わせた説明は、ブローカーインスタンスタイプ (mq.m7g.large など) と呼ばれます。
クラスターデプロイと単一インスタンスデプロイの両方に mq.m7g インスタンスタイプを使用することをお勧めします。
Amazon MQ は、インスタンスタイプがサポート終了に達する少なくとも 90 日前に通知を送信します。中断を防ぐために、サポート終了日より前にブローカーを新しいインスタンスタイプにアップグレードすることをお勧めします。
**重要**
ブローカーを `mq.m7g`または `mq.m5`インスタンスタイプから`mq.t3.micro`インスタンスタイプにダウングレードすることはできません。
`mq.t3.micro` インスタンスタイプはクラスターのデプロイをサポートしていません。
## m7g クラスターデプロイのインスタンスタイプ
クラスターデプロイで `mq.m7g.x` インスタンスタイプを使用することをお勧めします。次の表は、クラスターデプロイで使用可能な `mq.m7g.x` インスタンスタイプを示しています。
| インスタンスタイプ | vCPU | メモリ (GiB) | ネットワークベースライン/バースト帯域幅 (Gbps) | 推奨用途 | Storage | ノードあたりのディスクボリュームサイズ (GB) |
| --- | --- | --- | --- | --- | --- | --- |
| mq.m7g.medium | 1 | 4 | 0.52 / 12.5 | 評価 | EBS | 5 |
| mq.m7g.large | 2 | 8 | 0.937/12.5 | 本番稼働 | EBS | 15 |
| mq.m7g.xlarge | 4 | 16 | 1.876 / 12.5 | 本番稼働 | EBS | 25 |
| mq.m7g.2xlarge | 8 | 32 | 3.75/15.0 | 本番稼働 | EBS | 45 |
| mq.m7g.4xlarge | 16 | 64 | 7.5/15.0 | 本番稼働 | EBS | 90 |
| mq.m7g.8xlarge | 32 | 128 | 15 ギガビット | 本番稼働 | EBS | 175 |
| mq.m7g.12xlarge | 48 | 192 | 22.5 ギガビット | 本番稼働 | EBS | 260 |
| mq.m7g.16xlarge | 64 | 256 | 30 ギガビット | 本番稼働 | EBS | 345 |
## m7g 単一インスタンスデプロイのインスタンスタイプ
次の表は、単一インスタンスのデプロイで使用可能な `mq.m7g.x` インスタンスタイプを示しています。
| インスタンスタイプ | vCPU | メモリ (GiB) | ネットワークベースライン/バースト帯域幅 (Gbps) | 推奨用途 | Storage | ノードあたりのディスクボリュームサイズ (GB) |
| --- | --- | --- | --- | --- | --- | --- |
| mq.m7g.medium | 1 | 4 | 0.52 / 12.5 | 評価 | EBS | 200 |
| mq.m7g.large | 2 | 8 | 0.937/12.5 | 本番稼働 | EBS | 200 |
| mq.m7g.xlarge | 4 | 16 | 1.876 / 12.5 | 本番稼働 | EBS | 200 |
| mq.m7g.2xlarge | 8 | 32 | 3.75/15.0 | 本番稼働 | EBS | 200 |
| mq.m7g.4xlarge | 16 | 64 | 7.5/15.0 | 本番稼働 | EBS | 200 |
| mq.m7g.8xlarge | 32 | 128 | 15 ギガビット | 本番稼働 | EBS | 200 |
| mq.m7g.12xlarge | 48 | 192 | 22.5 ギガビット | 本番稼働 | EBS | 200 |
| mq.m7g.16xlarge | 64 | 256 | 39 ギガビット | 本番稼働 | EBS | 200 |
## `mq.m5` 単一インスタンスデプロイのインスタンスタイプ
次の表は、単一インスタンスデプロイで使用可能な `mq.m5.x` インスタンスタイプを示しています。
| インスタンスタイプ | vCPU | メモリ (GiB) | ネットワークベースライン/バースト帯域幅 (Gbps) | 推奨用途 | Storage | ノードあたりのディスクボリュームサイズ (GB) |
| --- | --- | --- | --- | --- | --- | --- |
| mq.t3.micro | 2 | 1 | 0.064 / 5.0 | 評価 | EBS | 20 |
| mq.m5.large | 2 | 8 | 0.75 / 10.0 | 本番稼働 | EBS | 200 |
| mq.m5.xlarge | 4 | 16 | 1.25 / 10.0 | 本番稼働 | EBS | 200 |
| mq.m5.2xlarge | 8 | 32 | 2.5 / 10.0 | 本番稼働 | EBS | 200 |
| mq.m5.4xlarge | 16 | 64 | 5.0 / 10.0 | 本番稼働 | EBS | 200 |
## `mq.m5` クラスターデプロイのインスタンスタイプ
次の表は、クラスターデプロイで使用可能な `mq.m5.x` インスタンスタイプを示しています。
| インスタンスタイプ | vCPU | メモリ (GiB) | ネットワークベースライン/バースト帯域幅 (Gbps) | 推奨用途 | Storage | ノードあたりのディスクボリュームサイズ (GB) |
| --- | --- | --- | --- | --- | --- | --- |
| mq.m5.large | 2 | 8 | 0.75 / 10.0 | 本番稼働 | EBS | 200 |
| mq.m5.xlarge | 4 | 16 | 1.25 / 10.0 | 本番稼働 | EBS | 200 |
| mq.m5.2xlarge | 8 | 32 | 2.5 / 10.0 | 本番稼働 | EBS | 200 |
| mq.m5.4xlarge | 16 | 64 | 5.0 / 10.0 | 本番稼働 | EBS | 200 |
# Amazon MQ for RabbitMQ のサイズ設定ガイドライン
アプリケーションに最適なブローカーインスタンスタイプを選択できます。インスタンスタイプを選択するときは、ブローカーのパフォーマンスに影響する要因を考慮してください。
+ クライアントとキューの数
+ 送信されるメッセージの量
+ メモリに保持されるメッセージ
+ 冗長メッセージ
小規模なブローカーインスタンスタイプ`m7g.medium`は、アプリケーションパフォーマンスのテストにのみ推奨されます。より大きいブローカーインスタンスタイプ`m7g.large`以上、または本番稼働レベルのクライアントとキュー、高スループット、メモリ内のメッセージ、冗長メッセージをお勧めします。
**重要**
ブローカーを `mq.m5`または `mq.m7g`インスタンスタイプから `mq.t3.micro`インスタンスタイプにダウングレードすることはできません。
ブローカーをテストして、ワークロードのメッセージング要件に適したインスタンスタイプとサイズを決定することが重要です。
RabbitMQ 4 ブローカーのデフォルトのリソース制限を常に使用して、Amazon MQ のベストプラクティスに従ってアプリケーションに適したインスタンスサイズを決定します。これらのデフォルトのリソース制限は、`m7g`インスタンスタイプとクォーラムキューのタイプに基づいています。
+ [m7g 単一インスタンスデプロイのデフォルトのリソース制限](rabbitmq-resource-limits-configuration.md#default-values-single-instance)
+ [m7g クラスターデプロイのデフォルトのリソース制限](rabbitmq-resource-limits-configuration.md#default-values-cluster-brokers)
任意の制限の値は、インスタンスタイプとデプロイモードによって定義された最大値まで増やすことができます。ただし、本番環境で を使用する前に、値を増やしてブローカーのパフォーマンスをテストすることを強くお勧めします。
+ [m7g 単一インスタンスデプロイの最大リソース制限](rabbitmq-resource-hard-limit.md#sizing-guidelines-m7g-single-instance)
+ [m7g クラスターデプロイの最大リソース制限](rabbitmq-resource-hard-limit.md#sizing-guidelines-m7g-cluster)
+ [m5 単一インスタンスデプロイの最大リソース制限](rabbitmq-resource-hard-limit.md#sizing-guidelines-single-instance)
+ [m5 クラスターデプロイの最大リソース制限](sizing-guidelines-cluster.md)
+ [エラーメッセージ](rabbitmq-resource-hard-limit.md#sizing-guidelines-limits-error-messages)
**注記**
RabbitMQ 3.13 ブローカーにはデフォルトのリソース制限はありませんが、推奨されるデフォルトを使用することをお勧めします。
# デフォルトのリソース制限
Amazon MQ for RabbitMQ は、RabbitMQ 4 以降のブローカーリソース制限の設定をサポートしています。ブローカーを作成すると、Amazon MQ はこれらのリソース制限にデフォルト値を自動的に適用します。これらのデフォルトは、一般的な顧客使用パターンに対応しながらブローカーの可用性を保護するためのガードレールとして機能します。特定のワークロード要件に合わせて制限設定値を変更することで、ブローカーの動作をカスタマイズできます。
変更を行う前に、次の点に注意してください。
**重要**
設定の変更はブローカーのパフォーマンスと可用性に影響を与える可能性があります
デフォルト設定オプションを変更する前に影響を理解する
非本番環境で最初に設定変更をテストする
変更を適用した後でブローカーの状態をモニタリングする
**重要**
これらの設定でサポートされているデフォルト値と範囲は、RabbitMQ のバージョン、インスタンスタイプ、ブローカーデプロイモードによって異なります。
**重要**
* 注: サポートされている範囲外の設定値を持つブローカーを関連付けたり作成したりすると、エラーレスポンスが発生します。 *
ブローカーのこれらのデフォルトのリソース制限をカスタマイズする方法については、「」を参照してください[リソース制限の設定](configure-resource-limits.md)。
RabbitMQ 4.2 ブローカーに適用されるデフォルトのリソース制限は次のとおりです。
+ [m7g 単一インスタンスデプロイのデフォルトのリソース制限](#default-values-single-instance)
+ [m7g クラスターデプロイのデフォルトのリソース制限](#default-values-cluster-brokers)
## デフォルトのリソース制限
**重要**
Amazon MQ for RabbitMQ 3 ブローカーの場合、デフォルトは最大リソース制限で設定され、Amazon MQ はリソース制限設定を上書きする機能を提供しません。
### 単一インスタンスブローカーのデフォルト値
| インスタンスタイプ | ノードあたりの接続数 | ノードあたりのチャネル数 | チャネルあたりのコンシューマー | [キュー] | vhosts | シャベル | 交換 | バイト単位のメッセージサイズ |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| mq.m7g.medium | 100 | 500 | 10 | 500 | 10 | 30 | 500 | 524288 |
| mq.m7g.large | 1,500 | 4,500 | 10 | 1,000 | 50 | 50 | 1,000 | 524288 |
| mq.m7g.xlarge | 3,000 | 9,000 | 10 | 2,000 | 100 | 100 | 2,000 | 524288 |
| mq.m7g.2xlarge | 6,000 | 18,000 | 10 | 4,000 | 150 | 200 | 4,000 | 524288 |
| mq.m7g.4xlarge | 12,000 | 36,000 | 10 | 8,000 | 200 | 400 | 8,000 | 524288 |
| mq.m7g.8xlarge | 24,000 | 72,000 | 10 | 16,000 | 250 | 800 | 16,000 | 524288 |
| mq.m7g.12xlarge | 36,000 | 108,000 | 10 | 24,000 | 300 | 1,200 | 24,000 | 524288 |
| mq.m7g.16xlarge | 48,000 | 144,000 | 10 | 32,000 | 350 | 1,600 | 32,000 | 524288 |
### クラスターブローカーのデフォルト値
| インスタンスタイプ | ノードあたりの接続数 | ノードあたりのチャネル数 | チャネルあたりのコンシューマー | [キュー] | vhosts | シャベル | 交換 | バイト単位のメッセージサイズ |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| mq.m7g.medium | 100 | 300 | 10 | 100 | 10 | 10 | 100 | 524288 |
| mq.m7g.large | 500 | 1500 | 10 | 1,000 | 50 | 30 | 1,000 | 524288 |
| mq.m7g.xlarge | 1,000 | 3000 | 10 | 2,000 | 100 | 60 | 2,000 | 524288 |
| mq.m7g.2xlarge | 2000 | 6000 | 10 | 4,000 | 150 | 120 | 4,000 | 524288 |
| mq.m7g.4xlarge | 4000 | 12,000 | 10 | 8,000 | 200 | 240 | 8,000 | 524288 |
| mq.m7g.8xlarge | 8000 | 24,000 | 10 | 16,000 | 250 | 480 | 16,000 | 524288 |
| mq.m7g.12xlarge | 12000 | 36,000 | 10 | 24,000 | 300 | 720 | 24000 | 524288 |
| mq.m7g.16xlarge | 16,000 | 48,000 | 10 | 32,000 | 350 | 960 | 32,000 | 524288 |
# Amazon MQ for RabbitMQ の最大リソース制限
リソース制限は、次の表に示す最大値まで設定できます。ブローカーのリソース制限を更新する方法については、「」を参照してください[リソース制限の設定](configure-resource-limits.md)。
## 単一インスタンスデプロイのクォーラムキューを使用する m7g のサイズ設定ガイドライン
次の表は、単一インスタンスブローカーの各インスタンスタイプの**上限**値を示しています。
| インスタンスタイプ | Connections | チャンネル | チャネルあたりのコンシューマー | [キュー] | Vhost | シャベル | 交換 | バイト単位のメッセージサイズ |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| mq.m7g.medium | 300 | 900 | 1,000 | 2,500 | 10 | 150 | 12500 | 134217728 |
| mq.m7g.large | 5,000 | 15,000 | 1,000 | 20,000 | 1500 | 250 | 100,000 | 134217728 |
| mq.m7g.xlarge | 10,000 | 30,000 | 1,000 | 30,000 | 1,500 | 500 | 150,000 | 134217728 |
| mq.m7g.2xlarge | 20,000 | 60,000 | 1,000 | 40,000 | 1,500 | 1,000 | 200,000 件の | 134217728 |
| mq.m7g.4xlarge | 40,000 | 120,000 | 1,000 | 60,000 | 1,500 | 2000 | 300,000 | 134217728 |
| mq.m7g.8xlarge | 80,000 | 240,000 | 1,000 | 80,000 | 1,500 | 4000 | 400,000 | 134217728 |
| mq.m7g.12xlarge | 120,000 | 360,000 | 1,000 | 100,000 | 1,500 | 6,000 | 500,000 | 134217728 |
| mq.m7g.16xlarge | 160,000 | 480,000 | 1,000 | 120,000 | 1,500 | 8,000 | 600,000 | 134217728 |
## クラスターデプロイのクォーラムキューを使用した m7g のサイズ設定ガイドライン
次の表は、クラスターブローカーの各インスタンスタイプの**上限**値を示しています。
| インスタンスタイプ | ノードあたりの接続数 | ノードあたりのチャネル数 | チャネルあたりのコンシューマー | [キュー] | Vhost | シャベル | 交換 | バイト単位のメッセージサイズ |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| mq.m7g.medium | 300 | 900 | 1,000 | 500 | 10 | 50 | 500 | 134217728 |
| mq.m7g.large | 5,000 | 15,000 | 1,000 | 10,000 | 1,500 | 150 | 50,000 | 134217728 |
| mq.m7g.xlarge | 10,000 | 30,000 | 1,000 | 15,000 | 1,500 | 300 | 75,000 | 134217728 |
| mq.m7g.2xlarge | 20,000 | 60,000 | 1,000 | 20,000 | 1,500 | 600 | 100,000 | 134217728 |
| mq.m7g.4xlarge | 40,000 | 120,000 | 1,000 | 30,000 | 1,500 | 1200 | 150,000 | 134217728 |
| mq.m7g.8xlarge | 80,000 | 240,000 | 1,000 | 40,000 | 1,500 | 2,400 | 200,000 件の | 134217728 |
| mq.m7g.12xlarge | 120,000 | 360,000 | 1,000 | 50,000 | 1,500 | 3,600 | 250,000 | 134217728 |
| mq.m7g.16xlarge | 160,000 | 480,000 | 1,000 | 60,000 | 1,500 | 4,800 | 300,000 | 134217728 |
## M5 単一インスタンスデプロイの最大リソース制限
次の表は、単一インスタンスブローカーの各インスタンスタイプの**上限**値を示しています。
| インスタンスタイプ | Connections | チャンネル | チャネルあたりのコンシューマー | [キュー] | Vhost | シャベル |
| --- | --- | --- | --- | --- | --- | --- |
| m5.large | 5,000 | 15,000 | 1,000 | 30,000 | 1500 | 250 |
| m5.xlarge | 10,000 | 30,000 | 1,000 | 60,000 | 1500 | 500 |
| m5.2xlarge | 20,000 | 60,000 | 1,000 | 120,000 | 1500 | 1,000 |
| m5.4xlarge | 40,000 | 120,000 | 1,000 | 240,000 | 1,000 | 2,000 |
# m5 クラスターデプロイの最大リソース制限
次の表は、クラスターブローカーの各インスタンスタイプの**上限**値を示しています。
| インスタンスタイプ | [キュー] | チャネルあたりのコンシューマー | シャベル |
| --- | --- | --- | --- |
| m5.large | 10,000 | 1,000 | 150 |
| m5.xlarge | 15,000 | 1,000 | 300 |
| m5.2xlarge | 20,000 | 1,000 | 600 |
| m5.4xlarge | 30,000 | 1,000 | 1200 |
ノードごとに以下の接続とチャネルの制限が適用されます。
| インスタンスタイプ | Connections | チャンネル |
| --- | --- | --- |
| m5.large | 5000 | 15,000 |
| m5.xlarge | 10,000 | 30,000 |
| m5.2xlarge | 20,000 | 60,000 |
| m5.4xlarge | 40,000 | 120,000 |
クラスターブローカーの正確な制限値は、利用可能なノードの数と、利用可能なノード間で RabbitMQ がどのようにリソースを分散するかに応じて、示されている値よりも低くなる場合があります。制限値を超えた場合は、別のノードへの新しい接続を作成して再試行するか、インスタンスのサイズをアップグレードして最大制限を増やすことができます。
## エラーメッセージ
制限を超えると、以下のエラーメッセージが返されます。すべての値は、**m7.large** の単一インスタンスの制限が基になっています。
**注記**
以下のメッセージのエラーコードは、使用しているクライアントライブラリによって異なる場合があります。
**Connection**
`ConnectionClosedByBroker 500 "NOT_ALLOWED - connection refused: node connection limit (5000) is reached"`
**[チャネル]**
`ConnectionClosedByBroker 1500 "NOT_ALLOWED - number of channels opened on node 'rabbit@ip-10-0-23-173.us-west-2.compute.internal' has reached the maximum allowed limit of (15,000)"`
**コンシューマー**
`ConnectionClosedByBroker: (530, 'NOT_ALLOWED - reached maximum (1,000) of consumers per channel')`
**メッセージの最大サイズ **
` (406, 'PRECONDITION_FAILED - message size 524289 is larger than configured max size 524288') `
**Exchange**
` (406, "PRECONDITION_FAILED - cannot declare exchange 'limit_test_3' in vhost '/': exchange limit of 10 is reached") `
**注記**
次のエラーメッセージは、HTTP 管理 API 形式を使用します。
**[キュー]**
`{"error":"bad_request","reason":"cannot declare queue 'my_queue': queue limit in cluster (10,000) is reached"}]`
**シャベル**
`{"error":"bad_request","reason":"Validation failed\n\ncomponent shovel is limited to 150 per node\n"}`
**Vhost**
`{"error":"bad_request","reason":"cannot create vhost 'my_vhost': vhost limit of 1500 is reached"}`
# Amazon MQ for RabbitMQ のブローカーデフォルト
Amazon MQ for RabbitMQ ブローカーを作成するときは、ブローカーのパフォーマンスを最適化するために、Amazon MQ がブローカーポリシーと vhost 制限のデフォルトセットを適用します。Amazon MQ が vhost 制限を適用するのは、デフォルト (`/`) vhost のみです。Amazon MQ は、新しく作成された vhost にデフォルトポリシーを適用しません。すべての新規および既存のブローカーに対してこれらのデフォルトを維持することが推奨されますが、これらのデフォルトはいつでも変更、上書き、または削除できます。
Amazon MQ は、Amazon MQ for RabbitMQ 3 と RabbitMQ 4 に対して異なるブローカーポリシーと vhost 制限を作成します。 RabbitMQ 相違点については、以下のサブセクションで詳しく説明します。
Amazon MQ は、ブローカーの作成時に選択されたインスタンスタイプとブローカーデプロイモードに基づいてポリシーと制限を作成します。デフォルトポリシーの名前は、以下のように、デプロイモードに従って命名されます。
**Amazon MQ for RabbitMQ 3:**
+ **単一インスタンス** – `AWS-DEFAULT-POLICY-SINGLE-INSTANCE`
+ **クラスターのデプロイ** – `AWS-DEFAULT-POLICY-CLUSTER-MULTI-AZ` && `AWS-DEFAULT-QUORUM-QUEUES-POLICY-CLUSTER-MULTI-AZ`
**Amazon MQ for RabbitMQ 4:**
+ **単一インスタンス** – `AWS-DEFAULT-POLICY-SINGLE-INSTANCE`
+ **クラスターのデプロイ** – `AWS-DEFAULT-POLICY-CLUSTER` && `AWS-DEFAULT-QUORUM-QUEUES-POLICY-CLUSTER-MULTI-AZ`
[単一インスタンスブローカー](rabbitmq-broker-architecture.md#rabbitmq-broker-architecture-single-instance)の場合、Amazon MQ はポリシーの優先順位値を `0` に設定します。デフォルトの優先順位値を上書きするには、より高い優先順位値を持つ独自のカスタムポリシーを作成することができます。[クラスターデプロイ](rabbitmq-broker-architecture.md#rabbitmq-broker-architecture-cluster)の場合、Amazon MQ はブローカーデフォルトに対して優先順位値を `1` に設定します。クラスター用に独自のカスタムポリシーを作成するには、`1` を超える優先順位値を割り当てます。
**注記**
クラシックミラーリングと高可用性 (HA) のため、クラスターデプロイでは `ha-mode` および `ha-sync-mode` のブローカーポリシーが必要になります。これらの設定は Amazon MQ for RabbitMQ 3 にのみ適用され、RabbitMQ 4 には設定されません。
デフォルトの `AWS-DEFAULT-POLICY-CLUSTER-MULTI-AZ` ポリシーを削除する場合、Amazon MQ は優先順位値が `0` の `ha-all-AWS-OWNED-DO-NOT-DELETE` ポリシー使用します。これは、必要な `ha-mode` および `ha-sync-mode` ポリシーが引き続き有効であることを確実にします。独自のカスタムポリシーを作成する場合、Amazon MQ はポリシー定義に `ha-mode` および `ha-sync-mode` を自動的に付加します。
**Topics**
+ [
## ポリシーと制限の説明
](#rabbitmq-defaults-descriptions)
+ [
## 推奨されるデフォルト値
](#rabbitmq-defaults-values)
## ポリシーと制限の説明
以下のリストには、新しく作成されたブローカーに Amazon MQ が適用するデフォルトのポリシーと制限の説明があります。`max-length`、`max-queues`、および `max-connections` の値は、ブローカーのインスタンスタイプとデプロイモードに応じて異なります。これらの値は、[推奨されるデフォルト値](#rabbitmq-defaults-values) セクションにリストされています。
**RabbitMQ 3 ブローカーと RabbitMQ 4 ブローカーの両方の設定**
+ **`queue-mode: lazy`** (ポリシー) – レイジーキューを有効にします。デフォルトで、キューはメッセージのインメモリキャッシュを保持し、ブローカーがコンシューマーにメッセージを可能な限り速く配信できるようにします。これは、ブローカーのメモリが不足し、高メモリアラームが発生する原因になる場合があります。レイジーキューは、現実的な範囲でできる限り早急にメッセージをディスクに移動しようとします。つまり、通常の動作条件下では、メモリに保持されるメッセージはそれほど多くないということです。レイジーキューを使用することにより、RabbitMQ for Amazon MQ は、はるかに大きなメッセージング負荷とはるかに長いキューをサポートできます。特定のユースケースでは、レイジーキューを使用するブローカーのパフォーマンスがわずかに遅くなる可能性があることに注意してください。これは、メッセージがインメモリキャッシュから配信されるのではなく、ディスクからブローカーに移動されるためです。
**デプロイモード**
単一インスタンス、クラスター
+ **`max-length: number-of-messages`** (ポリシー) – キュー内のメッセージ数に対する制限を設定します。クラスターデプロイでは、この制限が、ブローカーの再起動やメンテナンスウィンドウの後などにキューの同期が一時停止されることを防ぎます。
**デプロイモード**
クラスター
+ **`overflow: reject-publish`** (ポリシー) – キュー内の数が `max-length` 値に達した後、`max-length` ポリシーを持つキューが新しいメッセージを拒否するようにします。キューがオーバーフロー状態になった場合にメッセージが失われないようにするには、ブローカーにメッセージを発行するクライアントアプリケーションが[パブリッシャー確認](best-practices-message-reliability.md#configure-confirmation-acknowledgement)を実装する必要があります。パブリッシャー確認の実装の詳細については、RabbitMQ ウェブサイトの「[Publisher Confirms](https://www.rabbitmq.com/confirms.html#publisher-confirms)」を参照してください。
**デプロイモード**
クラスター
**RabbitMQ 3 に固有の設定**
+ **`max-queues: number-of-queues-per-vhost`** (vhost 制限) – ブローカー内のキューの数に対する制限を設定します。`max-length` ポリシー定義と同様に、クラスターデプロイ内のキュー数の制限は、ブローカーの再起動やメンテナンスウィンドウの後などにキューの同期が一時停止されることを防ぎます。キューの制限は、キューを維持するための過剰な CPU 量の使用も防ぎます。
**デプロイモード**
単一インスタンス、クラスター
+ **`max-connections: number-of-connections-per-vhost`** (vhost 制限) – ブローカーへのクライアント接続数に対する制限を設定します。推奨される値に従って接続数を制限すると、ブローカーがメモリアラームを発し、操作を一時停止させる原因となり得るブローカーメモリの過剰な使用を防ぎます。
**デプロイモード**
単一インスタンス、クラスター
## 推奨されるデフォルト値
**重要**
`max-queues` と `max-connections`は、Amazon MQ for RabbitMQ 3 にのみ適用されます。
**注記**
`max-length` および `max-queue` のデフォルト制限は、5 kB の平均メッセージサイズに基づいてテストおよび評価されます。メッセージが 5 kB を大幅に超える場合は、`max-length` および `max-queue` 制限を調整して低くする必要があります。
以下の表には、新しく作成されたブローカーに対するデフォルト制限値がリストされています。Amazon MQ は、ブローカーのインスタンスタイプとデプロイモードに従ってこれらの値を適用します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/rabbitmq-defaults.html)
| インスタンスタイプ | デプロイモード | `max-length` | `max-queues` | `max-connections` |
| --- | --- | --- | --- | --- |
| t3.micro | 単一インスタンス | 該当なし | 500 | 500 |
| m5.large | 単一インスタンス | 該当なし | 20,000 | 4,000 |
| m5.large | クラスター | 8,000,000 | 10,000 | 15,000 |
| m5.xlarge | 単一インスタンス | 該当なし | 30,000 | 8,000 |
| m5.xlarge | クラスター | 9,000,000 | 10,000 | 20,000 |
| m5.2xlarge | 単一インスタンス | 該当なし | 60,000 | 15,000 |
| m5.2xlarge | クラスター | 10,000,000 | 10,000 | 40,000 |
| m5.4xlarge | 単一インスタンス | 該当なし | 150,000 | 30,000 |
| m5.4xlarge | クラスター | 12,000,000 | 10,000 | 100,000 |
# RabbitMQ ブローカーの設定
設定には、Cuttlefish 形式の RabbitMQ ブローカーのすべての設定が含まれます。設定は、ブローカーを作成する前に作成することができます。作成後、設定を 1 つ、または複数のブローカーに適用できます。
## 属性
ブローカー設定には複数の属性があります。次に例を示します。
+ 名前 (MyConfiguration)
+ ID (c-1234a5b6-78cd-901e-2fgh-3i45j6k178l9)
+ Amazon リソースネーム (ARN) (arn:aws:mq:us-east-2:123456789012:configuration:c-1234a5b678cd-901e-2fgh-3i45j6k178l9)
設定属性の完全なリストについては、Amazon MQ REST API リファレンスで以下を参照してください。
+ [REST オペレーション ID: 設定](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/rest-api-configuration.html)
+ [REST オペレーション ID: 設定](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/rest-api-configurations.html)
設定のリビジョン属性の詳細なリストについては、以下を参照してください。
+ [REST オペレーション ID: 設定のリビジョン](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/rest-api-configuration-revision.html)
+ [REST オペレーション ID: 設定のリビジョン](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/rest-api-configuration-revisions.html)
トピック
+ [RabbitMQ ブローカー設定の作成と適用](rabbitmq-creating-applying-configurations.md)
+ [Amazon MQ for RabbitMQ 設定リビジョンを編集する](edit-current-rabbitmq-configuration-console.md)
+ [Amazon MQ での RabbitMQ の設定可能な値 Amazon MQ](configurable-values.md)
+ [RabbitMQ 設定での ARN サポート](arn-support-rabbitmq-configuration.md)
# RabbitMQ ブローカー設定の作成と適用
*configuration* には、ActiveMQ ブローカーのすべての設定が Cuttlefish 形式で含まれています。設定は、ブローカーを作成する前に作成することができます。次に、設定を 1 つ以上のブローカーに適用できます。
以下の例では、 AWS マネジメントコンソールを使用して Amazon MQ ブローカーの設定を作成および適用する方法を示します。
**重要**
設定は `DeleteConfiguration` API を使用してのみ**削除**できます。詳細については、「*Amazon MQ API リファレンス*」の「[設定](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/configurations-configuration-id.html)」を参照してください。
## 新しい設定の作成
設定をブローカーに適用するには、まず設定を作成する必要があります。
1. [Amazon MQ コンソール](https://console.aws.amazon.com/amazon-mq/)にサインインします。
1. 左側のナビゲーションパネルを展開し、[**設定**] を選択します。
![\[Amazon MQ navigation panel showing Brokers and Configurations options.\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/amazon-mq-tutorials-create-configuration.png)
1. [**設定**] ページで、[**Create configuration (設定の作成)**] を選択します。
1. **[設定の作成]** ページの **[詳細]** セクションで **[設定名]** (`MyConfiguration` など) を入力し、**[ブローカーエンジン]** のバージョンを選択します。
Amazon MQ for ActiveMQ がサポートする RabbitMQ エンジンバージョンの詳細については、「[Amazon MQ for RabbitMQ エンジンバージョンの管理](rabbitmq-version-management.md)」を参照してください。
1. **[設定を作成]** を選択します。
## 新しい設定リビジョンの作成
設定を作成したら、設定リビジョンを使用して設定を編集する必要があります。
1. 設定リストから、[***MyConfiguration***] を選択します。
**注記**
設定の最初のリビジョンは常に、Amazon MQ が設定を作成するときに作成されます。
**[*MyConfiguration*]** ページに、新しい設定リビジョンが使用するブローカーのエンジンタイプとバージョン (例: **RabbitMQ 3.xx.xx**) が表示されます。
1. **[設定の詳細]** タブに、設定リビジョン番号、説明、およびブローカー設定が Cuttlefish 形式で表示されます。
**注記**
現在の設定を編集すると、設定の新しいリビジョンが作成されます。
1. **[設定の編集]** を選択して、Cuttlefish 設定を変更します。
1. **[保存]** を選択します。
[**Save revision**] (リビジョンの保存) ダイアログボックスが表示されます。
1. (オプション) `A description of the changes in this revision` を入力します。
1. **[保存]** を選択します。
設定の新しいリビジョンが保存されます。
**重要**
設定を変更しても、その変更はブローカーに直ちに適用*されません*。変更を適用するには、次のメンテナンスウィンドウまで待機するか、[ブローカーを再起動](amazon-mq-rebooting-broker.md)する必要があります。
現在、設定を削除することはできません。
## 設定リビジョンをブローカーに適用する
設定リビジョンを作成したら、設定リビジョンをブローカーに適用できます。
1. 左側のナビゲーションパネルを展開し、[**Brokers (ブローカー)**] を選択します。
![\[Amazon MQ navigation panel showing Brokers and Configurations options.\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/amazon-mq-tutorials-apply-configuration.png)
1. ブローカーリストからブローカーを選択して (**MyBroker** など)、[**Edit**] (編集) をクリックします。
1. [**Edit *MyBroker***] (MyBroker の編集) ページの [**Configuration**] (設定) セクションで [**Configuration**] (設定) と [**Revision**] (リビジョン) を選択してから、[**Schedule Modifications**] (変更をスケジュールする) をクリックします。
1. [**ブローカー変更のスケジュール**] セクションで、変更を [**次回のスケジュールされたメンテナンスウィンドウ中**] に適用するか、[**即時**] 適用するかを選択します。
**重要**
再起動中、シングルインスタンスブローカーはオフラインになります。クラスターブローカーの場合、ブローカーの再起動中にダウンするノードは 1 つだけです。
1. [**Apply**] (適用) をクリックします。
設定リビジョンが指定された時刻にブローカーに適用されます。
# Amazon MQ for RabbitMQ 設定リビジョンの編集
以下の手順では、ブローカーの設定リビジョンを編集する方法について説明します。
1. [Amazon MQ コンソール](https://console.aws.amazon.com/amazon-mq/)にサインインします。
1. ブローカーリストからブローカーを選択して (**MyBroker** など)、[**Edit**] (編集) をクリックします。
1. [***MyBroker***] ページで、[**編集**] を選択します。
1. [**Edit *MyBroker***] (MyBroker の編集) ページの [**Configuration**] (設定) セクションで [**Configuration**] (設定) と [**Revision**] (リビジョン) を選択してから、[**Edit**] (変更) をクリックします。
**注記**
ブローカーの作成時に設定を選択する場合を除き、最初のリビジョンは、常に Amazon MQ がブローカーを作成する時に作成されます。
**[*MyBroker*]** ページに、設定が使用するブローカーのエンジンタイプとバージョン (**RabbitMQ 3.xx.xx** など) が表示されます。
1. **[設定の詳細]** タブに、設定リビジョン番号、説明、およびブローカー設定が Cuttlefish 形式で表示されます。
**注記**
現在の設定を編集すると、設定の新しいリビジョンが作成されます。
1. **[設定の編集]** を選択して、Cuttlefish 設定を変更します。
1. **[保存]** を選択します。
[**Save revision**] (リビジョンの保存) ダイアログボックスが表示されます。
1. (オプション) `A description of the changes in this revision` を入力します。
1. **[保存]** を選択します。
設定の新しいリビジョンが保存されます。
**重要**
設定を変更しても、その変更はブローカーに直ちに適用*されません*。変更を適用するには、次のメンテナンスウィンドウまで待機するか、[ブローカーを再起動](amazon-mq-rebooting-broker.md)する必要があります。
現在、設定を削除することはできません。
# 設定可能な値
AWS マネジメントコンソールでブローカー設定ファイルを変更することで、以下のブローカー設定オプションの値を設定できます。
次の表で説明する値に加えて、Amazon MQ は、認証と認可、およびリソース制限に関連する追加のブローカー設定オプションをサポートしています。これらの設定オプションの詳細については、「」を参照してください。
+ [OAuth 2.0 の設定](configure-oauth2.md)
+ [LDAP 設定](configure-ldap.md)
+ [HTTP 設定](configure-http.md)
+ [SSL 設定](configure-ssl.md)
+ [mTLS 設定](configure-mtls.md)
+ [ARN サポート](arn-support-rabbitmq-configuration.md)
+ [リソースの制限](rabbitmq-resource-limits-configuration.md)
+ [AMQP クライアント SSL 設定](rabbitmq-amqp-client-ssl-configuration.md)
| 設定 | デフォルト値 | 推奨値 | 値 | 適用可能なバージョン | 説明 |
| --- | --- | --- | --- | --- | --- |
| consumer\$1timeout | 1800000 ミリ秒 (30 分) | 1800000 ミリ秒 (30 分) | 0～2,147,483,647 ミリ秒。Amazon MQ は値 0 もサポートしています。これは「無限」を意味します。 | すべてのバージョン | コンシューマーの配信承認のタイムアウト。コンシューマーが配信を受け付けない状況を検出するために使用されます。 |
| heartbeat | 60 秒 | 60 秒 | 60～3600 秒 | すべてのバージョン | RabbitMQ で接続が利用できないと見なされるまでの時間を定義します。 |
| management.restrictions.operator\$1policy\$1changes.disabled | true | true | true、false | すべてのバージョン | オペレーターポリシーへの変更を無効にします。この変更を行う場合は、HA プロパティを独自のオペレーターポリシーに含めることを強くお勧めします。 |
| quorum\$1queue.property\$1equivalence.relaxed\$1checks\$1on\$1redeclaration | true | true | true、false | すべてのバージョン | TRUE に設定すると、アプリケーションはクォーラムキューを再宣言するときのチャネル例外を回避します。 |
| secure.management.http.headers.enabled | true | true | true、false | すべてのバージョン | 変更不可能な HTTP セキュリティヘッダーを有効にします。 |
## コンシューマーの配信承認の設定
consumer\$1timeout を設定して、コンシューマーが配信を受け付けないタイミングを検出できます。コンシューマーがタイムアウト値の時間内に承認を送信しない場合、チャネルは閉じられます。例えば、デフォルト値の 1800000 ミリ秒を使用している場合は、コンシューマーが 1800000 ミリ秒以内に配信承認を送信しないとチャネルが閉じられます。Amazon MQ は値 0 もサポートしています。これは「無限」を意味します。
## ハートビートの設定
ハートビートタイムアウトを設定すると、接続の中断や失敗が発生したときに検出できます。ハートビート値は、接続がダウンと見なされるまでの時間制限を定義します。
## オペレーターポリシーの設定
各仮想ホストのデフォルトのオペレーターポリシーには、以下の推奨される HA プロパティがあります。
```
{
"name": "default_operator_policy_AWS_managed",
"pattern": ".*",
"apply-to": "all",
"priority": 0,
"definition": {
"ha-mode": "all",
"ha-sync-mode": "automatic"
}
}
```
AWS マネジメントコンソール または Management API を介したオペレーターポリシーの変更は、デフォルトでは利用できません。ブローカー設定に次の行を追加することで変更を有効にすることができます。
```
management.restrictions.operator_policy_changes.disabled=false
```
この変更を行う場合は、HA プロパティを独自のオペレーターポリシーに含めることを強くお勧めします。
## キューの宣言時の緩和チェックの設定
クラシックキューをクォーラムキューに移行してもクライアントコードを更新していない場合は、quorum\$1queue.property\$1equivalence.relaxed\$1checks\$1on\$1redeclaration を true に設定することで、クォーラムキューを再宣言するときにチャネル例外を回避できます。
## HTTP セキュリティヘッダーの設定
secure.management.http.headers.enabled 設定では、次の HTTP セキュリティヘッダーが有効になります。
+ [X-Content-Type-Options: nosniff:](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options) ブラウザによるコンテンツスニッフィングの実行を防ぎます。コンテンツスニッフィングは、ウェブサイトのファイル形式を推定するために使用されるアルゴリズムです。
+ [X-Frame-Options: DENY:](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options) 第三者が独自のウェブサイト上のフレームに管理プラグインを埋め込んで他者をだますことを防ぎます。
+ [Strict-Transport-Security: max-age=47304000; includeSubDomains:](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) ウェブサイトとそのサブドメインに接続を行うときに、今後長期間 (1.5 年) にわたって HTTPS を使用するようにブラウザに強制します。
バージョン 3.10 以降で作成された Amazon MQ for RabbitMQ ブローカーは、デフォルトで secure.management.http.headers.enabled が true に設定されます。これらの HTTP セキュリティヘッダーを有効にするには、secure.management.http.headers.enabled を true に設定します。これらの HTTP セキュリティヘッダーをオプトアウトする場合は、secure.management.http.headers.enabled を false に設定します。
# OAuth 2.0 認証と認可の設定
OAuth 2.0 設定オプションとブローカーの OAuth 2.0 認証の設定については、[「サポートされている OAuth 2.0 設定](oauth-for-amq-for-rabbitmq.md#oauth-tutorial-supported-configs)」および[OAuth 2.0 認証と認可の使用](oauth-tutorial.md)」を参照してください。
# LDAP 認証と認可の設定
LDAP 設定オプションとブローカーの LDAP 認証の設定については、[「サポートされている LDAP 設定](ldap-for-amq-for-rabbitmq.md#ldap-supported-configs)」および「」を参照してください[LDAP 認証と認可の使用](rabbitmq-ldap-tutorial.md)。
# HTTP 認証と認可の設定
HTTP 認証設定値とブローカーの HTTP 認証の設定については、[「HTTP 認証と認可](http-for-amq-for-rabbitmq.md)」および「」を参照してください[HTTP 認証と認可の使用](rabbitmq-http-tutorial.md)。
**注記**
HTTP 認証プラグインは、Amazon MQ for RabbitMQ バージョン 4 以降でのみ使用できます。
# SSL 証明書認証の設定
SSL 証明書認証の設定値とブローカーの SSL 証明書認証の設定については、[「SSL 証明書認証](ssl-for-amq-for-rabbitmq.md)」および「」を参照してください[SSL 証明書認証の使用](rabbitmq-ssl-tutorial.md)。
**注記**
SSL 証明書認証プラグインは、Amazon MQ for RabbitMQ バージョン 4 以降でのみ使用できます。
# mTLS の設定
Amazon MQ for RabbitMQ は、さまざまなエンドポイントや外部サービスへの安全な接続のための相互 TLS (mTLS) をサポートしています。mTLS は、クライアントとサーバーの両方に証明書を使用した認証を要求することで、セキュリティを強化します。
**注記**
mTLS のプライベート認証機関の使用は、Amazon MQ for RabbitMQ バージョン 4 以降でのみ使用できます。
**重要**
Amazon MQ for RabbitMQ は、証明書とプライベートキーファイルに対して AWS ARNs の使用を強制します。詳細については、[RabbitMQ 設定の ARN サポート](arn-support-rabbitmq-configuration.md)を参照してください。
**Topics**
+ [
## AMQP エンドポイント
](#mtls-amqp-endpoint)
+ [
## RabbitMQ 管理プラグイン
](#mtls-management-plugin)
+ [
## RabbitMQ OAuth 2.0 プラグイン
](#mtls-oauth2-plugin)
+ [
## RabbitMQ HTTP 認証プラグイン
](#mtls-http-plugin)
+ [
## RabbitMQ LDAP プラグイン
](#mtls-ldap-plugin)
+ [
## AMQP クライアント接続
](#mtls-amqp-client)
## AMQP エンドポイント
AMQP エンドポイントへのクライアント接続に mTLS を設定します。これは SSL 証明書認証で使用されます。サポートされている設定については、「」を参照してください[SSL 証明書認証](ssl-for-amq-for-rabbitmq.md)。
## RabbitMQ 管理プラグイン
RabbitMQ 管理インターフェイスへの接続用に mTLS を設定します。
**注記**
厳格な mTLS は、 管理 API ではサポートされていません。
`aws.arns.management.ssl.cacertfile`
管理インターフェイスに接続するクライアント証明書を検証するための認証機関ファイル。
`management.ssl.verify`
ピア検証モード。サポートされている値: `verify_none`、 `verify_peer`
`management.ssl.depth`
検証のための証明書チェーンの最大深度。
`management.ssl.hostname_verification`
ホスト名検証モード。サポートされている値: `wildcard`、 `none`
以下の SSL 設定値はサポートされていません。
### 完全なリストを表示する
+ `management.ssl.cert`
+ `management.ssl.client_renegotiation`
+ `management.ssl.dh`
+ `management.ssl.dhfile`
+ `management.ssl.fail_if_no_peer_cert`
+ `management.ssl.honor_cipher_order`
+ `management.ssl.honor_ecc_order`
+ `management.ssl.key.RSAPrivateKey`
+ `management.ssl.key.DSAPrivateKey`
+ `management.ssl.key.PrivateKeyInfo`
+ `management.ssl.log_alert`
+ `management.ssl.password`
+ `management.ssl.psk_identity`
+ `management.ssl.reuse_sessions`
+ `management.ssl.secure_renegotiate`
+ `management.ssl.versions.$version`
+ `management.ssl.sni`
## RabbitMQ OAuth 2.0 プラグイン
Amazon MQ から OAuth 2.0 ID プロバイダーへの接続用に mTLS を設定します。サポートされている設定については、「」を参照してください[OAuth 2.0 の認証と認可](oauth-for-amq-for-rabbitmq.md)。
## RabbitMQ HTTP 認証プラグイン
Amazon MQ から HTTP 認証サーバーへの接続に mTLS を設定します。サポートされている設定については、「」を参照してください[HTTP 認証と認可](http-for-amq-for-rabbitmq.md)。
## RabbitMQ LDAP プラグイン
Amazon MQ から LDAP サーバーへの接続用に mTLS を設定します。サポートされている設定については、「」を参照してください[LDAP 認証と認可](ldap-for-amq-for-rabbitmq.md)。
## AMQP クライアント接続
フェデレーションとシャベルで使用される AMQP クライアント接続の TLS ピア検証を設定します。詳細については、[「AMQP クライアント SSL 設定](rabbitmq-amqp-client-ssl-configuration.md)」を参照してください。
**重要**
Amazon MQ は現在、AMQP クライアント接続のクライアント証明書の設定をサポートしていません。そのため、フェデレーションとシャベルは、クライアント証明書認証を必要とする mTLS 対応ブローカーに接続できません。
# リソース制限の設定
Amazon MQ for RabbitMQ は、RabbitMQ 4 以降のブローカーリソース制限の設定をサポートしています。ブローカーを作成すると、Amazon MQ はこれらのリソース制限にデフォルト値を自動的に適用します。これらのデフォルトは、一般的な顧客使用パターンに対応しながらブローカーの可用性を保護するためのガードレールとして機能します。特定のワークロード要件に合わせて制限設定値を変更することで、ブローカーの動作をカスタマイズできます。デフォルトと最大許容値の詳細については、「」を参照してください[Amazon MQ for RabbitMQ のサイズ設定ガイドライン](rabbitmq-sizing-guidelines.md)。
## リソース名と設定キー
| リソース名 | 設定キー |
| --- | --- |
| 接続 | connection\$1max |
| [チャネル] | channel\$1max\$1per\$1node |
| [キュー] | cluster\$1queue\$1limit |
| Vhost | vhost\$1max |
| シャベル | runtime\$1parameters.limits.shovel |
| Exchange | cluster\$1exchange\$1limit |
| チャネルあたりのコンシューマー | consumer\$1max\$1per\$1channel |
| 最大メッセージサイズ (MB) | max\$1message\$1size |
## リソース制限を上書きする方法
Amazon MQ API と Amazon MQ コンソールを使用してリソース制限を上書きできます。
次の例は、 を使用してキュー数のデフォルト制限を上書きする方法を示しています AWS CLI。
```
aws mq update-configuration --configuration-id --data "$(echo "cluster_queue_limit=500" | base64 --wrap=0)"
```
呼び出しが成功すると、設定リビジョンが作成されます。設定を RabbitMQ ブローカーに関連付け、ブローカーを再起動してオーバーライドを適用する必要があります。詳細については、「」を参照してください。 [RabbitMQ Broker Configurations](rabbitmq-broker-configuration-parameters.md)
## リソース制限オーバーライドエラー
ブローカーをサポートされている範囲外の設定値に関連付けたり作成したりすると、次のようなエラーレスポンスが発生します。
```
Configuration Revision N for configuration:cluster_queue_limit has limit: of value: 100000000 larger than maximum allowed limit:5000
```
# RabbitMQ 設定での ARN サポート
Amazon MQ for RabbitMQ は、一部の RabbitMQ 設定の値の AWS ARNs をサポートしています。これは、RabbitMQ コミュニティプラグイン [rabbitmq-aws](https://github.com/amazon-mq/rabbitmq-aws) によって有効になります。このプラグインは Amazon MQ によって開発および保守されており、Amazon MQ によって管理されていないセルフホスト RabbitMQ ブローカーでも使用できます。 Amazon MQ
**重要な考慮事項**
aws プラグインによって取得された解決された ARN 値は、実行時に RabbitMQ プロセスに直接渡されます。RabbitMQ ノードの他の場所には保存されません。
Amazon MQ for RabbitMQ には、設定された ARNs にアクセスするために Amazon MQ が引き受けることができる IAM ロールが必要です。これは、 を設定することによって設定されます`aws.arns.assume_role_arn`。
IAM ロールを含むブローカー設定で CreateBroker または UpdateBroker APIs を呼び出すユーザーには、そのロールに対する `iam:PassRole` アクセス許可が必要です。
IAM ロールは、RabbitMQ ブローカーと同じ AWS アカウントに存在する必要があります。設定内のすべての ARNs は、RabbitMQ ブローカーと同じ AWS リージョンに存在する必要があります。
Amazon MQ は、IAM ロールを引き受ける`aws:SourceArn`ときに IAM グローバル条件キー`aws:SourceAccount`と を追加します。これらの値は、[混乱した代理保護](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)のためにロールにアタッチされた IAM ポリシーで使用する必要があります。
**Topics**
+ [
## サポートされるキー
](#arn-support-supported-keys)
+ [
## IAM ポリシーのサンプル
](#arn-support-iam-policy-samples)
+ [
## アクセス検証
](#arn-support-validation)
+ [
## 関連するブローカーの隔離状態
](#arn-support-quarantine-states)
+ [
## シナリオの例
](#arn-support-example-scenario)
## サポートされるキー
`aws.arns.assume_role_arn`
Amazon MQ が他の AWS リソースにアクセスするために引き受ける IAM ロール ARN。他の ARN 設定を使用する場合に必要です。
### AMQP エンドポイント
| 設定キー | 説明 |
| --- | --- |
| aws.arns.ssl\$1options.cacertfile | SSL/TLS クライアント接続の認証機関ファイル。Amazon MQ では、Amazon S3 または を使用して証明書を保存する必要があります。 |
### RabbitMQ 管理プラグイン
| 設定キー | 説明 |
| --- | --- |
| aws.arns.management.ssl.cacertfile | 管理インターフェイス SSL/TLS 接続の認証機関ファイル。Amazon MQ では、Amazon S3 または を使用して証明書を保存する必要があります。 |
### RabbitMQ OAuth 2.0 プラグイン
| 設定キー | 説明 |
| --- | --- |
| aws.arns.auth\$1oauth2.https.cacertfile | OAuth 2.0 HTTPS 接続の認証機関ファイル。Amazon MQ では、Amazon S3 または を使用して証明書を保存する必要があります。 |
### RabbitMQ HTTP 認証プラグイン
| 設定キー | 説明 |
| --- | --- |
| aws.arns.auth\$1http.ssl\$1options.cacertfile | HTTP 認証 SSL/TLS 接続の認証機関ファイル。Amazon MQ では、Amazon S3 または を使用して証明書を保存する必要があります。 |
| aws.arns.auth\$1http.ssl\$1options.certfile | Amazon MQ と HTTP 認証サーバー間の相互 TLS 接続用の証明書ファイル。Amazon MQ では、Amazon S3 または を使用して証明書を保存する必要があります。 |
| aws.arns.auth\$1http.ssl\$1options.keyfile | Amazon MQ と HTTP 認証サーバー間の相互 TLS 接続用のプライベートキーファイル。Amazon MQ では AWS Secrets Manager 、 を使用してプライベートキーを保存する必要があります。 |
### RabbitMQ LDAP プラグイン
| 設定キー | 説明 |
| --- | --- |
| aws.arns.auth\$1ldap.ssl\$1options.cacertfile | LDAP SSL/TLS 接続の認証機関ファイル。Amazon MQ では、Amazon S3 または を使用して証明書を保存する必要があります。 |
| aws.arns.auth\$1ldap.ssl\$1options.certfile | Amazon MQ と LDAP サーバー間の相互 TLS 接続用の証明書ファイル。Amazon MQ では、Amazon S3 または を使用して証明書を保存する必要があります。 |
| aws.arns.auth\$1ldap.ssl\$1options.keyfile | Amazon MQ と LDAP サーバー間の相互 TLS 接続用のプライベートキーファイル。Amazon MQ では AWS Secrets Manager 、 を使用してプライベートキーを保存する必要があります。 |
| aws.arns.auth\$1ldap.dn\$1lookup\$1bind.password | LDAP DN ルックアップバインドのパスワード。Amazon MQ では AWS Secrets Manager 、 を使用してパスワードをプレーンテキスト値として保存する必要があります。 |
| aws.arns.auth\$1ldap.other\$1bind.password | LDAP の他のバインドのパスワード。Amazon MQ では AWS Secrets Manager 、 を使用してパスワードをプレーンテキスト値として保存する必要があります。 |
## IAM ポリシーのサンプル
ロールの引き受けポリシードキュメントやロールポリシードキュメントを含む IAM ポリシーの例については、[CDK サンプル実装](https://github.com/aws-samples/amazon-mq-samples/blob/main/rabbitmq-samples/rabbitmq-ldap-activedirectory-sample/lib/rabbitmq-activedirectory-stack.ts#L232)を参照してください。
AWS Secrets Manager と Amazon S3 リソースをセットアップする手順[LDAP 認証と認可の使用](rabbitmq-ldap-tutorial.md)については、「」を参照してください。
## アクセス検証
ARN 値を取得できないシナリオをトラブルシューティングするために、aws プラグインは、Amazon [MQ がロールと resolveARN を正常に引き受けることができるかどうかを確認するために呼び出すことができる RabbitMQ 管理 API エンドポイント](https://github.com/amazon-mq/rabbitmq-aws/blob/main/API.md)をサポートしています。 Amazon MQ AWS ARNs これにより、ブローカー設定を更新したり、新しい設定リビジョンでブローカーを更新したり、設定変更をテストするためにブローカーを再起動したりする必要がなくなります。
**注記**
この API を使用するには、既存の RabbitMQ 管理者ユーザーが必要です。Amazon MQ では、他のアクセス方法に加えて、内部ユーザーを使用してテストブローカーを作成することをお勧めします。[OAuth 2.0 と簡易 (内部) 認証の両方を有効にする](oauth-tutorial.md#oauth-tutorial-config-both-auth-methods-using-cli)を参照してください。その後、このユーザーを使用して検証 API にアクセスできます。
**注記**
aws プラグインは検証 API への入力として新しいロールを渡すことをサポートしていますが、このパラメータは Amazon MQ ではサポートされていません。検証に使用する IAM ロールは、ブローカー設定`aws.arns.assume_role_arn`の の値と一致する必要があります。
## 関連するブローカーの隔離状態
ARN サポートの問題に関連するブローカーの隔離状態については、以下を参照してください。
+ [RABBITMQ\$1INVALID\$1ASSUMEROLE](troubleshooting-action-required-codes-invalid-assumerole.md)
+ [RABBITMQ\$1INVALID\$1ARN\$1LDAP](troubleshooting-action-required-codes-invalid-arn-ldap.md)
+ [RABBITMQ\$1INVALID\$1ARN](troubleshooting-action-required-codes-invalid-arn.md)
## シナリオの例
+ ブローカー`b-f0fc695e-2f9c-486b-845a-988023a3e55b`は、IAM ロールを使用して AWS Secrets Manager シークレット``にアクセスするように設定されています ``
+ Amazon MQ に提供されたロールに AWS Secrets Manager シークレットに対する読み取りアクセス許可がない場合、RabbitMQ ログに次のエラーが表示されます。
```
[error] <0.254.0> aws_arn_config: {handle_assume_role,{error,{assume_role_failed,"AWS service is unavailable"}}}
```
さらに、ブローカーは`INVALID_ASSUMEROLE`隔離状態になります。詳細については、[「INVALID\$1ASSUMEROLE](troubleshooting-action-required-codes-invalid-assumerole.md)」を参照してください。
+ LDAP 認証の試行は、次のエラーで失敗します。
```
[error] <0.254.0> LDAP bind failed: invalid_credentials
```
+ 適切なアクセス許可を持つ IAM ロールを修正する
+ 検証エンドポイントを呼び出して、RabbitMQ がシークレットにアクセスできるかどうかを確認します。
```
curl -4su 'guest:guest' -XPUT -H 'content-type: application/json' /api/aws/arn/validate -d '{"assume_role_arn":"arn:aws:iam:::role/","arns":["arn:aws:secretsmanager:::secret:"]}' | jq '.'
```
# AMQP クライアント SSL 設定
フェデレーションとシャベルは、アップストリームブローカーとダウンストリームブローカー間の通信に AMQP を使用します。デフォルトでは、*TLS ピア検証*は Amazon MQ for RabbitMQ 4 の AMQP クライアントで有効になっています。この設定では、Amazon MQ ブローカーで実行されているフェデレーションおよびシャベル AMQP クライアントは、アップストリームブローカーとの接続を確立するときにピア検証を実行します。
Amazon MQ ブローカーで実行されている AMQP クライアントは、Mozilla と同じ認証機関をサポートしています。[ACM](https://www.amazontrust.com/repository) を使用しない場合は、[Mozilla Included CA Certificate List の CA によって発行された証明書](https://wiki.mozilla.org/CA/Included_Certificates)を使用します。オンプレミスブローカーが他の認証機関の証明書を使用する場合、SSL 検証は失敗します。これらのユースケースでは、*TLS ピア検証*を無効にすることができます。
**重要**
Amazon MQ は現在、AMQP クライアント接続のクライアント証明書の設定をサポートしていません。そのため、フェデレーションとシャベルは、クライアント証明書認証を必要とする mTLS 対応ブローカーに接続できません。
**重要**
Amazon MQ for RabbitMQ 3 では、AMQP クライアントの SSL プロパティは RabbitMQ defaults*(verify\$1none)* で設定されます。Amazon MQ for RabbitMQ 3 では、これらのデフォルトを上書きすることはできません。
**注記**
`verify_peer` デフォルト設定では、任意の 2 つの Amazon MQ ブローカー間のフェデレーション接続とシャベル接続を確立できますが、Amazon MQ ブローカーとプライベートブローカー、または Amazon MQ CA 以外の証明書で実行されているオンプレミスブローカー間の接続の確立はサポートされていません。プライベートブローカーまたはオンプレミスブローカーに接続するには、ダウンストリーム Amazon MQ ブローカーでピア検証を無効にする必要があります。
## AMQP クライアント SSL 設定キー
| 設定 | 設定キー | サポートされる値 |
| --- | --- | --- |
| AMQP クライアント SSL ピア検証 | amqp\$1client.ssl\$1options.verify | verify\$1none, verify\$1peer |
## AMQP クライアント SSL ピア検証を上書きする方法
RabbitMQ 4 ブローカーの Amazon MQ API と Amazon MQ コンソールを使用して、AMQP クライアントの SSL ピア検証を上書きできます。
次の例は、 を使用して AMQP クライアント SSL ピア検証を上書きする方法を示しています AWS CLI。
```
aws mq update-configuration --configuration-id --data "$(echo "amqp_client.ssl_options.verify=verify_none" | base64 --wrap=0)"
```
呼び出しが成功すると、設定リビジョンが作成されます。設定を RabbitMQ ブローカーに関連付け、ブローカーを再起動してオーバーライドを適用する必要があります。詳細については、「」を参照してください。 [Creating and applying broker configurations](rabbitmq-creating-applying-configurations.md)
**重要**
を使用する場合`verify_none`、SSL 暗号化は引き続きアクティブですが、ピアの ID は検証されません。この設定は必要な場合にのみ使用し、送信先ブローカーへのネットワークパスを信頼してください。
# Amazon MQ for RabbitMQ の認証と認可
Amazon MQ for RabbitMQ は、次の認証および認可方法をサポートしています。
## シンプルな認証と認可
この方法では、ブローカーユーザーは内部的に RabbitMQ ブローカーに保存され、ウェブコンソールまたは管理 API を介して管理されます。vhost、交換、キュー、トピックのアクセス許可は、RabbitMQ で直接設定されます。これがデフォルトの方法です。詳細については、[「シンプルな認証と認可](rabbitmq-simple-auth-broker-users.md)」を参照してください。
## OAuth 2.0 の認証と認可
この方法では、ブローカーユーザーとそのアクセス許可は、外部 OAuth 2.0 ID プロバイダー (IdP) によって管理されます。vhost、交換、キュー、トピックのユーザー認証とリソースアクセス許可は、OAuth 2.0 プロバイダーのスコープシステムを通じて一元化されます。これにより、ユーザー管理が簡素化され、既存の ID システムとの統合が可能になります。詳細については、[OAuth 2.0 の認証と認可](oauth-for-amq-for-rabbitmq.md)」を参照してください。
## IAM 認証と認可
この方法では、ブローカーユーザーは IAM AWS [アウトバウンドフェデレーションを介して IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html) 認証情報を使用して認証します。IAM 認証情報は、 AWS Security Token Service (STS) から JWT トークンを取得するために使用されます。これらの JWT トークンは、認証用の OAuth 2.0 トークンとして機能します。このメソッドは、Amazon MQ for RabbitMQ の既存の OAuth 2.0 サポートを活用します。 は OAuth 2.0 ID プロバイダー AWS として機能します。ユーザー認証は IAM AWS によって処理され、vhost、エクスチェンジ、キュー、トピックのリソースアクセス許可は RabbitMQ で設定された IAM ポリシーとスコープエイリアスによって管理されます。詳細については、[「IAM 認証と認可](iam-for-amq-for-rabbitmq.md)」を参照してください。
## LDAP 認証と認可
この方法では、ブローカーユーザーとそのアクセス許可は外部 LDAP ディレクトリサービスによって管理されます。ユーザー認証とリソースのアクセス許可は LDAP サーバーを通じて一元化されるため、ユーザーは既存のディレクトリサービス認証情報を使用して RabbitMQ にアクセスできます。詳細については、[「LDAP 認証と認可](ldap-for-amq-for-rabbitmq.md)」を参照してください。
## HTTP 認証と認可
この方法では、ブローカーユーザーとそのアクセス許可は外部 HTTP サーバーによって管理されます。ユーザー認証とリソースのアクセス許可は HTTP サーバーを通じて一元化されるため、ユーザーは独自の認証および認可プロバイダーを使用して RabbitMQ にアクセスできます。この方法の詳細については、[「HTTP 認証と認可](http-for-amq-for-rabbitmq.md)」を参照してください。
## SSL 証明書認証
Amazon MQ は、RabbitMQ ブローカーの相互 TLS (mTLS) をサポートしています。SSL 認証プラグインは、mTLS 接続からのクライアント証明書を使用してユーザーを認証します。この方法では、ブローカーユーザーはユーザー名とパスワードの認証情報の代わりに X.509 クライアント証明書を使用して認証されます。クライアントの証明書は信頼できる認証機関 (CA) に対して検証され、ユーザー名は共通名 (CN) やサブジェクト代替名 (SAN) などの証明書のフィールドから抽出されます。この方法は、ネットワーク経由で認証情報を送信せずに強力な認証を提供します。詳細については、[「SSL 証明書認証](ssl-for-amq-for-rabbitmq.md)」を参照してください。
**注記**
RabbitMQ は、同時に使用する複数の認証および認可方法をサポートしています。たとえば、OAuth 2.0 と簡易 (内部) 認証の両方を有効にできます。詳細については、OAuth 2.0 チュートリアルセクション[OAuth 2.0 と簡易 (内部) 認証の両方を有効にする](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/oauth-tutorial.html#oauth-tutorial-config-both-auth-methods-using-cli)」および[RabbitMQ アクセスコントロールドキュメント](https://www.rabbitmq.com/docs/access-control)」を参照してください。
Amazon MQ では、認証設定をテストするときに内部ユーザーを作成することをお勧めします。これにより、RabbitMQ 管理 API を使用してアクセス設定を検証できます。詳細については、[「アクセス検証](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/arn-support-rabbitmq-configuration.html#access-validation)」を参照してください。
# シンプルな認証と認可
## Amazon MQ for RabbitMQ ブローカーのユーザー
**注記**
このトピックでは、RabbitMQ のデフォルトの内部認証および認可メカニズムを使用したブローカーユーザーの管理について説明します。サポートされているすべての認証および認可方法の詳細については、[Amazon MQ for RabbitMQ Authentication and Authorization](rabbitmq-authentication.md)」を参照してください。
すべての AMQP 0-9-1 クライアント接続には、関連付けられたユーザーがあります。このユーザーは認証されている必要があります。各クライアント接続は仮想ホスト (vhost) もターゲットにします。ユーザーには、この vhost に対する一連のアクセス許可が必要です。ユーザーは、vhost 内のキューとエクスチェンジに対して**設定**、**書き込み**、および**読み込み**を行う許可を持つことができます。接続が確立されると、ユーザー認証情報とターゲット vhost を指定します。
Amazon MQ for RabbitMQ ブローカーを初めて作成する場合、Amazon MQ は、指定されたサインイン認証情報を使用して、`administrator` タグで RabbitMQ ユーザーを作成します。その後、RabbitMQ [Management API](https://www.rabbitmq.com/management.html)、または RabbitMQ ウェブコンソールを使用してユーザーを追加および管理することができます。また、RabbitMQ ウェブコンソールまたは Management API を使用して、ユーザーの認証情報とタグを設定または変更することもできます。
**注記**
RabbitMQ ユーザーは、Amazon MQ の[ユーザー](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/brokers-broker-id-users.html) API 経由で保存または表示されません。
**重要**
Amazon MQ for RabbitMQ では、ユーザー名「guest」はサポートされず、デフォルトのゲストアカウントは新しいブローカーの作成時に削除されます。ユーザーが作成した「guest」というアカウントも、Amazon MQ によって定期的に削除されます。
RabbitMQ Management API を使用して新しいユーザーを作成するには、以下の API エンドポイントとリクエストボディを使用します。*ユーザー名*と*パスワード*を、新しいサインイン認証情報に置き換えます。
```
PUT /api/users/username HTTP/1.1
{"password":"password","tags":"administrator"}
```
**重要**
個人を特定できる情報 (PII) などの機密情報や秘匿性の高い情報はブローカーのユーザー名に追加しないでください。ブローカーユーザー名は、CloudWatch Logs を含む他の AWS のサービスからアクセスできます。ブローカーのユーザー名は、プライベートデータや機密データとして使用することを意図していません。
すべての管理者アカウントにアクセスできなくなった場合は、[「復旧に IAM 認証を使用するためのブローカーアクセス](troubleshooting-rabbitmq.md#rabbitmq-broker-recovery)の復旧」を参照してください。
`tags` キーは必須です。これは、ユーザーのタグのカンマで区切られたリストです。Amazon MQ は、`administrator`、`management`、`monitoring`、および `policymaker` ユーザータグをサポートします。
個々のユーザーに対する許可は、以下の API エンドポイントとリクエストボディを使用して設定できます。*vhost* および *username* を、独自の情報に置き換えます。デフォルト vhost `/` には、`%2F` を使用します。
```
PUT /api/permissions/vhost/username HTTP/1.1
{"configure":".*","write":".*","read":".*"}
```
**注記**
`configure`、`read`、および `write` キーはすべて必須です。
ワイルドカード `.*` 値を使用することによって、このオペレーションは、指定された vhost 内のすべてのキューに対する読み取り、書き込み、および設定許可をユーザーに付与します。RabbitMQ Management API を使用したユーザーの管理の詳細については、「[RabbitMQ Management HTTP API](https://rawcdn.githack.com/rabbitmq/rabbitmq-server/main/deps/rabbitmq_management/priv/www/api/index.html)」を参照してください。
# Amazon MQ for RabbitMQ に対する OAuth 2.0 の認証と認可
Amazon MQ for RabbitMQ は、複数の認証および認可方法をサポートしています。サポートされているすべての方法の詳細については、[Amazon MQ for RabbitMQ ブローカーの認証と認可](rabbitmq-authentication.md)」を参照してください。
OAuth 2.0 の認証と認可では、ブローカーユーザーとそのアクセス許可は外部 OAuth 2.0 ID プロバイダー (IdP) によって管理されます。vhost、交換、キュー、トピックのユーザー認証とリソースアクセス許可は、OAuth 2.0 プロバイダーのスコープシステムを通じて一元化されます。これにより、ユーザー管理が簡素化され、既存の ID システムとの統合が可能になります。
**重要な考慮事項**
OAuth 2.0 統合は、Amazon MQ for ActiveMQ ブローカーではサポートされていません。
Amazon MQ for RabbitMQ では、プライベート CA によって発行されたサーバー証明書はサポートされません。
RabbitMQ OAuth 2.0 プラグインは、トークンイントロスペクションエンドポイントと不透明なアクセストークンをサポートしていません。また、トークンの取り消しチェックも実行しません。
既存のブローカーで OAuth 2.0 を有効にするには、IAM アクセス許可、`mq:UpdateBrokerAccessConfiguration` を含める必要があります。
Amazon MQ は、モニタリングのみのアクセス許可を持つ `monitoring-AWS-OWNED-DO-NOT-DELETE` という名前のシステムユーザーを自動的に作成します。このユーザーは、OAuth 2.0 対応ブローカーでも RabbitMQ の内部認証システムを使用し、ループバックインターフェイスアクセスのみに制限されています。
Amazon MQ for RabbitMQ ブローカーに OAuth 2.0 を設定する方法については、「」を参照してください[OAuth 2.0 の認証と認可の使用](oauth-tutorial.md)。
**Topics**
+ [
## サポートされている OAuth 2.0 設定
](#oauth-tutorial-supported-configs)
+ [
## OAuth 2.0 認証の追加検証
](#oauth-tutorial-additional-validations)
## サポートされている OAuth 2.0 設定
Amazon MQ for RabbitMQ は、RabbitMQ OAuth 2.0 プラグインで[設定可能なすべての変数](https://www.rabbitmq.com/docs/oauth2#variables-configurable)をサポートしますが、以下の例外があります。
+ `auth_oauth2.https.cacertfile`
+ `auth_oauth2.oauth_providers.{id/index}.https.cacertfile`
+ `management.oauth_client_secret`
Amazon MQ はこのキーをサポートしていないため、UAA は IdP としてサポートされません。
+ `management.oauth_resource_servers.{id/index}.oauth_client_secret`
+ `auth_oauth2.signing_keys.{id/index}`
## OAuth 2.0 認証の追加検証
Amazon MQ では、OAuth 2.0 認証に次の追加の検証も適用されます。
+ すべての URL は `https://` で始まる必要があります。
+ サポートされている署名アルゴリズム: `Ed25519`、`Ed25519ph`、`Ed448`、`Ed448ph`、`EdDSA`、`ES256K`、`ES256`、`ES384`、`ES512`、`HS256`、`HS384`、`HS512`、`PS256`、`PS384`、`PS512`、`RS256`、`RS384`、`RS512`。
# Amazon MQ for RabbitMQ の IAM 認証と認可
Amazon MQ for RabbitMQ は、複数の認証および認可方法をサポートしています。サポートされているすべての方法の詳細については、[Amazon MQ for RabbitMQ ブローカーの認証と認可](rabbitmq-authentication.md)」を参照してください。
IAM 認証と認可により、ブローカーユーザーは IAM AWS [アウトバウンドフェデレーションを通じて IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html) 認証情報を使用して認証できます。この方法では、IAM 認証情報を使用して AWS Security Token Service (STS) から JWT トークンを取得します。これらの JWT トークンは認証用の OAuth 2.0 トークンとして機能し、Amazon MQ for RabbitMQ の既存の OAuth 2.0 サポートを活用します。 AWS は OAuth 2.0 ID プロバイダーとして機能します。 AWS IAM はユーザー認証を処理し、仮想ホスト、交換、キュー、トピックのリソース許可は RabbitMQ で設定された IAM ポリシーとスコープエイリアスを通じて管理されます。
**重要な考慮事項**
IAM 認証は、RabbitMQ バージョン 3.13、4.2 以降でサポートされています。Amazon MQ for ActiveMQ ブローカーではサポートされていません。
IAM 認証では、IAM アウトバウンドフェデレーションを設定し、 AWS アカウントで使用できるようにする必要があります。
このメソッドは、Amazon MQ for RabbitMQ の既存の OAuth 2.0 インフラストラクチャ上に構築され、OAuth 2.0 ID プロバイダー AWS として機能します。
Amazon MQ は、モニタリングのみのアクセス許可を持つ `monitoring-AWS-OWNED-DO-NOT-DELETE` という名前のシステムユーザーを自動的に作成します。このユーザーは、IAM 対応ブローカーでも RabbitMQ の内部認証システムを使用し、ループバックインターフェイスアクセスのみに制限されています。
**Topics**
+ [
## IAM 認証の仕組み
](#iam-authentication-overview)
+ [
## 制限事項
](#iam-authentication-limitations)
## IAM 認証の仕組み
Amazon MQ for RabbitMQ の IAM 認証は、[IAM アウトバウンドフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html)を使用して、IAM AWS 認証情報が RabbitMQ ブローカーで認証できるようにします。IAM 認証情報は、 AWS Security Token Service (STS) から JWT トークンを取得するために使用されます。これらの JWT トークンは、RabbitMQ ブローカーによる認証用の OAuth 2.0 トークンとして機能します。
## 制限事項
Amazon MQ for RabbitMQ の IAM 認証には、次の制限があります。
+ **スコープクレーム設定** – STS の JWT トークンがネストされているため、スコープクレームを直接使用することはできません。キーは で`sts.amazonaws.com`、RabbitMQ 設定でスコープエイリアスを使用して IAM ロールを RabbitMQ アクセス許可にマッピングする必要があります。この制限により、認可に IAM ポリシーが完全に使用されなくなり、代わりに認可に RabbitMQ 設定が必要になります。
Amazon MQ for RabbitMQ ブローカーの IAM 認証と認可を設定する方法については、「」を参照してください[IAM 認証と認可の使用](rabbitmq-iam-tutorial.md)。
# Amazon MQ for RabbitMQ の HTTP 認証と認可
Amazon MQ for RabbitMQ は、外部 HTTP サーバーを使用したブローカーユーザーの認証と認可をサポートしています。サポートされているその他の方法については、[Amazon MQ for RabbitMQ ブローカーの認証と認可](rabbitmq-authentication.md)」を参照してください。
**注記**
HTTP 認証プラグインは、Amazon MQ for RabbitMQ バージョン 4 以降でのみ使用できます。
**重要な考慮事項**
HTTP サーバーは、パブリックインターネット経由でアクセス可能である必要があります。Amazon MQ for RabbitMQ は、相互 TLS を使用して HTTP サーバーに対して認証するように設定できます。
Amazon MQ for RabbitMQ は、ローカルファイルシステムへのアクセスを必要とする設定に AWS ARNs の使用を強制します。詳細については、[RabbitMQ 設定の ARN サポート](arn-support-rabbitmq-configuration.md)を参照してください。
既存のブローカーで HTTP 認証を有効にするには`mq:UpdateBrokerAccessConfiguration`、IAM アクセス許可 を含める必要があります。
Amazon MQ は、モニタリングのみのアクセス許可を持つ `monitoring-AWS-OWNED-DO-NOT-DELETE` という名前のシステムユーザーを自動的に作成します。このユーザーは、HTTP 対応ブローカーでも RabbitMQ の内部認証システムを使用し、ループバックインターフェイスアクセスのみに制限されています。Amazon MQ は、[保護されたユーザータグを追加することで、このユーザー](https://github.com/rabbitmq/rabbitmq-server/blob/3751301d5a851f3f0a7d0b15583e52cb81af4e6b/release-notes/4.2.0.md#enhancements-3)の削除を防止します。
Amazon MQ for RabbitMQ ブローカーの HTTP 認証を設定する方法については、「」を参照してください[HTTP 認証と認可の使用](rabbitmq-http-tutorial.md)。
**Topics**
+ [
## サポートされている HTTP 設定
](#http-supported-configs)
+ [
## Amazon MQ での HTTP 設定の追加検証
](#http-additional-validations)
## サポートされている HTTP 設定
Amazon MQ for RabbitMQ は[RabbitMQ HTTP 認証プラグイン](https://github.com/rabbitmq/rabbitmq-auth-backend-http)ですべての設定可能な変数をサポートしますが、 AWS ARNs。ARN サポートの詳細については、[RabbitMQ 設定での ARN サポート](arn-support-rabbitmq-configuration.md)」を参照してください。
### ARNs を必要とする設定
`auth_http.ssl_options.cacertfile`
代わりに `aws.arns.auth_http.ssl_options.cacertfile` を使用
`auth_http.ssl_options.certfile`
代わりに `aws.arns.auth_http.ssl_options.certfile` を使用
`auth_http.ssl_options.keyfile`
代わりに `aws.arns.auth_http.ssl_options.keyfile` を使用
### サポートされていない SSL オプション
以下の SSL 設定オプションもサポートされていません。
#### 完全なリストを表示する
+ `auth_http.ssl_options.cert`
+ `auth_http.ssl_options.client_renegotiation`
+ `auth_http.ssl_options.dh`
+ `auth_http.ssl_options.dhfile`
+ `auth_http.ssl_options.honor_cipher_order`
+ `auth_http.ssl_options.honor_ecc_order`
+ `auth_http.ssl_options.key.RSAPrivateKey`
+ `auth_http.ssl_options.key.DSAPrivateKey`
+ `auth_http.ssl_options.key.PrivateKeyInfo`
+ `auth_http.ssl_options.log_alert`
+ `auth_http.ssl_options.password`
+ `auth_http.ssl_options.psk_identity`
+ `auth_http.ssl_options.reuse_sessions`
+ `auth_http.ssl_options.secure_renegotiate`
+ `auth_http.ssl_options.versions.$version`
+ `auth_http.ssl_options.sni`
+ `auth_http.ssl_options.crl_check`
## Amazon MQ での HTTP 設定の追加検証
Amazon MQ では、HTTP 認証と認可に次の追加の検証も適用されます。
+ `auth_http.http_method` は `get`または のいずれかである必要があります `post`
+ 次のパス設定では、HTTPS URLs を使用する必要があります。
+ `auth_http.user_path`
+ `auth_http.vhost_path`
+ `auth_http.resource_path`
+ `auth_http.topic_path`
+ 設定で AWS ARN の使用が必要な場合は、 を指定`aws.arns.assume_role_arn`する必要があります。
# Amazon MQ for RabbitMQ の SSL 証明書認証
Amazon MQ for RabbitMQ は、X.509 クライアント証明書を使用したブローカーユーザーの認証をサポートしています。サポートされているその他の方法については、[Amazon MQ for RabbitMQ ブローカーの認証と認可](rabbitmq-authentication.md)」を参照してください。
**注記**
SSL 証明書認証プラグインは、Amazon MQ for RabbitMQ バージョン 4 以降でのみ使用できます。
**重要な考慮事項**
クライアント証明書は、信頼できる認証機関 (CA) によって署名されている必要があります。Amazon MQ for RabbitMQ は、認証中に証明書チェーンを検証します。
Amazon MQ for RabbitMQ は、CA 証明書などの証明書関連の設定や、ローカルファイルシステムへのアクセスを必要とする設定に AWS ARNs の使用を強制します。詳細については、[RabbitMQ 設定の ARN サポート](arn-support-rabbitmq-configuration.md)を参照してください。
Amazon MQ は、モニタリングのみのアクセス許可を持つ `monitoring-AWS-OWNED-DO-NOT-DELETE` という名前のシステムユーザーを自動的に作成します。このユーザーは、SSL 証明書が有効なブローカーでも RabbitMQ の内部認証システムを使用し、ループバックインターフェイスアクセスのみに制限されています。Amazon MQ は、[保護されたユーザータグを追加することで、このユーザー](https://github.com/rabbitmq/rabbitmq-server/blob/3751301d5a851f3f0a7d0b15583e52cb81af4e6b/release-notes/4.2.0.md#enhancements-3)の削除を防止します。
Amazon MQ for RabbitMQ ブローカーの SSL 証明書認証を設定する方法については、「」を参照してください[SSL 証明書認証の使用](rabbitmq-ssl-tutorial.md)。
**Topics**
+ [
## サポートされている SSL 設定
](#ssl-supported-configs)
+ [
## Amazon MQ での SSL 設定の追加検証
](#ssl-additional-validations)
## サポートされている SSL 設定
Amazon MQ for RabbitMQ は、クライアント接続の SSL/TLS 設定をサポートしています。ARN サポートの詳細については、[RabbitMQ 設定での ARN サポート](arn-support-rabbitmq-configuration.md)」を参照してください。
### ARNs を必要とする設定
`ssl_options.cacertfile`
代わりに `aws.arns.ssl_options.cacertfile` を使用
### SSL 証明書のログイン設定
次の設定は、クライアント証明書からユーザー名を抽出する方法を制御します。
`ssl_cert_login_from`
ユーザー名抽出に使用する証明書フィールドを指定します。サポートされる値。
+ `distinguished_name` - 完全な識別名を使用する
+ `common_name` - Common Name (CN) フィールドを使用する
+ `subject_alternative_name` または `subject_alt_name` - サブジェクトの代替名を使用する
`ssl_cert_login_san_type`
サブジェクト代替名を使用する場合、 は SAN タイプを指定します。サポートされている値: `dns`、`ip`、`email`、`uri`、 `other_name`
`ssl_cert_login_san_index`
サブジェクト代替名を使用する場合、使用する SAN エントリのインデックスを指定します (ゼロベース）。負以外の整数である必要があります。
### クライアント接続の SSL オプション
クライアント接続には、次の SSL オプションが適用されます。
`ssl_options.verify`
ピア検証モード。サポートされている値: `verify_none`、 `verify_peer`
`ssl_options.fail_if_no_peer_cert`
クライアントが証明書を提供しない場合に接続を拒否するかどうか。ブール値。
`ssl_options.depth`
検証のための証明書チェーンの最大深度。
`ssl_options.hostname_verification`
ホスト名検証モード。サポートされている値: `wildcard`、 `none`
### サポートされていない SSL オプション
以下の SSL 設定オプションはサポートされていません。
#### 完全なリストを表示する
+ `ssl_options.cert`
+ `ssl_options.client_renegotiation`
+ `ssl_options.dh`
+ `ssl_options.dhfile`
+ `ssl_options.honor_cipher_order`
+ `ssl_options.honor_ecc_order`
+ `ssl_options.key.RSAPrivateKey`
+ `ssl_options.key.DSAPrivateKey`
+ `ssl_options.key.PrivateKeyInfo`
+ `ssl_options.log_alert`
+ `ssl_options.password`
+ `ssl_options.psk_identity`
+ `ssl_options.reuse_sessions`
+ `ssl_options.secure_renegotiate`
+ `ssl_options.versions.$version`
+ `ssl_options.sni`
+ `ssl_options.crl_check`
## Amazon MQ での SSL 設定の追加検証
Amazon MQ では、SSL 証明書認証に次の追加の検証も適用されます。
+ 設定で AWS ARN の使用が必要な場合は、 を指定`aws.arns.assume_role_arn`する必要があります。
# Amazon MQ for RabbitMQ の LDAP 認証と認可
Amazon MQ for RabbitMQ は、外部 LDAP サーバーを使用したブローカーユーザーの認証と認可をサポートしています。サポートされているその他の方法については、[Amazon MQ for RabbitMQ ブローカーの認証と認可](rabbitmq-authentication.md)」を参照してください。
**重要な考慮事項**
LDAP サーバーは、パブリックインターネット経由でアクセス可能である必要があります。Amazon MQ for RabbitMQ は、相互 TLS を使用して LDAP サーバーに対して認証するように設定できます。
Amazon MQ for RabbitMQ は、パスワードなどの機密性の高い LDAP 設定や、ローカルファイルシステムへのアクセスを必要とする設定に AWS ARNs の使用を強制します。詳細については、[RabbitMQ 設定の ARN サポート](arn-support-rabbitmq-configuration.md)を参照してください。
既存のブローカーで LDAP を有効にするには`mq:UpdateBrokerAccessConfiguration`、IAM アクセス許可 を含める必要があります。
Amazon MQ は、モニタリングのみのアクセス許可を持つ `monitoring-AWS-OWNED-DO-NOT-DELETE` という名前のシステムユーザーを自動的に作成します。このユーザーは、LDAP 対応ブローカーでも RabbitMQ の内部認証システムを使用し、ループバックインターフェイスアクセスのみに制限されています。Amazon MQ は、[保護されたユーザータグを追加することで、このユーザー](https://github.com/rabbitmq/rabbitmq-server/blob/3751301d5a851f3f0a7d0b15583e52cb81af4e6b/release-notes/4.2.0.md#enhancements-3)の削除を防止します。
Amazon MQ for RabbitMQ ブローカーの LDAP を設定する方法については、「」を参照してください[LDAP 認証と認可の使用](rabbitmq-ldap-tutorial.md)。
**Topics**
+ [
## サポートされている LDAP 設定
](#ldap-supported-configs)
+ [
## Amazon MQ での LDAP 設定の追加検証
](#ldap-additional-validations)
## サポートされている LDAP 設定
Amazon MQ for RabbitMQ は[RabbitMQ LDAP プラグイン](https://www.rabbitmq.com/docs/ldap)で設定可能なすべての変数をサポートしますが、 AWS ARNs。ARN サポートの詳細については、[RabbitMQ 設定での ARN サポート](arn-support-rabbitmq-configuration.md)」を参照してください。
### ARNs を必要とする設定
`auth_ldap.dn_lookup_bind.password`
代わりに `aws.arns.auth_ldap.dn_lookup_bind.password` を使用
`auth_ldap.other_bind.password`
代わりに `aws.arns.auth_ldap.other_bind.password` を使用
`auth_ldap.ssl_options.cacertfile`
代わりに `aws.arns.auth_ldap.ssl_options.cacertfile` を使用
`auth_ldap.ssl_options.certfile`
代わりに `aws.arns.auth_ldap.ssl_options.certfile` を使用
`auth_ldap.ssl_options.keyfile`
代わりに `aws.arns.auth_ldap.ssl_options.keyfile` を使用
### サポートされていない SSL オプション
以下の SSL 設定オプションもサポートされていません。
#### 完全なリストを表示する
+ `auth_ldap.ssl_options.cert`
+ `auth_ldap.ssl_options.client_renegotiation`
+ `auth_ldap.ssl_options.dh`
+ `auth_ldap.ssl_options.dhfile`
+ `auth_ldap.ssl_options.honor_cipher_order`
+ `auth_ldap.ssl_options.honor_ecc_order`
+ `auth_ldap.ssl_options.key.RSAPrivateKey`
+ `auth_ldap.ssl_options.key.DSAPrivateKey`
+ `auth_ldap.ssl_options.key.PrivateKeyInfo`
+ `auth_ldap.ssl_options.log_alert`
+ `auth_ldap.ssl_options.password`
+ `auth_ldap.ssl_options.psk_identity`
+ `auth_ldap.ssl_options.reuse_sessions`
+ `auth_ldap.ssl_options.secure_renegotiate`
+ `auth_ldap.ssl_options.versions.$version`
+ `auth_ldap.ssl_options.sni`
## Amazon MQ での LDAP 設定の追加検証
Amazon MQ では、LDAP 認証と認可に対して次の追加の検証も適用されます。
+ `auth_ldap.log` を に設定することはできません `network_unsafe`
+ LDAP サーバーは LDAPS を使用する必要があります。`auth_ldap.use_ssl` または のいずれかを明示的に有効に`auth_ldap.use_starttls`する必要があります
+ 設定で AWS ARN の使用が必要な場合は、 を指定`aws.arns.assume_role_arn`する必要があります。
+ `auth_ldap.servers` は有効な IP アドレスまたは有効な FQDN である必要があります
+ 次のキーは有効な LDAP 識別名である必要があります。
+ `auth_ldap.dn_lookup_base`
+ `auth_ldap.dn_lookup_bind.user_dn`
+ `auth_ldap.other_bind.user_dn`
+ `auth_ldap.group_lookup_base`
# プラグイン
Amazon MQ for RabbitMQ は、次のプラグインもサポートしています。
+ [RabbitMQ 管理プラグイン](#rabbitmq-management-plugin)
+ [シャベルプラグイン](#rabbitmq-shovel-plugin)
+ [フェデレーションプラグイン](#rabbitmq-federation-plugin)
+ [整合性のあるハッシュ交換プラグイン](#rabbitmq-consistent-hash-exchange)
+ [OAuth 2 プラグイン](#rabbitmq-oauth-plugin)
+ [LDAP プラグイン](#rabbitmq-ldap-plugin)
+ [HTTP プラグイン](#rabbitmq-http-plugin)
+ [SSL 証明書プラグイン](#rabbitmq-ssl-plugin)
+ [aws プラグイン](#rabbitmq-aws-plugin)
+ [JMS Topic Exchange プラグイン](#rabbitmq-jms-topic-exchange-plugin)
## RabbitMQ 管理プラグイン
Amazon MQ for RabbitMQ は[、HTTP ベースの管理 API と RabbitMQ ウェブコンソール用のブラウザベースの UI を提供する RabbitMQ 管理プラグイン](https://www.rabbitmq.com/management.html)をサポートしています。 RabbitMQ ブローカーのユーザーとポリシーの作成と管理には、ウェブコンソールと Management API を使用できます。
## シャベルプラグイン
Amazon MQ for RabbitMQ は [RabbitMQ シャベルプラグイン](https://www.rabbitmq.com/shovel.html)をサポートしています。これにより、あるブローカーのキューと交換から別のブローカーにメッセージを移動できます。シャベルは、疎結合されたブローカーを接続し、メッセージ負荷が高いノードを避けてメッセージを分散するために使用できます。
**重要**
シャベル先がプライベートブローカーの場合は、キューまたはエクスチェンジの間でシャベルを構成することはできません。
Amazon MQ は、静的シャベルの使用をサポートしません。
[動的シャベル](https://www.rabbitmq.com/shovel-dynamic.html)のみがサポートされています。動的シャベルはランタイムパラメータを使用して設定され、クライアント接続によっていつでもプログラムで開始および停止できます。例えば、RabbitMQ 管理 API を使用して、次の API エンドポイントへの PUT リクエストを作成して、動的シャベルを設定できます。この例では、\$1vhost\$1 をブローカーの vhost の名前に置き換え、\$1name\$1 を新しい動的シャベルの名前に置き換えることができます。
```
/api/parameters/shovel/{vhost}/{name}
```
リクエストボディでは、キューまたはエクスチェンジのどちらかを指定する必要がありますが、両方を指定する必要はありません。以下の例では、src-queue で指定されたローカルキューと dest-queue で定義されたリモートキューの間に動的シャベルを設定します。同様に、src-exchange パラメータと dest-exchange パラメータを使用して、2 つのエクスチェンジ間でシャベルを設定できます。
```
{
"value": {
"src-protocol": "amqp091",
"src-uri": "amqp://localhost",
"src-queue": "source-queue-name",
"dest-protocol": "amqp091",
"dest-uri": "amqps://b-c8352341-ec91-4a78-ad9c-a43f23d325bb.mq.us-west2.amazonaws.com:5671",
"dest-queue": "destination-queue-name"
}
}
```
## フェデレーションプラグイン
Amazon MQ は、[RabbitMQ フェデレーションプラグインを使用してフェデ](https://www.rabbitmq.com/federation.html)レーティッドエクスチェンジとキューをサポートします。フェデレーションを使用すると、個別のブローカー上にあるキュー、エクスチェンジ、およびコンシューマー間でメッセージのフローをレプリケートできます。フェデレートされたキューとエクスチェンジは、他のブローカー内のピアへの接続にポイントツーポイントリンクを使用します。フェデレートされたエクスチェンジでは、デフォルトでメッセージが 1 回送信されますが、フェデレートされたキューでは、コンシューマーが必要とする回数だけメッセージを移動できます。
フェデレーションを使用して、アップストリームのエクスチェンジまたはキューからのメッセージをダウンストリームブローカーが消費できるようにすることが可能です。RabbitMQ ウェブコンソールまたは Management API を使用して、ダウンストリームブローカーでフェデレーションを有効にできます。
**重要**
アップストリームキューまたはエクスチェンジがプライベートブローカーにある場合は、フェデレーションを設定できません。フェデレーションは、パブリックブローカーのキューまたはエクスチェンジの間、または、パブリックブローカーのアップストリームキューかエクスチェンジと、プライベートブローカーのダウンストリームキューかエクスチェンジの間のみ設定できます。
例えば、Management API を使用して以下を実行することにより、フェデレーションを設定できます。
+ 他のノードへのフェデレーション接続を定義する 1 つ、または複数のアップストリームを設定する。フェデレーション接続は、RabbitMQ ウェブコンソールまたは Management API を使用して定義できます。管理 API を使用して、次のリクエストボディを使用して /api/parameters/federation-upstream/%2f/myupstream への POST リクエストを作成できます。
```
{"value":{"uri":"amqp://server-name","expires":3600000}}
```
+ キューまたはエクスチェンジがフェデレートされるようにするポリシーを設定する。ポリシーは、RabbitMQ ウェブコンソールまたは Management API を使用して設定できます。管理 API を使用すると、次のリクエストボディを使用して /api/policies/%2f/federate-me への POST リクエストを作成できます。
```
{"pattern":"^amq\.", "definition":{"federation-upstream-set":"all"}, "apply-to":"exchanges"}
```
**注記**
リクエストボディは、サーバー上のエクスチェンジの名前が amq で始まることを前提としています。正規表現 ^amq\$1 を使用します。 は、名前が「amq」で始まるすべてのエクスチェンジでフェデレーションが有効になっていることを確認します。RabbitMQ サーバー上のエクスチェンジには、異なる名前を付けることができます。
## コンシステントハッシュエクスチェンジプラグイン
Amazon MQ for RabbitMQ は、[RabbitMQ 整合性ハッシュ交換タイププラグイン](https://github.com/rabbitmq/rabbitmq-consistent-hash-exchange)をサポートしています。コンシステントハッシュエクスチェンジは、メッセージのルーティングキーから計算されたハッシュ値に基づいてメッセージをキューに送信します。合理的に均等なルーティングキーが提供されると、コンシステントハッシュエクスチェンジはキュー間でメッセージを合理的にむらなく分散できます。
コンシステントハッシュエクスチェンジにバインドされたキューの場合、バインディングキーは各キューのバインドの重みを決定する文字列数値です。バインドの重みが高いキューでは、それらがバインドされているコンシステントハッシュエクスチェンジから受け取るメッセージの配分が相対的に高くなります。コンシステントハッシュエクスチェンジトポロジでは、パブリッシャーは単にメッセージをエクスチェンジに発行できますが、コンシューマーは特定のキューからのメッセージを消費するように明示的に設定される必要があります。
## OAuth 2.0 プラグイン
Amazon MQ for RabbitMQ は、[OAuth 2 認証バックエンドプラグイン](https://github.com/rabbitmq/rabbitmq-auth-backend-oauth2)をサポートしています。このプラグインは、ブローカーの設定に基づいて条件付きで有効になります。有効にすると、このプラグインは OAuth 2.0 認証と認可を提供し、外部 OAuth 2.0 ID プロバイダーとの統合により、ユーザー管理とアクセスコントロールを一元化します。OAuth 2.0 認証の詳細については、「」を参照してください[OAuth 2.0 の認証と認可](oauth-for-amq-for-rabbitmq.md)。
## LDAP プラグイン
Amazon MQ for RabbitMQ は、[LDAP 認証バックエンドプラグイン](https://github.com/rabbitmq/rabbitmq-auth-backend-ldap)をサポートしています。このプラグインは、ブローカーの設定に基づいて条件付きで有効になります。有効にすると、このプラグインは LDAP 認証と認可を外部 LDAP ディレクトリサービスに統合して、一元化されたユーザー認証と認可を提供します。LDAP 認証の詳細については、「」を参照してください[LDAP 認証と認可](ldap-for-amq-for-rabbitmq.md)。
## HTTP プラグイン
Amazon MQ for RabbitMQ は、[HTTP 認証バックエンドプラグイン](https://github.com/rabbitmq/rabbitmq-auth-backend-http)をサポートしています。このプラグインは、ブローカーの設定に基づいて条件付きで有効になります。有効にすると、このプラグインは HTTP 認証と認可を提供し、外部 HTTP サーバーとの統合により、一元化されたユーザー認証と認可を行います。HTTP 認証の詳細については、「」を参照してください[HTTP 認証と認可](http-for-amq-for-rabbitmq.md)。
**注記**
HTTP 認証プラグインは、Amazon MQ for RabbitMQ バージョン 4 以降でのみ使用できます。
## SSL 証明書プラグイン
Amazon MQ は、RabbitMQ ブローカーの相互 TLS (mTLS) をサポートしています。[SSL 認証プラグイン](https://github.com/rabbitmq/rabbitmq-auth-mechanism-ssl)は、mTLS 接続のクライアント証明書を使用してユーザーを認証します。このプラグインは、ブローカーの設定に基づいて条件付きで有効になります。有効にすると、ネットワーク経由で認証情報を送信せずに、X.509 クライアント証明書を使用して証明書ベースの認証を提供し、強力な認証を実現します。SSL 証明書認証の詳細については、「」を参照してください[SSL 証明書認証](ssl-for-amq-for-rabbitmq.md)。
**注記**
SSL 証明書認証プラグインは、Amazon MQ for RabbitMQ バージョン 4 以降でのみ使用できます。
## aws プラグイン
[aws プラグイン](https://github.com/rabbitmq/rabbitmq-aws)は、ブローカーの設定に基づいて Amazon MQ for RabbitMQ によって条件付きで有効になります。Amazon MQ によって開発および保守されているこのコミュニティプラグインは、RabbitMQ 構成設定で AWS ARNs を使用して AWS のサービスから認証情報と証明書を安全に取得できます。ARN サポートの詳細については、「」を参照してください[RabbitMQ 設定での ARN サポート](arn-support-rabbitmq-configuration.md)。
## JMS Topic Exchange プラグイン
[JMS Topic Exchange プラグイン](https://github.com/rabbitmq/rabbitmq-server/tree/main/deps/rabbitmq_jms_topic_exchange)は、Amazon MQ for RabbitMQ によって常に有効になります。[RabbitMQ JMS クライアント](https://github.com/rabbitmq/rabbitmq-jms-client)と連携して、新規および既存の JMS アプリケーションが Amazon MQ for RabbitMQ に接続できるようにします。
**注記**
JMS Topic Exchange プラグインは、Amazon MQ for RabbitMQ バージョン 4 以降でのみ使用できます。デフォルトでは有効になっていますが、RabbitMQ JMS クライアントが JMS ワークロードの実行に使用されている場合にのみアクティブ化されます。
# サポートされるプロトコル
RabbitMQ ブローカーにアクセスするには、[RabbitMQ がサポートする任意のプログラミング言語](https://www.rabbitmq.com/client-libraries/devtools)を使用し、次のいずれかのプロトコル仕様で TLS を有効にします。
+ [AMQP (0-9-1)](https://www.rabbitmq.com/docs/extensions)
+ [AMQP 1.0](https://www.rabbitmq.com/docs/amqp)
+ [JMS 1.1](https://www.rabbitmq.com/client-libraries/jms-client)
+ [JMS 2.0](https://www.rabbitmq.com/client-libraries/jms-client)
+ [JMS 3.1](https://www.rabbitmq.com/client-libraries/jms-client)
# Amazon MQ for RabbitMQ JMS のサポート
RabbitMQ JMS クライアントを使用して、Amazon MQ for RabbitMQ 4 で JMS 1.1、2.0RabbitMQ3.1 ワークロードを実行できるようになりました。 RabbitMQ
## RabbitMQ JMS クライアント
RabbitMQ JMS クライアントは、JMS アプリケーションを Amazon MQ RabbitMQ ブローカーに接続するために必要なオープンソースの JMS クライアントライブラリです。詳細については、[公式の GitHub リポジトリ](https://github.com/rabbitmq/rabbitmq-jms-client)を参照してください。
## サポートされている JMS 1.1、2.0、3.1 APIs
Amazon MQ for RabbitMQ 4 以降では、プラグイン`jms-topic-exchange`は常に有効になっています。したがって、JMS ワークロードには Amazon MQ for RabbitMQ 4 および RabbitMQ JMS クライアントを使用できます。JMS 1.1 で定義されているすべての JMS APIs は、以下を除いてサポートされています。 [https://javaee.github.io/jms-spec/pages/JMS20FinalRelease#reference-implementation](https://javaee.github.io/jms-spec/pages/JMS20FinalRelease#reference-implementation)
+ サーバーセッション APIsはサポートされていません。
+ XA トランザクション APIsはサポートされていません。
+ JMS キューの送信先の JMS セレクタはサポートされていません。
+ JMS `NoLocal`サブスクリプション属性はサポートされていません。
JMS 2.0 および JMS 3.1 で新しく追加されたすべての APIs がサポートされています。 [https://javaee.github.io/jms-spec/pages/JMS20FinalRelease#reference-implementation](https://javaee.github.io/jms-spec/pages/JMS20FinalRelease#reference-implementation)
+ `JMSProducer.setDeliveryDelay` API はサポートされていません。
JMS アプリケーションを Amazon MQ for RabbitMQ ブローカーに接続する方法の詳細については、[「JMS アプリケーションを Amazon MQ for RabbitMQ ブローカーに接続する](rabbitmq-tutorial-jms.md)」のチュートリアルを参照してください。
## 認証と認可
[このセクション](rabbitmq-authentication.md)に記載されているすべての認証および認可メカニズムがサポートされています。JMS クライアントを使用してブローカーに接続するために使用される認証情報は、AMQP Java クライアントを使用して RabbitMQ ブローカーに接続する場合と同じです。
## RabbitMQ での AMQP キューとの相互運用性
RabbitMQ JMS クライアントを使用して JMS メッセージを AMQP 交換に送信し、AMQP キューからのメッセージを消費できます (この機能は JMS トピックをサポートしていません）。これにより、特定の JMS ワークロードを AMQP ワークロードに相互運用または移行できます。詳細については、[公式のクライアントドキュメント](https://rabbitmq.github.io/rabbitmq-jms-client/2.x/stable/htmlsingle/index.html#destination-interoperability)を参照してください。
# Amazon MQ for RabbitMQ へのポリシーの適用
Amazon MQ の推奨デフォルト値を持つカスタムのポリシーと制限を適用できます。推奨されるデフォルトポリシーと制限を削除したが、それらを再作成したい、または追加の vhost を作成して、新しい vhost にデフォルトのポリシーと制限を適用したいという場合は、以下のステップを実行できます。
**重要**
Amazon MQ for RabbitMQ エンジンバージョン 3.13 以前では、現在のデフォルトのオペレータポリシーは次のとおりです。
```
vhost name pattern apply-to definition priority/ default_operator_policy_AWS_managed .* classic_queues {"ha-mode":"all","ha-sync-mode":"automatic","queue-version":2} 0
```
バージョン 4.0 以降では、デフォルトの演算子ポリシーが次のように変更されました。
```
vhost name pattern apply-to definition priority/ default_operator_policy_AWS_managed .* classic_queues {"queue-version":2} 0
```
この変更は、従来のキューミラーリングと HA ポリシー設定が RabbitMQ 4 でサポートされていないために必要です。
従来のミラーキューとクォーラムキューの両方に適用されるポリシーを作成することはできません。ポリシーをクォーラムキューにのみ適用する場合は、`--apply-to` を `quorum_queues` に設定する必要があります。従来のミラーキューとクォーラムキューを使用している場合は、クォーラムキューポリシーに加えて、`--apply-to:classic_queues` を設定した別のポリシーを作成する必要があります。
**重要**
以下のステップを実行するには、管理者権限を持つ Amazon MQ for RabbitMQ ブローカーユーザーが必要です。ブローカーを初めて作成したときに作成された管理者ユーザー、またはその後で作成した別のユーザーを使用できます。以下の表は、正規表現 (regexp) パターンとしての必要な管理者ユーザータグと許可です。
| タグ | 読み込み regexp | 設定 regexp | 書き込み regexp |
| --- | --- | --- | --- |
| administrator | .\$1 | .\$1 | .\$1 |
RabbitMQ ユーザーの作成、およびユーザータグと許可の管理の詳細については、「[Amazon MQ for RabbitMQ ブローカーのユーザー](rabbitmq-simple-auth-broker-users.md#rabbitmq-basic-elements-user)」を参照してください。
**RabbitMQ ウェブコンソールを使用してデフォルトのポリシーと仮想ホスト制限を適用する**
1. [Amazon MQ コンソール](https://console.aws.amazon.com/amazon-mq/)にサインインします。
1. 左側のナビゲーションペインで [**Brokers**] (ブローカー) をクリックします。
1. ブローカーのリストから、新しいポリシーを適用するブローカーの名前を選択します。
1. ブローカーの詳細ページの [**Connections**] (接続) セクションで、**RabbitMQ ウェブコンソール** URL をクリックします。RabbitMQ ウェブコンソールが新しいブラウザタブまたはウィンドウで開きます。
1. ブローカー管理者のユーザー名とパスワードを使用して RabbitMQ ウェブコンソールにログインします。
1. RabbitMQ ウェブコンソールのページ上部で、[**Admin**] (管理) をクリックします。
1. [**Admin**] (管理) ページの右側にあるナビゲーションペインで [**Policies**] (ポリシー) をクリックします。
1. [**Policies**] (ポリシー) ページに、ブローカーの現在の [**User policies**] (ユーザーポリシー) が表示されます。[**User policies**] (ユーザーポリシー) の下で、[**Add / update a policy**] (ポリシーの追加/更新) を展開します。
1. 新しいブローカーポリシーを作成するには、[**Add / update a policy**] (ポリシーの追加/更新) で以下を実行します。
1. [**Virtual host**] (仮想ホスト) には、ドロップダウンリストからポリシーをアタッチする仮想ホストの名前を選択します。デフォルト vhost を選択するには、[**/**] を選択します。
**注記**
追加の vhost を作成していない場合は、RabbitMQ コンソールに [**Virtual host**] (仮想ホスト) オプションが表示されず、デフォルト vhost のみにポリシーが適用されます。
1. [**Name**] (名前) には、ポリシーの名前 (**policy-defaults** など) を入力します。
1. [**Pattern**] (パターン) には regexp パターン **.\$1** を入力して、ポリシーがブローカー上のすべてのキューと一致するようにします。
1. [**Apply to**] (適用先) には、ドロップダウンリストから [**Exchanges and queues**] (エクスチェンジとキュー) を選択します。
1. [**Priority**] (優先順位) には、vhost に適用されたその他すべてのポリシーよりも大きい整数を入力します。RabbitMQ のキューとエクスチェンジに適用できるのは、常に 1 つのポリシー定義セットのみです。RabbitMQ は、一致するポリシーで、最高の優先順位値を持つものを選択します。ポリシーの優先順位とポリシーの結合方法の詳細については、RabbitMQ サーバードキュメントの「[Policies](https://www.rabbitmq.com/parameters.html#policies)」を参照してください。
1. [**Definition**] (定義) には、以下のキーバリューペアを追加します。
+ **queue-mode**=**lazy**。ドロップダウンリストから [**String**] (文字列) を選択します。
+ **overflow**=**reject-publish**。ドロップダウンリストから [**String**] (文字列) を選択します。
**注記**
単一インスタンスブローカーには適用されません。
+ **max-length**=***number-of-messages***。*number-of-messages* は、ブローカーのインスタンスサイズとデプロイモードに従った [Amazon MQ の推奨値](rabbitmq-defaults.md#rabbitmq-defaults-values) (例えば、`mq.m7g.large` クラスターには **8000000**) に置き換えます。ドロップダウンリストから [**Number**] (数値) を選択します。
**注記**
単一インスタンスブローカーには適用されません。
1. [**Add / update policy**] (ポリシーを追加/更新) をクリックします。
1. [**User policies**] (ユーザーポリシー) リストに新しいポリシーが表示されることを確認します。
**注記**
クラスターブローカーの場合、Amazon MQ が `ha-mode: all` および `ha-sync-mode: automatic` ポリシー定義を自動的に適用します。
1. 右側のナビゲーションペインで [**Limits**] (制限) をクリックします。
1. [**Limits**] (制限) ページに、ブローカーの現在の [**Virtual host limits**] (仮想ホストの制限) が表示されます。[**Virtual host limits**] (仮想ホスト制限) で、[**Set / update a virtual host limit**] (仮想ホスト制限の設定/更新) を展開します。
1. 新しい vhost 制限を作成するには、[**Set / update a virtual host limit**] (仮想ホスト制限の設定/更新) で以下を実行します。
1. [**Virtual host**] (仮想ホスト) には、ドロップダウンリストからポリシーをアタッチする仮想ホストの名前を選択します。デフォルト vhost を選択するには、[**/**] を選択します。
1. [**Limit**] (制限) には、ドロップダウンオプションから [**max-connections**] を選択します。
1. [**Value**] (値) には、ブローカーのインスタンスサイズとデプロイモードに従った [Amazon MQ の推奨値](rabbitmq-defaults.md#rabbitmq-defaults-values) (例えば、`mq.m5.large` クラスターには **15000**) を入力します。
1. [**Set / update limit**] (制限を設定/更新) をクリックします。
1. 上記のステップを繰り返します。[**Limit**] (制限) には、ドロップダウンオプションから [**max-queues**] を選択します。
1. 新しい制限が **[仮想ホスト制限]** リストに表示されていることを確認します。
**RabbitMQ Management API を使用してデフォルトのポリシーと仮想ホスト制限を適用する**
1. [Amazon MQ コンソール](https://console.aws.amazon.com/amazon-mq/)にサインインします。
1. 左側のナビゲーションペインで [**Brokers**] (ブローカー) をクリックします。
1. ブローカーのリストから、新しいポリシーを適用するブローカーの名前を選択します。
1. ブローカーのページの [**Connections**] (接続) セクションで、**RabbitMQ ウェブコンソール** URL をメモします。これは、HTTP リクエストで使用するブローカーエンドポイントです。
1. 任意の新しいターミナルまたはコマンドラインウィンドウを開きます。
1. 新しいブローカーポリシーを作成するには、以下の `curl` コマンドを入力します。このコマンドでは、`%2F` としてエンコードされているデフォルト `/` vhost 上のキューを前提としています。別の vhost にポリシーを適用するには、`%2F` をその vhost の名前に置き換えてください。
**注記**
*ユーザー名*と*パスワード*を、管理者のサインイン認証情報に置き換えます。*number-of-messages* を、ブローカーのインスタンスサイズとデプロイモードに従った [Amazon MQ の推奨値](rabbitmq-defaults.md#rabbitmq-defaults-values)に置き換えます。*policy-name* をポリシーの名前に置き換えます。*broker-endpoint* を先ほどメモした URL に置き換えます。
```
curl -i -u username:password -H "content-type:application/json" -XPUT \
-d '{"pattern":".*", "priority":1, "definition":{"queue-mode":lazy, "overflow":"reject-publish", "max-length":"number-of-messages"}}' \
broker-endpoint/api/policies/%2F/policy-name
```
1. 新しいポリシーがブローカーのユーザーポリシーに追加されていることを確認するには、以下の `curl` コマンドを入力して、すべてのブローカーポリシーをリストします。
```
curl -i -u username:password broker-endpoint/api/policies
```
1. 新しい `max-connections` 仮想ホスト制限を作成するには、以下の `curl` コマンドを入力します。このコマンドでは、`%2F` としてエンコードされているデフォルト `/` vhost 上のキューを前提としています。別の vhost にポリシーを適用するには、`%2F` をその vhost の名前に置き換えてください。
**注記**
*ユーザー名*と*パスワード*を、管理者のサインイン認証情報に置き換えます。*max-connections* を、ブローカーのインスタンスサイズとデプロイモードに従った [Amazon MQ の推奨値](rabbitmq-defaults.md#rabbitmq-defaults-values)に置き換えます。ブローカーエンドポイントを先ほどメモした URL に置き換えます。
```
curl -i -u username:password -H "content-type:application/json" -XPUT \
-d '{"value":"number-of-connections"}' \
broker-endpoint/api/vhost-limits/%2F/max-connections
```
1. 新しい `max-queues` 仮想ホスト制限を作成するには、前のステップを繰り返しますが、curl コマンドを以下のように変更します。
```
curl -i -u username:password -H "content-type:application/json" -XPUT \
-d '{"value":"number-of-queues"}' \
broker-endpoint/api/vhost-limits/%2F/max-queues
```
1. 新しい制限がブローカーの仮想ホスト制限に追加されていることを確認するには、以下の `curl` コマンドを入力して、すべてのブローカー仮想ホスト制限をリストします。
```
curl -i -u username:password broker-endpoint/api/vhost-limits
```
# Amazon MQ での RabbitMQ のクォーラムキュー
クォーラムキューは、1 つのリーダー (プライマリレプリカ) と複数のフォロワー (その他のレプリカ) で構成されるレプリケーション型のキュータイプです。リーダーが利用不可能になった場合、クォーラムキューでは、[Raft](https://raft.github.io/) コンセンサスアルゴリズムを使用して多数決で新しいリーダーノードが選出され、前のリーダーは同じクラスター内のフォロワーノードに降格されます。残りのフォロワーは、以前と同様にレプリケーションを続行します。各ノードは別々のアベイラビリティーゾーンにあるため、1 つのノードが一時的に利用できなくなっても、メッセージ配信は別のアベイラビリティーゾーンにある新しく選出されたリーダーレプリカによって続行されます。
クォーラムキューは、メッセージが失敗し、キューに何度も入れ直されたときに発生する有害メッセージを処理するために役立ちます。
以下の場合はクォーラムキューを使用しないでください。
+ 一時キューを使用する場合
+ 長いキューバックログがある場合
+ 低レイテンシーを優先する場合
クォーラムキューを宣言するには、ヘッダー `x-queue-type` を `quorum` に設定します。
**Topics**
+ [
# Amazon MQ for RabbitMQ での従来のキューからクォーラムキューへの移行
](quorum-queues-migration.md)
+ [
# Amazon MQ for RabbitMQ のクォーラムキューのポリシー設定
](quorum-queues-policy-configurations.md)
+ [
# Amazon MQ for RabbitMQ のクォーラムキューのベストプラクティス
](quorum-queues-best-practices.md)
# Amazon MQ for RabbitMQ での従来のキューからクォーラムキューへの移行
従来のミラーキューを、バージョン 3.13 以降の Amazon MQ ブローカーのクォーラムキューに移行することができます。そのためには、同じクラスター上に新しい仮想ホストを作成する方法と、インプレースで移行する方法があります。
## オプション 1: 新しい仮想ホストを使用した従来のミラーキューからクォーラムキューへの移行
同じクラスター上に新しい仮想ホストを作成することで、従来のミラーキューをバージョン 3.13 以降の Amazon MQ ブローカーのクォーラムキューに移行できます。
1. 既存のクラスターで、デフォルトのキュータイプをクォーラムとする新しい仮想ホスト (vhost) を作成します。
1. 新しい vhost から [フェデレーションプラグイン](rabbitmq-basic-elements-plugins.md#rabbitmq-federation-plugin)を作成して、従来のミラーキューを使用する以前の vhost を指す URL を指定します。
1. `rabbitmqadmin` を使用して、以前の vhost から新しいファイルに定義をエクスポートします。このスキーマファイルを変更して、クォーラムキューとの互換性を持たせる必要があります。ファイルに加える必要のある変更の完全なリストについては、RabbitMQ クォーラムキュードキュメントの「[Moving definitions](https://www.rabbitmq.com/blog/2023/03/02/quorum-queues-migration#moving-definitions)」を参照してください。必要な変更をファイルに適用したら、新しい vhost に定義を再インポートします。
1. 新しい vhost に新しいポリシーを作成します。クォーラムキュー向けの Amazon MQ ポリシー設定に関する推奨事項については、「[Amazon MQ for RabbitMQ のクォーラムキューのポリシー設定](quorum-queues-policy-configurations.md)」を参照してください。次に、前の手順で作成した、以前の vhost から新しい vhost へのフェデレーションを開始します。
1. コンシューマーとプロデューサーが新しい vhost を指すように設定します。
1. Shovel プラグインを設定して、残っているメッセージをすべて移動します。キューが空になったら、Shovel を削除します。
## 従来のミラーキューからクォーラムキューへのインプレース移行
従来のミラーキューを、バージョン 3.13 以降の Amazon MQ ブローカーのクォーラムキューにインプレースで移行できます。
1. コンシューマーとプロデューサーを停止します。
1. 新しい一時クォーラムキューを作成します。
1. Shovel プラグインを設定して、以前の従来のミラーキューから新しい一時クォーラムキューにすべてのメッセージを移動します。すべてのメッセージが一時クォーラムキューに移動されたら、Shovel を削除します。
1. 移行元の従来のミラーキューを削除します。次に、移行元の従来のミラーキューと同じ名前とバインディングでクォーラムキューを再作成します。
1. 新しい Shovel を作成して、一時クォーラムキューから新しいクォーラムキューにメッセージを移動します。
# Amazon MQ for RabbitMQ のクォーラムキューのポリシー設定
Amazon MQ 上の RabbitMQ ブローカーのクォーラムキューに、特定のポリシー設定を追加できます。
クォーラムキューのポリシーを作成するときは、次の操作を実行する必要があります。
+ `ha` で始まるポリシー属性をすべて削除します。`ha-mode`、`ha-params`、`ha-sync-mode`、`ha-sync-batch-size`、`ha-promote-on-shutdown`、`ha-promote-on-failure` などが該当します。
+ `queue-mode` を削除します。
+ オーバーフローが `reject-publish-dlx` に設定されている場合は変更します。
**重要**
Amazon MQ for RabbitMQ は、ポリシー内のすべての属性を適用するか、一切適用しないかのどちらかの動作になります。従来のミラーキューとクォーラムキューの両方に適用されるポリシーを作成することはできません。ポリシーをクォーラムキューにのみ適用する場合は、`--apply-to` を `quorum_queues` に設定する必要があります。従来のミラーキューとクォーラムキューを使用している場合は、クォーラムキューポリシーに加えて、`--apply-to`:`classic_queues` を設定した別のポリシーを作成する必要があります。
`AWS-DEFAULT` ポリシーは、「適用先」パラメータに自動的に新しいキュータイプを採用するため、変更する必要はありません。Amazon MQ for RabbitMQ のデフォルトポリシーの詳細については、「[オペレーターポリシーの設定](configurable-values.md#configuring-operator-policies)」を参照してください。
# Amazon MQ for RabbitMQ のクォーラムキューのベストプラクティス
クォーラムキューを使用する際のパフォーマンスを向上させるには、次のベストプラクティスを使用することをお勧めします。
## 配信制限を設定して有害メッセージを処理する
有害メッセージは、メッセージが失敗し、何度も再配信される場合に発生します。`delivery-limit` ポリシー引数を使用してメッセージ配信制限を設定すると、何度も再配信されるメッセージを削除できます。配信制限で許容される回数を超えてメッセージが再配信された場合、メッセージは RabbitMQ によってドロップされ、削除されます。配信制限を設定すると、メッセージはキューの先頭の近くに再び入れられます。
## クォーラムキューのメッセージ優先度
クォーラムキューにはメッセージ優先度がありません。メッセージ優先度が必要な場合は、複数のクォーラムキューを作成する必要があります。複数のクォーラムキューを持つメッセージの優先度設定の詳細については、RabbitMQ ドキュメントの「[Message priority](https://www.rabbitmq.com/docs/quorum-queues#priorities)」を参照してください。
## デフォルトのレプリケーション係数の使用
Amazon MQ for RabbitMQ では、クォーラムキューを使用するクラスターブローカーのレプリケーション係数はデフォルトで 3 ノードになります。`x-quorum-initial-group-size` に変更を加えると、Amazon MQ は、再びデフォルトでレプリケーション係数 3 を使用するようになります。
# Amazon MQ for RabbitMQ のベストプラクティス
Amazon MQ for RabbitMQ ブローカーを使用する際にブローカーのパフォーマンスを最大化し、メッセージのスループット効率を最適化するには、以下の本番の準備状況ガイドラインに従ってください。
**重要**
現在、Amazon MQ は[ストリーム](https://www.rabbitmq.com/streams.html)や、RabbitMQ 3.9.x で導入された JSON での構造化ロギングの使用をサポートしていません。
**Topics**
+ [
# Amazon MQ for RabbitMQ でのブローカーのセットアップと接続管理のベストプラクティス
](best-practices-broker-setup.md)
+ [
# Amazon MQ for RabbitMQ でのメッセージの耐久性と信頼性に関するベストプラクティス
](best-practices-message-reliability.md)
+ [
# Amazon MQ for RabbitMQ のパフォーマンス最適化と効率のベストプラクティス
](best-practices-performance.md)
+ [
# Amazon MQ for RabbitMQ でのネットワークの耐障害性とモニタリングのベストプラクティス
](best-practices-network-resilience.md)
# Amazon MQ for RabbitMQ でのブローカーのセットアップと接続管理のベストプラクティス
ブローカーのセットアップと接続管理は、ブローカーメッセージのスループット、リソース使用率、本番環境のワークロードを処理する機能に関する問題を防ぐ最初のステップです。[Amazon MQ for RabbitMQ ブローカーを作成および設定する](getting-started-rabbitmq.md#create-rabbitmq-broker)ときは、適切なインスタンスタイプの選択、接続の効率的な管理、ブローカーのパフォーマンスを最大化するためのメッセージプリフェッチの設定に関する以下のベストプラクティスを完了してください。
**重要**
Amazon MQ for RabbitMQ では、ユーザー名「guest」はサポートされず、デフォルトのゲストアカウントは新しいブローカーの作成時に削除されます。ユーザーが作成した「guest」というアカウントも、Amazon MQ によって定期的に削除されます。
## ステップ 1: クラスターデプロイを使用する
本番ワークロードでは、高可用性とメッセージの耐障害性を確保するために、単一インスタンスブローカーの代わりにクラスターデプロイを使用することをお勧めします。クラスターデプロイでは、単一障害点が削除され、耐障害性が向上します。
クラスターデプロイは、3 つのアベイラビリティーゾーンに分散された 3 つの RabbitMQ ブローカーノードで構成され、自動フェイルオーバーを提供し、アベイラビリティーゾーン全体が使用できなくなってもオペレーションが続行されるようにします。Amazon MQ は、すべてのノードにメッセージを自動的にレプリケートし、ノードの障害時やメンテナンス時の可用性を確保します。
クラスターのデプロイは本番環境に不可欠であり、[Amazon MQ サービスレベルアグリーメント](https://aws.amazon.com/amazon-mq/sla/)でサポートされています。
詳細については、「[Amazon MQ for RabbitMQ でのクラスターデプロイ](rabbitmq-broker-architecture.md#rabbitmq-broker-architecture-cluster)」を参照してください。
## ステップ 2: 正しいブローカーインスタンスタイプを選択する
ブローカーインスタンスタイプのメッセージスループットは、アプリケーションのユースケースによって異なります。`M7g.medium` はアプリケーションパフォーマンスのテストにのみ使用する必要があります。本番環境で大きいインスタンスを使用する前に、この小さいインスタンスを使用すると、アプリケーションのパフォーマンスを向上させることができます。`m7g.large` 以上のインスタンスタイプでは、クラスターデプロイを使用して高可用性とメッセージの耐久性を確保できます。大きいブローカーインスタンスタイプは、本番稼働レベルのクライアントとキュー、高スループット、メモリ内のメッセージ、冗長メッセージを処理できます。
適切なインスタンスタイプを選択する方法の詳細については、「[Amazon MQ for RabbitMQ のサイズ設定ガイドライン](rabbitmq-sizing-guidelines.md)」を参照してください。
## ステップ 3: クォーラムキューを使用する
クラスターデプロイのクォーラムキューは、3.13 以降の RabbitMQ ブローカーの本番環境でレプリケートされたキュータイプのデフォルトの選択肢である必要があります。クォーラムキューは、高い信頼性、高スループット、安定したレイテンシーを提供する最新のレプリケートキュータイプです。
クォーラムキューは Raft コンセンサスアルゴリズムを使用して耐障害性を向上させます。リーダーノードが使用できなくなると、クォーラムキューは過半数投票によって自動的に新しいリーダーを選択し、メッセージ配信が中断を最小限に抑えながら継続されるようにします。各ノードは異なるアベイラビリティーゾーンにあるため、1 つのアベイラビリティーゾーン全体が一時的に使用できなくなってもメッセージングシステムは引き続き使用できます。
クォーラムキューを宣言するには、キューの作成時に `x-queue-type` ヘッダーを `quorum` に設定します。
移行戦略やベストプラクティスなど、クォーラムキューの詳細については、「[Amazon MQ for RabbitMQ のクォーラムキュー](quorum-queues.md)」を参照してください。
## ステップ 4: 複数のチャネルを使用する
接続チャーンを回避するには、1 つの接続で複数のチャネルを使用します。アプリケーションでは、チャネルに対する 1:1 の接続を避ける必要があります。プロセスごとに 1 つの接続を使用し、スレッドごとに 1 つのチャネルを使用することをお勧めします。チャネルのリークを防ぐために、チャネルを過剰に使用することは避けてください。
# Amazon MQ for RabbitMQ でのメッセージの耐久性と信頼性に関するベストプラクティス
アプリケーションを本番環境に移行する前に、メッセージの損失とリソースの過剰使用を防ぐための以下のベストプラクティスを完了してください。
## ステップ 1: 永続メッセージと持続キューを使用する
永続メッセージは、ブローカーがクラッシュまたは再起動するという状況におけるデータの耐久性の保護に役立ちます。永続メッセージは、到着するとすぐにディスクに書き込まれますが、レイジーキューとは異なり、ブローカーがより多くのメモリを必要とする場合を除き、永続メッセージはメモリとディスクの両方にキャッシュされます。より多くのメモリが必要な場合は、ディスクへのメッセージの保存を管理する RabbitMQ ブローカーメカニズム (一般に*永続レイヤー*と呼ばれます) によって、メモリからメッセージが削除されます。
メッセージの永続性を有効にするには、キューを `durable` として宣言し、メッセージ配信モードを `persistent` に設定できます。以下の例は、[RabbitMQ Java クライアントライブラリ](https://www.rabbitmq.com/java-client.html)を使用した持続キューの宣言を示しています。AMQP 0-9-1 を使用している場合は、配信モード「2」を設定することで、メッセージを永続としてマークできます。
```
boolean durable = true;
channel.queueDeclare("my_queue", durable, false, false, null);
```
キューを持続キューとして設定したら、以下の例にあるように、`MessageProperties` を `PERSISTENT_TEXT_PLAIN` に設定することによって永続メッセージをキューに送信できます。
```
import com.rabbitmq.client.MessageProperties;
channel.basicPublish("", "my_queue",
MessageProperties.PERSISTENT_TEXT_PLAIN,
message.getBytes());
```
## ステップ 2: パブリッシャーの確認とコンシューマーの配信承認の設定
ブローカーにメッセージが送信されたことを確認するプロセスは、*パブリッシャーの確認*と呼ばれます。パブリッシャーは、メッセージが確実に格納されたときにアプリケーションに通知します。パブリッシャーの確認は、ブローカーに格納されるメッセージの割合を制御するためにも役立ちます。パブリッシャーの確認がないと、メッセージが正常に処理されたという確認が得られないため、ブローカーは処理できないメッセージをドロップする可能性があります。
同様に、クライアントアプリケーションはメッセージの配信と消費の確認をブローカーに返送します。これは*コンシューマーの配信承認*と呼ばれます。RabbitMQ ブローカーの使用時にデータの安全性を確保するには、確認と承認の両方が不可欠です。
コンシューマーの配信承認は、通常クライアントアプリケーションで設定されています。AMQP 0-9-1 を使用している場合は、`basic.consume` メソッドを設定することで承認を有効化できます。AMQP 0-9-1 クライアントでは、`confirm.select` メソッドを送信してパブリッシャーの確認を設定することもできます。
通常、配信承認はチャネルで有効化されます。例えば、RabbitMQ Java クライアントライブラリの使用時には、以下の例にあるように、`Channel#basicAck` を使用してシンプルな `basic.ack` 肯定承認をセットアップできます。
```
// this example assumes an existing channel instance
boolean autoAck = false;
channel.basicConsume(queueName, autoAck, "a-consumer-tag",
new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag,
Envelope envelope,
AMQP.BasicProperties properties,
byte[] body)
throws IOException
{
long deliveryTag = envelope.getDeliveryTag();
// positively acknowledge a single delivery, the message will
// be discarded
channel.basicAck(deliveryTag, false);
}
});
```
**注記**
未承認メッセージは、メモリにキャッシュする必要があります。コンシューマーがプリフェッチするメッセージの数は、クライアントアプリケーションの[プリフェッチ](best-practices-performance.md#configure-prefetching)を設定することによって制限できます。
`consumer_timeout` を設定すると、コンシューマーから配信承認が届かない状況を検出できます。コンシューマーがタイムアウト値の時間内に承認を送信しない場合、チャネルは閉じられ、`PRECONDITION_FAILED` が発生します。エラーを診断するには、[UpdateConfiguration](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/configurations-configuration-id.html) API を使用して `consumer_timeout` 値を大きくします。
## ステップ 3: キューを短くしておく
クラスターデプロイでは、多数のメッセージを持つキューがリソースの過剰な使用につながる場合があります。ブローカーが過剰に使用されているときは、Amazon MQ for RabbitMQ ブローカーの再起動がパフォーマンスをさらに低下させる原因となる可能性があります。過剰に使用されているブローカーが再起動されると、`REBOOT_IN_PROGRESS` 状態のまま応答しなくなることがあります。
Amazon MQ は[メンテナンスウィンドウ](amazon-mq-rabbitmq-editing-broker-preferences.md#rabbitmq-edit-current-configuration-console)中、すべてのメンテナンス作業を一度に 1 ノードずつ実行して、ブローカーが動作可能な状態を維持することを確実にします。その結果、各ノードが操作を再開するときに、キューが同期する必要が生じる場合があります。同期中、ミラーにレプリケートする必要があるメッセージは、バッチで処理されるように、対応する Amazon Elastic Block Store (Amazon EBS) ボリュームからメモリにロードされます。メッセージをバッチで処理することにより、キューの同期が速くなります。
キューを短くし、メッセージを小さくしておくと、キューが正常に同期し、期待通りに操作を再開します。ただし、バッチ内のデータ量がノードのメモリ制限に近づいた場合は、ノードが高メモリアラームを発し、キューの同期を一時停止します。メモリ使用量は、[CloudWatch で `RabbitMemUsed` および `RabbitMqMemLimit` のブローカーノードメトリクス](amazon-mq-accessing-metrics.md)を比較することで確認できます。同期は、メッセージが消費もしくは削除される、またはバッチ内のメッセージの数が減るまで完了できません。
クラスターデプロイのためにキューの同期化が一時停止される場合は、メッセージを消費または削除して、キュー内のメッセージの数を減らすことをお勧めします。キュー深度が減少し、キューの同期が完了すると、ブローカーのステータスが `RUNNING` に変更されます。一時停止されたキューの同期を解決するには、[キューの同期のバッチサイズを小さくする](rabbitmq-queue-sync.md)ポリシーを適用することも可能です。
また、自動削除ポリシーと TTL ポリシーを定義すると、リソースの使用量をプロアクティブに削減するとともに、コンシューマーからの NACK を最小限に抑えることができます。ブローカーへのメッセージの再キュー処理は CPU 負荷が高いため、大量の NACK が発生するとブローカーのパフォーマンスに影響する可能性があります。
# Amazon MQ for RabbitMQ のパフォーマンス最適化と効率のベストプラクティス
Amazon MQ for RabbitMQ ブローカーのパフォーマンスを最適化するには、スループットを最大化し、レイテンシーを最小限に抑え、効率的なリソース使用率を確保します。アプリケーションのパフォーマンスを最適化するには、次のベストプラクティスを実行します。
## ステップ 1: メッセージサイズを 1 MB 未満に維持する
最適なパフォーマンスと信頼性を得るには、メッセージを 1 メガバイト (1 MB) 未満にしておくことをお勧めします。
RabbitMQ 3.13 はデフォルトで最大 128 MB のメッセージサイズをサポートしますが、大きなメッセージは、発行をブロックし、ノード間でメッセージをレプリケートしながら高いメモリ負荷を発生させる可能性のある予測不可能なメモリアラームをトリガーする可能性があります。メッセージのサイズが大きすぎると、ブローカーの再起動プロセスや復旧プロセスにも影響し、サービス継続性に対するリスクが高まり、パフォーマンスが低下する可能性があります。
**クレームチェックパターンを使用して大きなペイロードを保存および取得する**
大きなメッセージを管理するには、メッセージペイロードを外部ストレージに保存し、RabbitMQ を介してペイロード参照識別子のみを送信することにより、クレームチェックパターンを実装できます。コンシューマーはペイロード参照識別子を使用して、大きなメッセージを取得して処理します。
次の図は、Amazon MQ for RabbitMQ と Amazon S3 を使用してクレームチェックパターンを実装する方法を示しています。
![\[Diagram showing data flow between Producer, Consumer, Amazon MQ broker, and AWS S3.\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/claim-check-pattern.png)
次の例は、Amazon MQ、[AWS SDK for Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/home.html)、[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) を使用したこのパターンを示しています。
1. まず、Amazon S3 参照識別子を保持する Message クラスを定義します。
```
class Message {
// Other data fields of the message...
public String s3Key;
public String s3Bucket;
}
```
1. Amazon S3 にペイロードを保存し、RabbitMQ を介してリファレンスメッセージを送信するパブリッシャーメソッドを作成します。
```
public void publishPayload() {
// Store the payload in S3.
String payload = PAYLOAD;
String prefix = S3_KEY_PREFIX;
String s3Key = prefix + "/" + UUID.randomUUID();
s3Client.putObject(PutObjectRequest.builder()
.bucket(S3_BUCKET).key(s3Key).build(),
RequestBody.fromString(payload));
// Send the reference through RabbitMQ.
Message message = new Message();
message.s3Key = s3Key;
message.s3Bucket = S3_BUCKET;
// Assign values to other fields in your message instance.
publishMessage(message);
}
```
1. Amazon S3 からペイロードを取得し、ペイロードを処理して、Amazon S3 オブジェクトを削除するコンシューマーメソッドを実装します。
```
public void consumeMessage(Message message) {
// Retrieve the payload from S3.
String payload = s3Client.getObjectAsBytes(GetObjectRequest.builder()
.bucket(message.s3Bucket).key(message.s3Key).build())
.asUtf8String();
// Process the complete message.
processPayload(message, payload);
// Delete the S3 object.
s3Client.deleteObject(DeleteObjectRequest.builder()
.bucket(message.s3Bucket).key(message.s3Key).build());
}
```
## ステップ 2: `basic.consume` と存続期間の長いコンシューマーを使用する
存続期間の長いコンシューマーで `basic.consume` を使用すると、`basic.get` を使用して個々のメッセージをポーリングするよりも効率的です。詳細については、「[個々のメッセージのポーリング](https://www.rabbitmq.com/docs/3.13/consumers#polling)」を参照してください。
## ステップ 3: プリフェッチを設定する
RabbitMQ のプリフェッチ値を使用して、コンシューマーがメッセージを消費する方法を最適化できます。RabbitMQ は、プリフェッチ数をチャネルではなくコンシューマーに適用することによって、AMQP 0-9-1 が提供するチャネルプリフェッチメカニズムを実装します。プリフェッチ値は、特定の時間にコンシューマに送信されるメッセージの数を指定するために使用されます。デフォルトで、RabbitMQ はクライアントアプリケーションに無制限のバッファサイズを設定します。
RabbitMQ コンシューマーにプリフェッチ数を設定するときに考慮する要因にはさまざまなものがあります。まず、コンシューマーの環境と設定を考慮します。コンシューマーは、メッセージが処理されるときにそれらすべてをメモリに保持する必要があるため、高いプリフェッチ値はコンシューマーのパフォーマンスに悪影響を及ぼし、場合によってはコンシューマー全体がクラッシュする原因になることもあります。同様に、RabbitMQ ブローカー自体も、コンシューマー承認を受け取るまで、送信するすべてのメッセージをメモリにキャッシュしておきます。コンシューマに自動承認が設定されておらず、コンシューマによるメッセージの処理に比較的長い時間がかかる場合、高いプリフェッチ値は RabbitMQ サーバーのメモリがすぐになくなる原因になる可能性があります。
上記の考慮事項を踏まえて、大量の未処理または未承認のメッセージが原因で RabbitMQ ブローカー、またはそのコンシューマーでメモリ不足が発生する状況を防ぐため、常にプリフェッチ値を設定することが推奨されます。大量のメッセージを処理するためにブローカーを最適化する必要がある場合は、さまざまなプリフェッチ数を使用してブローカーとコンシューマーをテストし、コンシューマーがメッセージを処理するためにかかる時間と比較して、ネットワークオーバーヘッドがおおむね軽微なものになる値を判断します。
**注記**
コンシューマーへのメッセージの配信を自動承認するようにクライアントアプリケーションが設定されている場合、プリフェッチ値を設定しても効果はありません。
プリフェッチされたメッセージはすべて、キューから削除されます。
以下の例は、RabbitMQ Java クライアントライブラリを使用した単一のコンシューマーへのプリフェッチ値 `10` の設定を示しています。
```
ConnectionFactory factory = new ConnectionFactory();
Connection connection = factory.newConnection();
Channel channel = connection.createChannel();
channel.basicQos(10, false);
QueueingConsumer consumer = new QueueingConsumer(channel);
channel.basicConsume("my_queue", false, consumer);
```
**注記**
RabbitMQ Java クライアントライブラリでは、`global` フラグのデフォルト値が `false` に設定されているので、上記の例は単純に `channel.basicQos(10)` として記述できます。
## ステップ 4: Celery 5.5 以降をクォーラムキューで使用する
分散タスクキューシステムである [Python Celery](https://docs.celeryq.dev/en/stable/index.html) は、高いタスクロードが発生している場合に、重要ではないメッセージを多数生成できます。この追加のブローカーアクティビティにより [Amazon MQ for RabbitMQ: 高メモリアラーム](troubleshooting-action-required-codes-rabbitmq-memory-alarm.md) がトリガーされ、ブローカーが利用できなくなる可能性があります。メモリアラームがトリガーされる可能性を減らすには、以下を実行します。
**すべての Celery バージョンの場合**
1. [https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-task_create_missing_queues](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-task_create_missing_queues) をオフにしてキューチャーンを軽減します。
1. 次に、`worker_enable_remote_control` をオフにして、`celery@...pidbox` キューの動的作成を停止します。これにより、ブローカーのキューチャーンが減少します。
```
worker_enable_remote_control = false
```
1. 重要でないメッセージアクティビティをさらに減らすには、Celery アプリケーションを起動するときに `-E` または `--task-events` フラグを付けずに、Celery [worker-send-task-events](https://docs.celeryq.dev/en/stable/userguide/configuration.html#worker-send-task-events) をオフにします。
1. 次のパラメータを使用して Celery アプリケーションを起動します。
```
celery -A app_name worker --without-heartbeat --without-gossip --without-mingle
```
**Celery バージョン 5.5 以降の場合**
1. [Celery バージョン 5.5](https://docs.celeryq.dev/en/latest/changelog.html#version-5-5-0)、クォーラムキューをサポートする最小バージョン、またはそれ以降のバージョンにアップグレードします。使用している Celery のバージョンを確認するには、`celery --version` を使用します。クォーラムキューの詳細については、「[Amazon MQ での RabbitMQ のクォーラムキュー](quorum-queues.md)」を参照してください。
1. Celery 5.5 以降にアップグレードした後、`task_default_queue_type` を ["quorum"](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-task_default_queue_type) に設定します。
1. 次に、[ブローカートランスポートオプション](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-broker_transport_options)で発行確認を有効にする必要もあります。
```
broker_transport_options = {"confirm_publish": True}
```
# Amazon MQ for RabbitMQ でのネットワークの耐障害性とモニタリングのベストプラクティス
信頼性の高いメッセージングアプリケーションを維持するには、ネットワークの耐障害性とブローカーメトリクスのモニタリングが不可欠です。自動復旧メカニズムとリソースモニタリング戦略を実装するには、次のベストプラクティスを実行します。
## ステップ 1: ネットワーク障害から自動的に回復する
RabbitMQ ノードへのクライアント接続が失敗した場合の大幅なダウンタイムを防ぐため、自動ネットワークリカバリを常に有効にしておくことをお勧めします。バージョン `4.0.0` 以降の RabbitMQ Java クライアントライブラリは、自動ネットワークリカバリをデフォルトでサポートします。
自動接続リカバリは、接続の I/O ループで未処理の例外がスローされた場合、ソケット読み取り操作のタイムアウトが検出された場合、またはサーバーが[ハートビート](https://www.rabbitmq.com/heartbeats.html)を受信しない場合にトリガーされます。
クライアントと RabbitMQ ノード間の初期接続が失敗した場合、自動リカバリはトリガーされません。アプリケーションコードは、接続の再試行によって、初期接続障害を考慮するように記述することをお勧めします。以下の例は、RabbitMQ Java クライアントライブラリを使用した初期ネットワーク障害の再試行を示しています。
```
ConnectionFactory factory = new ConnectionFactory();
// enable automatic recovery if using RabbitMQ Java client library prior to version 4.0.0.
factory.setAutomaticRecoveryEnabled(true);
// configure various connection settings
try {
Connection conn = factory.newConnection();
} catch (java.net.ConnectException e) {
Thread.sleep(5000);
// apply retry logic
}
```
**注記**
アプリケーションが `Connection.Close` メソッド使用して接続を閉じる場合、自動ネットワークリカバリは有効化またはトリガーされません。
## ステップ 2: ブローカーメトリクスとアラームをモニタリングする
Amazon MQ for RabbitMQ ブローカーの [CloudWatch メトリクス](amazon-mq-accessing-metrics.md)とアラームを定期的にモニタリングして、メッセージングアプリケーションに影響を与える前に潜在的な問題を特定して対処することをお勧めします。プロアクティブモニタリングは、回復力のあるメッセージングアプリケーションを維持し、最適なパフォーマンスを確保するために不可欠です。
Amazon MQ for RabbitMQ は、ブローカーのパフォーマンス、リソース使用率、メッセージフローに関するインサイトを提供するメトリクスを CloudWatch に発行します。モニタリングする主なメトリクスには、メモリ使用量とディスク使用量が含まれます。ブローカーがリソース制限に近づいたり、パフォーマンスが低下したりしたときの [CloudWatch アラーム](https://docs.aws.amazon.com/Ihttps://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Metrics.html)を設定できます。
次の必須メトリクスをモニタリングします。
**`RabbitMQMemUsed` および `RabbitMQMemLimit`**
メモリ使用量をモニタリングして、メッセージの発行をブロックする可能性のあるメモリアラームを防止します。
**`RabbitMQDiskFree` および `RabbitMQDiskFreeLimit`**
ディスクの使用状況をモニタリングして、ブローカーの障害の原因となるディスク容量の問題を回避します。
クラスターデプロイでは、[ノード固有のメトリクス](rabbitmq-logging-monitoring.md#security-logging-monitoring-cloudwatch-destination-metrics-rabbitmq)もモニタリングして、ノード固有の問題を特定します。
**注記**
高メモリアラームを防ぐ方法の詳細については、「[Address and prevent high memory alarm](troubleshooting-action-required-codes-rabbitmq-memory-alarm.md#address-prevent-high-memory-alarm)」を参照してください。
# RabbitMQ のチュートリアル
以下のチュートリアルでは、Amazon MQ で RabbitMQ を設定して使用する方法を説明します。サポートされているクライアントライブラリを Node.js、Python、.NET などのさまざまなプログラミング言語で使用する方法の詳細については、「*RabbitMQ Getting Started Guide*」の「[RabbitMQ Tutorials](https://www.rabbitmq.com/getstarted.html)」を参照してください。
**Topics**
+ [
# ブローカー設定の編集
](amazon-mq-rabbitmq-editing-broker-preferences.md)
+ [
# Amazon MQ for RabbitMQ でPython Pika を使う
](amazon-mq-rabbitmq-pika.md)
+ [
# RabbitMQ の一時停止されたキュー同期の解決
](rabbitmq-queue-sync.md)
+ [
# 接続およびチャネルの数の削減
](reducing-connections-and-channels.md)
+ [
## ステップ 2: ブローカーに JVM ベースのアプリケーションを接続する
](#rabbitmq-connect-jvm-application)
+ [Connect your Amazon MQ for RabbitMQ broker to Lambda](#rabbitmq-connect-to-lambda)
+ [
# Amazon MQ for RabbitMQ での OAuth 2.0 認証と認可の使用
](oauth-tutorial.md)
+ [
# Amazon MQ for RabbitMQ での IAM 認証と認可の使用
](rabbitmq-iam-tutorial.md)
+ [
# Amazon MQ for RabbitMQ での LDAP 認証と認可の使用
](rabbitmq-ldap-tutorial.md)
+ [
# Amazon MQ for RabbitMQ での HTTP 認証と認可の使用
](rabbitmq-http-tutorial.md)
+ [
# Amazon MQ for RabbitMQ での SSL 証明書認証の使用
](rabbitmq-ssl-tutorial.md)
+ [
# AMQP および管理エンドポイントに mTLS を使用する
](rabbitmq-mtls-tutorial.md)
+ [
# JMS アプリケーションを接続する
](rabbitmq-tutorial-jms.md)
# ブローカー設定の編集
を使用して CloudWatch ログの有効化や無効化など、ブローカーの設定を編集できます AWS マネジメントコンソール。
## RabbitMQ ブローカーオプションを編集する
1. [Amazon MQ コンソール](https://console.aws.amazon.com/amazon-mq/)にサインインします。
1. ブローカーリストからブローカーを選択して (**MyBroker** など)、[**Edit**] (編集) をクリックします。
1. [***MyBroker* の編集**] ページの [**仕様**] セクションで、[**ブローカーエンジンのバージョン**] または [**ブローカーインスタンスタイプ**] を選択します。
1. [**CloudWatch Logs**] セクションのトグルボタンをクリックして、一般ログを有効化または無効化します。これ以上のステップは必要ありません。
**注記**
RabbitMQ ブローカーの場合、Amazon MQ は自動的にサービスリンクロール (SLR) を使用して、CloudWatch に一般ログを発行します。詳細については、「[Amazon MQ のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
Amazon MQ は、RabbitMQ ブローカーに対する監査ロギングをサポートしません。
1. [**Maintenance (メンテナンス)**] セクションで、ブローカーのメンテナンススケジュールを設定します。
ブローカーを AWS リリース時に新しいバージョンにアップグレードするには、「自動**マイナーバージョンアップグレードを有効にする**」を選択します。自動アップグレードは、曜日、時刻 (24 時間形式)、およびタイムゾーン (デフォルトは UTC) で定義された*メンテナンスウィンドウ*中に行われます。
1. [**Schedule modifications (スケジュールの変更)**] を選択します。
**注記**
[**自動マイナーバージョンのアップグレードを有効にする**] のみを選択した場合、ブローカーの再起動が必要ないため、ボタンは [**保存**] に変わります。
設定が指定された時刻にブローカーに適用されます。
# Amazon MQ for RabbitMQ でPython Pika を使う
次のチュートリアルでは、Amazon MQ for RabbitMQ ブローカーに接続するように構成された TLS を使用して [Python Pika](https://github.com/pika/pika) クライアントをセットアップする方法を示しています。Pika は RabbitMQ のための AMQP 0-9-1 プロトコルの Python 実装です。このチュートリアルでは、Pika のインストール、キューの宣言、ブローカーのデフォルトエクスチェンジにメッセージを送信するパブリッシャーの設定、キューからメッセージを受信するコンシューマーの設定について説明します。
**Topics**
+ [
## 前提条件
](#amazon-mq-rabbitmq-pika-prerequisites)
+ [
## 権限
](#amazon-mq-rabbitmq-pika-permissions)
+ [
## ステップ 1: 基本的な Python Pika クライアントを作成する
](#amazon-mq-rabbitmq-pika-basic-client)
+ [
## ステップ 2: パブリッシャーを作成してメッセージを送信する
](#amazon-mq-rabbitmq-pika-publisher-basic-publish)
+ [
## ステップ 3: コンシューマーを作成してメッセージを受信する
](#amazon-mq-rabbitmq-pika-consumer-basic-get)
+ [
## ステップ 4: (オプション) イベントループを設定し、メッセージを消費する
](#amazon-mq-rabbitmq-pika-consumer-basic-consume)
+ [
## 次のステップ
](#amazon-mq-rabbitmq-pika-whats-next)
## 前提条件
このチュートリアルの最初のステップを完了するには、以下のものが必要です。
+ Amazon MQ for RabbitMQ ブローカー。詳細については、「[Amazon MQ for RabbitMQ ブローカーを作成する](getting-started-rabbitmq.md#create-rabbitmq-broker)」を参照してください。
+ オペレーティングシステム用に [Python 3](https://www.python.org/downloads/) がインストールされています。
+ Python `pip` を使用して、[Pika](https://pika.readthedocs.io/en/stable/) がインストールされました。Pika をインストールするには、新しいターミナルウィンドウを開き、以下を実行します。
```
$ python3 -m pip install pika
```
## 権限
このチュートリアルでは、vhost への書き込みおよび読み取りの許可を持つ Amazon MQ for RabbitMQ ブローカーユーザーが少なくとも 1 人必要です。次の表は、正規表現 (regexp) パターンに必要な最小アクセス許可を示しています。
| タグ | 設定 regexp | 書き込み regexp | 読み込み regexp |
| --- | --- | --- | --- |
| none | | .\$1 | .\$1 |
リストされているユーザー許可は、ブローカで管理オペレーションを実行するための管理プラグインへのアクセスを付与することなく、ユーザーに読み取りおよび書き込み許可のみを提供します。特定のキューへのユーザーのアクセスを制限する正規表現パターンを提供することで、許可をさらに制限できます。例えば、読み取り regexp パターンを `^[hello world].*` に変更する場合、ユーザーには `hello world` で始まるキューからの読み取り許可のみが付与されます。
RabbitMQ ユーザーの作成、およびユーザータグと許可の管理の詳細については、「[Amazon MQ for RabbitMQ ブローカーのユーザー](rabbitmq-simple-auth-broker-users.md#rabbitmq-basic-elements-user)」を参照してください。
## ステップ 1: 基本的な Python Pika クライアントを作成する
Amazon MQ for RabbitMQ ブローカーと対話するときに、コンストラクタを定義し、TLS 設定に必要な SSL コンテキストを提供する Python Pika クライアント基本クラスを作成するには、次の手順を実行します。
1. 新しいターミナルウィンドウを開き、プロジェクトの新しいディレクトリを作成し、そのディレクトリに移動します。
```
$ mkdir pika-tutorial
$ cd pika-tutorial
```
1. 以下の Python コードを含む `basicClient.py` というファイルを作成します。
```
import ssl
import pika
class BasicPikaClient:
def __init__(self, rabbitmq_broker_id, rabbitmq_user, rabbitmq_password, region):
# SSL Context for TLS configuration of Amazon MQ for RabbitMQ
ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
ssl_context.set_ciphers('ECDHE+AESGCM:!ECDSA')
url = f"amqps://{rabbitmq_user}:{rabbitmq_password}@{rabbitmq_broker_id}.mq.{region}.amazonaws.com:5671"
parameters = pika.URLParameters(url)
parameters.ssl_options = pika.SSLOptions(context=ssl_context)
self.connection = pika.BlockingConnection(parameters)
self.channel = self.connection.channel()
```
パブリッシャーとコンシューマに対して、`BasicPikaClient` から継承する追加のクラスを定義できるようになりました。
## ステップ 2: パブリッシャーを作成してメッセージを送信する
キューを宣言し、1 つのメッセージを送信するパブリッシャを作成するには、次の手順を実行します。
1. 次のコードサンプルの内容をコピーし、前のステップで作成した同じディレクトリで、`publisher.py` と名前を付けてローカルに保存します。
```
from basicClient import BasicPikaClient
class BasicMessageSender(BasicPikaClient):
def declare_queue(self, queue_name):
print(f"Trying to declare queue({queue_name})...")
self.channel.queue_declare(queue=queue_name)
def send_message(self, exchange, routing_key, body):
channel = self.connection.channel()
channel.basic_publish(exchange=exchange,
routing_key=routing_key,
body=body)
print(f"Sent message. Exchange: {exchange}, Routing Key: {routing_key}, Body: {body}")
def close(self):
self.channel.close()
self.connection.close()
if __name__ == "__main__":
# Initialize Basic Message Sender which creates a connection
# and channel for sending messages.
basic_message_sender = BasicMessageSender(
"",
"",
"",
""
)
# Declare a queue
basic_message_sender.declare_queue("hello world queue")
# Send a message to the queue.
basic_message_sender.send_message(exchange="", routing_key="hello world queue", body=b'Hello World!')
# Close connections.
basic_message_sender.close()
```
`BasicMessageSender` クラスは `BasicPikaClient` から継承され、キューの宣言、キューへのメッセージの送信、および接続を閉じるための追加のメソッドを実装します。コードサンプルでは、キューの名前と等しいルーティングキーを使用して、メッセージをデフォルトの交換にルーティングします。
1. [`if __name__ == "__main__":`] で、渡されたパラメータを次の情報を含む `BasicMessageSender` コンストラクターステートメントで置換します。
+ **``** – Amazon MQ がブローカー用に生成する一意の ID です。ID は、ブローカー ARN から解析できます。例えば、`arn:aws:mq:us-east-2:123456789012:broker:MyBroker:b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9` という ARN の場合、ブローカー ID は `b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9` になります。
+ **``** - ブローカにメッセージを書き込むのに十分な許可を持つブローカユーザーのユーザー名。
+ **``** - ブローカにメッセージを書き込むのに十分な許可を持つブローカユーザーのパスワード。
+ **``** – Amazon MQ for RabbitMQ ブローカーを作成した AWS リージョン。例えば、`us-west-2`。
1. `publisher.py` を作成した同じディレクトリで次のコマンドを実行します。
```
$ python3 publisher.py
```
コードが正常に実行された場合、ターミナルウィンドウに次の出力が表示されます。
```
Trying to declare queue(hello world queue)...
Sent message. Exchange: , Routing Key: hello world queue, Body: b'Hello World!'
```
## ステップ 3: コンシューマーを作成してメッセージを受信する
キューから単一のメッセージを受信するコンシューマーを作成するには、次の手順を実行します。
1. 次のコードサンプルの内容をコピーし、同じディレクトリで、`consumer.py` と名前を付けてローカルに保存します。
```
from basicClient import BasicPikaClient
class BasicMessageReceiver(BasicPikaClient):
def get_message(self, queue):
method_frame, header_frame, body = self.channel.basic_get(queue)
if method_frame:
print(method_frame, header_frame, body)
self.channel.basic_ack(method_frame.delivery_tag)
return method_frame, header_frame, body
else:
print('No message returned')
def close(self):
self.channel.close()
self.connection.close()
if __name__ == "__main__":
# Create Basic Message Receiver which creates a connection
# and channel for consuming messages.
basic_message_receiver = BasicMessageReceiver(
"",
"",
"",
""
)
# Consume the message that was sent.
basic_message_receiver.get_message("hello world queue")
# Close connections.
basic_message_receiver.close()
```
前のステップで作成したパブリッシャーと同様に、 は から`BasicMessageReceiver`継承`BasicPikaClient`し、単一のメッセージを受信して接続を閉じるための追加のメソッドを実装します。
1. `if __name__ == "__main__":` ステートメントで、渡されたパラメータを次の情報を含む `BasicMessageReceiver` コンストラクターに置換します。
1. プロジェクトディレクトリで次のコマンドを実行します。
```
$ python3 consumer.py
```
コードが正常に実行されると、メッセージ本文とルーティングキーを含むヘッダーがターミナルウィンドウに表示されます。
```
b'Hello World!'
```
## ステップ 4: (オプション) イベントループを設定し、メッセージを消費する
キューから複数のメッセージを消費するには、Pika の [https://pika.readthedocs.io/en/stable/modules/channel.html#pika.channel.Channel.basic_consume](https://pika.readthedocs.io/en/stable/modules/channel.html#pika.channel.Channel.basic_consume) メソッドと、次に示すコールバック関数を使用します
1. `consumer.py` で、`BasicMessageReceiver` クラスに以下のメソッド定義を追加します。
```
def consume_messages(self, queue):
def callback(ch, method, properties, body):
print(" [x] Received %r" % body)
self.channel.basic_consume(queue=queue, on_message_callback=callback, auto_ack=True)
print(' [*] Waiting for messages. To exit press CTRL+C')
self.channel.start_consuming()
```
1. `consumer.py` の `if __name__ == "__main__":` の下で、前のステップで定義した `consume_messages` メソッドを呼び出します。
```
if __name__ == "__main__":
# Create Basic Message Receiver which creates a connection and channel for consuming messages.
basic_message_receiver = BasicMessageReceiver(
"",
"",
"",
""
)
# Consume the message that was sent.
# basic_message_receiver.get_message("hello world queue")
# Consume multiple messages in an event loop.
basic_message_receiver.consume_messages("hello world queue")
# Close connections.
basic_message_receiver.close()
```
1. `consumer.py` をもう一度実行し、成功すると、キューに入れられたメッセージがターミナルウィンドウに表示されます。
```
[*] Waiting for messages. To exit press CTRL+C
[x] Received b'Hello World!'
[x] Received b'Hello World!'
...
```
## 次のステップ
+ サポートされている他の RabbitMQ クライアントライブラリの詳細については、RabbitMQ のウェブサイトの「[RabbitMQ クライアントドキュメント](https://www.rabbitmq.com/clients.html)」を参照してください。
# RabbitMQ の一時停止されたキュー同期の解決
Amazon MQ for RabbitMQ [クラスターデプロイ](rabbitmq-broker-architecture.md#rabbitmq-broker-architecture-cluster)では、各キューに発行されたメッセージが 3 つのブローカーノード全体にレプリケートされます。*ミラーリング*と呼ばれるこのレプリケーションは、RabbitMQ ブローカーに高可用性 (HA) を提供します。クラスターデプロイ内のキューは、1 つのノード上にある*メイン*レプリカと、1 つ、または複数の*ミラー*で構成されています。ミラーキューに適用されるすべての操作 (メッセージのキュー登録など) は、まずメインキューに適用され、その後ミラー全体にレプリケートされます。
例えば、メインノード (`main`) と 2 つのミラー (`mirror-1` および `mirror-2`) の 3 つのノード全体にレプリケートされたミラーキューについて考えてみましょう。このミラーキュー内のすべてのメッセージがすべてのミラーに正常に伝播されると、キューが同期されたことになります。ノード (`mirror-1`) が一定期間使用できなくなった場合でも、キューは引き続き動作可能で、メッセージのキュー登録を継続できますが、キューを同期するには、`mirror-1` が使用不可である間に `main` に発行されたメッセージが `mirror-1` にレプリケートされる必要があります。
ミラーリングの詳細については、RabbitMQ ウェブサイトで「[Classic Mirrored Queues](https://www.rabbitmq.com/ha.html)」を参照してください。
**メンテナンスとキューの同期**
[メンテナンスウィンドウ](amazon-mq-rabbitmq-editing-broker-preferences.md#rabbitmq-edit-current-configuration-console)中、Amazon MQ はすべてのメンテナンス作業を一度に 1 ノードずつ実行して、ブローカーが動作可能な状態を維持することを確実にします。その結果、各ノードが操作を再開するときに、キューが同期する必要が生じる場合があります。同期中、ミラーにレプリケートする必要があるメッセージは、バッチで処理されるように、対応する Amazon Elastic Block Store (Amazon EBS) ボリュームからメモリにロードされます。メッセージをバッチで処理することにより、キューの同期が速くなります。
キューを短くし、メッセージを小さくしておくと、キューが正常に同期し、期待通りに操作を再開します。ただし、バッチ内のデータ量がノードのメモリ制限に近づいた場合は、ノードが高メモリアラームを発し、キューの同期を一時停止します。メモリ使用量は、[CloudWatch で `RabbitMemUsed` および `RabbitMqMemLimit` のブローカーノードメトリクス](amazon-mq-accessing-metrics.md)を比較することで確認できます。同期は、メッセージが消費もしくは削除される、またはバッチ内のメッセージの数が減るまで完了できません。
**注記**
キューの同期のバッチサイズを小さくすると、レプリケーショントランザクション数の増加につながる可能性があります。
一時停止されたキューの同期を解決するには、`ha-sync-batch-size` ポリシーの適用とキューの同期の再開について説明する、このチュートリアルのステップに従ってください。
**Topics**
+ [
## 前提条件
](#rabbitmq-queue-sync-prerequisites)
+ [
## ステップ 1: `ha-sync-batch-size` ポリシーを適用する
](#rabbitmq-queue-sync-step-1)
+ [
## ステップ 2: キューの同期を再開する
](#rabbitmq-queue-sync-step-2)
+ [
## 次の手順
](#rabbitmq-queue-sync-next-steps)
+ [
## 関連リソース
](#rabbitmq-queue-sync-related-resources)
## 前提条件
このチュートリアルには、管理者権限を持つ Amazon MQ for RabbitMQ ブローカーユーザーが必要です。ブローカーを初めて作成したときに作成された管理者ユーザー、またはその後で作成した別のユーザーを使用できます。以下の表は、正規表現 (regexp) パターンとしての必要な管理者ユーザータグと許可です。
| タグ | 読み込み regexp | 設定 regexp | 書き込み regexp |
| --- | --- | --- | --- |
| administrator | .\$1 | .\$1 | .\$1 |
RabbitMQ ユーザーの作成、およびユーザータグと許可の管理の詳細については、「[Amazon MQ for RabbitMQ ブローカーのユーザー](rabbitmq-simple-auth-broker-users.md#rabbitmq-basic-elements-user)」を参照してください。
## ステップ 1: `ha-sync-batch-size` ポリシーを適用する
以下の手順では、ブローカーで作成されたすべてのキューに適用されるポリシーの追加について説明します。RabbitMQ ウェブコンソールまたは RabbitMQ Management API を使用できます。詳細については、RabbitMQ ウェブサイトの「[Management Plugin](https://www.rabbitmq.com/management.html)」を参照してください。
**RabbitMQ ウェブコンソールを使用して `ha-sync-batch-size` ポリシーを適用する**
1. [Amazon MQ コンソール](https://console.aws.amazon.com/amazon-mq/)にサインインします。
1. 左側のナビゲーションペインで [**Brokers**] (ブローカー) をクリックします。
1. ブローカーのリストから、新しいポリシーを適用するブローカーの名前を選択します。
1. ブローカーのページの [**Connections**] (接続) セクションで、**RabbitMQ ウェブコンソール** URL をメモします。新しいブラウザタブまたはウィンドウに RabbitMQ ウェブコンソールが開きます。
1. ブローカー管理者のサインイン認証情報を使用して RabbitMQ ウェブコンソールにログインします。
1. RabbitMQ ウェブコンソールのページ上部で、[**Admin**] (管理) をクリックします。
1. [**Admin**] (管理) ページの右側にあるナビゲーションペインで [**Policies**] (ポリシー) をクリックします。
1. [**Policies**] (ポリシー) ページに、ブローカーの現在の [**User policies**] (ユーザーポリシー) が表示されます。[**User policies**] (ユーザーポリシー) の下で、[**Add / update a policy] (ポリシーの追加/更新**) を展開します。
**注記**
デフォルトで、Amazon MQ for RabbitMQ クラスターは、`ha-all-AWS-OWNED-DO-NOT-DELETE` という名前の初期ブローカーポリシーを使用して作成されます。Amazon MQ はこのポリシーを管理して、ブローカー上のすべてのキューが 3 つのノードすべてにレプリケートされ、キューが自動的に同期化されることを確実にします。
1. 新しいブローカーポリシーを作成するには、[**Add / update a policy**] (ポリシーの追加/更新) で以下を実行します。
1. [**Name**] (名前) には、ポリシーの名前 (**batch-size-policy** など) を入力します。
1. [**Pattern**] (パターン) には regexp パターン **.\$1** を入力して、ポリシーがブローカー上のすべてのキューと一致するようにします。
1. [**Apply to**] (適用先) には、ドロップダウンリストから [**Exchanges and queues**] (エクスチェンジとキュー) を選択します。
1. [**Priority**] (優先順位) には、vhost に適用されたその他すべてのポリシーよりも大きい整数を入力します。RabbitMQ のキューとエクスチェンジに適用できるのは、常に 1 つのポリシー定義セットのみです。RabbitMQ は、一致するポリシーで、最高の優先順位値を持つものを選択します。ポリシーの優先順位とポリシーの結合方法の詳細については、RabbitMQ サーバードキュメントの「[Policies](https://www.rabbitmq.com/parameters.html#policies)」を参照してください。
1. [**Definition**] (定義) には、以下のキーバリューペアを追加します。
+ **ha-sync-batch-size**=*100*。ドロップダウンリストから [**Number**] (数値) を選択します。
**注記**
`ha-sync-batch-size` の値は、キュー内の同期されていないメッセージの数とサイズに基づいて調整と較正を行う必要がある場合があります。
+ **ha-mode**=**all**。ドロップダウンリストから [**String**] (文字列) を選択します。
**重要**
`ha-mode` 定義は、すべての HA 関連ポリシーに必須です。省略すると、検証が失敗します。
+ **ha-sync-mode**=**automatic**。ドロップダウンリストから [**String**] (文字列) を選択します。
**注記**
`ha-sync-mode` 定義は、すべてのカスタムポリシーに必須です。省略すると、Amazon MQ が定義を自動的に付加します。
1. [**Add / update policy**] (ポリシーを追加/更新) をクリックします。
1. [**User policies**] (ユーザーポリシー) リストに新しいポリシーが表示されることを確認します。
**RabbitMQ Management API を使用して `ha-sync-batch-size` ポリシーを適用する**
1. [Amazon MQ コンソール](https://console.aws.amazon.com/amazon-mq/)にサインインします。
1. 左側のナビゲーションペインで [**Brokers**] (ブローカー) をクリックします。
1. ブローカーのリストから、新しいポリシーを適用するブローカーの名前を選択します。
1. ブローカーのページの [**Connections**] (接続) セクションで、**RabbitMQ ウェブコンソール** URL をメモします。これは、HTTP リクエストで使用するブローカーエンドポイントです。
1. 任意の新しいターミナルまたはコマンドラインウィンドウを開きます。
1. 新しいブローカーポリシーを作成するには、以下の `curl` コマンドを入力します。このコマンドでは、`%2F` としてエンコードされているデフォルト `/` vhost 上のキューを前提としています。
**注記**
*ユーザー名*と*パスワード*を、ブローカー管理者のサインイン認証情報に置き換えます。`ha-sync-batch-size` の値 (*100*) は、キュー内の同期されていないメッセージの数とサイズに基づいて調整と較正を行う必要がある場合があります。ブローカーエンドポイントを先ほどメモした URL に置き換えます。
```
curl -i -u username:password -H "content-type:application/json" -XPUT \
-d '{"pattern":".*", "priority":1, "definition":{"ha-sync-batch-size":100, "ha-mode":"all", "ha-sync-mode":"automatic"}}' \
https://b-589c045f-f8ln-4ab0-a89c-co62e1c32ef8.mq.us-west-2.amazonaws.com/api/policies/%2F/batch-size-policy
```
1. 新しいポリシーがブローカーのユーザーポリシーに追加されていることを確認するには、以下の `curl` コマンドを入力して、すべてのブローカーポリシーをリストします。
```
curl -i -u username:password https://b-589c045f-f8ln-4ab0-a89c-co62e1c32ef8.mq.us-west-2.amazonaws.com/api/policies
```
## ステップ 2: キューの同期を再開する
ブローカーに新しい `ha-sync-batch-size` ポリシーを適用したら、キューの同期を再開します。
**RabbitMQ ウェブコンソールを使用してキューの同期を再開する**
**注記**
RabbitMQ ウェブコンソールを開くには、このチュートリアルのステップ 1 にある前述の手順を参照してください。
1. RabbitMQ ウェブコンソールのページ上部で、[**Queues**] (キュー) をクリックします。
1. [**Queues**] (キュー) ページの [**All queues**] (すべてのキュー) で、一時停止されたキューを見つけます。**[ポリシー]** 行に、キューが作成された新しいポリシーの名前をリストします (`batch-size-policy` など)。
1. 縮小されたバッチサイズで同期プロセスを再開するには、まずキュー同期をキャンセルします。次に、キュー同期を再起動します。
**注記**
同期が一時停止して正常に終了しない場合は、`ha-sync-batch-size` の値を低くして、もう一度キューの同期を再開してみてください。
## 次の手順
+ キューが正常に同期化されたら、Amazon CloudWatch メトリクス `RabbitMQMemUsed` を表示することで、RabbitMQ ノードが使用するメモリの量をモニタリングできます。`RabbitMQMemLimit` メトリクスを表示して、ノードのメモリ制限をモニタリングすることもできます。詳細については、「[Amazon MQ 向けの CloudWatch メトリクスへのアクセス](amazon-mq-accessing-metrics.md)」および「[Amazon MQ for RabbitMQ ブローカーで利用可能な CloudWatch メトリクス](rabbitmq-logging-monitoring.md)」を参照してください。
+ キューの同期が一時停止しないようにするため、キューを短くしておき、メッセージを処理することをお勧めします。メッセージサイズが大きいワークロードの場合は、より多くのメモリを備えたより大きなインスタンスサイズにブローカーインスタンスタイプをアップグレードすることもお勧めします。ブローカーインスタンスタイプとブローカー設定の編集に関する詳細については、「[ブローカー設定の編集](amazon-mq-rabbitmq-editing-broker-preferences.md)」を参照してください。
+ 新しい Amazon MQ for RabbitMQ ブローカーを作成するときは、ブローカーのパフォーマンスを最適化するために、Amazon MQ が一連のデフォルトブローカーポリシーと仮想ホスト制限を適用します。お使いのブローカーに推奨されるデフォルトのポリシーと制限がない場合は、独自のポリシーと制限を作成することをお勧めします。デフォルトのポリシーと vhost 制限の作成に関する詳細については、「[https://docs.aws.amazon.com//amazon-mq/latest/developer-guide/rabbitmq-defaults.html](https://docs.aws.amazon.com//amazon-mq/latest/developer-guide/rabbitmq-defaults.html)」を参照してください。
## 関連リソース
+ [UpdateBrokerInput](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/brokers-broker-id.html#brokers-broker-id-model-updatebrokerinput) – Amazon MQ API を使用してブローカーインスタンスタイプを更新するには、このブローカープロパティを使用します。
+ [Parameters and Policies](https://www.rabbitmq.com/parameters.html) (RabbitMQ サーバードキュメント) – RabbitMQ のウェブサイトで、RabbitMQ のパラメータとポリシーの詳細について学びます。
+ [RabbitMQ Management HTTP API](https://pulse.mozilla.org/api/) – RabbitMQ Management API の詳細について学びます。
# 接続およびチャネルの数の削減
Amazon MQ 上の RabbitMQ への接続は、クライアントアプリケーションで終了できます。また、RabbitMQ ウェブコンソールを使用して手動で終了することもできます。RabbitMQ ウェブコンソールを使用して接続を終了するには、次の手順を実行します。
1. にサインイン AWS マネジメントコンソール し、ブローカーの RabbitMQ ウェブコンソールを開きます。
1. RabbitMQ コンソールで、**[Connections]** (接続) タブを選択します。
1. **[Connections]** (接続) ページの **[All connections]** (すべての接続) から、終了する接続の名前をリストから選択します。
1. 接続の詳細ページで、**[Close this connection]** (この接続を終了する) を選択してセクションを展開し、**[Force Close]** (強制終了) を選択します。オプションで、**理由**のデフォルトのテキストをお客様自身の説明に置き換えることもできます。接続を終了すると、Amazon MQ 上の RabbitMQ により、指定した理由がクライアントに返されます。
1. ダイアログボックスで **[OK]** を選択し、確認して接続を終了します。
接続を終了すると、終了した接続に関連付けられているすべてのチャネルも終了します。
**注記**
クライアントアプリケーションは、終了後にブローカーが自動的に接続を再確立するように設定されている場合があります。この場合、接続またはチャネルの数を減らすには、ブローカーのウェブコンソールからの接続を終了するだけでは不十分です。
パブリックアクセスがないブローカーの場合、適切なメッセージプロトコルのポート (例えば AMQP 接続の場合、ポート `5671`) でインバウンドトラフィックを拒否することで、一時的に接続をブロックできます。ブローカーの作成時に Amazon MQ に指定したセキュリティグループのポートをブロックできます。セキュリティグループの変更方法の詳細については、*Amazon VPC ユーザーガイド*の「[セキュリティグループへのルールの追加](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#adding-security-group-rules)」を参照してください。
## ステップ 2: ブローカーに JVM ベースのアプリケーションを接続する
RabbitMQ ブローカーを作成したら、ブローカーにアプリケーションを接続できます。以下の例では、[RabbitMQ Java クライアントライブラリ](https://www.rabbitmq.com/java-client.html)を使用してブローカーへの接続を作成し、キューを作成して、メッセージを送信する方法を説明します。RabbitMQ ブローカーには、サポートされているさまざまな言語の RabbitMQ クライアントライブラリを使用して接続することができます。サポートされている RabbitMQ クライアントライブラリの詳細については、「[RabbitMQ client libraries and developer tools](https://www.rabbitmq.com/devtools.html)」を参照してください。
### 前提条件
**注記**
以下の前提条件ステップは、パブリックアクセシビリティなしで作成された RabbitMQ ブローカーのみに適用されます。パブリックアクセシビリティがあるブローカーを作成している場合は、スキップすることができます。
#### VPC 属性 を有効にする
VPC 内でブローカーにアクセスできることを確実にするには、`enableDnsHostnames` および `enableDnsSupport` VPC 属性を有効にする必要があります。詳細については、*Amazon VPC ユーザーガイド*の「[VPC の DNS サポート](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support)」を参照してください。
#### インバウンド接続を有効にする
1. [Amazon MQ コンソール](https://console.aws.amazon.com/amazon-mq/)にサインインします。
1. ブローカーのリストからブローカーの名前 (**MyBroker** など) を選択します。
1. [***MyBroker***] ページの [**Connections**] (接続) セクションで、ブローカーのウェブコンソール URL とワイヤレベルプロトコルのアドレスとポートをメモします。
1. [**Details**] (詳細) セクションの [**Security and network**] (セキュリティとネットワーク) で、セキュリティグループの名前または ![\[Pencil icon indicating an edit or modification action.\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/amazon-mq-tutorials-broker-details-link.png) をクリックします。
EC2 ダッシュボードの [**セキュリティグループ**] ページが表示されます。
1. セキュリティグループのリストから、セキュリティグループを選択します。
1. ページ下部で、[**インバウンド**] を選択し、次に [**編集**] を選択します。
1. [**Edit inbound rules**] (インバウンドルールの編集) ダイアログボックスで、パブリックアクセスを許可する URL またはエンドポイントごとにルールを追加します (以下の例は、これをブローカーのウェブコンソールに対して行う方法を説明しています)。
1. **[ルールの追加]** を選択します。
1. [**タイプ**] で、[**カスタム TCP**] を選択します。
1. [**Source**] (ソース) では、[**Custom**] (カスタム) が選択された状態のままにしておき、ウェブコンソールにアクセスできるようにするシステムの IP アドレスを入力します (`192.0.2.1` など)。
1. [**Save**] (保存) をクリックします。
これで、ブローカーはインバウンド接続を受け入れることができます。
#### Java の依存関係を追加する
ビルドの自動化のために Apache Maven を使用している場合は、以下の依存関係を `pom.xml` ファイルに追加します。Apache Maven のプロジェクトオブジェクトモデルファイルの詳細については、「[Introduction to the POM](https://maven.apache.org/guides/introduction/introduction-to-the-pom.html)」を参照してください。
```
com.rabbitmq
amqp-client
5.9.0
```
ビルドの自動化のために [Gradle](https://docs.gradle.org/current/userguide/userguide.html) を使用している場合は、以下の依存関係を宣言します。
```
dependencies {
compile 'com.rabbitmq:amqp-client:5.9.0'
}
```
#### `Connection` と `Channel` クラスをインポートする
RabbitMQ Java クライアントは、そのトップレベルパッケージとして `com.rabbitmq.client` を使用し、それぞれが AMQP 0-9-1 接続とチャネルを表す `Connection` および `Channel` API クラスがあります。以下の例にあるように、使用する前に `Connection` と `Channel` クラスをインポートします。
```
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.Channel;
```
#### `ConnectionFactory` を作成してブローカーに接続する
以下の例を使用して、所定のパラメータで `ConnectionFactory` クラスのインスタンスを作成します。`setHost` メソッドを使用して、先ほどメモしておいたブローカーエンドポイントを設定します。`AMQPS` のワイヤレベル接続には、ポート `5671` を使用します。
```
ConnectionFactory factory = new ConnectionFactory();
factory.setUsername(username);
factory.setPassword(password);
//Replace the URL with your information
factory.setHost("b-c8352341-ec91-4a78-ad9c-a43f23d325bb.mq.us-west-2.amazonaws.com");
factory.setPort(5671);
// Allows client to establish a connection over TLS
factory.useSslProtocol();
// Create a connection
Connection conn = factory.newConnection();
// Create a channel
Channel channel = conn.createChannel();
```
#### エクスチェンジにメッセージを発行する
エクスチェンジにメッセージを発行するには、`Channel.basicPublish` を使用できます。以下の例では、AMQP `Builder` クラスを使用して、content-type が `plain/text` のメッセージプロパティオブジェクトを構築します。
```
byte[] messageBodyBytes = "Hello, world!".getBytes();
channel.basicPublish(exchangeName, routingKey,
new AMQP.BasicProperties.Builder()
.contentType("text/plain")
.userId("userId")
.build(),
messageBodyBytes);
```
**注記**
`BasicProperties` は自動生成されたホルダークラス `AMQP` の内部クラスであることに注意してください。
#### キューにサブスクライブしてメッセージを受信する
メッセージは、`Consumer` インターフェイスを使用してキューにサブスクライブすることによって受信できます。サブスクライブすると、メッセージが到着すると同時に自動配信されます。
`Consumer` を実装する最も簡単な方法は、サブクラス `DefaultConsumer` の使用です。以下の例にあるように、`DefaultConsumer` オブジェクトは、サブスクリプションをセットアップするための `basicConsume` コールの一部として渡すことがきます。
```
boolean autoAck = false;
channel.basicConsume(queueName, autoAck, "myConsumerTag",
new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag,
Envelope envelope,
AMQP.BasicProperties properties,
byte[] body)
throws IOException
{
String routingKey = envelope.getRoutingKey();
String contentType = properties.getContentType();
long deliveryTag = envelope.getDeliveryTag();
// (process the message components here ...)
channel.basicAck(deliveryTag, false);
}
});
```
**注記**
`autoAck = false` を指定したので、`Consumer` に配信されたメッセージを承認する必要があります。これは、上記の例にあるように、`handleDelivery` で実行することが最も便利です。
#### 接続を閉じてブローカーへの接続を切断する
RabbitMQ ブローカーへの接続を切断するには、以下に示すように、チャネルと接続の両方を閉じます。
```
channel.close();
conn.close();
```
**注記**
RabbitMQ Java クライアントライブラリの使用に関する詳細については、[RabbitMQ Java Client API Guide](https://www.rabbitmq.com/api-guide.html) を参照してください。
## ステップ 3: (オプション) AWS Lambda 関数に接続する
AWS Lambda は Amazon MQ ブローカーに接続して、Amazon MQ ブローカーからのメッセージを消費できます。ブローカーを Lambda に接続するときは、キューからメッセージを読み取り、関数 [synchronously](https://docs.aws.amazon.com/lambda/latest/dg/invocation-sync.html) を呼び出す[イベントソースマッピング](https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html)を作成します。作成するイベントソースマッピングは、ブローカーからメッセージをバッチで読み取り、それらを JSON オブジェクト形式の Lambda ペイロードに変換します。
**ブローカーを Lambda 関数に接続する**
1. Lambda 関数 [execution role](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) に以下の IAM ロール許可を追加します。
+ [ mq:DescribeBroker ](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/brokers-broker-id.html#brokers-broker-id-http-methods)
+ [ec2:CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html)
+ [ec2:DeleteNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkInterface.html)
+ [ec2:DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html)
+ [ec2:DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html)
+ [ec2:DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ [ec2:DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html)
+ [logs:CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html)
+ [logs:CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html)
+ [logs:PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html)
+ [secretsmanager:GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
**注記**
必要な IAM 許可がない場合、関数は Amazon MQ リソースからレコードを正常に読み取ることができません。
1. (オプション) パブリックアクセシビリティがないブローカーを作成した場合は、次のいずれかを実行して、Lambda のブローカーへの接続を許可する必要があります。
+ パブリックサブネットごとに 1 つの NAT ゲートウェイを設定します。詳細については、*AWS Lambda デベロッパーガイド*の「[VPC に接続した関数のインターネットアクセスとサービスアクセス](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-internet)」を参照してください。
+ VPC エンドポイントを使用して、Amazon Virtual Private Cloud (Amazon VPC) と Lambda 間の接続を作成します。Amazon VPC は、 AWS Security Token Service (AWS STS) および Secrets Manager エンドポイントにも接続する必要があります。詳細については、*AWS Lambda デベロッパーガイド*の「[Lambda のインターフェイス VPC エンドポイントの設定](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc-endpoints.html)」を参照してください。
1. AWS マネジメントコンソールを使用して、Lambda 関数の[イベントソースとしてブローカーを設定](https://docs.aws.amazon.com/lambda/latest/dg/with-mq.html#services-mq-eventsourcemapping)します。[https://docs.aws.amazon.com/cli/latest/reference/lambda/create-event-source-mapping.html](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-event-source-mapping.html) AWS Command Line Interface コマンドを使用することもできます。
1. ブローカーから取り込まれたメッセージを処理するための Lambda 関数のコードをいくつか記述します。イベントソースマッピングによって取得される Lambda ペイロードは、ブローカーのエンジンタイプに依存します。以下は、Amazon MQ for RabbitMQ キューの Lambda ペイロードの例です。
**注記**
この例では、`test` がキューの名前で、`/` がデフォルト仮想ホストの名前です。メッセージを受信すると、イベントソースは `test::/` の下にメッセージを一覧表示します。
```
{
"eventSource": "aws:rmq",
"eventSourceArn": "arn:aws:mq:us-west-2:112556298976:broker:test:b-9bcfa592-423a-4942-879d-eb284b418fc8",
"rmqMessagesByQueue": {
"test::/": [
{
"basicProperties": {
"contentType": "text/plain",
"contentEncoding": null,
"headers": {
"header1": {
"bytes": [
118,
97,
108,
117,
101,
49
]
},
"header2": {
"bytes": [
118,
97,
108,
117,
101,
50
]
},
"numberInHeader": 10
}
"deliveryMode": 1,
"priority": 34,
"correlationId": null,
"replyTo": null,
"expiration": "60000",
"messageId": null,
"timestamp": "Jan 1, 1970, 12:33:41 AM",
"type": null,
"userId": "AIDACKCEVSQ6C2EXAMPLE",
"appId": null,
"clusterId": null,
"bodySize": 80
},
"redelivered": false,
"data": "eyJ0aW1lb3V0IjowLCJkYXRhIjoiQ1pybWYwR3c4T3Y0YnFMUXhENEUifQ=="
}
]
}
}
```
Amazon MQ の Lambda への接続、Amazon MQ イベントソースに対して Lambda がサポートするオプション、およびイベントソースマッピングエラーに関する詳細については、「*AWS Lambda デベロッパーガイド*」の「[Amazon MQ で Lambda を使用する](https://docs.aws.amazon.com/lambda/latest/dg/with-mq.html)」を参照してください。
# Amazon MQ for RabbitMQ での OAuth 2.0 認証と認可の使用
このチュートリアルでは、Amazon Cognito を OAuth 2.0 プロバイダーとして使用して、Amazon MQ for RabbitMQ ブローカーの [OAuth 2.0 認証](oauth-for-amq-for-rabbitmq.md)を設定する方法について説明します。
**注記**
Amazon Cognito は、中国 (北京) および中国 (寧夏) では使用できません。
**重要**
このチュートリアルは Amazon Cognito に固有のものですが、他の ID プロバイダー (IdP) を使用できます。詳細については、「[OAuth 2.0 認証の例](https://www.rabbitmq.com/docs/oauth2-examples)」を参照してください。
**Topics**
+ [
## OAuth 2.0 認証を設定するための前提条件
](#oauth-tutorial-prerequisites)
+ [
## AWS CLI を使用した Amazon Cognito による OAuth 2.0 認証の設定
](#oauth-tutorial-config-cognito-using-cli)
+ [
## Amazon Cognito による OAuth 2.0 とシンプルな認証の設定
](#oauth-tutorial-config-both-auth-methods-using-cli)
## OAuth 2.0 認証を設定するための前提条件
このチュートリアルで必要な Amazon Cognito リソースを設定するには、AWS CDK スタックである [RabbitMQ OAuth 2 プラグイン用 Amazon Cognito スタック](https://github.com/aws-samples/amazon-mq-samples/tree/main/rabbitmq-samples/rabbitmq-oauth2-cognito-sample)をデプロイします。Amazon Cognito を手動で設定する場合は、Amazon MQ for RabbitMQ ブローカーで OAuth 2.0 を設定する前に、次の前提条件を満たしていることを確認してください。
**Amazon Cognito をセットアップするための前提条件**
+ ユーザープールを作成して Amazon Cognito エンドポイントをセットアップします。これを行うには、「[How to use OAuth 2.0 in Amazon Cognito: Learn about the different OAuth 2.0 grants](https://aws.amazon.com/blogs/security/how-to-use-oauth-2-0-in-amazon-cognito-learn-about-the-different-oauth-2-0-grants/)」というタイトルのブログを参照してください。
+ ユーザープールに `rabbitmq` という名前のリソースサーバーを作成し、`read:all`、`write:all`、`configure:all`、`tag:administrator` のスコープを定義します。これらのスコープは RabbitMQ アクセス許可に関連付けられます。
リソースサーバーの作成の詳細については、「*Amazon Cognito デベロッパーガイド*」の「[ユーザープール (AWS マネジメントコンソール) のリソースサーバーの定義](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-define-resource-servers.html#cognito-user-pools-define-resource-servers-console)」を参照してください。
+ 以下のアプリケーションクライアントを作成します。
+ タイプ `Machine-to-Machine application` のユーザープールのアプリケーションクライアント。これは、RabbitMQ AMQP クライアントに使用されるクライアントシークレットを持つ機密クライアントです。アプリケーションクライアントとその作成の詳細については、「[アプリクライアントの種類](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html#user-pool-settings-client-app-client-types)」および「[アプリクライアントの作成](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html#cognito-user-pools-app-idp-settings-console-create)」を参照してください。
+ タイプ `Single-page application` のユーザープールのアプリケーションクライアント。これは、RabbitMQ マネジメントコンソールへのユーザーのログインに使用されるパブリッククライアントです。このアプリケーションクライアントを更新して、次の手順で作成する Amazon MQ for RabbitMQ ブローカーのエンドポイントを許可されたコールバック URL として含める必要があります。詳細については、「[Amazon Cognito コンソールでのマネージドログインのセットアップ](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-managed-login.html#set-up-managed-login)」を参照してください。
**Amazon MQ をセットアップするための前提条件**
+ OAuth 2.0 のセットアップが成功したかどうかを確認する bash スクリプトを実行するための作業中の [Docker](https://docs.docker.com/engine/install/) インストール。
+ ブローカーの作成中にユーザー名とパスワードの追加をオプションにする AWS CLI version >= `2.28.23`。
## AWS CLI を使用した Amazon Cognito による OAuth 2.0 認証の設定
次の手順は、Amazon Cognito を IdP として使用して Amazon MQ for RabbitMQ ブローカーの OAuth 2.0 認証を設定する方法を示しています。この手順では、AWS CLI を使用して必要なリソースを作成および設定します。
次の手順では、configurationID や Revision、**、*<2>* などのプレースホルダー値を実際の値に置き換えてください。
1. 次の例に示すように、[create-configuration](https://docs.aws.amazon.com/cli/latest/reference/mq/create-configuration.html) AWS CLI コマンドを使用して新しい設定を作成します。
```
aws mq create-configuration \
--name "rabbitmq-oauth2-config" \
--engine-type "RABBITMQ" \
--engine-version "3.13"
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"Arn": "arn:aws:mq:us-west-2:123456789012:configuration:c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"AuthenticationStrategy": "simple",
"Created": "2025-07-17T16:03:01.759943+00:00",
"Id": "c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"LatestRevision": {
"Created": "2025-07-17T16:03:01.759000+00:00",
"Description": "Auto-generated default for rabbitmq-oauth2-config on RabbitMQ 3.13",
"Revision": 1
},
"Name": "rabbitmq-oauth2-config"
}
```
1. 次の例に示すように、OAuth 2.0 を認証および認可方法として使用する **rabbitmq.conf** と呼ばれる設定ファイルを作成します。
```
auth_backends.1 = oauth2
# FIXME: Update this value with the token signing key URL of your Amazon Cognito user pool.
# If you used the AWS CDK stack to deploy Amazon Cognito, this is one of the stack outputs.
auth_oauth2.jwks_url = ${RabbitMqOAuth2TestStack.JwksUri}
auth_oauth2.resource_server_id = rabbitmq
# Amazon Cognito does not include an audience field in access tokens
auth_oauth2.verify_aud = false
# Amazon Cognito does not allow * in its custom scopes. Use aliases to translate between Amazon Cognito and RabbitMQ.
auth_oauth2.scope_prefix = rabbitmq/
auth_oauth2.scope_aliases.1.alias = rabbitmq/read:all
auth_oauth2.scope_aliases.1.scope = rabbitmq/read:*/*
auth_oauth2.scope_aliases.2.alias = rabbitmq/write:all
auth_oauth2.scope_aliases.2.scope = rabbitmq/write:*/*
auth_oauth2.scope_aliases.3.alias = rabbitmq/configure:all
auth_oauth2.scope_aliases.3.scope = rabbitmq/configure:*/*
# Allow OAuth 2.0 login for RabbitMQ management console
management.oauth_enabled = true
# FIXME: Update this value with the client ID of your public application client
management.oauth_client_id = ${RabbitMqOAuth2TestStack.ManagementConsoleAppClientId}
# FIXME: Update this value with the base JWKS URI (without /.well-known/jwks.json)
auth_oauth2.issuer = ${RabbitMqOAuth2TestStack.Issuer}
management.oauth_scopes = rabbitmq/tag:administrator
```
この設定では、[スコープエイリアス](https://www.rabbitmq.com/docs/oauth2#scope-translation)を使用して、Amazon Cognito で定義されたスコープを RabbitMQ 互換スコープにマッピングします。
1. 次の例に示すように、[update-configuration](https://docs.aws.amazon.com/cli/latest/reference/mq/update-configuration.html) AWS CLI コマンドを使用して設定を更新します。このコマンドでは、この手順のステップ 1 のレスポンスで受け取った設定 ID を追加します。例えば、**c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca**。
```
aws mq update-configuration \
--configuration-id "" \
--data "$(cat rabbitmq.conf | base64 --wrap=0)"
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"Arn": "arn:aws:mq:us-west-2:123456789012:configuration:c-b600ac8e-8183-4f74-a713-983e59f30e3d",
"Created": "2025-07-17T16:57:04.520931+00:00",
"Id": "c-b600ac8e-8183-4f74-a713-983e59f30e3d",
"LatestRevision": {
"Created": "2025-07-17T16:57:39.172000+00:00",
"Revision": 2
},
"Name": "rabbitmq-oauth2-config",
"Warnings": []
}
```
1. この手順のステップ 2 で作成した OAuth 2.0 設定でブローカーを作成します。そのためには、以下の例に示すように [create-broker](https://docs.aws.amazon.com/cli/latest/reference/mq/create-broker.html) AWS CLI コマンドを使用します。このコマンドでは、ステップ 1 と 2 のレスポンスで取得した設定 ID とリビジョン番号をそれぞれ指定します。例えば、**c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca** と **2** です。
```
aws mq create-broker \
--broker-name "rabbitmq-oauth2-broker" \
--engine-type "RABBITMQ" \
--engine-version "3.13" \
--host-instance-type "mq.m7g.large" \
--deployment-mode "CLUSTER_MULTI_AZ" \
--logs '{"General": true}' \
--publicly-accessible \
--configuration '{"Id": "","Revision": <2>}' \
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"BrokerArn": "arn:aws:mq:us-west-2:123456789012:broker:rabbitmq-oauth2-broker:b-2a1b5133-a10c-49d2-879b-8c176c34cf73",
"BrokerId": "b-2a1b5133-a10c-49d2-879b-8c176c34cf73"
}
```
1. 次の例に示すように、[describe-broker](https://docs.aws.amazon.com/cli/latest/reference/mq/describe-broker.html) AWS CLI コマンドを使用して、ブローカーのステータスが `CREATION_IN_PROGRESS` から `RUNNING` に移行していることを確認します。このコマンドでは、前のステップの結果で取得したブローカー ID を指定します。例: **b-2a1b5133-a10c-49d2-879b-8c176c34cf73**。
```
aws mq describe-broker \
--broker-id ""
```
このコマンドでは、次の例のようなレスポンスが返されます。次のレスポンスは、`describe-broker` コマンドが返す完全な出力の省略バージョンです。このレスポンスは、ブローカーのステータスと、ブローカーの保護に使用される認証戦略を示します。この場合、`config_managed` 認証戦略はブローカーが OAuth 2 認証方法を使用していることを示します。
```
{
"AuthenticationStrategy": "config_managed",
...,
"BrokerState": "RUNNING",
...
}
```
OAuth2 を使用して RabbitMQ マネジメントコンソールにログインするには、ブローカーエンドポイントを、対応する Amazon Cognito アプリクライアントの有効なコールバック URL として追加する必要があります。詳細については、サンプル [ Amazon Cognito CDK スタック](https://github.com/aws-samples/amazon-mq-samples/tree/main/rabbitmq-samples/rabbitmq-oauth2-cognito-sample#step-5-update-callback-urls-if-using-placeholder-urls)のセットアップのステップ 5 を参照してください。
1. 次の `perf-test.sh` スクリプトを使用して、OAuth 2.0 の認証と認可を検証します。
この bash スクリプトを使用して、Amazon MQ for RabbitMQ ブローカーへの接続をテストします。このスクリプトは Amazon Cognito からトークンを取得し、接続が正しく設定されているかどうかを確認します。正常に設定されると、ブローカーがメッセージを発行して消費します。
`ACCESS_REFUSED` エラーが発生した場合は、ブローカーの CloudWatch ログを使用して設定をトラブルシューティングできます。ブローカーの CloudWatch ロググループのリンクは、Amazon MQ コンソールにあります。
このスクリプトでは、次の値を指定する必要があります。
+ `CLIENT_ID` および `CLIENT_SECRET`: これらの値は、Amazon Cognito コンソールの **[アプリクライアント]** ページで確認できます。
+ Cognito ドメイン: これは Amazon Cognito コンソールで確認できます。**[ブランディング]** で、**[ドメイン]** を選択します。**[ドメイン]** ページで、この値は **[リソースサーバー]** セクションにあります。
+ Amazon MQ ブローカーエンドポイント: この値は、Amazon MQ コンソールのブローカーの詳細ページの **[接続]** にあります。
```
#! /bin/bash
set -e
# Client information
## FIXME: Update this value with the client ID and secret of your confidential application client
CLIENT_ID=${RabbitMqOAuth2TestStack.AmqpAppClientId}
CLIENT_SECRET=${RabbitMqOAuth2TestStack.AmqpAppClientSecret}
# FIXME: Update this value with the domain of your Amazon Cognito user pool
RESPONSE=$(curl -X POST ${RabbitMqOAuth2TestStack.TokenEndpoint} \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&client_id=${CLIENT_ID}&client_secret=${CLIENT_SECRET}&scope=rabbitmq/configure:all rabbitmq/read:all rabbitmq/tag:administrator rabbitmq/write:all")
# Extract the access_token from the response.
# This token will be passed in the password field when connecting to the broker.
# Note that the username is left blank, the field is ignored by the plugin.
BROKER_PASSWORD=$(echo ${RESPONSE} | jq -r '.access_token')
# FIXME: Update this value with the endpoint of your broker. For example, b-89424106-7e0e-4abe-8e98-8de0dada7630.mq.us-east-1.on.aws.
BROKER_DNS=
CONNECTION_STRING=amqps://:${BROKER_PASSWORD}@${BROKER_DNS}:5671
# Produce/consume messages using the above connection string
QUEUES_COUNT=1
PRODUCERS_COUNT=1
CONSUMERS_COUNT=1
PRODUCER_RATE=1
docker run -it --rm --ulimit nofile=40960:40960 pivotalrabbitmq/perf-test:latest \
--queue-pattern 'test-queue-%d' --queue-pattern-from 1 --queue-pattern-to $QUEUES_COUNT \
--producers $PRODUCERS_COUNT --consumers $CONSUMERS_COUNT \
--id "test${QUEUES_COUNT}q${PRODUCERS_COUNT}p${CONSUMERS_COUNT}c${PRODUCER_RATE}r" \
--uri ${CONNECTION_STRING} \
--flag persistent --rate $PRODUCER_RATE
```
## Amazon Cognito による OAuth 2.0 とシンプルな認証の設定
OAuth 2.0 認証を使用してブローカーを作成する場合、次のいずれかの認証方法を指定できます。
+ **OAuth 2.0 のみ**: この方法を使用するには、ブローカーの作成時にユーザー名とパスワードを指定しないでください。[前の手順](#oauth-tutorial-config-cognito-using-cli)は、OAuth 2.0 認証方法のみを使用する方法を示しています。
+ **OAuth 2.0 とシンプルな認証の両方**: この方法を使用するには、ブローカーの作成時にユーザー名とパスワードを指定します。また、次の手順に示すように、`auth_backends.2 = internal` をブローカー設定に追加します。
次の手順では、** や ** などのプレースホルダー値を実際の値に置き換えてください。
1. 両方の認証方法を使用するには、次の例に示すように、ブローカー設定を作成します。
```
auth_backends.1 = oauth2
auth_backends.2 = internal
# FIXME: Update this value with the token signing key URL of your Amazon Cognito user pool
auth_oauth2.jwks_url = ${RabbitMqOAuth2TestStack.JwksUri}
auth_oauth2.resource_server_id = rabbitmq
auth_oauth2.verify_aud = false
auth_oauth2.scope_prefix = rabbitmq/
auth_oauth2.scope_aliases.1.alias = rabbitmq/read:all
auth_oauth2.scope_aliases.1.scope = rabbitmq/read:*/*
auth_oauth2.scope_aliases.2.alias = rabbitmq/write:all
auth_oauth2.scope_aliases.2.scope = rabbitmq/write:*/*
auth_oauth2.scope_aliases.3.alias = rabbitmq/configure:all
auth_oauth2.scope_aliases.3.scope = rabbitmq/configure:*/*
```
この設定では、[スコープエイリアス](https://www.rabbitmq.com/docs/oauth2#scope-translation)を使用して、Amazon Cognito で定義されたスコープを RabbitMQ 互換スコープにマッピングします。
1. 次の例に示すように、両方の認証方法を使用するブローカーを作成します。
```
aws mq create-broker \
--broker-name "rabbitmq-oauth2-broker-with-internal-user" \
--engine-type "RABBITMQ" \
--engine-version "3.13" \
--host-instance-type "mq.m7g.large" \
--deployment-mode "CLUSTER_MULTI_AZ" \
--logs '{"General": true}' \
--publicly-accessible \
--configuration '{"Id": "","Revision": }' \
--users '[{"Username":"","Password":""}]'
```
1. [Amazon Cognito による OAuth 2.0 認証の設定](#oauth-tutorial-config-cognito-using-cli) 手順のステップ 5 と 6 で説明されているように、ブローカーのステータスと認証方法の設定が成功したことを確認します。
# Amazon MQ for RabbitMQ での IAM 認証と認可の使用
次の手順は、Amazon MQ for RabbitMQ AWS ブローカーの IAM 認証と認可を有効にする方法を示しています。IAM を有効にすると、ユーザーは IAM AWS 認証情報を使用して RabbitMQ Management API にアクセスし、AMQP 経由で接続するための認証を行うことができます。Amazon MQ for RabbitMQ での IAM 認証の仕組みの詳細については、「」を参照してください[Amazon MQ for RabbitMQ の IAM 認証と認可](iam-for-amq-for-rabbitmq.md)。
## 前提条件
+ AWS Amazon MQ for RabbitMQ ブローカーを所有する AWS アカウントの管理者認証情報
+ これらの管理者認証情報で設定されたシェル環境 (CLI AWS プロファイルまたは環境変数を使用)
+ AWS CLI のインストールと設定
+ `jq` コマンドライン JSON プロセッサがインストールされている
+ `curl` コマンドラインツールのインストール
## を使用した IAM 認証と認可の設定 AWS CLI
1. **環境変数を設定する**
ブローカーに必要な環境変数を設定します。
```
export AWS_DEFAULT_REGION=
export BROKER_ID=
```
1. **アウトバウンド JWT トークンを有効にする**
AWS アカウントのアウトバウンドウェブ ID フェデレーションを有効にします。
```
ISSUER_IDENTIFIER=$(aws iam enable-outbound-web-identity-federation --query 'IssuerIdentifier' --output text)
echo $ISSUER_IDENTIFIER
```
出力には、アカウントの一意の発行者識別子 URL が 形式で表示されます`https://.tokens.sts.global.api.aws`。
1. **IAM ポリシードキュメントを作成する**
ウェブ ID トークンを取得するアクセス許可を付与するポリシードキュメントを作成します。
```
cat > policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"sts:GetWebIdentityToken",
"sts:TagGetWebIdentityToken"
],
"Resource": "*"
}
]
}
EOF
```
1. **信頼ポリシーを作成する**
発信者 ID を取得し、信頼ポリシードキュメントを作成します。
```
CALLER_ARN=$(aws sts get-caller-identity --query Arn --output text)
cat > trust-policy.json << EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "$CALLER_ARN"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
```
1. **IAM ロールを作成する**
IAM ロールを作成し、ポリシーをアタッチします。
```
aws iam create-role --role-name RabbitMqAdminRole --assume-role-policy-document file://trust-policy.json
aws iam put-role-policy --role-name RabbitMqAdminRole --policy-name RabbitMqAdminRolePolicy --policy-document file://policy.json
```
1. **RabbitMQ OAuth2 設定を構成する**
OAuth2 認証および認可設定を使用して RabbitMQ 設定ファイルを作成します。
```
cat > rabbitmq.conf << EOF
auth_backends.1 = oauth2
auth_backends.2 = internal
auth_oauth2.jwks_url = ${ISSUER_IDENTIFIER}/.well-known/jwks.json
auth_oauth2.resource_server_id = rabbitmq
auth_oauth2.scope_prefix = rabbitmq/
auth_oauth2.additional_scopes_key = sub
auth_oauth2.scope_aliases.1.alias = arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/RabbitMqAdminRole
auth_oauth2.scope_aliases.1.scope = rabbitmq/tag:administrator rabbitmq/read:*/* rabbitmq/write:*/* rabbitmq/configure:*/*
auth_oauth2.https.hostname_verification = wildcard
management.oauth_enabled = true
EOF
```
1. **ブローカー設定を更新する**
新しい設定をブローカーに適用します。
```
# Retrieve the configuration ID
CONFIG_ID=$(aws mq describe-broker --broker-id $BROKER_ID --query 'Configurations[0].Id' --output text)
# Create a new configuration revision
REVISION=$(aws mq update-configuration --configuration-id $CONFIG_ID --data "$(cat rabbitmq.conf | base64 --wrap=0)" --query 'LatestRevision.Revision' --output text)
# Apply the configuration to the broker
aws mq update-broker --broker-id $BROKER_ID --configuration Id=$CONFIG_ID,Revision=$REVISION
# Reboot the broker to apply changes
aws mq reboot-broker --broker-id $BROKER_ID
```
ブローカーのステータスが に戻るのを待って`RUNNING`から、次のステップに進みます。
1. **JWT トークンを取得する**
IAM ロールを引き受け、ウェブ ID トークンを取得します。
```
# Assume the RabbitMqAdminRole
ROLE_CREDS=$(aws sts assume-role --role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/RabbitMqAdminRole --role-session-name rabbitmq-session)
# Configure the session with temporary credentials
export AWS_ACCESS_KEY_ID=$(echo "$ROLE_CREDS" | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo "$ROLE_CREDS" | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo "$ROLE_CREDS" | jq -r '.Credentials.SessionToken')
# Obtain the web identity token
TOKEN_RESPONSE=$(aws sts get-web-identity-token \
--audience "rabbitmq" \
--signing-algorithm ES384 \
--duration-seconds 300 \
--tags Key=scope,Value="rabbitmq/tag:administrator")
# Extract the token
TOKEN=$(echo "$TOKEN_RESPONSE" | jq -r '.WebIdentityToken')
```
1. **RabbitMQ 管理 API にアクセスする**
JWT トークンを使用して RabbitMQ Management API にアクセスします。
```
BROKER_URL=.mq..on.aws
curl -u ":$TOKEN" \
-X GET https://${BROKER_URL}/api/overview \
-H "Content-Type: application/json"
```
応答が成功すると、IAM 認証が正しく動作していることが確認されます。レスポンスには、JSON 形式のブローカーの概要情報が含まれています。
1. **JWT トークンを使用して AMQP 経由で接続する**
パフォーマンステストツールで JWT トークンを使用して AMQP 接続をテストします。
```
BROKER_DNS=
CONNECTION_STRING=amqps://:${TOKEN}@${BROKER_DNS}:5671
docker run -it --rm --ulimit nofile=40960:40960 pivotalrabbitmq/perf-test:latest \
--queue-pattern 'test-queue-%d' --queue-pattern-from 1 --queue-pattern-to 1 \
--producers 1 --consumers 1 \
--uri ${CONNECTION_STRING} \
--flag persistent --rate 1
```
`ACCESS_REFUSED` エラーが発生した場合は、ブローカーの CloudWatch ログを使用して設定をトラブルシューティングできます。ブローカーの CloudWatch Logs ロググループのリンクは、Amazon MQ コンソールにあります。
# Amazon MQ for RabbitMQ での LDAP 認証と認可の使用
このチュートリアルでは、 を使用して Amazon MQ for RabbitMQ ブローカーの LDAP 認証と認可を設定する方法について説明します AWS Managed Microsoft AD。
**Topics**
+ [
## LDAP 認証と認可を設定するための前提条件
](#rabbitmq-ldap-tutorial-prerequisites)
+ [
## CLI を使用した RabbitMQ での LDAP AWS の設定
](#rabbitmq-ldap-tutorial-configure-cli)
## LDAP 認証と認可を設定するための前提条件
このチュートリアルで必要な AWS リソースを設定するには、[AWS Amazon MQ for RabbitMQ LDAP 統合用の CDK スタックを と AWS Managed Microsoft AD](https://github.com/aws-samples/amazon-mq-samples/blob/main/rabbitmq-samples/rabbitmq-ldap-activedirectory-sample/)デプロイします。
この CDK スタックは、LDAP ユーザーとグループ AWS Managed Microsoft AD、Network Load Balancer、証明書、IAM ロールなど、必要なすべての AWS リソースを自動的に作成します。スタックによって作成されたリソースの完全なリストについては、パッケージ README を参照してください。
CDK スタックを使用する代わりにリソースを手動で設定する場合は、Amazon MQ for RabbitMQ ブローカーで LDAP を設定する前に、同等のインフラストラクチャが整っていることを確認してください。
### Amazon MQ をセットアップするための前提条件
AWS CLI バージョン >= 2.28.23。ブローカーの作成時にユーザー名とパスワードをオプションで追加します。
## CLI を使用した RabbitMQ での LDAP AWS の設定
この手順では、 CLI AWS を使用して必要なリソースを作成および設定します。次の手順では、configurationID や Revision、 `` などのプレースホルダー値を実際の値に置き換え`<2>`てください。
1. 次の例に示すように、`create-configuration` AWS CLI コマンドを使用して新しい設定を作成します。
```
aws mq create-configuration \
--name "rabbitmq-ldap-config" \
--engine-type "RABBITMQ" \
--engine-version "3.13"
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"Arn": "arn:aws:mq:us-west-2:123456789012:configuration:c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"AuthenticationStrategy": "simple",
"Created": "2025-07-17T16:03:01.759943+00:00",
"Id": "c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"LatestRevision": {
"Created": "2025-07-17T16:03:01.759000+00:00",
"Description": "Auto-generated default for rabbitmq-ldap-config on RabbitMQ 3.13",
"Revision": 1
},
"Name": "rabbitmq-ldap-config"
}
```
1. 次の例に示すように、LDAP `rabbitmq.conf`を認証および認可方法として使用する という設定ファイルを作成します。テンプレート内のすべてのプレースホルダー値 ( でマーク) を`${RabbitMqLdapTestStack.*}`、デプロイされた AWS CDK 前提条件スタック出力または同等のインフラストラクチャの実際の値に置き換えます。
```
auth_backends.1 = ldap
# LDAP authentication settings - For more information,
# see https://www.rabbitmq.com/docs/ldap#basic
# FIXME: Replace the ${RabbitMqLdapTestStack.*} placeholders with actual values
# from your deployed prerequisite CDK stack outputs.
auth_ldap.servers.1 = ${RabbitMqLdapTestStack.NlbDnsName}
auth_ldap.dn_lookup_bind.user_dn = ${RabbitMqLdapTestStack.DnLookupUserDn}
auth_ldap.dn_lookup_base = ${RabbitMqLdapTestStack.DnLookupBase}
auth_ldap.dn_lookup_attribute = ${RabbitMqLdapTestStack.DnLookupAttribute}
auth_ldap.port = 636
auth_ldap.use_ssl = true
auth_ldap.ssl_options.verify = verify_peer
auth_ldap.log = network
# AWS integration for secure credential retrieval
# - see: https://github.com/amazon-mq/rabbitmq-aws
# The aws plugin allows RabbitMQ to securely retrieve credentials and certificates
# from AWS services.
# Replace the ${RabbitMqLdapTestStack.*} placeholders with actual ARN values
# from your deployed prerequisite CDK stack outputs.
aws.arns.auth_ldap.ssl_options.cacertfile = ${RabbitMqLdapTestStack.CaCertArn}
aws.arns.auth_ldap.dn_lookup_bind.password = ${RabbitMqLdapTestStack.DnLookupUserPasswordArn}
aws.arns.assume_role_arn = ${RabbitMqLdapTestStack.AmazonMqAssumeRoleArn}
# LDAP authorization queries - For more information,
# see: https://www.rabbitmq.com/docs/ldap#authorisation
# FIXME: Replace the ${RabbitMqLdapTestStack.*} placeholders with actual group DN
# values from your deployed prerequisite CDK stack outputs
# Uses Active Directory groups created by the prerequisite CDK stack
auth_ldap.queries.tags = '''
[{administrator, {in_group, "${RabbitMqLdapTestStack.RabbitMqAdministratorsGroupDn}"}},
{management, {in_group, "${RabbitMqLdapTestStack.RabbitMqMonitoringUsersGroupDn}"}}]
'''
# FIXME: This provides all authenticated users access to all vhosts
# - update to restrict access as required
auth_ldap.queries.vhost_access = '''
{constant, true}
'''
# FIXME: This provides all authenticated users full access to all
# queues and exchanges - update to restrict access as required
auth_ldap.queries.resource_access = '''
{for, [ {permission, configure, {constant, true}},
{permission, write,
{for, [{resource, queue, {constant, true}},
{resource, exchange, {constant, true}}]}},
{permission, read,
{for, [{resource, exchange, {constant, true}},
{resource, queue, {constant, true}}]}}
]
}
'''
# FIXME: This provides all authenticated users access to all topics
# - update to restrict access as required
auth_ldap.queries.topic_access = '''
{for, [{permission, write, {constant, true}},
{permission, read, {constant, true}}
]
}
'''
```
1. 次の例に示すように、`update-configuration` AWS CLI コマンドを使用して設定を更新します。このコマンドでは、この手順のステップ 1 のレスポンスで受け取った設定 ID を追加します。例えば、`c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca`。
```
aws mq update-configuration \
--configuration-id "" \
--data "$(cat rabbitmq.conf | base64 --wrap=0)"
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"Arn": "arn:aws:mq:us-west-2:123456789012:configuration:c-b600ac8e-8183-4f74-a713-983e59f30e3d",
"Created": "2025-07-17T16:57:04.520931+00:00",
"Id": "c-b600ac8e-8183-4f74-a713-983e59f30e3d",
"LatestRevision": {
"Created": "2025-07-17T16:57:39.172000+00:00",
"Revision": 2
},
"Name": "rabbitmq-ldap-config",
"Warnings": []
}
```
1. この手順のステップ 2 で作成した LDAP 設定を使用してブローカーを作成します。これを行うには、次の例に示すように `create-broker` AWS CLI コマンドを使用します。このコマンドでは、ステップ 1 と 2 のレスポンスで取得した設定 ID とリビジョン番号をそれぞれ指定します。例えば、`c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca` と `2` です。
```
aws mq create-broker \
--broker-name "rabbitmq-ldap-test-1" \
--engine-type "RABBITMQ" \
--engine-version "3.13" \
--host-instance-type "mq.m7g.large" \
--deployment-mode "CLUSTER_MULTI_AZ" \
--logs '{"General": true}' \
--publicly-accessible \
--configuration '{"Id": "","Revision": <2>}'
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"BrokerArn": "arn:aws:mq:us-west-2:123456789012:broker:rabbitmq-ldap-broker:b-2a1b5133-a10c-49d2-879b-8c176c34cf73",
"BrokerId": "b-2a1b5133-a10c-49d2-879b-8c176c34cf73"
}
```
**ブローカーの命名制限**
前提条件の CDK スタックによって作成された IAM ロールは、ブローカー名を で始まるように制限します`rabbitmq-ldap-test`。ブローカー名がこのパターンに従っているか、IAM ロールに ARN 解決のためにロールを引き受けるアクセス許可がないことを確認します。
1. 次の例に示すように `describe-broker` AWS CLI コマンドを使用して`RUNNING`、ブローカーのステータスが から `CREATION_IN_PROGRESS`に移行していることを確認します。このコマンドでは、前のステップの結果で取得したブローカー ID を指定します (例: `b-2a1b5133-a10c-49d2-879b-8c176c34cf73`)。
```
aws mq describe-broker \
--broker-id ""
```
このコマンドでは、次の例のようなレスポンスが返されます。次のレスポンスは、`describe-broker` コマンドが返す完全な出力の省略バージョンです。このレスポンスは、ブローカーのステータスと、ブローカーの保護に使用される認証戦略を示します。この場合、`config_managed`認証戦略はブローカーが LDAP 認証方法を使用していることを示します。
```
{
"AuthenticationStrategy": "config_managed",
...,
"BrokerState": "RUNNING",
...
}
```
1. 前提条件の CDK スタックによって作成されたテストユーザーの 1 人を使用して RabbitMQ アクセスを検証する
```
# FIXME: Replace ${RabbitMqLdapTestStack.ConsoleUserPasswordArn} with the actual ARN from your deployed prerequisite CDK stack outputs
CONSOLE_PASSWORD=$(aws secretsmanager get-secret-value \
--secret-id ${RabbitMqLdapTestStack.ConsoleUserPasswordArn} \
--query 'SecretString' --output text)
# FIXME: Replace BrokerConsoleURL with the actual ConsoleURL retrieved by
# calling describe-broker for the broker created above
# Call management API /api/overview (should succeed)
curl -u RabbitMqConsoleUser:$CONSOLE_PASSWORD \
https://${BrokerConsoleURL}/api/overview
# Try to create a user (should fail - console user only has monitoring permissions)
curl -u RabbitMqConsoleUser:$CONSOLE_PASSWORD \
-X PUT https://${BrokerConsoleURL}/api/users/testuser \
-H "Content-Type: application/json" \
-d '{"password":"testpass","tags":"management"}'
```
# Amazon MQ for RabbitMQ での HTTP 認証と認可の使用
このチュートリアルでは、外部 HTTP サーバーを使用して Amazon MQ for RabbitMQ ブローカーの HTTP 認証と認可を設定する方法について説明します。
**注記**
HTTP 認証プラグインは、Amazon MQ for RabbitMQ バージョン 4 以降でのみ使用できます。
**Topics**
+ [
## HTTP 認証と認可を設定するための前提条件
](#rabbitmq-http-tutorial-prerequisites)
+ [
## CLI を使用した RabbitMQ での HTTP AWS 認証の設定
](#rabbitmq-http-tutorial-configure-cli)
## HTTP 認証と認可を設定するための前提条件
このチュートリアルで必要な AWS リソースを設定するには、[AWS Amazon MQ for RabbitMQ HTTP 認証統合用の CDK スタック](https://github.com/aws-samples/amazon-mq-samples/blob/main/rabbitmq-samples/rabbitmq-http-sample/)をデプロイします。
この CDK スタックは、HTTP 認証サーバー、証明書、IAM ロールなど、必要なすべての AWS リソースを自動的に作成します。スタックによって作成されたリソースの完全なリストについては、パッケージ README を参照してください。
CDK スタックを使用する代わりにリソースを手動で設定する場合は、Amazon MQ for RabbitMQ ブローカーで HTTP 認証を設定する前に、同等のインフラストラクチャが整っていることを確認してください。
### Amazon MQ をセットアップするための前提条件
AWS CLI バージョン >= 2.28.23。ブローカーの作成時にユーザー名とパスワードをオプションで追加します。
## CLI を使用した RabbitMQ での HTTP AWS 認証の設定
この手順では、 CLI AWS を使用して必要なリソースを作成および設定します。次の手順では、プレースホルダー値を実際の値に置き換えてください。
1. 次の例に示すように、`create-configuration` AWS CLI コマンドを使用して新しい設定を作成します。
```
aws mq create-configuration \
--name "rabbitmq-http-config" \
--engine-type "RABBITMQ" \
--engine-version "4.2"
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"Arn": "arn:aws:mq:us-west-2:123456789012:configuration:c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"AuthenticationStrategy": "simple",
"Created": "2025-07-17T16:03:01.759943+00:00",
"Id": "c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"LatestRevision": {
"Created": "2025-07-17T16:03:01.759000+00:00",
"Description": "Auto-generated default for rabbitmq-http-config on RabbitMQ 4.2",
"Revision": 1
},
"Name": "rabbitmq-http-config"
}
```
1. 次の例に示すように、HTTP `rabbitmq.conf`を認証および認可方法として使用する という設定ファイルを作成します。テンプレート内のすべてのプレースホルダー値 ( でマーク) を`${...}`、デプロイされた AWS CDK 前提条件スタック出力または同等のインフラストラクチャの実際の値に置き換えます。
```
auth_backends.1 = cache
auth_backends.2 = http
auth_cache.cached_backend = http
# HTTP authentication settings
# For more information, see https://github.com/rabbitmq/rabbitmq-auth-backend-http
# FIXME: Replace the ${...} placeholders with actual values
# from your deployed prerequisite CDK stack outputs.
auth_http.http_method = post
auth_http.user_path = ${HttpServerUserPath}
auth_http.vhost_path = ${HttpServerVhostPath}
auth_http.resource_path = ${HttpServerResourcePath}
auth_http.topic_path = ${HttpServerTopicPath}
# TLS/HTTPS configuration
auth_http.ssl_options.verify = verify_peer
auth_http.ssl_options.sni = test.amazonaws.com
# AWS integration for secure credential retrieval
# For more information, see https://github.com/amazon-mq/rabbitmq-aws
# Replace the ${...} placeholders with actual ARN values
# from your deployed prerequisite CDK stack outputs.
aws.arns.assume_role_arn = ${AmazonMqAssumeRoleArn}
aws.arns.auth_http.ssl_options.cacertfile = ${CaCertArn}
```
1. `update-configuration` AWS CLI コマンドを使用して設定を更新します。ステップ 3 の設定 ID を使用します。
```
aws mq update-configuration \
--configuration-id "" \
--data "$(cat rabbitmq.conf | base64 --wrap=0)"
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"Arn": "arn:aws:mq:us-west-2:123456789012:configuration:c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"Created": "2025-07-17T16:57:04.520931+00:00",
"Id": "c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"LatestRevision": {
"Created": "2025-07-17T16:57:39.172000+00:00",
"Revision": 2
},
"Name": "rabbitmq-http-config",
"Warnings": []
}
```
1. HTTP 設定でブローカーを作成します。前のステップの設定 ID とリビジョン番号を使用します。
```
aws mq create-broker \
--broker-name "rabbitmq-http-test-1" \
--engine-type "RABBITMQ" \
--engine-version "4.2" \
--host-instance-type "mq.m7g.large" \
--deployment-mode "SINGLE_INSTANCE" \
--logs '{"General": true}' \
--publicly-accessible \
--configuration '{"Id": "","Revision": <2>}'
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"BrokerArn": "arn:aws:mq:us-west-2:123456789012:broker:rabbitmq-http-test-1:b-2a1b5133-a10c-49d2-879b-8c176c34cf73",
"BrokerId": "b-2a1b5133-a10c-49d2-879b-8c176c34cf73"
}
```
1. `describe-broker` AWS CLI コマンドを使用して`RUNNING`、ブローカーのステータスが から `CREATION_IN_PROGRESS`に移行していることを確認します。
```
aws mq describe-broker \
--broker-id ""
```
このコマンドでは、次の例のようなレスポンスが返されます。`config_managed` 認証戦略は、ブローカーが HTTP 認証方法を使用していることを示します。
```
{
"AuthenticationStrategy": "config_managed",
...,
"BrokerState": "RUNNING",
...
}
```
1. 前提条件の CDK スタックによって作成されたテストユーザーの 1 人を使用して RabbitMQ アクセスを検証する
```
# FIXME: Replace ${RabbitMqHttpAuthElbStack.ConsoleUserPasswordArn} with the actual ARN from your deployed prerequisite CDK stack outputs
CONSOLE_PASSWORD=$(aws secretsmanager get-secret-value \
--secret-id ${RabbitMqHttpAuthElbStack.ConsoleUserPasswordArn} \
--query 'SecretString' --output text)
# FIXME: Replace BrokerConsoleURL with the actual ConsoleURL retrieved by
# calling describe-broker for the broker created above
# Call management API /api/overview (should succeed)
curl -u RabbitMqConsoleUser:$CONSOLE_PASSWORD \
https://${BrokerConsoleURL}/api/overview
# Try to create a vhost (should fail - console user only has management permissions)
curl -u RabbitMqConsoleUser:$CONSOLE_PASSWORD \
-X PUT https://${BrokerConsoleURL}/api/vhosts/test-vhost \
-H "Content-Type: application/json" \
-d '{}'
```
# Amazon MQ for RabbitMQ での SSL 証明書認証の使用
このチュートリアルでは、プライベート認証機関を使用して Amazon MQ for RabbitMQ ブローカーの SSL 証明書認証を設定する方法について説明します。
**注記**
SSL 証明書認証プラグインは、Amazon MQ for RabbitMQ バージョン 4 以降でのみ使用できます。
**Topics**
+ [
## SSL 証明書認証を設定するための前提条件
](#rabbitmq-ssl-tutorial-prerequisites)
+ [
## CLI を使用した RabbitMQ での SSL AWS 証明書認証の設定
](#rabbitmq-ssl-tutorial-configure-cli)
## SSL 証明書認証を設定するための前提条件
SSL 証明書認証は、相互 TLS (mTLS) を使用して X.509 証明書を使用してクライアントを認証します。このチュートリアルで必要な AWS リソースを設定するには、[AWS Amazon MQ for RabbitMQ mTLS 統合用の CDK スタック](https://github.com/aws-samples/amazon-mq-samples/blob/main/rabbitmq-samples/rabbitmq-mtls-sample/)をデプロイします。
この CDK スタックは、認証機関、クライアント証明書、IAM ロールなど、必要なすべての AWS リソースを自動的に作成します。スタックによって作成されたリソースの完全なリストについては、パッケージ README を参照してください。
**注記**
CDK スタックをデプロイする前に、 `RABBITMQ_TEST_USER_NAME`環境変数を設定します。この値はクライアント証明書の共通名 (CN) として使用され、チュートリアルのステップで使用するユーザー名と一致する必要があります。例: `export RABBITMQ_TEST_USER_NAME="myuser"`
CDK スタックを使用する代わりにリソースを手動で設定する場合は、Amazon MQ for RabbitMQ ブローカーで SSL 証明書認証を設定する前に、同等のインフラストラクチャが整っていることを確認してください。
### Amazon MQ をセットアップするための前提条件
AWS CLI バージョン >= 2.28.23。ブローカーの作成時にユーザー名とパスワードをオプションで追加します。
## CLI を使用した RabbitMQ での SSL AWS 証明書認証の設定
この手順では、 CLI AWS を使用して必要なリソースを作成および設定します。次の手順では、configurationID や Revision、 `` などのプレースホルダー値を実際の値に置き換え`<2>`てください。
1. 次の例に示すように、`create-configuration` AWS CLI コマンドを使用して新しい設定を作成します。
```
aws mq create-configuration \
--name "rabbitmq-ssl-config" \
--engine-type "RABBITMQ" \
--engine-version "4.2"
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"Arn": "arn:aws:mq:us-west-2:123456789012:configuration:c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"AuthenticationStrategy": "simple",
"Created": "2025-07-17T16:03:01.759943+00:00",
"Id": "c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"LatestRevision": {
"Created": "2025-07-17T16:03:01.759000+00:00",
"Description": "Auto-generated default for rabbitmq-ssl-config on RabbitMQ 4.2",
"Revision": 1
},
"Name": "rabbitmq-ssl-config"
}
```
1. 次の例に示すように、SSL 証明書認証を使用する`rabbitmq.conf`ように という設定ファイルを作成します。テンプレート内のすべてのプレースホルダー値 ( でマーク) を`${...}`、デプロイされた AWS CDK 前提条件スタック出力または同等のインフラストラクチャの実際の値に置き換えます。
```
auth_mechanisms.1 = EXTERNAL
ssl_cert_login_from = common_name
auth_backends.1 = internal
# Reject if no client cert
ssl_options.verify = verify_peer
ssl_options.fail_if_no_peer_cert = true
# AWS integration for secure credential retrieval
# For more information, see https://github.com/amazon-mq/rabbitmq-aws
# FIXME: Replace the ${...} placeholders with actual ARN values
# from your deployed prerequisite CDK stack outputs.
aws.arns.assume_role_arn = ${AmazonMqAssumeRoleArn}
aws.arns.ssl_options.cacertfile = ${CaCertArn}
```
1. 次の例に示すように、`update-configuration` AWS CLI コマンドを使用して設定を更新します。このコマンドでは、この手順のステップ 1 のレスポンスで受け取った設定 ID を追加します。例えば、`c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca`。
```
aws mq update-configuration \
--configuration-id "" \
--data "$(cat rabbitmq.conf | base64 --wrap=0)"
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"Arn": "arn:aws:mq:us-west-2:123456789012:configuration:c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"Created": "2025-07-17T16:57:04.520931+00:00",
"Id": "c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"LatestRevision": {
"Created": "2025-07-17T16:57:39.172000+00:00",
"Revision": 2
},
"Name": "rabbitmq-ssl-config",
"Warnings": []
}
```
1. この手順のステップ 2 で作成した SSL 証明書認証設定を使用してブローカーを作成します。これを行うには、次の例に示すように `create-broker` AWS CLI コマンドを使用します。このコマンドでは、ステップ 1 と 2 のレスポンスで取得した設定 ID とリビジョン番号をそれぞれ指定します。例えば、`c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca` と `2` です。
```
aws mq create-broker \
--broker-name "rabbitmq-ssl-test-1" \
--engine-type "RABBITMQ" \
--engine-version "4.2" \
--host-instance-type "mq.m7g.large" \
--deployment-mode "SINGLE_INSTANCE" \
--logs '{"General": true}' \
--publicly-accessible \
--configuration '{"Id": "","Revision": <2>}' \
--users '[{"Username":"testuser","Password":"testpassword"}]'
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"BrokerArn": "arn:aws:mq:us-west-2:123456789012:broker:rabbitmq-ssl-test-1:b-2a1b5133-a10c-49d2-879b-8c176c34cf73",
"BrokerId": "b-2a1b5133-a10c-49d2-879b-8c176c34cf73"
}
```
1. 次の例に示すように `describe-broker` AWS CLI コマンドを使用して`RUNNING`、ブローカーのステータスが から `CREATION_IN_PROGRESS`に移行していることを確認します。このコマンドでは、前のステップの結果で取得したブローカー ID を指定します。例えば、`b-2a1b5133-a10c-49d2-879b-8c176c34cf73`。
```
aws mq describe-broker \
--broker-id ""
```
このコマンドでは、次の例のようなレスポンスが返されます。次のレスポンスは、`describe-broker` コマンドが返す完全な出力の省略バージョンです。このレスポンスは、ブローカーのステータスと、ブローカーの保護に使用される認証戦略を示します。この場合、`config_managed`認証戦略はブローカーが SSL 証明書認証方法を使用していることを示します。
```
{
"AuthenticationStrategy": "config_managed",
...,
"BrokerState": "RUNNING",
...
}
```
1. 次の`ssl.sh`スクリプトを使用して SSL 証明書認証を検証します。
この bash スクリプトを使用して、Amazon MQ for RabbitMQ ブローカーへの接続をテストします。このスクリプトは、認証にクライアント証明書を使用し、接続が正しく設定されているかどうかを確認します。正常に設定されると、ブローカーがメッセージを発行して消費します。
`ACCESS_REFUSED` エラーが発生した場合は、ブローカーの CloudWatch ログを使用して設定をトラブルシューティングできます。ブローカーの CloudWatch ロググループのリンクは、Amazon MQ コンソールにあります。
このスクリプトでは、次の値を指定する必要があります。
+ `USERNAME`: クライアント証明書の共通名 (CN)。
+ `CLIENT_KEYSTORE`: クライアントキーストアファイルへのパス (PKCS12 形式）。前提条件の CDK スタックを使用した場合、デフォルトのパスは です`$(pwd)/certs/client-keystore.p12`。
+ `KEYSTORE_PASSWORD`: クライアントキーストアのパスワード。前提条件の CDK スタックを使用した場合、デフォルトのパスワードは です`changeit`。
+ `BROKER_DNS`: この値は、Amazon MQ コンソールのブローカーの詳細ページの **Connections** にあります。
```
#! /bin/bash
set -e
# Client information
## FIXME: Update this value with the client ID and secret of your confidential application client
USERNAME=
CLIENT_KEYSTORE=$(pwd)/certs/client-keystore.p12
KEYSTORE_PASSWORD=changeit
BROKER_DNS=
CONNECTION_STRING=amqps://${BROKER_DNS}:5671
# Produce/consume messages using the above connection string
QUEUES_COUNT=1
PRODUCERS_COUNT=1
CONSUMERS_COUNT=1
PRODUCER_RATE=1
finch run --rm --ulimit nofile=40960:40960 \
-v ${CLIENT_KEYSTORE}:/certs/client-keystore.p12:ro \
-e JAVA_TOOL_OPTIONS="-Djavax.net.ssl.keyStore=/certs/client-keystore.p12 -Djavax.net.ssl.keyStorePassword=${KEYSTORE_PASSWORD} -Djavax.net.ssl.keyStoreType=PKCS12" \
pivotalrabbitmq/perf-test:latest \
--queue-pattern 'test-queue-cert-%d' --queue-pattern-from 1 --queue-pattern-to $QUEUES_COUNT \
--producers $PRODUCERS_COUNT --consumers $CONSUMERS_COUNT \
--id "cert-test${QUEUES_COUNT}q${PRODUCERS_COUNT}p${CONSUMERS_COUNT}c${PRODUCER_RATE}r" \
--uri ${CONNECTION_STRING} \
--sasl-external \
--use-default-ssl-context \
--flag persistent --rate $PRODUCER_RATE
```
# AMQP および管理エンドポイントに mTLS を使用する
このチュートリアルでは、プライベート認証機関を使用して AMQP クライアント接続と RabbitMQ 管理インターフェイスの相互 TLS (mTLS) を設定する方法について説明します。
**注記**
mTLS のプライベート認証機関の使用は、Amazon MQ for RabbitMQ バージョン 4 以降でのみ使用できます。
**Topics**
+ [
## mTLS を設定するための前提条件
](#rabbitmq-mtls-tutorial-prerequisites)
+ [
## CLI を使用した RabbitMQ での mTLS AWS の設定
](#rabbitmq-mtls-tutorial-configure-cli)
## mTLS を設定するための前提条件
このチュートリアルで必要な AWS リソースを設定するには、[AWS Amazon MQ for RabbitMQ mTLS 統合用の CDK スタックを に](https://github.com/aws-samples/amazon-mq-samples/blob/main/rabbitmq-samples/rabbitmq-mtls-sample/)デプロイします。
この CDK スタックは、認証機関、クライアント証明書、IAM ロールなど、必要なすべての AWS リソースを自動的に作成します。スタックによって作成されたリソースの完全なリストについては、パッケージ README を参照してください。
CDK スタックを使用する代わりにリソースを手動で設定する場合は、Amazon MQ for RabbitMQ ブローカーで mTLS を設定する前に、同等のインフラストラクチャが整っていることを確認してください。
### Amazon MQ をセットアップするための前提条件
AWS CLI バージョン >= 2.28.23。ブローカーの作成時にユーザー名とパスワードをオプションで追加します。
## CLI を使用した RabbitMQ での mTLS AWS の設定
この手順では、 CLI AWS を使用して必要なリソースを作成および設定します。次の手順では、configurationID や Revision、 `` などのプレースホルダー値を実際の値に置き換え`<2>`てください。
1. 次の例に示すように、`create-configuration` AWS CLI コマンドを使用して新しい設定を作成します。
```
aws mq create-configuration \
--name "rabbitmq-mtls-config" \
--engine-type "RABBITMQ" \
--engine-version "4.2"
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"Arn": "arn:aws:mq:us-west-2:123456789012:configuration:c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"AuthenticationStrategy": "simple",
"Created": "2025-07-17T16:03:01.759943+00:00",
"Id": "c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"LatestRevision": {
"Created": "2025-07-17T16:03:01.759000+00:00",
"Description": "Auto-generated default for rabbitmq-mtls-config on RabbitMQ 4.2",
"Revision": 1
},
"Name": "rabbitmq-mtls-config"
}
```
1. 次の例に示すように、 という設定ファイルを作成して、AMQP および管理エンドポイントの mTLS `rabbitmq.conf`を設定します。テンプレート内のすべてのプレースホルダー値 ( でマーク) を`${...}`、デプロイされた AWS CDK 前提条件スタック出力または同等のインフラストラクチャの実際の値に置き換えます。
```
auth_backends.1 = internal
# TLS configuration
ssl_options.verify = verify_peer
ssl_options.fail_if_no_peer_cert = true
management.ssl.verify = verify_peer
# AWS integration for secure credential retrieval
# For more information, see https://github.com/amazon-mq/rabbitmq-aws
# FIXME: Replace the ${...} placeholders with actual ARN values
# from your deployed prerequisite CDK stack outputs.
aws.arns.assume_role_arn = ${AmazonMqAssumeRoleArn}
aws.arns.ssl_options.cacertfile = ${CaCertArn}
aws.arns.management.ssl.cacertfile = ${CaCertArn}
```
1. 次の例に示すように、`update-configuration` AWS CLI コマンドを使用して設定を更新します。このコマンドでは、この手順のステップ 1 のレスポンスで受け取った設定 ID を追加します。例えば、`c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca`。
```
aws mq update-configuration \
--configuration-id "" \
--data "$(cat rabbitmq.conf | base64 --wrap=0)"
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"Arn": "arn:aws:mq:us-west-2:123456789012:configuration:c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"Created": "2025-07-17T16:57:04.520931+00:00",
"Id": "c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca",
"LatestRevision": {
"Created": "2025-07-17T16:57:39.172000+00:00",
"Revision": 2
},
"Name": "rabbitmq-mtls-config",
"Warnings": []
}
```
1. この手順のステップ 2 で作成した mTLS 設定を使用してブローカーを作成します。これを行うには、次の例に示すように `create-broker` AWS CLI コマンドを使用します。このコマンドでは、ステップ 1 と 2 のレスポンスで取得した設定 ID とリビジョン番号をそれぞれ指定します。例えば、`c-fa3390a5-7e01-4559-ae0c-eb15b38b22ca` と `2` です。
```
aws mq create-broker \
--broker-name "rabbitmq-mtls-test-1" \
--engine-type "RABBITMQ" \
--engine-version "4.2" \
--host-instance-type "mq.m7g.large" \
--deployment-mode "SINGLE_INSTANCE" \
--logs '{"General": true}' \
--publicly-accessible \
--configuration '{"Id": "","Revision": <2>}' \
--users '[{"Username":"testuser","Password":"testpassword"}]'
```
このコマンドでは、次の例のようなレスポンスが返されます。
```
{
"BrokerArn": "arn:aws:mq:us-west-2:123456789012:broker:rabbitmq-mtls-test-1:b-2a1b5133-a10c-49d2-879b-8c176c34cf73",
"BrokerId": "b-2a1b5133-a10c-49d2-879b-8c176c34cf73"
}
```
1. 次の例に示すように `describe-broker` AWS CLI コマンドを使用して`RUNNING`、ブローカーのステータスが から `CREATION_IN_PROGRESS`に移行していることを確認します。このコマンドでは、前のステップの結果で取得したブローカー ID を指定します。例えば、`b-2a1b5133-a10c-49d2-879b-8c176c34cf73`。
```
aws mq describe-broker \
--broker-id ""
```
このコマンドでは、次の例のようなレスポンスが返されます。次のレスポンスは、`describe-broker` コマンドが返す完全な出力の省略バージョンです。
```
{
"AuthenticationStrategy": "simple",
...,
"BrokerState": "RUNNING",
...
}
```
1. 次の`mtls.sh`スクリプトを使用して mTLS 認証を検証します。
この bash スクリプトを使用して、Amazon MQ for RabbitMQ ブローカーへの接続をテストします。このスクリプトは、クライアント証明書を使用して認証し、接続が正しく設定されているかどうかを確認します。正常に設定されると、ブローカーがメッセージを発行して消費します。
`ACCESS_REFUSED` エラーが発生した場合は、ブローカーの CloudWatch ログを使用して設定をトラブルシューティングできます。ブローカーの CloudWatch ロググループのリンクは、Amazon MQ コンソールにあります。
このスクリプトでは、次の値を指定する必要があります。
+ `USERNAME` および `PASSWORD`: ブローカーで作成した RabbitMQ ユーザー認証情報。
+ `CLIENT_KEYSTORE`: クライアントキーストアファイルへのパス (PKCS12 形式）。前提条件の CDK スタックを使用した場合、デフォルトのパスは です`$(pwd)/certs/client-keystore.p12`。
+ `KEYSTORE_PASSWORD`: クライアントキーストアのパスワード。前提条件の CDK スタックを使用した場合、デフォルトのパスワードは です`changeit`。
+ `BROKER_DNS`: この値は、Amazon MQ コンソールのブローカーの詳細ページの **Connections** にあります。
```
#! /bin/bash
set -e
# Client information
## FIXME: Update this value with the client ID and secret of your confidential application client
USERNAME=
PASSWORD=
CLIENT_KEYSTORE=$(pwd)/certs/client-keystore.p12
KEYSTORE_PASSWORD=changeit
BROKER_DNS=
CONNECTION_STRING=amqps://${USERNAME}:${PASSWORD}@${BROKER_DNS}:5671
# Produce/consume messages using the above connection string
QUEUES_COUNT=1
PRODUCERS_COUNT=1
CONSUMERS_COUNT=1
PRODUCER_RATE=1
finch run --rm --ulimit nofile=40960:40960 \
-v ${CLIENT_KEYSTORE}:/certs/client-keystore.p12:ro \
-e JAVA_TOOL_OPTIONS="-Djavax.net.ssl.keyStore=/certs/client-keystore.p12 -Djavax.net.ssl.keyStorePassword=${KEYSTORE_PASSWORD} -Djavax.net.ssl.keyStoreType=PKCS12" \
pivotalrabbitmq/perf-test:latest \
--queue-pattern 'test-queue-cert-%d' --queue-pattern-from 1 --queue-pattern-to $QUEUES_COUNT \
--producers $PRODUCERS_COUNT --consumers $CONSUMERS_COUNT \
--id "cert-test${QUEUES_COUNT}q${PRODUCERS_COUNT}p${CONSUMERS_COUNT}c${PRODUCER_RATE}r" \
--uri ${CONNECTION_STRING} \
--use-default-ssl-context \
--flag persistent --rate $PRODUCER_RATE
```
# JMS アプリケーションを接続する
このチュートリアルでは、RabbitMQ JMS クライアントを使用して JMS アプリケーションを Amazon MQ for RabbitMQ ブローカーに接続する方法を示します。 RabbitMQ プロデューサーを作成してメッセージを送信し、コンシューマーを作成して RabbitMQ キューからメッセージを受信する方法について説明します。
開始する前に、適切な RabbitMQ JMS 依存関係を Maven プロジェクトに追加します。
JMS 1.1 および 2.0 の場合:
```
com.rabbitmq.jms
rabbitmq-jms
2.12.0
```
JMS 3.1 の場合:
```
com.rabbitmq.jms
rabbitmq-jms
3.5.0
```
## プロデューサーを作成する
次のコード例は、JMS を使用して RabbitMQ キューに書き込む方法を示しています。
```
import jakarta.jms.*;
import com.rabbitmq.jms.admin.*;
// Setting the connection factory
RMQConnectionFactory factory = new RMQConnectionFactory();
factory.setHost(envProps.getProperty("RABBITMQ_HOST", "localhost"));
factory.setPort(Integer.parseInt(envProps.getProperty("RABBITMQ_PORT", "5672")));
factory.setUsername(envProps.getProperty("RABBITMQ_USERNAME", "guest"));
factory.setPassword(envProps.getProperty("RABBITMQ_PASSWORD", "guest"));
factory.setVirtualHost(envProps.getProperty("RABBITMQ_VIRTUAL_HOST", "/"));
factory.useSslProtocol();
connection = factory.createConnection();
connection.start();
String queueName = "test-queue-jms";
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
RMQDestination destination = new RMQDestination(queueName, true, false);
// Send the message to the queue
MessageProducer producer = session.createProducer(destination);
producer.setDeliveryMode(DeliveryMode.PERSISTENT);
String msg_content = "Hello World!!";
TextMessage textMessage = session.createTextMessage(msg_content);
producer.send(textMessage);
System.out.printf("Published to AMQP queue '%s': %s", queueName, msg_content);
```
## コンシューマーを作成する
次のコード例は、JMS を使用して RabbitMQ キューから読み取る方法を示しています。
```
import jakarta.jms.*;
import com.rabbitmq.jms.admin.*;
// Setting the connection factory
RMQConnectionFactory factory = new RMQConnectionFactory();
factory.setHost(envProps.getProperty("RABBITMQ_HOST", "localhost"));
factory.setPort(Integer.parseInt(envProps.getProperty("RABBITMQ_PORT", "5672")));
factory.setUsername(envProps.getProperty("RABBITMQ_USERNAME", "guest"));
factory.setPassword(envProps.getProperty("RABBITMQ_PASSWORD", "guest"));
factory.setVirtualHost(envProps.getProperty("RABBITMQ_VIRTUAL_HOST", "/"));
factory.useSslProtocol();
// Establish the connection and session
jakarta.jms.Connection connection = factory.createConnection();
String queueName = "test-queue-jms";
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
RMQDestination destination = new RMQDestination();
destination.setDestinationName(queueName);
destination.setAmqp(true);
destination.setAmqpQueueName(queueName);
// Initialize consumer
MessageConsumer consumer = session.createConsumer(destination);
consumer.setMessageListener(message -> {
try {
if (message instanceof TextMessage) {
TextMessage textMessage = (TextMessage) message;
System.out.printf("Message: %s%n", textMessage.getText());
} else if (message instanceof BytesMessage) {
BytesMessage bytesMessage = (BytesMessage) message;
byte[] bytes = new byte[(int) bytesMessage.getBodyLength()];
bytesMessage.readBytes(bytes);
String content = new String(bytes);
System.out.printf("Message: %s%n", content);
} else {
System.out.printf("Message: [%s]%n", message.getClass().getSimpleName());
}
} catch (JMSException e) {
System.err.printf("Error processing message: %s%n", e.getMessage());
}
});
connection.start();
```