トラブルシューティング: 一般的な Amazon MQ - Amazon MQ
ブローカーのウェブコンソールまたはエンドポイントに接続できません。SSL 例外ブローカーを作成しましたが、ブローカーの作成に失敗しました。ブローカーが再起動したのですが、その理由がよくわかりません。

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

トラブルシューティング: 一般的な Amazon MQ

このセクションの情報を使用して、ブローカーへの接続問題、またはブローカーの再起動などの、Amazon MQ ブローカーの使用時に発生する可能性がある一般的な問題の診断に役立てます。

ブローカーのウェブコンソールまたはエンドポイントに接続できません。

ウェブコンソールまたはワイヤレベルのエンドポイントを使用したブローカーへの接続で問題が発生する場合は、以下の手順が推奨されます。

  1. ファイアウォールの内側からブローカーに接続しようとしているかどうかをチェックします。ブローカーへのアクセスを許可するようにファイアウォールを設定する必要がある場合があります。

  2. FIPS エンドポイントを使用して、ブローカーに接続しようとしているかどうかをチェックしてください。Amazon MQ では、API オペレーションを使用する場合のみ FIPS エンドポイントがサポートされ、ブローカーインスタンス自体へのワイヤレベルの接続はサポートされません。

  3. ブローカーの [Public Accessibility] (パブリックアクセシビリティ) オプションが [Yes] (はい) に設定されているかどうかをチェックします。これが [No] (いいえ) に設定されている場合は、サブネットのネットワークアクセスコントロールリスト (ACL) ルールをチェックしてください。カスタムネットワーク ACL を作成した場合は、ブローカーへのアクセス権を提供するようにネットワーク ACL ルールを変更する必要がある場合があります。Amazon VPC ネットワークの詳細については、Amazon VPC ユーザーガイドの「インターネットアクセスを有効にする」を参照してください。

  4. ブローカーのセキュリティグループルールをチェックします。以下のポートへの接続が許可されていることを確認してください。

    注記

    Amazon MQ の ActiveMQ と Amazon MQ の RabbitMQ は接続に異なるポート Amazon MQ を使用するため、次のポートはエンジンタイプに従ってグループ化されています。

    Amazon MQ での ActiveMQ Amazon MQ

    • ウェブコンソール – ポート 8162

    • OpenWire – ポート 61617

    • AMQP – ポート 5671

    • STOMP — ポート 61614

    • MQTT – ポート 8883

    • WSS – ポート 61619

    Amazon MQ の RabbitMQ Amazon MQ

    • ウェブコンソールおよび Management API – ポート 443 および 15671

    • AMQP – ポート 5671

  5. ブローカーエンジンタイプに対して、以下のネットワーク接続テストを実行します。

    注記

    パブリックアクセシビリティがないブローカーの場合は、Amazon MQ ブローカーと同じ Amazon VPC 内の Amazon EC2 インスタンスからテストを実行して、レスポンスを評価してください。

    ActiveMQ on Amazon MQ
    Amazon MQ ブローカーのネットワーク接続で ActiveMQ をテストするには Amazon MQ

    1. 新規のターミナルまたはコマンドラインウィンドウを開きます。

    2. 以下の nslookup コマンドを実行して、ブローカー DNS レコードをクエリします。アクティブ/スタンバイデプロイの場合は、アクティブエンドポイントとスタンバイエンドポイントの両方をテストします。アクティブ/スタンバイエンドポイントは、一意のブローカー ID に追加された -1 または -2 サフィックスで特定されます。エンドポイントを独自の情報に置き換えます。

      $ nslookup b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com

      クエリが正常に完了すると、以下のような出力が表示されます。

      Non-authoritative answer:
Server:  dns-resolver-corp-sfo-1.sfo.corp.amazon.com
Address:  172.10.123.456

Name:    ec2-12-345-123-45.us-west-2.compute.amazonaws.com
Address:  12.345.123.45
Aliases:  b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com

      解決された IP アドレスが、Amazon MQ コンソールで指定した IP アドレスと一致している必要があります。これは、ドメイン名が DNS サーバーで正しく解決されていることを示すので、次のステップに進むことができます。

    3. 以下の telnet コマンドを実行して、ブローカーのネットワークパスをテストします。エンドポイントを独自の情報に置き換えます。必要に応じて、port をウェブコンソールのポート番号 8162、またはその他のワイヤレベルのポートに置き換えて、追加のプロトコルをテストします。

      注記

      アクティブ/スタンバイデプロイの場合、スタンバイエンドポイントで telnet を実行すると、Connect failed エラーメッセージが返されます。スタンバイインスタンス自体は実行されていますが、ActiveMQ プロセスは実行されておらず、ブローカーの Amazon EFS ストレージボリュームへのアクセス権がないため、これは期待どおりの動作です。アクティブインスタンスとスタンバイインスタンスの両方をテストできるように、-1 および -2 両方のエンドポインにこのコマンドを実行してください。

      $ telnet b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com port

      アクティブインスタンスには、以下のような出力が表示されます。

      Connected to b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com.
Escape character is '^]'.

    4. 以下のいずれかを行ってください。

      • telnet コマンドが正常に完了する場合は、EstablishedConnectionsCount メトリクスをチェックして、ブローカーがワイヤレベル接続の上限に到達していないことを確認します。ブローカーの General ログを調べて、上限に到達したかどうかを確認することも可能です。このメトリクスがゼロより大きい場合は、現在少なくとも 1 つのクライアントがブローカーに接続されています。メトリクスがゼロ個の接続を示している場合は、telnet パステストを再度実行し、少なくとも 1 分待ってから接続を切断してください (ブローカーメトリクスは毎分発行されるため)。

      • telnet コマンドが失敗する場合は、ブローカーの Elastic Network Interface のステータスをチェックして、ステータスが in-use になっていることを確認します。各インスタンスのネットワークインターフェイスに関する Amazon VPC フローログを作成して、生成されたフローログを検証します。telnet コマンドを実行したときのブローカーの IP アドレスを調べて、応答パケットを含む接続パケットが ACCEPTED であることを確認します。フローログの詳細と例については、Amazon VPC デベロッパーガイドの「フローログレコードの例」を参照してください。

    5. 以下の curl コマンドを実行して、ActiveMQ の管理ウェブコンソールへの接続をチェックします。

      $ curl https://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com:8162/index.html

      コマンドが正常に完了すると、出力は以下のような HTML ドキュメントになります。

      <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
        <title>Apache ActiveMQ</title>
        ...
    RabbitMQ on Amazon MQ
    Amazon MQ ブローカーのネットワーク接続で RabbitMQ をテストするには Amazon MQ

    1. 新規のターミナルまたはコマンドラインウィンドウを開きます。

    2. 以下の nslookup コマンドを実行して、ブローカー DNS レコードをクエリします。エンドポイントを独自の情報に置き換えます。

      $ nslookup b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com

      クエリが正常に完了すると、以下のような出力が表示されます。

      Non-authoritative answer:
Server:  dns-resolver-corp-sfo-1.sfo.corp.amazon.com
Address:  172.10.123.456

Name:    rabbit-broker-1c23e456ca78-b9000123b4ebbab5.elb.us-west-2.amazonaws.com
Addresses:  52.12.345.678
          52.23.234.56
          41.234.567.890
          54.123.45.678
Aliases:  b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com

    3. 以下の telnet コマンドを実行して、ブローカーのネットワークパスをテストします。エンドポイントを独自の情報に置き換えます。port をウェブコンソールのポート 443 に置き換える、および 5671 に置き換えてワイヤレベルの AMQP 接続をテストすることができます。

      $ telnet b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com port

      コマンドが正常に完了する場合は、以下のような出力が表示されます。

      Connected to b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com.
Escape character is '^]'.
      注記

      Telnet 接続は、数秒後に自動的に終了します。

    4. 以下のいずれかを行ってください。

      • telnet コマンドが正常に完了する場合は、ConnectionCount メトリクスをチェックして、max-connections デフォルトポリシーで設定されている値にブローカーが到達していないことを確認します。ブローカーの Connection.log ロググループを調べて、上限に到達したかどうかを確認することも可能です。このメトリクスがゼロより大きい場合は、現在少なくとも 1 つのクライアントがブローカーに接続されています。メトリクスがゼロ個の接続を示している場合は、telnet パステストを再度実行します。ブローカーが新しい接続メトリクスを CloudWatch に発行する前に接続が終了する場合は、このプロセスを繰り返す必要がある場合があります。メトリクスは毎分発行されます。

      • パブリックアクセシビリティがないブローカーで telnet コマンドが失敗する場合は、ブローカーの Elastic Network Interface のステータスをチェックして、ステータスが in-use になっていることを確認します。各ネットワークインターフェイスに関する Amazon VPC フローログを作成して、生成されたフローログを検証します。telnet コマンドが呼び出されたときのブローカーのプライベート IP アドレスを調べて、応答パケットを含む接続パケットが ACCEPTED であることを確認します。フローログの詳細と例については、Amazon VPC デベロッパーガイドの「フローログレコードの例」を参照してください。

        注記

        このステップは、パブリックアクセシビリティを備えた Amazon MQ ブローカーの RabbitMQ には適用されません。 Amazon MQ

    5. 以下の curl コマンドを実行して、RabbitMQ の管理ウェブコンソールへの接続をチェックします。

      $ curl https://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com:443/index.html

      コマンドが正常に完了すると、出力は以下のような HTML ドキュメントになります。

      <!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="X-UA-Compatible" content="IE=edge" />
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <title>RabbitMQ Management</title>
        ...

ブローカーが実行中であり、telnet を使用して接続を検証できますが、クライアントは接続できず、SSL 例外を返しています。

ブローカーのエンドポイント証明書がブローカーのメンテナンスウィンドウ中に更新されている可能性があります。Amazon MQ ブローカー証明書は定期的にローテーションされ、ブローカーの可用性とセキュリティが引き続き維持されます。

Amazon Trust Services で Amazon ルート認証局 (CA) を使用して、クライアントのトラストストアで認証することをお勧めします。すべての Amazon MQ ブローカーの証明書は、このルート CA で署名されています。Amazon ルート CA を使用することで、ブローカーで証明書が更新されるたびに、新しい Amazon MQ ブローカーの証明書をダウンロードする必要がなくなります。

ブローカーを作成しましたが、ブローカーの作成に失敗しました。

ブローカーが CREATION_FAILED ステータスになっている場合は、以下の手順を実行します。

  • IAM 許可をチェックします。ブローカーを作成するには、 AWS マネージド IAM ポリシーを使用するか、カスタム IAM ポリシーに正しい Amazon EC2 アクセス許可のセットAmazonMQFullAccessが必要です。必要な Amazon EC2 許可の詳細については、「Amazon MQ ブローカーの作成に必要な IAM 許可」を参照してください。

  • ブローカー用に選択しているサブネットが、共有 Amazon Virtual Private Cloud (VPC) 内にあるかどうかをチェックします。共有 Amazon VPC 内で Amazon MQ ブローカーを作成するには、その Amazon VPC を所有するアカウントでブローカーを作成する必要があります。

ブローカーが再起動したのですが、その理由がよくわかりません。

ブローカーが自動的に再起動した場合は、以下の理由のいずれかが原因で再起動した可能性があります。

  • スケジュールされた毎週のメンテナンスウィンドウが原因でブローカーが再起動した可能性があります。Amazon MQ は、ハードウェア、オペレーティングシステム、またはメッセージブローカーのエンジンソフトウェアに対して定期的にメンテナンスを実行します。メンテナンスの所要時間はさまざまですが、メッセージブローカーに対してスケジュールされている操作によっては、最長 2 時間継続することがあります。ブローカーは、この 2 時間のメンテナンスウィンドウのどの時点でも再起動する可能性があります。ブローカーのメンテナンスウィンドウの詳細については、「Amazon MQ ブローカーのメンテナンスウィンドウのスケジュール」を参照してください。

  • ブローカーのインスタンスタイプがアプリケーションワークロードに適していない可能性があります。例えば、mq.t2.micro で実稼働ワークロードを実行すると、ブローカーのリソースが不足する原因になる場合があります。CPU 使用率が高い、またはブローカーのメモリ使用率が高いと、ブローカーが予期せず再起動する原因になる場合があります。ブローカーが使用する CPU とメモリの量を確認するには、エンジンタイプに対応する以下の CloudWatch メトリクスを使用してください。

    • Amazon MQ での ActiveMQ Amazon MQ – ブローカーが現在使用している割り当てられた Amazon EC2 コンピューティングユニットの割合CpuUtilizationを確認します。ActiveMQ JVM メモリ制限のうち、ブローカーが現在使用している割合について HeapUsage をチェックします。

    • Amazon MQ の RabbitMQ Amazon MQ – 割り当てられた Amazon EC2 コンピューティングユニットのうち、ブローカーが現在使用しているものの割合SystemCpuUtilizationを確認します。使用済みの RAM の量 (バイト単位) について RabbitMQMemUsed をチェックし、それを RabbitMQMemLimit で除算して、RabbitMQ ノードが使用したメモリの割合を算出します。

    ブローカーのインスタンスタイプ、およびワークロードに適したインスタンスタイプを選択する方法の詳細については、「Broker instance types」を参照してください。