最大接続数

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

セッションの維持

デフォルトでは、ALB は、受信した要求を、構成されているロード・バランシング方式に基づいてバックエンド・サーバーに転送します。 セッションのスティッキネスを有効にすると、クライアントがセッション中ずっと同じバックエンドサーバーに接続されたままになります。 詳細については、 「アプリケーション ロード バランサーのセッション固定の更新」 を参照してください。

HTTP キープアライブ

HTTP keep alive は、 HTTP クライアントとサーバーが、一つの TCP 接続上で複数のリクエストとレスポンスのペアを交換することを可能にする。 これにより、後続のリクエストの遅延が低減され、ネットワークのオーバーヘッドが最小限に抑えられ、全体的な効率が向上します。

Application Load Balancer for VPC コンシューマー・サーバーとバックエンド・サーバーの両方で有効になっている場合、 HTTP keep alive をサポートする。 クライアントがサポート HTTP keep alive している場合、ALBは複数のリクエストのために接続を開いたままにします。 ALBは、接続オーバーヘッドを最小化するため、バックエンドサーバーへのサーバーサイド HTTP 接続の再利用を試みます。

HTTP keep alive 接続のお客様とサーバー側の両方で有効化されている必要があります。

TCP キープアライブ

TCP keep alive は、トランスポート層( TCP )のメカニズムで、定期的に小さなパケット(キープアライブプローブと呼ばれる)を送信して、接続のもう一方の端がまだ到達可能かどうかをチェックすることによって、長期間のアイドル接続を維持するのに役立つ。

Application Load Balancer for VPC TCP をサポートしている。 この設定では、ロードバランサはコンシューマサーバとバックエンドサーバの両方に TCP keep alive パケットを5秒ごとに送ります。 接続が指定時間（キープアライブタイムと呼ばれ、多くの場合デフォルトは2時間）アイドル状態になると、 TCP スタックはキープアライブプローブを送信する。 ピアが応答した場合、接続は維持される。 複数回のプローブ後に応答がない場合、接続は切断されたものとみなされ、閉じられます。

TCP keep aliveは、ホストが生きていることを通知するためにピアに送られる、データのないソケットレベルのパケットである。 そのため、ネットワーク層でのみ表示され、アプリケーション・レベルでは表示されません。 この設定は、非アクティブな一定期間が経過すると接続を破棄するポリシーが含まれている場合のある中間プロキシーまたはファイアウォールによって、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 は、 HTTPS リスナーに接続するクライアントとのネゴシエーションにアプリケーションレイヤープロトコルネゴシエーション(ALPN)を使用し、 HTTP と HTTPS の両方のプロトコルをサポートする。

バックエンド・プールでは、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 を選択する必要があります。 このクライアント情報をバックエンド・サーバーが処理できない場合は、この情報をバックエンド・サーバーに転送しないように選択することもできます。その場合、この情報はロード・バランサーでドロップされます。