Elastic Load Balancing の仕組み

ロードバランサーは、クライアントからの受信トラフィックを受け入れ、1 つ以上のアベイラビリティーゾーンの登録済みターゲット (EC2 インスタンスなど) にリクエストをルーティングします。また、ロードバランサーは登録されているターゲットの状態を監視して、トラフィックが正常なターゲットにのみルーティングされるようにします。ロードバランサーは、異常なターゲットを検出すると、そのターゲットへのトラフィックのルーティングを中止します。その後、ターゲットが再び正常になったことを検出すると、そのターゲットへのトラフィックのルーティングを再開します。

1 つ以上のリスナーを指定することで、受信トラフィックを受け入れるようにロードバランサーを設定します。リスナーとは接続リクエストをチェックするプロセスです。これは、クライアントからロードバランサーへの接続用のプロトコルとポート番号を使用して設定します。同様に、ロードバランサーからターゲットへの接続用のプロトコルとポート番号を使用して設定します。

Elastic Load Balancing では、以下のタイプのロードバランサーをサポートしています。

• Application Load Balancer

• Network Load Balancer

• ゲートウェイロードバランサー

• クラシックロードバランサー

ロードバランサーの設定方法は、種類によって大きく異なります。Application Load Balancer、Network Load Balancer、ゲートウェイロードバランサーでは、ターゲットをターゲットグループに登録し、トラフィックをターゲットグループにルーティングします。Classic Load Balancer では、ロードバランサーにインスタンスを登録します。

アベイラビリティーゾーンとロードバランサーノード

ロードバランサー用のアベイラビリティーゾーンを有効にすると、Elastic Load Balancing はアベイラビリティーゾーンにロードバランサーノードを作成します。ターゲットをアベイラビリティーゾーンに登録したが、アベイラビリティーゾーンを有効にしていない場合、登録したターゲットはトラフィックを受信しません。有効な各アベイラビリティーゾーンに 1 つ以上の登録済みターゲットが含まれるようにすると、ロードバランサーは最も効果的に機能します。

すべてのロードバランサーに対して複数のアベイラビリティーゾーンを有効にすることをお勧めします。ただし、Application Load Balancer では、少なくとも 2 つ以上のアベイラビリティーゾーンを有効にする必要があります。この設定により、ロードバランサーが引き続きトラフィックをルーティングできるようになります。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 では、クロスゾーン負荷分散がロードバランサーレベルで常に有効になっています。ターゲットグループレベルでは、クロスゾーン負荷分散を無効化できます。詳細については、「Application Load Balancer ユーザーガイド」の「Turn off cross-zone load balancing」(クロスゾーン負荷分散をオフにする) を参照してください。

Network Load Balancer と Gateway Load Balancer では、クロスゾーン負荷分散はデフォルトで無効になっています。ロードバランサーの作成後は、いつでもクロスゾーン負荷分散を有効または無効にできます。詳細は「Network Load Balancers ユーザーガイド」の「Cross-zone load balancing」を参照してください。

Classic Load Balancer の作成時における、クロスゾーン負荷分散のデフォルト状態は、ロードバランサーの作成方法により異なります。API または CLI では、クロスゾーン負荷分散はデフォルトで無効になっています。では AWS Management Console、クロスゾーン負荷分散を有効にするオプションがデフォルトで選択されています。クロスゾーン負荷分散は、Classic Load Balancer の作成後に、いつでも有効化または無効化できます。詳細については、Classic Load Balancer ユーザーガイドの Enable cross-zone load balancing を参照してください。

ゾーンシフト

ゾーンシフトは、Amazon Application Recovery Controller (ARC) (ARC) の機能です。ゾーンシフトを使用すると、1 回のアクションでロードバランサーのリソースを障害のあるアベイラビリティーゾーンから移動できます。このようにして、 AWS リージョンの他の正常なアベイラビリティーゾーンから操作を継続できます。

ゾーンシフトを開始すると、ロードバランサーは、影響を受けるアベイラビリティーゾーンへのリソースのトラフィックの送信を停止します。ARC はすぐにゾーンシフトを作成します。ただし、影響を受けるアベイラビリティーゾーンで進行中の既存の接続が完了するまでには、通常は数分程度の短い時間がかかる場合があります。詳細については、「Amazon Application Recovery Controller (Word) デベロッパーガイド」の「ゾーンシフトの仕組み: ヘルスチェックとゾーン IP アドレス」を参照してください。 ARC

ゾーンシフトを使用する前に、以下を確認してください。

• ゾーンシフトは、クロスゾーン負荷分散を有効にした Application Load Balancer を使用している場合はサポートされません。ゾーンシフトは、クロスゾーン負荷分散を無効にした Network Load Balancer を使用している場合はサポートされます。

• Application Load Balancer を AWS Global Acceleratorでアクセラレータエンドポイントとして使用する場合、ゾーンシフトはサポートされません。

• 1 つのアベイラビリティーゾーンに対してのみ、特定のロードバランサーのゾーンシフトを開始できます。複数のアベイラビリティーゾーンに対してゾーンシフトを開始することはできません。

• AWS は、複数のインフラストラクチャの問題が サービスに影響を与える場合に、DNS からゾーンロードバランサーの IP アドレスをプロアクティブに削除します。ゾーンシフトを開始する前に、現在のアベイラビリティーゾーンの容量を必ず確認してください。ロードバランサーのクロスゾーンロードバランシングがオフになっていて、ゾーンシフトを使用してゾーンロードバランサーの IP アドレスを削除すると、ゾーンシフトの影響を受けるアベイラビリティーゾーンもターゲット容量を失います。

• Application Load Balancer が Network Load Balancer のターゲットである場合は、常に Network Load Balancer からゾーンシフトを開始します。Application Load Balancer からゾーンシフトを開始すると、Network Load Balancer はシフトを認識せず、引き続き Application Load Balancer にトラフィックを送信します。

ガイダンスと詳細については、「Amazon Application Recovery Controller (ARC) デベロッパーガイド」のRoute 53 Word ゾーンシフトのベストプラクティス」を参照してください。 ARC

リクエストルーティング

クライアントは、ロードバランサーにリクエストを送信する前に、ドメインネームシステム (DNS) サーバーを使用してロードバランサーのドメイン名を解決します。Word DNSエントリは Amazon によって制御されます。ロードバランサーはamazonaws.comドメイン内にあるためです。Amazon DNS サーバーは、1 つ以上の IP アドレスをクライアントに返します。これらは、ロードバランサーのロードバランサーノードの IP アドレスです。Network Load Balancer を使用すると、Elastic Load Balancing は、有効にする各アベイラビリティーゾーンのネットワークインターフェイスを作成し、それを使用して静的 IP アドレスを取得します。Network Load Balancer の作成時に、必要に応じて 1 つの Elastic IP アドレスを各ネットワークインターフェイスに関連付けることができます。

アプリケーションへのトラフィックが時間の経過とともに変化すると、Elastic Load Balancing はロードバランサーをスケーリングし、DNS エントリを更新します。DNS エントリでは、60 秒の time-to-live (TTL) も指定します。これにより、トラフィックの変化に応じて IP アドレスを迅速に再マッピングできます。

クライアントは、ロードバランサーにリクエストを送信するために使用する IP アドレスを決定します。リクエストを受信したロードバランサーノードは、正常な登録済みターゲットを選択し、そのプライベート IP アドレスを使用してターゲットにリクエストを送信します。

詳細については、「Amazon Route 53 デベロッパーガイド」のELB ロードバランサーへのトラフィックのルーティング」を参照してください。

ルーティングアルゴリズム

Application Load Balancer では、リクエストを受信するロードバランサーノードは、次のプロセスを使用します。

1. リスナールールを優先度順に評価して、適用するルールを決定します。

2. ターゲットグループに設定されたルーティングアルゴリズムを使用して、ルールアクションのターゲットグループからターゲットを選択します。デフォルトのルーティングアルゴリズムはラウンドロビンです。それぞれのターゲットグループでルーティングは個別に実行され、複数のターゲットグループに登録されているターゲットの場合も同じです。

Network Load Balancer では、接続を受信するロードバランサーノードは、次のプロセスを使用します。

1. フローハッシュアルゴリズムを使用して、デフォルトルールのターゲットグループからターゲットを選択します。アルゴリズムは以下に基づきます。

   • プロトコル

   • 送信元 IP アドレスと送信元ポート

   • 送信先 IP アドレスと送信先ポート

   • TCP シーケンス番号

2. 接続の存続期間中、個々の TCP 接続を 1 つのターゲットにルーティングします。クライアントからの TCP 接続には異なるソースポートとシーケンス番号があり、異なるターゲットにルーティングできます。

Classic Load Balancer では、リクエストを受信するロードバランサーノードは、次のように登録済みインスタンスを選択します。

• TCP リスナーにラウンドロビンルーティングアルゴリズムを使用します

• HTTP リスナーと HTTPS リスナーには、未処理の最小リクエストルーティングアルゴリズムを使用します。

HTTP 接続

Classic Load Balancer は事前に開かれた接続を使用しますが、Application Load Balancer は使用しません。Classic Load Balancer と Application Load Balancer はどちらも接続の多重化を使用します。つまり、複数のフロントエンド接続の複数のクライアントからのリクエストは、1 つのバックエンド接続を介して指定のターゲットにルーティングできます。接続の多重化により、レイテンシーが改善され、アプリケーションの負荷が低下します。接続の多重化を防ぐには、HTTP レスポンスで keep-aliveヘッダーを設定して HTTP Connection: closeヘッダーを無効にします。

Application Load Balancer と Classic Load Balancer は、フロントエンド接続でパイプライン化された HTTP をサポートします。バックエンド接続でのパイプライン化された HTTP はサポートされていません。

Application Load Balancer は、HTTP、HEAD、GET、POST、PUT、DELETE、OPTIONS の PATCH リクエストメソッドをサポートしています。

Application Load Balancer は、フロントエンド接続で次のプロトコルをサポートしています: HTTP/0.9、HTTP/1.0、HTTP/1.1、および HTTP/2。HTTP/2 は HTTPS リスナーでのみ使用でき、1 つの HTTP/2 接続を使用して最大 128 個のリクエストを並行して送信できます。Application Load Balancer は、HTTP から WebSockets への接続アップグレードもサポートしています。ただし、接続のアップグレードがある場合、Application Load Balancer リスナーのルーティングルールと AWS WAF 統合は適用されません。

Application Load Balancer は、デフォルトでバックエンド接続 (登録済みターゲットへのロードバランサー) で HTTP/1.1 を使用します。ただし、プロトコルバージョンを使用して、HTTP/2 または gRPC を使用してターゲットにリクエストを送信できます。詳細については、「プロトコルバージョン」を参照してください。keep-alive ヘッダーは、デフォルトでは、バックエンド接続でサポートされています。ホストヘッダーを持たないクライアントからの HTTP/1.0 リクエストの場合、ロードバランサーはバックエンド接続で送信される HTTP/1.1 リクエストのホストヘッダーを生成します。ホストヘッダーには、ロードバランサーの DNS 名が含まれます。

Classic Load Balancer は、フロントエンド接続 (クライアントからロードバランサーへの接続) で HTTP/0.9、HTTP/1.0、HTTP/1.1 のプロトコルをサポートしています。バックエンド接続 (登録済みターゲットへのロードバランサー) で HTTP/1.1 を使用します。keep-alive ヘッダーは、デフォルトでは、バックエンド接続でサポートされています。ホストヘッダーを持たないクライアントからの HTTP/1.0 リクエストの場合、ロードバランサーはバックエンド接続で送信される HTTP/1.1 リクエストのホストヘッダーを生成します。ホストヘッダーにはロードバランサーノードの IP アドレスが含まれています。

HTTP ヘッダー

Application Load Balancer と Classic Load Balancer は、X-Forwarded-For、X-Forwarded-Proto、および X-Forwarded-Port ヘッダーを自動的にリクエストに追加します。

Application Load Balancer は、HTTP ホストヘッダーのホスト名を小文字に変換してからターゲットに送信します。

HTTP/2 を使用するフロントエンド接続の場合、ヘッダー名は小文字です。HTTP/1.1 を使用してリクエストがターゲットに送信される前に、次のヘッダー名が大文字と小文字が混在して変換されます。X-Forwarded-For、X-Forwarded-Proto、X-Forwarded-Port、ホスト、X-Amzn-Trace-Id、アップグレード、接続。そのほかのヘッダー名はすべて小文字です。

Application Load Balancer および Classic Load Balancer は、応答をクライアントにプロキシした後、着信クライアント要求からの接続ヘッダーを尊重します。

HTTP/1.1 を使用する Application Load Balancer と Classic Load Balancer が Expect: 100-Continue ヘッダーを受け取ると、コンテンツ長ヘッダーをテストせずに HTTP/1.1 100 Continue ですぐに応答します。Expect: 100-Continue リクエストヘッダーはターゲットに転送されません。

HTTP/2 を使用する場合、Application Load Balancer はクライアントリクエストからの Expect: 100-Continue ヘッダーをサポートしていません。Application Load Balancer は HTTP/2 100 Continue で応答したり、このヘッダーをターゲットに転送したりしません。

HTTP ヘッダーの制限

Application Load Balancer の以下のサイズ制限は、変更できないハードリミットです。

• リクエストライン: 16 K

• 単一ヘッダー: 16 K

• レスポンスのヘッダー全体: 32 K

• リクエストのヘッダー全体: 64 K

ロードバランサーのスキーム

ロードバランサーを作成するとき、ロードバランサーを内部向けにするかインターネット向けにするか選択する必要があります。

インターネット向けロードバランサーのノードにはパブリック IP アドレスが必要です。インターネット向けロードバランサーの DNS 名は、ノードのパブリック IP アドレスにパブリックに解決できます。したがって、インターネット向けロードバランサーは、クライアントからインターネット経由でリクエストをルーティングできます。

内部ロードバランサーのノードはプライベート IP アドレスのみを持ちます。内部ロードバランサーの DNS 名は、ノードのプライベート IP アドレスにパブリックに解決できます。したがって、内部ロードバランサーは、ロードバランサーの VPC にアクセスできるクライアントからのリクエストのみをルーティングできます。

インターネット向けロードバランサーと内部向けロードバランサーは、どちらもプライベート IP アドレスを使用してリクエストをターゲットにルーティングします。したがって、ターゲットは、内部またはインターネット向けロードバランサーからリクエストを受信するためのパブリック IP アドレスを必要としません。

アプリケーションに複数の層がある場合は、内部向けロードバランサーとインターネット向けロードバランサーを併用するアーキテクチャを設計できます。これはたとえば、アプリケーションで、インターネットに接続する必要があるウェブサーバーと、ウェブサーバーにのみ接続するアプリケーションサーバーを使用する場合に該当します。インターネット接続ロードバランサーを作成し、そこにウェブサーバーを登録します。内部ロードバランサーを作成し、そこにアプリケーションサーバーを登録します。ウェブサーバーは、インターネット接続ロードバランサーからリクエストを受け取り、アプリケーションサーバー用のリクエストを内部ロードバランサーに送信します。アプリケーションサーバーは、内部ロードバランサーからリクエストを受け取ります。

IP アドレスのタイプ

ユーザーがロードバランサーに指定した IP アドレスのタイプによって、クライアントがロードバランサーと通信する方法が決まります。

• IPv4 のみ — クライアントはパブリックおよびプライベートの IPv4 アドレスを使用して通信します。ロードバランサー用に選択するサブネットには、IPv4 アドレス範囲が必要です。

• デュアルスタック — クライアントはパブリックおよびプライベートの IPv4 アドレスと IPv6 アドレスを使用して通信します。ロードバランサー用に選択するサブネットには、IPv4 アドレス範囲と IPv6 アドレス範囲が必要です。

• パブリックIPv4のないデュアルスタック — クライアントは、パブリックおよびプライベートの IPv6 アドレスとプライベートの IPv4 アドレスを使用して通信します。ロードバランサー用に選択するサブネットには、IPv4 アドレス範囲と IPv6 アドレス範囲が必要です。この方法は、internal ロードバランサースキームではサポートされていません。

次の表は、各ロードバランサータイプでサポートされている IP アドレスタイプをまとめたものです。

ロードバランサーのタイプ	IPv4のみ	デュアルスタック	パブリックIPv4のないデュアルスタック
Application Load Balancer	はい	はい	はい
Network Load Balancer	はい	はい	いいえ
Gateway Load Balancer	はい	はい	いいえ
Classic Load Balancer	はい	いいえ	いいえ

ユーザーがターゲットグループに指定した IP アドレスタイプによって、ロードバランサーがターゲットと通信する方法が決まります。

• IPv4 のみ — ロードバランサーはプライベート IPv4 アドレスを使用して通信します。IPv4 アドレスを持つターゲットを IPv4 ターゲットグループに登録する必要があります。

• IPv6 のみ — ロードバランサーは IPv6 アドレスを使用して通信します。IPv6 アドレスを持つターゲットを IPv6 ターゲットグループに登録する必要があります。ターゲットグループは、デュアルスタックのロードバランサーで使用する必要があります。

次の表は、各ターゲットグループプロトコルでサポートされている IP アドレスタイプを示しています。

ターゲットグループプロトコル	IPv4のみ	IPv6のみ
HTTPとHTTPS	はい	はい
TCP	はい	はい
TLS	はい	はい
UDP と TCP_UDP	はい	はい
GENEVE	-	-

ロードバランサーのネットワークMTU

最大送信単位 (MTU) は、ネットワーク経由で送信できる最大のパケットのサイズをバイト単位で決定します。接続の MTU が大きいほど、1 つのパケットで渡すことができるデータが多くなります。イーサネットフレームは、パケット (送信している実際のデータ) とそれを囲むネットワークオーバーヘッド情報で構成されています。インターネットゲートウェイ経由で送信されるトラフィックの MTU は 1500 です。つまり、パケットが 1500 バイトを超えている場合は、断片化されて複数のフレームを使用して送信されるか、Don't Fragment が IP ヘッダーに設定されていればドロップされます。

ロードバランサーノードの MTU サイズは設定できません。ジャンボフレーム (9001 MTU) は、Application Load Balancer、Network Load Balancer、Classic Load Balancer のロードバランサーノード全体で標準です。Gateway Load Balancer は 8500 MTUをサポートします。詳細については、Gateway Load Balancer ユーザーガイドの「最大送信単位 (MTU）」を参照してください。

パスMTUは、送信元ホストと受信側ホスト間のパスでサポートされる最大パケットサイズです。パスMTU検出 (PMTUD) は、2 つのデバイス間のパスMTUを決定するために使用されます。パスMTU検出は、クライアントまたはターゲットがジャンボフレームをサポートしていない場合に特に重要です。

ホストが受信側ホストの MTU より大きいパケットを送信するか、パスに沿ってデバイスの MTU より大きいパケットを送信すると、受信側ホストまたはデバイスはパケットを削除し、次の ICMP メッセージを返します: Destination Unreachable: Fragmentation Needed and Don't Fragment was Set (Type 3, Code 4)。このメッセージは送信側ホストに対し、ペイロードを複数の小さなパケットに分割し再送信することを指示します。

クライアントまたはターゲットインターフェイスの MTU サイズより大きいパケットが引き続きドロップされる場合、パスMTU検出 (PMTUD) が機能していない可能性があります。これを回避するには、Path MTU Discovery がエンドツーエンドで動作していること、およびクライアントとターゲットでジャンボフレームが有効になっていることを確認します。パスMTU検出とジャンボフレームの有効化の詳細については、「Amazon MTU ユーザーガイド」の「パスワード検出」を参照してください。 EC2