

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon MQ for RabbitMQ でのブローカーのセットアップと接続管理のベストプラクティス
<a name="best-practices-broker-setup"></a>

 ブローカーのセットアップと接続管理は、ブローカーメッセージのスループット、リソース使用率、本番環境のワークロードを処理する機能に関する問題を防ぐ最初のステップです。[Amazon MQ for RabbitMQ ブローカーを作成および設定する](getting-started-rabbitmq.md#create-rabbitmq-broker)ときは、適切なインスタンスタイプの選択、接続の効率的な管理、ブローカーのパフォーマンスを最大化するためのメッセージプリフェッチの設定に関する以下のベストプラクティスを完了してください。

**重要**  
Amazon MQ for RabbitMQ では、ユーザー名「guest」はサポートされず、デフォルトのゲストアカウントは新しいブローカーの作成時に削除されます。ユーザーが作成した「guest」というアカウントも、Amazon MQ によって定期的に削除されます。

## ステップ 1: クラスターデプロイを使用する
<a name="use-cluster-deployments-for-high-availability"></a>

 本番ワークロードでは、高可用性とメッセージの耐障害性を確保するために、単一インスタンスブローカーの代わりにクラスターデプロイを使用することをお勧めします。クラスターデプロイでは、単一障害点が削除され、耐障害性が向上します。

 クラスターデプロイは、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: 正しいブローカーインスタンスタイプを選択する
<a name="choose-broker-instance-type"></a>

 ブローカーインスタンスタイプのメッセージスループットは、アプリケーションのユースケースによって異なります。`M7g.medium` はアプリケーションパフォーマンスのテストにのみ使用する必要があります。本番環境で大きいインスタンスを使用する前に、この小さいインスタンスを使用すると、アプリケーションのパフォーマンスを向上させることができます。`m7g.large` 以上のインスタンスタイプでは、クラスターデプロイを使用して高可用性とメッセージの耐久性を確保できます。大きいブローカーインスタンスタイプは、本番稼働レベルのクライアントとキュー、高スループット、メモリ内のメッセージ、冗長メッセージを処理できます。

 適切なインスタンスタイプを選択する方法の詳細については、「[Amazon MQ for RabbitMQ のサイズ設定ガイドライン](rabbitmq-sizing-guidelines.md)」を参照してください。

## ステップ 3: クォーラムキューを使用する
<a name="use-quorum-queues"></a>

 クラスターデプロイのクォーラムキューは、3.13 以降の RabbitMQ ブローカーの本番環境でレプリケートされたキュータイプのデフォルトの選択肢である必要があります。クォーラムキューは、高い信頼性、高スループット、安定したレイテンシーを提供する最新のレプリケートキュータイプです。

 クォーラムキューは Raft コンセンサスアルゴリズムを使用して耐障害性を向上させます。リーダーノードが使用できなくなると、クォーラムキューは過半数投票によって自動的に新しいリーダーを選択し、メッセージ配信が中断を最小限に抑えながら継続されるようにします。各ノードは異なるアベイラビリティーゾーンにあるため、1 つのアベイラビリティーゾーン全体が一時的に使用できなくなってもメッセージングシステムは引き続き使用できます。

 クォーラムキューを宣言するには、キューの作成時に `x-queue-type` ヘッダーを `quorum` に設定します。

 移行戦略やベストプラクティスなど、クォーラムキューの詳細については、「[Amazon MQ for RabbitMQ のクォーラムキュー](quorum-queues.md)」を参照してください。

## ステップ 4: 複数のチャネルを使用する
<a name="use-multiple-channels"></a>

 接続チャーンを回避するには、1 つの接続で複数のチャネルを使用します。アプリケーションでは、チャネルに対する 1:1 の接続を避ける必要があります。プロセスごとに 1 つの接続を使用し、スレッドごとに 1 つのチャネルを使用することをお勧めします。チャネルのリークを防ぐために、チャネルを過剰に使用することは避けてください。