Application Load Balancer (ALB) は、ヘルスチェックを使用してバックエンドサーバーを継続的に監視し、異常なサーバーへのトラフィックのルーティングを自動的に停止します。
ヘルスチェックは、すべてのサーバーグループでデフォルトで有効になっており、サーバーグループごとに個別に設定できます。
仕組み
ALB は、各バックエンドサーバーに定期的にプローブ要求を送信し、その応答を評価します。ALB がサーバーを正常と判断するには、サーバーが「正常しきい値」で指定された回数、連続でチェックに合格する必要があります。これにより、一時的なネットワークジッターによる誤検出を防ぎます。
サーバーが「異常しきい値」で指定された回数を超えて連続でチェックに失敗すると、ALB はそのサーバーへの新しいリクエストのルーティングを停止し、正常なサーバーにリダイレクトします。サーバーが復旧すると、ALB は自動的にそのサーバーを再度追加します。
ヘルスチェックでは、各プローブの完了直後に切断される短期間の接続が使用されます。
フェイルオープン挙動: サーバーグループ内のすべてのサーバーが同時にヘルスチェックに失敗した場合、ALB はトラフィックを完全に破棄するのではなく、スケジューリングアルゴリズムに基づいてすべてのサーバーにリクエストをルーティングし続けます。これにより、広範囲にわたる障害が発生した際のサービスの中断を抑制します。
重みが 0 のバックエンドサーバーは、ヘルスチェックの対象になりません。
送信元 IP アドレス
ALB は、特定の IP アドレスからバックエンドサーバーにプローブを送信します。iptables ルールやサードパーティ製のセキュリティソフトウェアを含め、サーバーがこれらのアドレスからのトラフィックを許可していることを確認してください。これらの IP をブロックすると、ヘルスチェックプローブがサーバーに到達できず、ALB はサーバーを異常と判断し、負荷分散のローテーションから除外します。
ALB インスタンスタイプ | 送信元 IP 範囲 |
アップグレードされた ALB インスタンス | vSwitch の CIDR ブロックからのプライベート IP アドレス (ローカル IP) です。これらのアドレスはインスタンス詳細ページで確認できます。 |
アップグレードされていない ALB インスタンス |
|
ヘルスチェックの作成
コンソール
ALB コンソールの[ヘルスチェック] ページに移動します。
対象リージョンを選択し、[ヘルスチェックの作成] をクリックします。
次のパラメーターを設定し、[作成] をクリックします。
基本設定
パラメーター | 説明 |
[ヘルスチェック名] | ヘルスチェックテンプレートの名前です。 |
[プロトコル] | プローブに使用するプロトコルです。詳細については、「プロトコル」をご参照ください。 |
[ヘルスチェックメソッド] | プローブ要求の HTTP メソッドです。HTTP、HTTPS、gRPC の場合にのみ適用されます。 |
[HTTP バージョン] | HTTP1.0 または HTTP1.1。HTTP と HTTPS の場合にのみ適用されます。 |
[ポート] | プローブ対象のポートです。空白のままにすると、各バックエンドサーバーのポートが使用されます。有効な値の範囲は 1~65535 です。 |
[パス] | プローブ対象の URL パスです (例: |
[ドメイン名] | プローブ要求で送信される |
正常性の判定
パラメーター | デフォルト | 有効な値 | 説明 |
[ヘルスチェックのステータスコード] |
| 「ヘルスチェックのステータスコード」をご参照ください | サーバーが正常であると判断するための HTTP ステータスコードです。HTTP、HTTPS、gRPC の場合にのみ適用されます。 |
[ヘルスチェックの応答タイムアウト] | 5 秒 | 1~300 秒 | サーバーがこの時間内に応答しない場合、チェックは失敗と見なされます。 |
[ヘルスチェック間隔] | 2 秒 | 1~50 秒 | 連続するヘルスチェック間の時間間隔です。間隔が長いほど、異常なサーバーの検出が遅くなります。 |
[正常しきい値] | 3 | 2~10 | サーバーを正常と判断するために必要な、連続して成功するチェックの回数です。 |
[異常しきい値] | 3 | 2~10 | サーバーを異常と判断するために必要な、連続して失敗するチェックの回数です。 |
タグとリソースグループ
パラメーター | 説明 |
[タグキー] / [タグ値] | ヘルスチェックテンプレートをフィルタリングおよび管理するための、キーと値のペアからなるタグです。 |
[リソースグループ] | このヘルスチェックが属するリソースグループです。 |
ヘルスチェックを作成した後、サーバーグループを作成する際に[ヘルスチェック設定] セクションで作成したヘルスチェックテンプレートを選択します。
サーバーグループの作成時にヘルスチェックを設定し、[ヘルスチェック設定をテンプレートとして保存] を選択して設定をテンプレートとして保存することもできます。
API
CreateHealthCheckTemplate API を呼び出して、ヘルスチェックテンプレートを作成します。
ApplyHealthCheckTemplateToServerGroup API を呼び出して、サーバーグループに適用します。
プロトコル
ヘルスチェックメソッド (HTTP、HTTPS、gRPC)
メソッド | デフォルト | 動作 |
HEAD | HTTP、HTTPS | ヘッダーのみをリクエストします。バックエンドが HEAD リクエストをサポートしていることを確認してください。サポートしていない場合は、GET を使用してください。 |
POST | gRPC | バックエンドが POST リクエストをサポートしていることを確認してください。サポートしていない場合は、GET を使用してください。 |
GET | — | 8 KB を超える応答は切り捨てられますが、ヘルスチェックの結果には影響しません。 |
プロトコルの詳細
プロトコル | メカニズム |
HTTP | ALB は HEAD または GET リクエストを送信して、バックエンドサーバーアプリケーションが正常であることを確認します。 |
HTTPS | ALB は HEAD または GET リクエストを送信して、バックエンドサーバーアプリケーションが正常であることを確認します。Standard および WAF-enhanced の ALB インスタンスでサポートされています。Basic の ALB インスタンスではサポートされていません。 |
TCP | ALB は SYN ハンドシェイクパケットを送信して、バックエンドサーバーのポートが利用可能であることを確認します。 |
gRPC | ALB は POST または GET リクエストを送信して、バックエンドサーバーアプリケーションが正常であることを確認します。 |
ヘルスチェックのステータスコード (HTTP、HTTPS、gRPC)
ALB は、プローブが設定されたステータスコードのいずれかを返した場合にのみ、サーバーを正常と判断します。
HTTP/HTTPS:
http_2xx、http_3xx、http_4xx、http_5xxから選択します。デフォルト:http_2xxとhttp_3xx。gRPC: 有効なコードは 0~99 です。最大 20 個の値の範囲をカンマで区切って指定します。
ステータスコードリストに http_4xx または http_5xx を含めると、異常なサーバーの検出が遅れる可能性があります。リストを http_2xx と http_3xx に限定し、4xx または 5xx 応答の原因となるバックエンドの問題を修正してください。
ヘルスチェックの変更
ヘルスチェックを無効にすると、ALB は異常なサーバーを検出できなくなります。サーバーがダウンした場合、トラフィックは正常なサーバーに自動的にリダイレクトされません。
ヘルスチェック間隔を長く指定すると、ALB が異常なバックエンドサーバーを検出するのに時間がかかります。
コンソール
ALB コンソールの [ヘルスチェック] ページに移動します。
対象のヘルスチェックの[操作] 列にある [変更] をクリックします。
[ヘルスチェック設定の変更] ダイアログで設定を更新し、[保存] をクリックします。
サーバーグループページでヘルスチェックを編集することもできます。
API
UpdateHealthCheckTemplateAttribute API を呼び出して、ヘルスチェックテンプレートを更新します。
ヘルスチェックステータスの表示
ALB インスタンスにリスナーがあり、ヘルスチェックが有効になっている場合、[リスナー] タブでバックエンドサーバーのヘルスチェックステータスを表示できます。
コンソール
API
GetListenerHealthStatus API を呼び出して、リスナーのヘルスチェックステータスを照会します。
ヘルスチェックの削除
コンソール
ALB コンソールの [ヘルスチェック] ページに移動します。
対象のヘルスチェックの[操作] 列にある [削除] をクリックします。
削除を確認し、[OK] をクリックします。
API
DeleteHealthCheckTemplates API を呼び出して、ヘルスチェックテンプレートを削除します。
本番運用時の注意点
専用のヘルスチェックエンドポイントを作成してください。 /health など、常に HTTP 200 を返す専用のルートを追加します。ビジネスロジックを含むパスの使用は避けてください。認証やリソースの欠落が原因で 4xx レスポンスが返され、ヘルスチェックが失敗と誤判断される可能性があります。
ステータスコードを緩和するのではなく、バックエンドの問題を修正してください。 ヘルスチェックが失敗した場合は、エンドポイントが 2xx または 3xx を返すように根本原因を調査し、修正してください。問題を回避するために、許容されるステータスコードリストに 4xx または 5xx を追加しないでください。
環境に合わせてパラメーターを調整してください。 ほとんどのシナリオでは、デフォルト設定で問題ありません。起動が遅いサービスの場合は、ヘルスチェック間隔 または [異常しきい値] を増やして、起動中のサーバーが起動処理を完了する前に異常と判断されるのを防いでください。高レイテンシーのネットワークの場合は、ヘルスチェックの応答タイムアウト を増やしてください。
curl を使用してヘルスチェックをシミュレートします。 トラブルシューティングの際は、次のコマンドを使用して ALB のプローブ動作を再現できます。メソッド、ドメイン、IP、ポート、パスを実際の設定に合わせて置き換えてください:
curl -Iv -X HEAD --http1.0 -H "Host: your-domain.com" http://backend_ip:port/health_path課金
ヘルスチェックに追加料金はかかりません。ALB の料金詳細については、「ALB 課金情報」をご参照ください。
クォータ
リージョンごとに最大 50 個のヘルスチェックテンプレートを作成できます。このクォータは増やすことはできません。