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

仕組み

ALB は、各バックエンドサーバーに定期的にプローブリクエストを送信し、その応答を評価します。サーバーが正常と判断されるには、正常しきい値で指定された回数のチェックに連続して合格する必要があります。これにより、一時的なネットワークのジッターによる誤検出を防ぎます。

サーバーが異常しきい値で指定された回数を超えて連続してチェックに失敗すると、ALB はそのサーバーへの新しいリクエストのルーティングを停止し、正常なサーバーにリダイレクトします。サーバーが復旧すると、ALB は自動的にそのサーバーをルーティング対象に戻します。

ヘルスチェックでは、各プローブの完了直後に切断される短時間接続が使用されます。

フェイルオープン： サーバーグループ内のすべてのサーバーが同時にヘルスチェックに失敗した場合、ALB はトラフィックを完全にドロップするのではなく、スケジューリングアルゴリズムに基づいてすべてのサーバーにリクエストをルーティングし続けます。これにより、広範囲にわたる障害が発生した場合のサービス中断を抑制します。

重みが 0 のバックエンドサーバーは、ヘルスチェックの対象になりません。

ソース IP アドレス

ALB は、特定の IP アドレスからバックエンドサーバーにプローブを送信します。iptables ルール、サードパーティのセキュリティソフトウェア、または VPC ネットワーク ACL などで、これらのアドレスからのトラフィックを許可するようにサーバーを設定してください。これらの IP をブロックすると、ヘルスチェックプローブがサーバーに到達できなくなり、ALB はサーバーを異常と判断して、負荷分散ローテーションから除外します。

ヘルスチェックの作成

プロトコル

ヘルスチェックの変更

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

ALB インスタンスにリスナーがあり、ヘルスチェックが有効になっている場合、[リスナー] タブでバックエンドサーバーのヘルスステータスを表示できます。リスナーのヘルスチェックステータスは、関連付けられているすべてのサーバーグループから集約されます。サーバーグループ内のいずれかのバックエンドサーバーが異常な場合、そのサーバーグループは異常と見なされます。リスナーに関連付けられているいずれかのサーバーグループが異常な場合、リスナーのヘルスチェックステータスは異常と表示されます。

ヘルスチェックの削除

本番環境に適用

専用のヘルスチェックエンドポイントを作成します。 常に HTTP 200 を返す専用ルート (例：/health) を追加します。ビジネスロジックを含むパスの使用は避けてください。認証やリソースの欠落により 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 個のヘルスチェックテンプレートを作成できます。このクォータは増やすことはできません。

次のステップ

• ALB ヘルスチェックに関する FAQ

• ALB ヘルスチェックの失敗に関するトラブルシューティング