最大接続数

max connections構成を使用して、特定のフロントエンド仮想ポートに対する同時接続の最大数を制限します。 値を構成しない場合、システムではデフォルトの同時接続数 2000 が使用されます。 1 つの特定のフロントエンド仮想ポートに対する最大同時接続数、あるいは、すべてのフロントエンド仮想ポートにわたるシステム全体での最大同時接続数は 15000 です。

セッション・パーシスタンス

デフォルトでは、ALB は、受信した要求を、構成されているロード・バランシング方式に基づいてバックエンド・サーバーに転送します。 セッション・パーシスタンスを有効にすると、1 つのセッションを通して同じバックエンド・サーバーにクライアントを接続し続けることができます。

HTTP キープアライブ

クライアント・サーバーとバックエンド・サーバーの両方で有効になっている場合、Application Load Balancer for VPC では、HTTP keep aliveがサポートされます。 ロード・バランサーは、接続効率の向上と待ち時間の短縮のためにサーバー・サイドの HTTP 接続を再利用しようとします。

TCP キープアライブ

Application Load Balancer for VPC では、TCP keep aliveがサポートされます。 この設定では、ロード・バランサーにより、クライアント・サーバーとバックエンド・サーバーの両方に、5 秒ごとに TCP キープアライブ・パケットが送信されます。

これは、ホストが活動状態であることを通知するためにピアに送信される、データが含まれないソケット・レベルのパケットです。 そのため、ネットワーク層でのみ表示され、アプリケーション・レベルでは表示されません。 この設定は、非アクティブな一定期間が経過すると接続を破棄するポリシーが含まれている場合のある中間プロキシーまたはファイアウォールによって、TCP 接続が切断されないようにするのにも役立ちます。

接続タイムアウト

ALB によって以下のタイムアウト値が使用されます。 現在、以下の表のクライアント・サイドおよびサーバー・サイドのアイドル・タイムアウト値のみがカスタマイズ可能です。

エンド・クライアントの IP アドレスの保持 (HTTP/HTTPS のみ)

Application Load Balancer for VPC は、クライアントからの着信トラフィックを終了するリバース・プロキシーとして機能します。 ロード・バランサーは独自の IP アドレスを使用して、バックエンド・サーバー・インスタンスへの別個の接続を確立します。 (フロントエンドの HTTP 接続または HTTPS 接続に対して、) バックエンド・サーバーとの HTTP 接続の場合、ロード・バランサーは、元のクライアント IP アドレスを X-Forwarded-For HTTP ヘッダーに組み込んで保持します。 TCP 接続の場合、元のクライアント IP 情報は保持されません。

エンド・クライアントのプロトコルの保持 (HTTP/HTTPS のみ)

ALB は、フロントエンドの HTTP および HTTPS の接続でクライアントが使用していた元のプロトコルを、HTTP ヘッダー X-Forwarded-Proto に含めることで保持します。 TCP プロトコルの場合は、これは当てはまりません。TCP プロトコルが使用されている場合、ALB はレイヤー 7 のトラフィックを参照しないからです。

プライベート・ロード・バランサーの適用の有効化

プライベート・ロード・バランサーを適用すると、パブリック・ロード・バランサーが作成されなくなります。 これにより、非インターネット・クライアント、つまり自分のネットワーク環境内のクライアントのみがロード・バランサーにアクセスできるようになります。 有効にすると、すべての ALB での浮動 IP の作成を禁止する制限がアカウントに適用されます。

プライベート・ロード・バランサーの適用を実装するには、IBM サポート Case を開き、浮動 IP の作成を制限するようにアカウントを変更することを希望する旨を記載してください。 IBM が変更を処理した後は、パブリック・ロード・バランサーを作成できなくなります。

プライベート・ロード・バランサーの適用は、有効にするとすべてのリージョンに適用されます。

HTTPS リスナーに接続するクライアントに対する HTTP/2 サポート

Application Load Balancer for VPC は、Application-Layer Protocol Negotiation (ALPN) を使用して、HTTPS リスナーに接続するクライアントとネゴシエーションします。また、HTTP/1.1 と HTTP/2 の両方ともサポートします。 ALB に接続するクライアントが HTTP/2 を使用している場合は、ALB も優先プロトコルとして HTTP/2 を使用し、バックエンド・プールへの要求を処理します。 それ以外の場合は、デフォルトで HTTP/1.1 が選択されます。

バックエンド・プールでは、HTTP/2 プロトコルはまだサポートされていません。 しかし、HTTP プロトコルと HTTPS プロトコルはサポートされています。

圧縮 (HTTP/HTTPS のみ)

HTTP/HTTPS 圧縮を使用すると、gzip を使用してユーザーに送信されるデータを圧縮できます。

ALB を使用して送信データを圧縮するには、要求ヘッダーに Accept-Encoding: gzip が含まれ、その MIME タイプが text/html、text/plain、または text/xml のいずれかでなければなりません。

プロキシー・プロトコルの有効化

TCP、HTTP、および HTTPS の各リスナーおよびバックエンド・プールのプロキシー・プロトコルを有効にすることができます。 次のようなユース・ケースがあります。

ユース・ケース 1: クライアントがロード・バランサーに直接接続する

ALB がクライアントからトラフィックを直接受信する場合は、そのリスナーのバックエンド・プールのプロキシー・プロトコルを有効にすることで、そのバックエンド・プールに送信される TCP パケットにプロキシー・プロトコル・ヘッダーを付加するようにロード・バランサーを構成します。

このデータ・パスが機能するには、そのプールのすべてのバックエンド・メンバーがプロキシー・プロトコルをサポートしている必要があります。 この設定を有効にするときに、プロキシー・プロトコル・ヘッダーのバージョン (バージョン 1 またはバージョン 2) を選択できます。 指定しない場合、この設定はデフォルトで無効になります。 この設定を使用すると、ロード・バランサーがプロキシー・プロトコル・ヘッダーに設定したクライアントの IP とポートの情報を、バックエンド・サーバーで取得することができます。

ユース・ケース 2: クライアントがプロキシーまたはプロキシー・チェーンに接続し、プロキシーまたはプロキシー・チェーンがプロキシー・プロトコルを使用してロード・バランサーに接続する

Application Load Balancer for VPC が、プロキシー・プロトコルを使用するプロキシー (またはプロキシー・チェーン) からトラフィックを受信する場合は、リスナーのプロキシー・プロトコルを有効にして、プロキシー・プロトコル・ヘッダーに含まれている元のクライアント情報をリスナーで解析できるようにする必要があります。 指定しない場合、この設定はデフォルトで無効になります。 ロード・バランサーは、プロキシー・プロトコル・ヘッダーのバージョンを検出してそのヘッダーを正しく解析することができるので、ALB へのトラフィックの送信に使用されるプロキシー・プロトコルのバージョンを指定する必要はありません。

フロントエンドのリスナーのプロキシー・プロトコルを有効にすると、そのフロントエンドのポートへのすべてのトラフィックが、プロキシー・プロトコル・トラフィックとして想定されます。 適切なプロキシー・プロトコル・ヘッダーが含まれていない接続は確立されなくなります。 このクライアント情報をバックエンド・サーバー・プールに転送するには、プールのプロキシー・プロトコルを有効にする必要があります。 ユース・ケース 1 と同じく、バックエンド・サーバーで使用するように構成されているプロキシー・プロトコルのバージョンに応じて、バージョン 1 またはバージョン 2 を選択する必要があります。 このクライアント情報をバックエンド・サーバーが処理できない場合は、この情報をバックエンド・サーバーに転送しないように選択することもできます。その場合、この情報はロード・バランサーでドロップされます。