RabbitMQ 4 - Amazon MQ

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

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: 詳細については、「プロトコル」を参照してください。

  • ローカルシャベル: 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 設定を参照してください。

  • SSL 証明書認証プラグイン: SSL 認証プラグインは mTLS 接続のクライアント証明書を使用してユーザーを認証し、ユーザー名とパスワード認証情報の代わりに X.509 クライアント証明書を使用した認証を許可します。詳細については、「SSL 証明書認証」を参照してください。

  • HTTP 認証プラグイン: HTTP 認証バックエンドプラグインを使用すると、認証と認可を外部 HTTP サービスに委任できます。詳細については、「HTTP 認証と認可」を参照してください。

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_max < 8192 を使用する AMQP クライアントライブラリは RabbitMQ に接続できません

  • デフォルトのリソース制限: Amazon MQ for RabbitMQ では、接続、チャネル、チャネルあたりのコンシューマー、キュー、vhost、シャベル、交換、最大メッセージサイズにデフォルトのリソース使用制限が導入されました。これらはブローカーの可用性を保護するためのガードレールとして機能し、特定の要件に合わせて設定を使用してカスタマイズできます。

Amazon MQ の RabbitMQ 4 では、以下の機能はサポートされていません。

  • ローカルランダム交換: Amazon MQ ノードがネットワークロードバランサーの背後にあるため、ローカルランダム交換は Amazon MQ ではサポートされていません。

  • メッセージインターセプター: RabbitMQ メッセージインターセプターは Amazon MQ ではサポートされていません。

  • キューごとのメトリクス: Amazon MQ は、 AWS CloudWatch を通じて RabbitMQ 4 ブローカーの RabbitMQ キューメトリクスを提供しません。Amazon MQ は引き続き AWS CloudWatch を通じてブローカーレベルのメトリクスを提供します。RabbitMQ 管理 API を使用してキューメトリクスをクエリできます。特定のキューのメトリクスを 1 分以上の頻度でクエリすることをお勧めします。