Elastic Load Balancing の仕組み
ロードバランサーは、クライアントからの受信トラフィックを受け入れ、リクエストを 1 つ以上のアベイラビリティーゾーンにある登録済みのターゲット (EC2 インスタンスなど) にルーティングします。また、ロードバランサーは登録されているターゲットの状態を監視して、トラフィックが正常なターゲットにのみルーティングされるようにします。ロードバランサーは、異常なターゲットを検出すると、そのターゲットへのトラフィックのルーティングを中止します。その後、ターゲットが再び正常になったことを検出すると、そのターゲットへのトラフィックのルーティングを再開します。
1 つ以上のリスナーを指定することで、受信トラフィックを受け入れるようにロードバランサーを設定します。リスナーとは接続リクエストをチェックするプロセスです。これは、クライアントからロードバランサーへの接続用のプロトコルとポート番号を使用して設定します。同様に、ロードバランサーからターゲットへの接続用のプロトコルとポート番号を使用して設定します。
Elastic Load Balancing は 3 種類のロードバランサーをサポートしています。
-
Application Load Balancer
-
Network Load Balancer
-
&CLB;
ロードバランサーの設定方法は、種類によって大きく異なります。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 の作成後は、いつでもクロスゾーン負荷分散を有効または無効にできます。詳細については、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 エントリは、60 秒の有効期限 (TTL) も指定します。これにより、トラフィックの変化に応じて 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 keep-alives を無効にします。
クラシックロードバランサー はフロントエンド接続 (ロードバランサーのクライアント) の次のプロトコルをサポートします: 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 を使用します。Keep-alive は、デフォルトでバックエンド接続でサポートされています。ホストヘッダーを満たさないクライアントからの HTTP/1.0 リクエストの場合、ロードバランサーによりバックエンド接続で送信されたリクエストに対してHTTP/1.1ホストヘッダーを生成します。Application
Load Balancer においては、ホストヘッダーにはロードバランサーの DNS 名が含まれます。Classic Load Balancer においては、ホストヘッダーにはロードバランサーノードの
IP アドレスが含まれています。
Application Load Balancer および クラシックロードバランサー は、フロントエンド接続でパイプライン化された HTTP をサポートします。バックエンド接続ではパイプライン化された HTTP をサポートしていません。
HTTP ヘッダー
Application Load Balancer と クラシックロードバランサー は、X-Forwarded-For、X-Forwarded-Proto、および 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 および クラシックロードバランサー は、クライアントに返信する応答のプロキシの後のクライアントの入力リクエストからの接続ヘッダーを優先します。
Application Load Balancer と クラシックロードバランサー が Expect ヘッダーを受信すると、コンテンツ長ヘッダーをテストせずに HTTP 100 Continue でクライアントに即座に応答し、Expect ヘッダーを削除して、リクエストをルーティングします。
HTTP ヘッダーの制限
Application Load Balancer の以下のサイズ制限は、変更できないハード制限です。
HTTP/1.x ヘッダー
-
リクエストライン: 16 K
-
単一ヘッダー: 16 K
-
総ヘッダー: 64 K
HTTP/2 ヘッダー
-
リクエストライン: 8 K
-
単一ヘッダー: 8 K
-
総ヘッダー: 64 K
ロードバランサーのスキーム
ロードバランサーを作成するとき、ロードバランサーを内部向けにするかインターネット向けにするか選択する必要があります。Classic Load Balancerを EC2-Classic に作成するときは、インターネット向けロードバランサーにする必要があります。
インターネット向けロードバランサーのノードにはパブリック IP アドレスが必要です。インターネット向けロードバランサーの DNS 名は、ノードのパブリック IP アドレスにパブリックに解決可能です。したがって、インターネット向けロードバランサーは、クライアントからインターネット経由でリクエストをルーティングできます。
内部ロードバランサーのノードはプライベート IP アドレスのみを持ちます。内部ロードバランサーの DNS 名は、ノードのプライベート IP アドレスにパブリックに解決可能です。そのため、内部向けロードバランサーは、ロードバランサー用に VPC へのアクセス権を持つクライアントからのみ、リクエストをルーティングできます。
インターネット向けロードバランサーと内部向けロードバランサーは、どちらもプライベート IP アドレスを使用してリクエストをターゲットにルーティングします。したがって、ターゲットは、内部またはインターネット向けロードバランサーからリクエストを受信するためのパブリック IP アドレスを必要としません。
アプリケーションに複数の層がある場合は、内部向けロードバランサーとインターネット向けロードバランサーを併用するアーキテクチャを設計できます。これはたとえば、アプリケーションで、インターネットに接続する必要があるウェブサーバーと、ウェブサーバーにのみ接続するアプリケーションサーバーを使用する場合に該当します。インターネット接続ロードバランサーを作成し、そこにウェブサーバーを登録します。内部ロードバランサーを作成し、そこにアプリケーションサーバーを登録します。ウェブサーバーは、インターネット接続ロードバランサーからリクエストを受け取り、アプリケーションサーバー用のリクエストを内部ロードバランサーに送信します。アプリケーションサーバーは、内部ロードバランサーからリクエストを受け取ります。
