Application Load Balancer (ALB) は、クライアントリクエストをサーバーグループ内の 1 つ以上のバックエンドサーバーに分散します。 ALB は、ヘルスチェックを実行することでバックエンドサーバーの可用性をチェックします。 ALB にリスナーを追加する際には、サーバーグループを指定する必要があります。リスナーを作成すると、リスナーは指定したプロトコルとポートを使用して接続リクエストをチェックし、リクエストを関連付けられたサーバーグループに転送します。
サーバーグループのタイプ
ALB サーバーグループを作成してバックエンドサーバーを追加する方法については、「サーバーグループの作成と管理」をご参照ください。
サーバーグループタイプ | バックエンドサーバータイプ | 説明 | 参照 |
サーバー | バックエンドサーバーとして、Elastic Compute Service (ECS) インスタンス、Elastic Network Interface (ENI)、および Elastic Container Instance を指定できます。 | バックエンドサーバーとサーバーグループは、同じ Virtual Private Cloud (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 | サーバータイプ、IP タイプ、および Function Compute タイプ 説明 バックエンドサーバーグループのタイプが Function Compute の場合は、バックエンドまたはヘルスチェックプロトコルを指定する必要はありません。 | サーバータイプ、IP タイプ、および Function Compute タイプ 説明 標準および Web Application Firewall (WAF) が有効な ALB インスタンスは、HTTPS ヘルスチェックをサポートしています。ベーシック ALB インスタンスは、HTTPS ヘルスチェックをサポートしていません。 |
HTTPS | HTTP、HTTPS、および gRPC 説明
| ||
HTTPS | HTTP |
ヘルスチェック
サーバーグループの状態を監視するために ヘルスチェック を構成できます。これにより、サーバーグループ内のバックエンドサーバーの可用性を評価できます。
ALB では、サーバーグループのヘルスチェックを構成できます。デフォルトでは、すべてのサーバーグループに対してヘルスチェックが有効になっています。
ヘルスチェックが有効になっている場合、ALB は正常なバックエンドサーバーへのリクエストのルーティングを自動的に行い、指定された間隔ですべてのバックエンドサーバーの可用性をプローブします。バックエンドサーバーは、正常と判断される前に、指定された回数（N 回）ヘルスチェックに合格する必要があります。ビジネス要件に基づいて N を指定できます。これにより、ネットワークジッターによって発生するヘルスチェックエラーを防ぎます。
バックエンドサーバーが指定された回数ヘルスチェックに失敗した場合、そのバックエンドサーバーは異常と判断されます。この場合、ALB はバックエンドサーバーへのリクエストの配信を自動的に停止します。
バックエンドサーバーが回復した後、ALB はバックエンドサーバーへのリクエストの配信を自動的に再開します。
ヘルスチェックは持続的接続を使用しません。ヘルスチェックが完了すると、接続は閉じられます。
セッションの永続化
デフォルトでは、ALB はリクエストを異なるバックエンドサーバーに分散します。セッションの永続化を有効にすると、同じクライアントからのリクエストは同じバックエンドサーバーに転送されます。これにより、バックエンドサーバーはステータス情報を維持し、クライアントに継続的なサービスを提供できます。
セッションの永続化が無効: 同じクライアントからのリクエストが、ALB の異なるバックエンドサーバーに分散される場合があります。バックエンドサーバーにログインしてインタラクション情報を取得するシナリオなど、一部のシナリオでは、バックエンドサーバーに複数回ログインする必要がある場合があります。
セッションの永続化が有効: 同じクライアントからのリクエストは、ALB の同じバックエンドサーバーに分散されます。バックエンドサーバーにログインしてインタラクション情報を取得するシナリオなど、一部のシナリオでは、バックエンドサーバーに複数回ログインする必要はありません。
Function Compute タイプのサーバーグループは、セッションの永続化をサポートしていません。
バックエンドサーバーでの持続的接続
持続的接続を有効にすると、ALB はバックエンドサーバーへの一定数の接続を維持します。 リクエストは、優先的にアイドル状態の TCP 持続的接続に分散され、TCP ハンドシェイクの回数が削減されます。 これにより、バックエンドサーバーの負荷が軽減されます。
Function Compute タイプのサーバーグループは、持続的接続をサポートしていません。
ゾーン間の負荷分散
デフォルトでは、ALB インスタンスに対してゾーン間の負荷分散が有効になっています。受信リクエストは、指定されたリージョン内の選択されたすべてのゾーンにデプロイされたバックエンド サービスに分散されます。サーバー グループに対してこの機能を無効にすると、負荷は各シングルゾーンに分散されます。
ゾーン間の負荷分散が無効になっているサーバー グループは、Standard および WAF 対応 ALB インスタンスにのみ関連付けることができます。Basic ALB インスタンスには関連付けることができません。
ゾーン間の負荷分散が無効になっている場合、[セッション維持] を有効にすることはできません。
IP タイプのサーバー グループの場合、[リモート IP] が有効になっていると、ゾーン間の負荷分散を無効にすることはできません。
このパラメーターは、Function Compute タイプのサーバー グループでは使用できません。
参照資料
サーバーグループを作成する際に、サーバーグループのヘルスチェックを設定したり、セッション維持、クロスゾーンロードバランシング、スロースタート、接続ドレインなどの機能を有効または無効にしたりできます。次のトピックを参照してください。