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

解決策

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

まず、AWS マネジメントコンソールを使用して、前回のヘルスチェックの失敗の原因を特定します。または、AWS CLI の get-health-check-last-failure-reason コマンドを使用します。

次に、以下のセクションの対応するトラブルシューティング手順を実行して、問題を特定して修正します。

**注:**ヘルスチェックのタイプにかかわらず、ヘルスチェックステータスの反転 オプションのステータスをチェックしてください。このオプションが true に設定されている場合、Route 53 はヘルスチェックが正常とマークされていても異常と見なします。

エンドポイントを監視するヘルスチェックのトラブルシューティング

エラー: ヘルスチェッカーはタイムアウト制限内で接続を確立できませんでした

前述のエラーは、ヘルスチェッカーが設定されたエンドポイントに接続しようとしてタイムアウトしたときに発生します。接続を確立するための最小時間は次のとおりです。

• TCP ヘルスチェックでは、ヘルスチェッカーとエンドポイント間の TCP 接続が 10 秒以内に行われる必要があります。
• HTTP および HTTPS のヘルスチェックでは、ヘルスチェッカーとエンドポイント間の TCP 接続が 4 秒以内に行われる必要があります。エンドポイントは、接続を確立してから 2 秒以内に 2xx または 3xx の HTTP ステータスコードで応答する必要があります。

詳細については、Amazon Route 53 がヘルスチェックが正常かどうかを判断する方法を参照してください。

タイムアウトエラーを回避するには、次の手順を実行してください。

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

2.    エンドポイントにアクセスします。ファイアウォールまたはサーバーが、ヘルスチェック設定で指定されている AWS リージョンの Route 53 パブリック IP アドレスからの接続を許可していることを確認します。[IP 範囲] を確認してサービス ROUTE53_HEALTHCHECKSを検索します。AWS でホストされているエンドポイントリソースについては、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 以外の HTTP コードが表示される場合は、次の設定を確認してください。

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

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

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

• TCP 接続時間
• 最初のバイトまでの時間
• 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 はヘルスチェックを異常とマークします

ヘルスチェッカーは、4 秒以内にエンドポイントとの TCP 接続を確立する必要があります。その後、ヘルスチェッカーは次の 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

CloudWatch アラームを監視するヘルスチェックのトラブルシューティング

Route 53 は、Amazon CloudWatch アラームが ALARM 状態になるまで待機しません。

前述の状況は、Route 53 が CloudWatch アラームの状態ではなくメトリックスデータストリームを監視している場合に発生します。

このエラーを解決するには、次の手順を実行してください。

1.    [INSUFFICIENT DATA] ステータスにあるヘルスチェックの設定を確認します。メトリック・データ・ストリームの情報が不十分なためにアラームの状態を判断できない場合、ヘルスチェックのステータスは [InsufficientDataHealthStatus] 構成によって異なります。[InsufficientDataHealthStatus] 設定のステータスオプションには、[正常]、[異常]、または [前回確認されたステータス] があります。

2.    CloudWatch アラームの設定を更新しても、新しい設定は関連するヘルスチェックに自動的に表示されません。ヘルスチェック設定を更新した CloudWatch アラームの設定と同期させるには:

• Route 53 コンソールで、[ヘルスチェック] を選択します。
• ヘルスチェックを選択し、[設定を同期] を選択します。