Classic Load Balancer (CLB) は、ヘルスチェックを使用してバックエンドサーバーの可用性を判断します。ヘルスチェックで異常なバックエンドサーバーが検出されると、CLB はそのサーバーへのリクエスト転送を停止し、正常なサーバーにリクエストを再ルーティングします。異常なサーバーが回復すると、CLB は自動的にそのサーバーへのリクエスト転送を再開します。このプロセスにより、アプリケーションの可用性が向上し、個々のサーバー障害によるサービス中断が防止されるため、高可用性の維持に不可欠です。ヘルスチェックの仕組みの詳細については、「CLB のヘルスチェック」をご参照ください。
前提条件
ヘルスチェックを設定する前に、必要なサービスがバックエンドサーバーにデプロイされていることを確認してください。
制限事項
リスナープロトコルによって、利用可能なヘルスチェックプロトコルが決まります。
TCP リスナーは、TCP および HTTP ヘルスチェックプロトコルのみをサポートします。
UDP リスナーは、TCP、UDP、および HTTP ヘルスチェックプロトコルをサポートします。
HTTP および HTTPS リスナーは、HTTP ヘルスチェックプロトコルのみをサポートします。
ヘルスチェックの設定
リスナーを追加する際にヘルスチェックを設定できます。ほとんどの場合、デフォルトのヘルスチェック設定を使用できます。
Classic Load Balancer (CLB) コンソールにログインします。
上部のナビゲーションバーで、インスタンスがデプロイされているリージョンを選択します。
インスタンス ページで、対象のインスタンスを見つけ、そのインスタンス ID をクリックします。
インスタンス詳細ページで、[リスナー] タブをクリックします。次に、[リスナーの追加] をクリックするか、対象リスナーの [操作] 列にある [リスナー設定の変更] をクリックします。
ウィザードに従ってリスナーを設定し、ヘルスチェック ページに進みます。ヘルスチェックはデフォルトで有効になっています。
詳細設定 の横にある 改正 をクリックして、次のパラメーターを設定します。
ヘルスチェック設定
説明
ヘルスチェックプロトコル
ヘルスチェックに使用するプロトコルを選択します。
TCP ヘルスチェックは、SYN ハンドシェイクパケットを送信してサーバーポートがアクティブかどうかを検出するネットワークレイヤープローブです。
UDP ヘルスチェックは、UDP パケットを使用してステータス情報をプローブします。
HTTP ヘルスチェックは、HEAD または GET リクエストを送信してサーバーアプリケーションが正常であるかどうかを確認することで、ブラウザのアクセスをシミュレートします。
ヘルスチェック方法
(HTTP ヘルスチェックプロトコルのみ)
HEAD または GET メソッドを使用できます。デフォルトでは、HEAD メソッドが使用されます。
説明HEAD メソッドがサポートされていないか無効になっている場合は、GET メソッドを使用してください。
GET メソッドを使用する場合、8 KB を超える応答は切り捨てられます。これはヘルスチェックの結果には影響しません。
ヘルスチェックポート
ヘルスチェックサービスがバックエンドサーバーをプローブするために使用するポートです。デフォルトでは、バックエンドサーバーのポートがヘルスチェックに使用されます。
説明このリスナーのサーバーグループ内のバックエンドサーバーが異なるポートを使用している場合、ヘルスチェックポートを設定する必要はありません。ロードバランシングシステムは、各バックエンドサーバーのポートをヘルスチェックに使用します。
ヘルスチェック パス
(HTTP ヘルスチェックプロトコルのみ)
デフォルトでは、HTTP ヘルスチェックはアプリケーションサーバーのデフォルトページに HTTP リクエストを送信します。
ヘルスチェックに使用されるページがデフォルトページでない場合は、ヘルスチェックパスを指定する必要があります。
ヘルスチェックには静的ページを使用することを推奨します。
[ヘルスチェックドメイン名] (HTTP ヘルスチェックプロトコルのみ)
ヘルスチェックドメイン名を設定すると、CLB はリクエストヘッダーの
Hostフィールドにそのドメイン名を追加します。ドメイン名を設定しない場合、Hostフィールドはリクエストヘッダーに含まれません。一部のアプリケーションサーバーは
Hostフィールドを検証します。この検証を必要とするサーバーに対してドメイン名を設定しないと、リクエストが拒否されてヘルスチェックが失敗する可能性があります。したがって、ご利用のサーバーがHostフィールドを検証する場合は、ヘルスチェックが期待どおりに機能するようにヘルスチェックドメイン名を設定する必要があります。説明[正常なステータスコード]
(HTTP ヘルスチェックプロトコルのみ)
正常な状態を示す HTTP ステータスコードを選択します。デフォルト値は http_2xx と http_3xx です。その他の有効な値は http_4xx と http_5xx です。
デフォルトでは、CLB のヘルスチェックは HTTP 2xx および 3xx ステータスコードのみを正常と見なします。バックエンドサーバーが 4xx (400、403、404 など) または 5xx (500、502、503 など) のステータスコードを返した場合、ヘルスチェックは失敗します。その後、バックエンドサーバーは異常とマークされ、トラフィックの受信を停止します。
警告正常なステータスコードのリストに 4xx または 5xx コードを追加すると、本当に障害が発生しているインスタンスのタイムリーな切り離しが妨げられる可能性があります。たとえば、バックエンドサーバーが 500 Internal Server Error を返し、http_5xx を正常なステータスコードとして設定している場合、異常なインスタンスは正常と見なされ、トラフィックを受信し続けます。この設定は、十分な評価を行った後にのみ使用してください。バックエンドサービスを修正して、正しい 2xx または 3xx ステータスコードを返すようにすることを優先的に推奨します。
4xx ステータスコードを引き起こす一般的なシナリオ：
404 エラー：ヘルスチェックパスが存在しない、バックエンドサービスが正しくデプロイされていない、ドメイン名のバインディングに問題がある、または HEAD メソッドがサポートされていない。
403 エラー：バックエンドサービスがアクセスを拒否している、IP ベースのアクセス制限がある、または権限検証が失敗している。
400 エラー：Host ヘッダーが欠落している、HTTP プロトコルのバージョンに互換性がない、またはリクエスト形式に問題がある。
[応答タイムアウト時間]
ヘルスチェック応答の最大タイムアウト時間です。
バックエンドサーバーが指定された時間内に応答しない場合、ヘルスチェックは失敗します。
ヘルスチェック間隔
ヘルスチェックが実行される間隔です。
CLB クラスター内のすべてのノードは、指定された間隔でバックエンドサーバーに対して独立して同時にヘルスチェックを実行します。ノードのチェック時間は同期されていないため、単一のバックエンドサーバーが受信するヘルスチェックリクエストは、指定された間隔に厳密に従うわけではありません。
正常状態のしきい値
異常なバックエンドサーバーが正常と見なされるために必要な、連続した成功したヘルスチェックの回数です。
異常しきい値
正常なバックエンドサーバーが異常と見なされるために必要な、連続した失敗したヘルスチェックの回数です。
[ヘルスチェックリクエスト] および [ヘルスチェック応答] (UDP ヘルスチェックプロトコルのみ)
UDP リスナーのヘルスチェックを設定する際、[ヘルスチェックリクエスト] フィールドに youraccountID などのリクエスト内容を入力し、[ヘルスチェック応答] フィールドに slb123 などの期待される応答を入力できます。
また、バックエンドサーバーのアプリケーションに対応する応答ロジックを追加する必要があります。たとえば、アプリケーションが youraccountID リクエストを受信した場合、slb123 を返す必要があります。
CLB がバックエンドサーバーから正しい応答を受信した場合、ヘルスチェックは成功します。そうでない場合、ヘルスチェックは失敗します。この方法は、最も信頼性の高い UDP ヘルスチェックを提供します。
[次へ] をクリックして、リスナーの設定を完了します。
ヘルスチェックステータスの表示
Classic Load Balancer (CLB) コンソールにログインします。
上部のナビゲーションバーで、インスタンスがデプロイされているリージョンを選択します。
インスタンス ページで、対象のインスタンスを見つけ、そのインスタンス ID をクリックします。
インスタンス詳細ページで、[リスナー] タブをクリックして、リスナーのヘルスチェックステータスを表示します。
リスナーのヘルスチェックステータスは、次のいずれかになります。
初期化中：ヘルスチェック対象のバックエンドサーバーのリストが初期化されています。
正常：すべてのバックエンドサーバーが正常です。
異常：1 つ以上の異常なバックエンドサーバーが存在します。
無効：ヘルスチェックが無効になっています。
リスナーの横にある [異常] または [初期化中] をクリックして、リスナー、転送ルール、サーバーグループ、ECS インスタンス、ポート、ヘルスステータス、および異常または初期化中の状態の原因に関する詳細を表示します。
ヘルスチェックの無効化
頻繁なヘルスチェックは、サービスアクセスに影響を与える可能性があります。影響を軽減するために、チェック頻度を低くするか、間隔を長くすることを推奨します。ただし、継続的なサービスの可用性を確保するために、ヘルスチェックを無効にすることは推奨しません。
ヘルスチェック機能を無効にすることができます。ただし、ヘルスチェックを無効にしてバックエンドの ECS インスタンスが異常になった場合、CLB はそのインスタンスへのリクエスト転送を続行します。これにより、サービスの一部が利用できなくなる可能性があります。したがって、ほとんどの場合、ヘルスチェックを無効にしないことを推奨します。
Classic Load Balancer (CLB) コンソールにログインします。
上部のナビゲーションバーで、インスタンスがデプロイされているリージョンを選択します。
インスタンス ページで、対象のインスタンスを見つけ、そのインスタンス ID をクリックします。
インスタンス詳細ページで、[リスナー] タブをクリックします。次に、[リスナーの追加] をクリックするか、対象リスナーの [操作] 列にある [リスナー設定の変更] をクリックします。
ウィザードに従ってリスナーを設定し、ヘルスチェック ページに進みます。
ヘルスチェックのスイッチをオフにし、[次へ] をクリックして変更を送信します。
ヘルスチェックのベストプラクティス
ヘルスチェックの正確性と信頼性を確保するために、以下のベストプラクティスに従ってください。
専用のヘルスチェックエンドポイントを作成する：バックエンドサーバーに、
/healthなどの専用のヘルスチェックエンドポイントを作成します。このエンドポイントは常に HTTP 200 ステータスコードを返す必要があります。ルートパス (/) などのビジネス関連パスをヘルスチェックに使用しないでください。ビジネスパスは、権限検証の失敗やリソースが存在しないなどの理由で 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 のヘルスチェックログ機能を使用して、ヘルスチェックログデータを分析できます。詳細については、「ヘルスチェックログの保存とダウンロード」をご参照ください。