翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Elastic Load Balancing の仕組み

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

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

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

ロードバランサーの設定方法は、種類によって大きく異なります。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 個のターゲットすべてにルーティングできるためです。

クロスゾーン負荷分散が無効な場合:

これは、各ロードバランサーノードが、そのクライアントトラフィックの 50% を自身のアベイラビリティーゾーンのターゲットにのみルーティングできるためです。

Application Load Balancer では、クロスゾーン負荷分散がロードバランサーレベルで常に有効になっています。ターゲットグループレベルでは、クロスゾーン負荷分散を無効化できます。詳細については、「Application Load Balancer ユーザーガイド」の「Turn off cross-zone load balancing」(クロスゾーン負荷分散をオフにする) を参照してください。

Network Load Balancer と Gateway Load Balancer では、クロスゾーン負荷分散はデフォルトで無効になっています。ロードバランサーの作成後は、いつでもクロスゾーン負荷分散を有効または無効にできます。

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 () デベロッパーガイド」の「ゾーンシフトの仕組み: ヘルスチェックとゾーン IP アドレス」を参照してください。 ARC

ゾーンシフトは、クロスゾーン負荷分散がオフになっている Application Load Balancer と Network Load Balancer でのみサポートされます。クロスゾーンロードバランサーをオンにすると、ゾーンシフトを開始できなくなります。詳細については、「Amazon Application Recovery Controller (ARC) デベロッパーガイド」の「ゾーンシフトでサポートされるリソース」を参照してください。

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

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

リクエストルーティング

クライアントは、ロードバランサーにリクエストを送信する前に、ドメインネームシステム (DNS) サーバーを使用してロードバランサーのドメイン名を解決します。ロードバランサーはamazonaws.comドメインにあるため、DNSエントリは Amazon によって制御されます。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 では、リクエストを受信するロードバランサーノードは、次のプロセスを使用します。

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

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

HTTP 接続

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

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

Application Load Balancer は、、GET、、HEAD、POST、OPTIONSおよび PUTDELETEのHTTPリクエストメソッドをサポートします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 または g を使用してターゲットにリクエストを送信できますRPC。詳細については、「プロトコルバージョン」を参照してください。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 で応答しません。このヘッダーをターゲットに続行または転送します。

HTTP ヘッダーの制限

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

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

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

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

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

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

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

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

最大送信単位 (MTU) は、ネットワーク経由で送信できる最大パケットのサイズをバイト単位で決定します。接続MTUの が大きいほど、1 つのパケットで渡すことができるデータが多くなります。イーサネットフレームは、パケット (送信している実際のデータ) とそれを囲むネットワークオーバーヘッド情報で構成されています。インターネットゲートウェイ経由で送信されるトラフィックの は 1500 MTUです。つまり、パケットが 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) が機能していない可能性があります。これを回避するには、パスMTU検出がエンドツーエンドで機能していること、およびクライアントとターゲットでジャンボフレームが有効になっていることを確認します。パスMTU検出とジャンボフレームの有効化の詳細については、「Amazon ユーザーガイド」の「パスMTU検出」を参照してください。 EC2