翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Route 53 でヘルスチェックの正常性を判断する方法
ヘルスチェックが正常かどうかを判断するために Amazon Route 53 が使用する方法は、ヘルスチェックのタイプによって異なります。
## Route 53 がエンドポイントをモニタリングするヘルスチェックのステータスを決定する方法
Route 53 は、世界各地にヘルスチェッカーを持っています。エンドポイントをモニタリングするヘルスチェックを作成すると、ヘルスチェッカーは、エンドポイントが正常であるかどうかを判断するためにユーザーが指定するエンドポイントにリクエストの送信を開始します Route 53 で使用するロケーションを選択することや、チェックの間隔 (10 秒ごとまたは 30 秒ごと) を指定することができます。異なるデータセンターの Route 53 ヘルスチェッカーは互いに調整しないため、選択した間隔に関係なく、1 秒あたり複数のリクエストを受け取った後、数秒間はヘルスチェックを受け取らないということが生じる場合があります。
各ヘルスチェッカーは、次の 2 つの値に基づいてエンドポイントの正常性を評価します。
+ 応答時間。さまざまな理由から、ヘルスチェックリクエストに対するリソースの応答が遅くなったり、応答に失敗したりすることがあります。例えば、リソースがメンテナンスのためにシャットダウンしている、分散サービス妨害 (DDoS) 攻撃にあっている、ネットワークがダウンしている、などの理由です。
+ エンドポイントが、指定した連続する回数のヘルスチェックに応答するかどうか (失敗のしきい値)
Route 53 はヘルスチェッカーからデータを集計し、エンドポイントが正常であるかどうかを判断します。
+ 18% を超えるヘルスチェッカーがエンドポイントを正常であるとレポートした場合、Route 53 はそのエンドポイントを正常と見なします。
+ 18% 以下のヘルスチェッカーがエンドポイントを正常であるとレポートした場合、Route 53 はそのエンドポイントを異常と見なします。
18% という値が選ばれたのは、複数のリージョンのヘルスチェッカーが確実にエンドポイントを正常であると見なすようにするためです。これにより、ネットワークの状態によって一部のヘルスチェックの場所からエンドポイントが分離されたというだけで、エンドポイントを異常と見なすことを回避できます。この値は、将来のリリースで変更される可能性があります。
個々のヘルスチェッカーが、エンドポイントが正常であるかどうかを判断するために使用する応答時間は、ヘルスチェックのタイプによって異なります。
+ **HTTP/HTTPS ヘルスチェック** – Route 53 が、エンドポイントとの TCP 接続を 4 秒以内に確立できることが必要です。加えて、接続後 2 秒以内に、HTTP ステータスコード 2xx または 3xx でエンドポイントが応答する必要があります。
**注記**
HTTPS ヘルスチェックでは SSL/TLS 証明書が検証されないため、証明書が無効または期限切れの場合でもチェックが不合格になることはありません。
+ **TCP ヘルスチェック**: Route 53 が、エンドポイントとの TCP 接続を 10 秒以内に確立できることが必要です。
+ **HTTP/HTTPS ヘルスチェックと文字列一致**: HTTP/HTTPS ヘルスチェックと同様に、Route 53 はエンドポイントとの TCP 接続を 4 秒以内に確立し、そのエンドポイントは接続後 2 秒以内に 2xx または 3xx の HTTP ステータスコードで応答する必要があります。
Route 53 ヘルスチェッカーは、HTTP ステータスコードを受信後、続けて 2 秒以内にエンドポイントからレスポンス本文を受信する必要があります。Route 53 は、指定された文字列をレスポンス本文から検索します。その際、検索文字列全体が、レスポンス本文の最初の 5,120 バイト内に出現している必要があります。それ以外の場合、エンドポイントはヘルスチェックで不合格となります。Route 53 コンソールを使用している場合は、**文字列の検索** フィールドに文字列を指定します。Route 53 API を使用している場合は、ヘルスチェックの作成時に、`SearchString` 要素で文字列を指定します。
エンドポイントを監視するヘルスチェック (TCP ヘルスチェックを除く) で、エンドポイントからの応答にヘッダーが含まれている場合、ヘッダーは RFC7230、Hypertext Transfer Protocol (HTTP/1.1): メッセージ構文とルーティング、[セクション 3.2、「ヘッダーフィールド」](https://tools.ietf.org/html/rfc7230#section-3.2)で定義されている形式でなければなりません。
Route 53 は、実際のステータス (正常または非正常) を決定するための十分なデータを得るまでは、新しいヘルスチェックを正常と見なします。ヘルスチェックのステータスを反転するオプションを選択した場合、Route 53 は、十分なデータを得るまでは、新しいヘルスチェックを*非正常*と見なします。
## Route 53 が他のヘルスチェックをモニタリングするヘルスチェックのステータスを決定する方法
ヘルスチェックは、他のヘルスチェックのステータスをモニタリングできます。このタイプのヘルスチェックは、*算出したヘルスチェック*として知られています。監視を行うヘルスチェックが*親ヘルスチェック*で、監視されるヘルスチェックが*子ヘルスチェック*です。1 つの親ヘルスチェックは、最大 255 の子ヘルスチェックの状態を監視できます。以下に、監視活動の仕組みを示します。
+ Route 53 は、正常であると考えられる子のヘルスチェックの数を合計します。
+ Route 53 はその後、正常と見なされる親のヘルスチェックのステータスについて正常でなければならない子ヘルスチェック数と、その数を比較します。
詳細については、「[ヘルスチェックを作成または更新するときに指定する値](health-checks-creating-values.md)」の [他のヘルスチェック (算出したヘルスチェック) の監視](health-checks-creating-values.md#health-checks-creating-values-calculated) を参照してください。
Route 53 は、実際のステータス (正常または非正常) を決定するための十分なデータを得るまでは、新しいヘルスチェックを正常と見なします。ヘルスチェックのステータスを反転するオプションを選択した場合、Route 53 は、十分なデータを得るまでは、新しいヘルスチェックを*非正常*と見なします。
## Route 53 が CloudWatch アラームをモニタリングするヘルスチェックのステータスを決定する方法
CloudWatch アラームに基づくヘルスチェックを作成した場合、Route 53 は該当するアラームの状態ではなくそのアラームのデータストリームをモニタリングします。データストリームがアラームの状態を [**OK**] と示している場合、ヘルスチェックは正常と見なされます。データストリームが状態を [**アラーム**] と示している場合、ヘルスチェックは異常と見なされます。アラームの状態を判断するための十分な情報がデータストリームから提供されない場合、ヘルスチェックのステータスは [**ヘルスチェックステータス**] の設定 (正常、異常、または最後の既知の状態) によって決まります (Route 53 API では、この設定は `InsufficientDataHealthStatus` です)。
Route 53 では、クロスアカウント CloudWatch アラームをサポートしていません。
**注記**
Route 53 のヘルスチェックでは、CloudWatch アラームの状態ではなく CloudWatch のデータストリームがモニタリングされるため、 CloudWatch の [SetAlarmState](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_SetAlarmState.html) API オペレーションを使用してヘルスチェックのステータスを強制的に変更することはできません。
Route 53 は、実際のステータス (正常または非正常) を決定するための十分なデータを得るまでは、新しいヘルスチェックを正常と見なします。ヘルスチェックのステータスを反転するオプションを選択した場合、Route 53 は、十分なデータを得るまでは、新しいヘルスチェックを*非正常*と見なします。