Elastic Load Balancing の詳細
ロードバランサーは、クライアントからの受信トラフィックを受け入れ、リクエストを 1 つ以上のアベイラビリティーゾーンにある登録済みのターゲット (EC2 インスタンスなど) にルーティングします。また、ロードバランサーは登録されているターゲットの状態を監視して、トラフィックが正常なターゲットにのみルーティングされるようにします。ロードバランサーは、不具合のあるターゲットを検出すると、そのターゲットへのトラフィックのルーティングを停止し、ターゲットが正常な状態に戻ったことを検出するとターゲットへのトラフィックのルーティングを再開します。
1 つ以上のリスナーを指定することで、受信トラフィックを受け入れるようにロードバランサーを設定します。リスナーとは接続リクエストをチェックするプロセスです。リスナーの設定には、クライアントからロードバランサーへの接続用のプロトコルとポート番号、およびロードバランサーからターゲットへの接続用のプロトコルとポート番号を使用します。
Elastic Load Balancing は、Application Load Balancer、Network Load Balancer、および クラシックロードバランサー の 3 種類のロードバランサーをサポートしています。これらのロードバランサーの設定方法には重要な相違点があります。Application Load Balancer および Network Load Balancer では、ターゲットをターゲットグループに登録し、トラフィックをターゲットグループにルーティングします。クラシックロードバランサー では、ロードバランサーにインスタンスを登録します。
アベイラビリティーゾーンとロードバランサーノード
ロードバランサー用のアベイラビリティーゾーンを有効にすると、Elastic Load Balancing はアベイラビリティーゾーンにロードバランサーノードを作成します。ターゲットをアベイラビリティーゾーンに登録したが、アベイラビリティーゾーンを有効にしていない場合、登録したターゲットはトラフィックを受信しません。ロードバランサーが最も効果的なのは、有効な各アベイラビリティーゾーンに少なくとも 1 つの登録済みターゲットがある場合です。
マルチアベイラビリティーゾーンを有効にすることをお勧めします。(Application Load Balancer では、マルチアベイラビリティーゾーンを有効にする必要があります。) この設定では、1 つのアベイラビリティーゾーンが利用できなくなったか正常なターゲットがなくなった場合、ロードバランサーはトラフィックを別のアベイラビリティゾーンの正常な登録済みターゲットにルーティングできます。
アベイラビリティーゾーンを無効にすると、そのアベイラビリティーゾーン内のターゲットはロードバランサーに登録されたままですが、ロードバランサーはトラフィックをターゲットにルーティングしなくなります。
クロスゾーン負荷分散
ロードバランサーのノードは、クライアントからのリクエストを登録済みターゲットに分散させます。クロスゾーン負荷分散が有効な場合、各ロードバランサーノードは、有効なすべてのアベイラビリティーゾーンの登録済みターゲットにトラフィックを分散します。クロスゾーン負荷分散が無効な場合、各ロードバランサーノードは、そのアベイラビリティーゾーンの登録済みターゲットにのみトラフィックを分散します。
次の図はクロスゾーン負荷分散の効果を示しています。有効なアベイラビリティーゾーンが 2 つがあり、アベイラビリティーゾーン A には 2 つのターゲット、アベイラビリティーゾーン B には 8 つのターゲットがあります。クライアントがリクエストを送信すると、Amazon Route 53 はロードバランサーノードのいずれか 1 つの IP アドレスを使用して各リクエストに応答します。これにより、各ロードバランサーノードがクライアントからのトラフィックの 50% を受け取るようにトラフィックが分散されます。各ロードバランサーノードは、範囲内の登録済みターゲット間で配分されたトラフィックを分散します。
クロスゾーン負荷分散が有効な場合、10 個のターゲットのそれぞれがトラフィックの 10% を受け取ります。これは、各ロードバランサーノードが、そのクライアントトラフィックの 50% を 10 個のターゲットすべてにルーティングできるためです。
クロスゾーン負荷分散が無効な場合、アベイラビリティーゾーン A の 2 つのターゲットそれぞれがトラフィックの 25% を受け取り、アベイラビリティーゾーン B の 8 つのターゲットそれぞれがトラフィックの 6.25% を受け取ります。これは、各ロードバランサーノードが、そのクライアントトラフィックの 50% を自身のアベイラビリティーゾーンのターゲットにのみルーティングできるためです。
Application Load Balancer では、クロスゾーン負荷分散が常に有効になっています。
Network Load Balancer を使用する場合、クロスゾーン負荷分散はデフォルトで無効化されます。ネットワークロードバランサー の作成後は、いつでもクロスゾーン負荷分散を有効または無効にできます。詳細については、Network Load Balancer 用ユーザーガイドの「クロスゾーン負荷分散」を参照してください。
Classic Load Balancer を作成する際に、クロスゾーン負荷分散のデフォルト設定は、ロードバランサーの作成方法により異なります。API または CLI を使用する場合、クロスゾーン負荷分散はデフォルトで無効化されます。AWS マネジメントコンソールを使用する場合、クロスゾーン負荷分散を有効にするオプションがデフォルトで選択されます。Classic Load Balancer の作成後は、いつでもクロスゾーン負荷分散を有効または無効にできます。詳細については、クラシックロードバランサー 用ユーザーガイドの「クロスゾーン負荷分散の有効化」を参照してください。
リクエストルーティング
クライアントがリクエストをロードバランサーに送信する前に、ドメインネームシステム (DNS) サーバーを使用してロードバランサーのドメイン名を解決します。ロードバランサーは
amazonaws.com ドメインにあるため、DNS エントリは Amazon によって制御されます。Amazon DNS サーバーは、1 つ以上の IP アドレス (ロードバランサー用のロードバランサーノードの
IP アドレス) をクライアントに返します。Network Load Balancer では、Elastic Load Balancing は有効にした各アベイラビリティーゾーンにネットワークインターフェイスを作成します。アベイラビリティーゾーンの各ロードバランサーノードは、このネットワークインターフェイスを使用して静的
IP アドレスを取得します。ロードバランサーの作成時に、必要に応じて 1 つの Elastic IP アドレスを各ネットワークインターフェイスに関連付けることができます。
アプリケーションへのトラフィックが時間の経過とともに変化すると、Elastic Load Balancing はロードバランサーをスケーリングして DNS エントリを更新します。DNS エントリでは、有効期限 (TTL) も 60 秒に指定されているため、トラフィックの変化に応じて IP アドレスが迅速に再マップされる点に注意してください。
クライアントは、ロードバランサーにリクエストを送信するために使用する IP アドレスを決定します。リクエストを受信したロードバランサーノードは、正常な登録済みターゲットを選択し、そのプライベート IP アドレスを使用してターゲットにリクエストを送信します。
ルーティングアルゴリズム
Application Load Balancer を使用すると、リクエストを受信したロードバランサーノードは、優先度順にリスナールールを評価して適用するルールを決定し、ラウンドロビンルーティングアルゴリズムを使用してルールアクションのターゲットグループからターゲットを選択します。それぞれのターゲットグループでルーティングは個別に実行され、複数のターゲットグループに登録されているターゲットの場合も同じです。
Network Load Balancer では、接続を受信したロードバランサーノードは、プロトコル、送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、および TCP シーケンス番号に基づいて、フローハッシュアルゴリズムを使用してデフォルトルールのターゲットグループからターゲットを選択します。クライアントからの TCP 接続のソースポートとシーケンス番号は異なり、別のターゲットにルーティングできます。各 TCP 接続は、接続中は単一のターゲットにルーティングされます。
クラシックロードバランサー では、リクエストを受信したロードバランサーノードは、TCP リスナーにはラウンドロビンルーティングアルゴリズムを使用して、HTTP および HTTPS リスナーには最小の未処理リクエストルーティングアルゴリズムを使用して、登録されたインスタンスを選択します。
HTTP 接続
クラシックロードバランサー は事前に開かれた接続を使用しますが、Application Load Balancer はこの接続を使用しません。クラシックロードバランサー
と Application Load Balancer の両方で、接続の多重化が使用されます。つまり、複数のフロントエンド接続の複数のクライアントからのリクエストは、1
つのバックエンド接続を介して指定のターゲットにルーティングできます。接続の多重化により、レイテンシーが改善され、アプリケーションの負荷が低下します。接続の多重化を回避するには、HTTP
レスポンスの Connection: close ヘッダーを設定して、HTTP キープアライブを無効にします。
クラシックロードバランサー はフロントエンド接続 (ロードバランサーのクライアント) の次のプロトコルをサポートします: HTTP/0.9、HTTP/1.0、HTTP/1.1。
Application Load Balancer はフロントエンド接続の次のプロトコルをサポートします: HTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2。HTTP/2 は HTTPS リスナーにのみ使用でき、HTTP/2 接続を使用して最大 128 のリクエストを並行して送信します。Application Load Balancer は、HTTP から Websockets への接続アップグレードもサポートします。
Application Load Balancer および クラシックロードバランサー はどちらもバックエンド接続で HTTP/1.1 を使用します (登録されたターゲットへのロードバランサー)。キープアライブによりバックエンド接続はデフォルトでサポートされます。ホストヘッダーを満たさないクライアントからの HTTP/1.0 リクエストの場合、ロードバランサーによりバックエンド接続で送信されたリクエストに対してHTTP/1.1ホストヘッダーを生成します。Application Load Balancer においては、ホストヘッダーにはロードバランサーの DNS 名が含まれます。Classic Load Balancer においては、ホストヘッダーにはロードバランサーノードの IP アドレスが含まれています。
Application Load Balancer と クラシックロードバランサー の両方でアイドルタイムアウト値を設定できます。デフォルト値は 60 秒です。Application Load Balancer では、アイドルタイムアウト値はフロントエンド接続のみに適用されます。Classic Load Balancer では、フロントエンド接続とバックエンド接続がアイドルタイムアウト値を超えたアイドル状態になった場合には、接続が切断されてクライアントはエラーレスポンスを受け取ります。登録されたターゲットは、切断できる状態になるまでキープアライブタイムアウトを使用してバックエンド接続を確保できます。
Application Load Balancer および クラシックロードバランサー は、フロントエンド接続でパイプライン化された HTTP をサポートします。バックエンド接続ではパイプライン化された HTTP をサポートしていません。
HTTP ヘッダー
Application Load Balancer と クラシックロードバランサー は [X-Forwarded-For]、[X-Forwarded-Prot]、[X-Forwarded-Port] ヘッダーをサポートします。
HTTP/2 を使用するフロントエンド接続の場合は、ヘッダー名は小文字です。リクエストが HTTP/1.1 を使用してターゲットに送信される前に、以下のヘッダー名は、大小混合文字に変換されます: X-Forwarded-For、X-Forwarded-Proto、X-Forwarded-Port、Host、X-Amzn-Trace-Id、Upgrade、および Connection。そのほかのヘッダー名はすべて小文字です。
Application Load Balancer および クラシックロードバランサー は、クライアントに返信する応答のプロキシの後のクライアントの入力リクエストからの接続ヘッダーを優先します。
HTTP ヘッダーの制限
Application Load Balancer の HTTP/1.x ヘッダーには次のようなサイズ制限があります。
-
リクエスト行: 16K
-
単一ヘッダー: 16K
-
総ヘッダー: 64K
Application Load Balancer の HTTP/2 ヘッダーには次のようなサイズ制限があります。
-
リクエスト行: 8K
-
単一ヘッダー: 8K
-
総ヘッダー: 64K
ロードバランサーのスキーム
ロードバランサーを作成するとき、ロードバランサーを内部向けにするかインターネット向けにするか選択する必要があります。Classic Load Balancerを EC2-Classic に作成するときは、インターネット向けロードバランサーにする必要があります。
インターネット向けロードバランサーのノードにはパブリック IP アドレスが必要です。インターネット向けロードバランサーの DNS 名は、ノードのパブリック IP アドレスにパブリックに解決可能です。したがって、インターネット向けロードバランサーは、クライアントからインターネット経由でリクエストをルーティングできます。
内部ロードバランサーのノードはプライベート IP アドレスのみを持ちます。内部ロードバランサーの DNS 名は、ノードのプライベート IP アドレスにパブリックに解決可能です。そのため、内部向けロードバランサーは、ロードバランサー用に VPC へのアクセス権を持つクライアントからのみ、リクエストをルーティングできます。
インターネット向けロードバランサーと内部向けロードバランサーは、どちらもプライベート IP アドレスを使用してリクエストをターゲットにルーティングします。したがって、ターゲットは、内部またはインターネット向けロードバランサーからリクエストを受信するためのパブリック IP アドレスを必要としません。
アプリケーションに複数のレイヤーがある場合 (インターネットに接続する必要があるウェブサーバーや、ウェブサーバーにのみ接続されているデータベースサーバーなど)、内部ロードバランサーとインターネット接続ロードバランサーの両方を使用するアーキテクチャーを設計できます。インターネット接続ロードバランサーを作成し、そこにウェブサーバーを登録します。内部ロードバランサーを作成し、そこにデータベースサーバーを登録します。ウェブサーバーは、インターネット接続ロードバランサーからリクエストを受け取り、データベースサーバー用のリクエストを内部ロードバランサーに送信します。データベースサーバーは、内部ロードバランサーからリクエストを受け取ります。
