Server Load Balancer:CLB のヘルスチェックの設定と管理

前提条件

ヘルスチェックを設定する前に、関連サービスがバックエンドサーバーにデプロイされていることを確認してください。

制限

リスナープロトコルとヘルスチェックプロトコルは、次のルールに準拠します。

• TCP リスナーは、TCP または HTTP ヘルスチェックプロトコルのみをサポートします。

• UDP リスナーは、TCP、UDP、または HTTP ヘルスチェックプロトコルをサポートします。

• HTTP および HTTPS リスナーは、HTTP ヘルスチェックプロトコルのみをサポートします。

ヘルスチェックの設定

リスナーを追加する際に、ヘルスチェックを設定できます。ほとんどの場合、デフォルトのヘルスチェック設定で十分です。

1. CLB コンソールにログインします。

2. 上部メニューで、インスタンスのあるリージョンを選択します。

3. インスタンス ページで、対象のインスタンスを見つけ、そのインスタンス ID をクリックします。

4. インスタンス詳細ページで、リスナー タブをクリックします。リスナーの作成 をクリックするか、対象リスナーの 操作 列にある リスナーの変更 をクリックします。

5. 設定ウィザードに従って ヘルスチェック の手順に進みます。ヘルスチェックはデフォルトで有効になっています。

6. 詳細設定 をクリックし、右側の 改正 をクリックしてヘルスチェックを設定します。

   ヘルスチェック設定	説明
   [ヘルスチェックするプロトコル]	ヘルスチェックに使用するプロトコルを選択します。 TCP ヘルスチェックはネットワーク層で動作し、SYN ハンドシェイクメッセージを送信してサーバーポートがアクティブであるかを確認します。 UDP ヘルスチェックは、UDP メッセージを用いてステータス情報を取得します。 HTTP ヘルスチェックは、HEAD または GET リクエストを送信してブラウザのアクセスをシミュレートし、サーバーアプリケーションが正常であるかを確認します。
   [ヘルスチェックのメソッド] (HTTP ヘルスチェックプロトコルでのみサポート)	HEAD または GET メソッドを選択できます。デフォルトでは、HEAD メソッドが使用されます。 説明 HEAD メソッドがサポートされていない、または無効になっている場合は、代わりに GET メソッドを使用してください。 GET メソッドを使用する場合、8 KB を超える応答は切り捨てられます。これはヘルスチェックの結果には影響しません。
   [ヘルスチェックのポート番号]	バックエンドサーバーのヘルスチェックに使用するポートです。デフォルトでは、CLB は各バックエンドサーバーのポートを使用します。 説明 サーバーグループ内のバックエンドサーバーが異なるポートを使用している場合は、ヘルスチェックポートを指定しないでください。この場合、CLB はヘルスチェックに各バックエンドサーバーのポートを使用します。
   [ヘルスチェックへのパス] (HTTP ヘルスチェックプロトコルでのみサポート)	デフォルトでは、CLB はアプリケーションのデフォルトインデックスページに HTTP リクエストを送信してヘルスチェックを行います。 ヘルスチェックに使用するページがアプリケーションのデフォルトインデックスページでない場合は、正確なパスを指定してください。 ヘルスチェックには静的ページを使用することを推奨します。
   [ヘルスチェックのドメイン名] (HTTP ヘルスチェックプロトコルでのみサポート)	ヘルスチェックドメインを設定すると、CLB はリクエストヘッダーの Host フィールドにそのドメインを設定します。ドメインが設定されていない場合、Host フィールドは省略されます。 一部のアプリケーションサーバーは Host フィールドを検証します。ドメインが設定されていない場合、リクエストが拒否され、ヘルスチェックが失敗する可能性があります。サーバーが Host フィールドを検証する場合は、ヘルスチェックが成功するよう、ヘルスチェックドメインを設定してください。 説明 ロードバランサーは、転送ルールに関係なく、リスナーに設定されたヘルスチェックパス (デフォルトではルートパス) に基づいてヘルスチェックを実行します。バックエンドサービスが異なるパスに対して異なる応答をする必要がある場合、デフォルトまたは一致しないパスを使用したヘルスチェックは失敗する可能性があります。これを解決するには、転送ルールの設定で特定のヘルスチェックパスを設定します。
   [通常のステータスコード] (HTTP ヘルスチェックプロトコルでのみサポート)	正常なバックエンドサーバーを示す HTTP ステータスコードを選択します。デフォルト値は http_2xx と http_3xx です。http_2xx、http_3xx、http_4xx、または http_5xx を選択できます。 デフォルトでは、CLB は HTTP 2xx および 3xx ステータスコードのみを正常と見なします。バックエンドサーバーが 400、403、404 などの 4xx ステータスコード、または 500、502、503 などの 5xx ステータスコードを返す場合、ヘルスチェックは失敗します。その後、CLB はバックエンドサーバーを異常と判断し、そのサーバーへのトラフィック転送を停止します。 警告 4xx または 5xx ステータスコードを正常として受け入れる場合、障害のあるインスタンスがバックエンドサーバープールから迅速に削除されない可能性があります。たとえば、バックエンドサーバーが 500 エラーを返し、http_5xx を正常ステータスコードとして設定している場合、CLB は障害のあるインスタンスにトラフィックをルーティングし続けます。この設定は、慎重に評価した後にのみ使用してください。可能な限り、バックエンドサーバーが 2xx または 3xx ステータスコードを返すように設定することを推奨します。 4xx エラーの一般的な原因： 404 エラー：ヘルスチェックパスが存在しない、バックエンドサービスが正しくデプロイされていない、ドメインバインディングに問題がある、または HEAD メソッドがサポートされていない。 403 エラー：バックエンドサーバーがアクセスを拒否している、IP アドレスベースの制限が設定されている、または権限検証が失敗している。 400 エラー：Host ヘッダーがない、HTTP バージョンに互換性がない、またはリクエスト形式が不正である。
   [レスポンスのタイムアウト]	ヘルスチェックへの応答を待機する最大時間です。 バックエンドサーバーが指定されたタイムアウト時間内に応答を返さない場合、ヘルスチェックは失敗します。
   [ヘルスチェックの間隔]	ヘルスチェックが実行される間隔です。 CLB クラスター内のすべてのノードは、指定された間隔で独立してヘルスチェックを実行します。異なるノードからのヘルスチェックは同期されていないため、バックエンドサーバーが受信するヘルスチェックリクエストは均等な間隔ではない場合があります。 デフォルトでは、HTTP ヘルスチェックは HEAD メソッドを使用します。HEAD リクエストは HTTP ステータスコードとヘッダーのみを返し、完全なページ内容は返しません。したがって、各ヘルスチェックがバックエンドサーバーに与える負荷は最小限です。間隔を短くすると、ヘルスチェックリクエストの数は増えますが、そのオーバーヘッドは通常、通常のサービストラフィックと比較して無視できるレベルです。
   [健全しきい値]	異常と判断された Elastic Compute Service (ECS) が正常と見なされるまでに必要な、連続で成功したヘルスチェックの回数です。
   [不健全しきい値]	ECS インスタンスが異常と見なされるまでに必要な、連続で失敗したヘルスチェックの回数です。
   [ヘルスチェックリクエスト]と[ヘルスチェック結果の項目を編集できます。] (UDP ヘルスチェックプロトコルでのみサポート)	UDP リスナーのヘルスチェックを設定する際は、ヘルスチェックリクエスト フィールドにリクエスト内容 (例： youraccountID) を、ヘルスチェック結果の項目を編集できます。 フィールドに期待する応答 (例： slb123) を入力します。 また、youraccountID を含むリクエストに対して slb123 で応答するように設定するなど、ヘルスチェック応答を処理するロジックをバックエンドアプリケーションに追加します。 CLB は、正しい応答を受信した場合にのみヘルスチェックが成功したと見なします。この方法は、UDP ヘルスチェックの信頼性を最大限に高めます。

7. リスナーの設定が完了するまで 次へ をクリックします。

ヘルスチェックステータスの表示

1. CLB コンソールにログインします。

2. 上部メニューで、インスタンスのあるリージョンを選択します。

3. インスタンス ページで、対象のインスタンスを見つけ、そのインスタンス ID をクリックします。

4. インスタンス詳細ページで、リスナー タブをクリックし、各リスナーのヘルスチェックステータスを確認します。

   ヘルスチェックステータスは、次のいずれかになります：

   • 初期化中： ヘルスチェックのため、バックエンドサーバーのリストを初期化しています。

   • 正常： すべてのバックエンドサーバーが正常です。

   • 異常： 1 つ以上のバックエンドサーバーが異常です。

   • 無効： ヘルスチェックが有効になっていません。

5. リスナーの横にある 異常 または [初期化中] をクリックすると、影響を受けるリスナーまたは転送ルール、サーバーグループ、ECS インスタンスとポート、ヘルスステータス、および失敗理由などの詳細が表示されます。

ヘルスチェックの無効化

ヘルスチェックを無効にすることはできます。ただし、ヘルスチェックを無効にした後にバックエンドの ECS インスタンスが異常になった場合、CLB はそのインスタンスにリクエストをルーティングし続けます。これにより、部分的なサービス停止につながります。したがって、ヘルスチェックを無効にしないことを推奨します。

1. CLB コンソールにログインします。

2. 上部メニューで、インスタンスのあるリージョンを選択します。

3. インスタンス ページで、対象のインスタンスを見つけ、そのインスタンス ID をクリックします。

4. インスタンス詳細ページで、リスナー タブをクリックします。リスナーの作成 をクリックするか、対象リスナーの 操作 列にある リスナーの変更 をクリックします。

5. 設定ウィザードに従って ヘルスチェック の手順に進みます。

6. ヘルスチェックのトグルをオフにし、次へ をクリックしてから、変更を確定します。

ヘルスチェックのベストプラクティス

正確で信頼性の高いヘルスチェックを確保するために、以下のベストプラクティスに従うことを推奨します：

• 専用のヘルスチェックエンドポイントを作成する：バックエンドサーバーに、常に HTTP 200 ステータスコードを返す専用のヘルスチェックエンドポイント (例： /health) を作成してください。権限チェックやリソース不足により 4xx ステータスコードを返す可能性があるため、/ などのビジネスパスをヘルスチェックに使用することは避けてください。

• バックエンドの問題修正を優先する：ヘルスチェックが予期しないステータスコードを返す場合は、まずバックエンドサービスの問題を診断して修正し、ヘルスチェックパスが 2xx または 3xx ステータスコードを返すようにしてください。単に正常ステータスコードの基準を緩和しないでください。

• curl を使用してヘルスチェックをシミュレートする：問題のトラブルシューティングでは、バックエンドサーバーにログインし、次のコマンドを実行して CLB のヘルスチェックをシミュレートできます：

  curl -Iv -X HEAD --http1.0 -H "Host: your-domain.com" http://127.0.0.1:80/health_path

  このコマンドでは、HEAD はヘルスチェックメソッド、your-domain.com はヘルスチェックドメイン、/health_path はヘルスチェックパスです。ドメインが設定されていない場合は、-H パラメーターを省略します。

• CLB の CIDR ブロックがブロックされていないことを確認する：CLB は、ヘルスチェックのためにバックエンドサーバーと通信するために 100.64.0.0/10 CIDR ブロックを使用します。この CIDR ブロックが iptables や他のファイアウォールルールによってブロックされていないことを確認してください。

関連ドキュメント

• CLB のヘルスチェックメカニズムに慣れていない場合は、「CLB のヘルスチェック」をご参照ください。

• CLB のヘルスチェックで問題が発生した場合は、「CLB のヘルスチェックに関するよくある質問」を参照してトラブルシューティングを行ってください。

• CLB のヘルスチェックログ機能を使用して、サーバーのヘルスチェックログを分析できます。詳細については、「ヘルスチェックログの保存とダウンロード」をご参照ください。