異常な Route 53 ヘルスチェックのトラブルシューティング方法を教えてください。

最終更新日: 2021 年 5 月 20 日

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、最新の AWS CLI バージョンを使用していることを確認してください。

まず、AWS マネジメントコンソールを使用して、ヘルスチェックの直近の失敗の理由を特定する必要があります。または、AWS CLI で get-health-check-last-failure-reason コマンドを使用できます。ヘルスチェックのタイプを特定したら、対応するトラブルシューティングステップを完了して、問題を特定して修正します。

注: ヘルスチェックのタイプにかかわらず、必ず [Invert health check status] (ヘルスチェックステータスを反転) オプションのステータスを確認してください。このオプションを「true」に設定した場合、Route 53 は、ヘルスチェッカーがヘルスチェックを正常とマークしたときにヘルスチェックを異常と見なします。逆も同様です。

原因: この問題が生じたことは、「ヘルスチェッカーがタイムアウト制限内で接続を確立できませんでした」というエラーメッセージで示唆されます。このエラーは、ヘルスチェッカーが設定されたエンドポイントとの接続を確立しようとしたときに発生するタイムアウトが原因で発生します。接続を確立するための最小時間は、ヘルスチェックプロトコル (TCP、HTTP、または HTTPS) によって異なります。

• TCP ヘルスチェックの場合、ヘルスチェッカーとエンドポイント間の TCP 接続は 10 秒以内に行われる必要があります。
• HTTP および HTTPS ヘルスチェックの場合、ヘルスチェッカーとエンドポイント間の TCP 接続は 4 秒以内に行われる必要があります。エンドポイントは、接続の確立後 2 秒以内に 2xx または 3xx HTTP ステータスコードで応答する必要があります。詳細については、「Amazon Route 53 がヘルスチェックの正常性を判断する方法」をご参照ください。

解決策:

1.    ヘルスチェック設定で、エンドポイントの「ドメイン名」または「IP アドレス」を書き留めます。

2.    エンドポイントにアクセスします。ファイアウォールまたはサーバーが、ヘルスチェック設定で有効になっているリージョンの Route 53 パブリック IP アドレスから接続を許可していることを確認します。IP 範囲を確認し、"service": "ROUTE53_HEALTHCHECKS" を検索します。エンドポイントリソースが AWS でホストされている場合は、セキュリティグループとネットワークアクセスコントロールリスト (ネットワーク ACL) を設定して、Route 53 ヘルスチェッカーの IP アドレスを許可します。

3.    次のツールを使用して、インターネット経由で設定されたエンドポイントとの接続をテストします。コマンドのプレースホルダーをそれぞれの値に置き換えてください。

TCP テスト:

$ telnet <domain name / IP address> <port>

HTTP/HTTPS テスト:

$ 

curl -Ik -w "HTTPCode=%{http_code} TotalTime=%{time_total}\n" <http/https>://<

domain-name/ip address>:<port>/<path>

 -so /dev/null

前述の出力を、前回のテスト時のヘルスチェックのタイムアウト値と比較します。次に、アプリケーションがそれぞれのタイムライン内で応答していることを確認します。

例えば、次のテストを実行すると、

curl -Ik -w "HTTPCode=%{http_code} TotalTime=%{time_total}\n" https://example.com -so /dev/null

出力は次のようになります。

HTTPCode=200 TotalTime=0.001963

この例では、HTTP ステータスコード 200 のレスポンスを取得する合計時間は 0.001963 秒です。

HTTP 接続の場合、接続時間は 4 秒以内である必要があります。エンドポイントは、接続後 2 秒以内に HTTP ステータスコードで応答する必要があります。合計時間は 6 秒です。合計時間値が 6 秒を超える場合は、エンドポイントのレスポンスが遅く、ヘルスチェックが失敗していることを示します。このような場合は、エンドポイントをチェックして、タイムアウト期間内に応答するようにします。

テストコマンドの出力に 200 以外の HTTPCode が表示されている場合は、次の設定を確認します。

• ファイアウォールルール
• セキュリティグループ
• ネットワーク ACL

これらの設定を確認するときは、エンドポイントで Route 53 パブリック IP アドレスからの接続が許可されていることを確認します。

4.    有効になっている場合、ヘルスチェック設定のレイテンシーグラフオプションを使用して、以下の点についてメトリクスグラフをチェックします。

• TCP 接続時間
• 最初の 1 バイトを受信するまでの時間
• SSL ハンドシェイクを完了するまでの時間

詳細については、「ヘルスチェッカーとエンドポイント間のレイテンシーのモニタリング」をご参照ください。

注:

• レイテンシーグラフが有効になっていない場合、既存のヘルスチェックを編集することはできません。代わりに、新しいヘルスチェックを作成する必要があります。
• モニタリングしているエンドポイントの Elastic IP アドレスがリリースまたは更新された場合、ヘルスチェックが失敗することがあります。

原因: この問題は、「SSL alert handshake_failure」エラーメッセージで示されます。

解決策:

このエラーは、エンドポイントとの SSL または TLS ネゴシエーションが失敗したことを示します。SNI (HTTPS のみ) を有効にすると、Route 53 は TLS ネゴシエーション中に「client_hello」メッセージのホスト名をエンドポイントに送信します。このアクションにより、エンドポイントは適切な SSL または TLS 証明書を使用して HTTPS リクエストに応答できます。

モニタリングしているホスト名がエンドポイントの SSL または TLS 証明書の共通名の一部でない場合、「SSL alert handshake_failure 」エラーメッセージを受け取ります。

注: SNI を有効にするには、モニタリング対象のエンドポイントが SNI をサポートしている必要があります。

原因: この問題は、エンドポイントサーバーが「200 OK」を返したが、Route 53 がヘルスチェックを異常ありとマークした場合に表示されます。ヘルスチェッカーは、エンドポイントとの TCP 接続を 4 秒以内に確立する必要があります。ヘルスチェッカーは、次の 2 秒間に 2xx または 3xx の HTTP ステータスコードを受信する必要があります。次に、設定された文字列は、次の 2 秒以内にレスポンス本文の最初の 5,120 バイトに表示される必要があります。文字列が最初の 5,120 バイトに存在しない場合、Route 53 はヘルスチェックを異常ありとしてマークします。

解決策:

文字列がレスポンス本文の最初の 5,120 バイトに完全に含まれているかどうかを確認するには、次のコマンドを使用します。「$search-string」をお客様の文字列に置き換えてください。

$ curl -sL <http/https>://<domain-name>:<port> | head -c 5120 | grep $search-string

原因: Route 53 は、Amazon CloudWatch アラームが ALARM 状態になるのを待機しません。Route 53 は、CloudWatch アラームの状態ではなく、メトリクスデータストリームをモニタリングします。

解決策:

1.    「INSUFFICIENT DATA」状態にあるヘルスチェックの設定を確認します。メトリクスデータストリームがアラームの状態を判断するための情報が不足している場合、ヘルスチェックのステータスは「InsufficientDataHealthStatus」設定によって異なります。「InsufficientDataHealthStatus」設定のステータスオプションは、「正常」、「異常」、または「最後の既知のステータス」です。

2.    CloudWatch アラームの設定を更新した場合、新しい設定は関連付けられたヘルスチェックに自動的に表示されません。ヘルスチェックの設定を、更新された CloudWatch アラームの設定と同期するには、以下の手順に従います。

• Route 53 コンソールで、[Health Checks] (ヘルスチェック) を選択します。
• ヘルスチェックを選択してから、[Synchronize configuration] (設定の同期) を選択します。