Application Load Balancer (ALB) は、クライアント要求をサーバーグループ内の1つ以上のバックエンドサーバーに配信します。 ALBは、ヘルスチェックを実行してバックエンドサーバーの可用性をチェックします。 ALBにリスナーを追加するときは、サーバーグループを指定する必要があります。 リスナーを作成した後、リスナーは指定したプロトコルとポートを使用して接続要求を確認し、関連するサーバーグループに要求を転送します。
ALBサーバーグループの種類
ALBサーバーグループを作成し、バックエンドサーバーを追加する方法の詳細については、「サーバーグループの作成と管理」をご参照ください。
サーバーグループタイプ | バックエンドサーバータイプ | 説明 | 関連ドキュメント |
サーバー | ECS (Elastic Compute Service) インスタンス、ENI (elastic network Interface) 、およびelasticコンテナインスタンスをバックエンドサーバーとして指定できます。 | バックエンドサーバーとサーバーグループは、同じ仮想プライベートクラウド (VPC) に属している必要があります。 バックエンドサーバーは、ALBによって配信されたリクエストを受信するために使用されます。 | ECSインスタンスをバックエンドサーバーとして指定する方法の詳細については、以下のトピックをご参照ください。 |
IP | バックエンドサーバーとしてIPアドレスを指定できます。 |
| リージョン間でバックエンドサーバーを追加する方法の詳細については、次のトピックを参照してください。 |
Function Compute | Function Computeの機能をバックエンドサーバーとして指定できます。 | Function Computeを有効化する必要があります。 追加する関数は、ALBインスタンスと同じリージョンに属している必要があります。 |
ALBインスタンスのバックエンドサーバーがリリースされた後、またはバックエンドサーバーのプライベートIPアドレスが変更された後、ALBはバックエンドサーバーのステータスを更新しません。 ALBバックエンドサーバーをリリースまたは変更する場合は、ビジネスに影響を与えないように、ALBサーバーグループからバックエンドサーバーを削除することを推奨します。
スケジューリングアルゴリズム
このセクションでは、ALBでサポートされるスケジューリングアルゴリズムについて説明します。 詳細は、「SLBスケジューリングアルゴリズム」をご参照ください。
重み付きラウンドロビン: 重みの大きいバックエンドサーバーは、重みの小さいバックエンドサーバーよりも多くのリクエストを受け取ります。
重み付き最小接続数: リクエストは、バックエンドサーバーへの接続の重みと数に基づいて転送されます。 2つのバックエンドサーバーの重みが同じ場合、接続数が少ないバックエンドサーバーはより多くのリクエストを受信します。
一貫性のあるハッシュ: 同じ送信元IPアドレスからのリクエストは、同じバックエンドサーバーに転送されます。
ハッシュファクター: ハッシュファクターを選択します。
送信元IP: 同じ送信元IPアドレスからのリクエストは、同じバックエンドサーバーに転送されます。
URLパラメーター: 同じURLに対するリクエストは、同じバックエンドサーバーに転送されます。 この操作を選択した場合は、[指定したURL] パラメーターを指定します。
バックエンドプロトコルとヘルスチェックプロトコル
次の表に、さまざまなALBリスナーでサポートされているサーバーグループとヘルスチェックプロトコルを示します。
リスナープロトコル | サーバグループのバックエンドプロトコル | サーバーグループタイプ | ヘルスチェックプロトコル |
HTTP | HTTPおよびHTTPS | サーバータイプ、IPタイプ、およびFunction Computeタイプ 説明 バックエンドサーバーグループの種類がFunction Computeの場合、バックエンドまたはヘルスチェックプロトコルを指定する必要はありません。 | HTTP、HTTPS、TCP、およびgRPC 説明 標準およびWeb Application Firewall (WAF) 対応のALBインスタンスは、HTTPSヘルスチェックをサポートしています。 基本ALBインスタンスはHTTPSヘルスチェックをサポートしていません。 |
HTTPS | HTTP、HTTPS、およびgRPC 説明
| ||
QUIC | HTTP |
ヘルスチェック
ヘルスチェックを設定して、サーバーグループの状態を監視できます。 これにより、サーバーグループ内のバックエンドサーバーの可用性を評価できます。
ALBでは、サーバーグループのヘルスチェックを設定できます。 デフォルトでは、すべてのサーバーグループでヘルスチェックが有効になっています。
ヘルスチェックが有効になっている場合、ALBは正常なバックエンドサーバーにリクエストを自動的にルーティングし、指定された間隔ですべてのバックエンドサーバーの可用性をプローブします。 バックエンドサーバーが正常であると宣言される前に、バックエンドサーバーは特定の回数 (N回) ヘルスチェックに合格する必要があります。 ビジネス要件に基づいてNを指定できます。 これにより、ネットワークジッタによるヘルスチェックエラーが防止されます。
バックエンドサーバーが特定の回数ヘルスチェックに失敗した場合、バックエンドサーバーは異常と宣言されます。 この場合、ALBはバックエンドサーバーへのリクエストの配信を自動的に停止します。
バックエンドサーバーが回復すると、ALBは自動的にリクエストをバックエンドサーバーに配信します。
ヘルスチェックは非永続接続を使用します。 ヘルスチェックが完了すると、接続は閉じられます。
重みが0のバックエンドサーバーではヘルスチェックは実行されません。
サーバーグループ内のすべてのバックエンドサーバーが正常でない場合、ALBはサービスの中断を防ぐためにスケジューリングアルゴリズムに基づいてサーバーグループにリクエストを配信し続けます。 詳細については、「」をご参照ください。同じバックエンドサーバー内のすべてのバックエンドサーバーが正常でない場合、ALBインスタンスはどのようにリクエストを転送できますか?
詳細については、「ヘルスチェック」をご参照ください。
セッション維持
デフォルトでは、ALBはリクエストを異なるバックエンドサーバーに配信します。 セッション永続化機能を有効にすると、同じクライアントからのリクエストが同じバックエンドサーバーに転送されます。 これにより、バックエンドサーバーはステータス情報を維持し、クライアントに継続的なサービスを提供できます。
セッション維持無効: 同じクライアントからのリクエストは、ALBの異なるバックエンドサーバーに配信される可能性があります。 バックエンドサーバーにログインしてインタラクション情報を取得するシナリオなど、一部のシナリオでは、バックエンドサーバーに複数回ログインする必要がある場合があります。
セッション持続性が有効: 同じクライアントからのリクエストは、ALBの同じバックエンドサーバーに配信されます。 バックエンドサーバーにログインしてインタラクション情報を取得するシナリオなど、一部のシナリオでは、バックエンドサーバーに複数回ログインする必要はありません。
Function Computeタイプのサーバーグループは、セッション永続化をサポートしていません。
詳しくは「セッション維持の設定」 をご参照ください。
バックエンドサーバーの永続的な接続
永続接続が有効になっている場合、ALBはバックエンドサーバーへの接続を一定数維持します。 要求は、TCPハンドシェイクの数を減らすために、アイドルTCP永続接続に優先的に分配される。 これにより、バックエンドサーバーの負荷が軽減されます。
Function Computeタイプのサーバーグループは、永続的な接続をサポートしていません。
詳細については、「サーバーグループの作成」をご参照ください。