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

Amazon MQ for RabbitMQ でのネットワークレジリエンスとモニタリングのベストプラクティス

信頼性の高いメッセージングアプリケーションを維持するには、ネットワークのレジリエンスとブローカーメトリクスのモニタリングが不可欠です。自動復旧メカニズムとリソースモニタリング戦略を実装するには、次のベストプラクティスを実行します。

ステップ 1: ネットワーク障害から自動的に復旧する

RabbitMQ ノードへのクライアント接続が失敗した場合の大幅なダウンタイムを防ぐため、自動ネットワークリカバリを常に有効にしておくことをお勧めします。バージョン 4.0.0 以降の RabbitMQ Java クライアントライブラリは、自動ネットワークリカバリをデフォルトでサポートします。

自動接続リカバリは、接続の I/O ループで未処理の例外がスローされた場合、ソケット読み取り操作のタイムアウトが検出された場合、またはサーバーがハートビートを受信しない場合にトリガーされます。

クライアントと 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
}

ステップ 2: ブローカーメトリクスとアラームをモニタリングする

Amazon MQ for RabbitMQ ブローカーの CloudWatch メトリクスとアラームを定期的にモニタリングして、メッセージングアプリケーションに影響を与える前に潜在的な問題を特定して対処することをお勧めします。プロアクティブモニタリングは、回復力のあるメッセージングアプリケーションを維持し、最適なパフォーマンスを確保するために不可欠です。

Amazon MQ for RabbitMQ は、ブローカーのパフォーマンス、リソース使用率、メッセージフローに関するインサイトを提供するメトリクスを CloudWatch に発行します。モニタリングする主なメトリクスには、メモリ使用量とディスク使用量が含まれます。ブローカーがリソース制限に近づいたり、パフォーマンスが低下したりしたときの CloudWatch アラームを設定できます。

クラスターデプロイでは、ノード固有のメトリクスもモニタリングして、ノード固有の問題を特定します。