Elastic Load Balancing の仕組み - Elastic Load Balancing
アベイラビリティーゾーンとロードバランサーノードリクエストルーティングロードバランサーのスキームネットワーク MTU

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

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 では、クロスゾーン負荷分散はデフォルトで無効になっています。ロードバランサーの作成後は、いつでもクロスゾーン負荷分散を有効または無効にできます。

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) デベロッパーガイド」の「ゾーンシフトでサポートされるリソース」を参照してください。

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

  • ゾーンシフトでは、クロスゾーンロードバランサーはサポートされていません。この機能を使用するには、クロスゾーンロードバランシングをオフにする必要があります。

  • 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 ゾーンシフトのベストプラクティス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 では、リクエストを受信するロードバランサーノードは、次のプロセスを使用します。

  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レスポンスで 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 の以下のサイズ制限は、変更できないハードリミットです。

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

  • 単一ヘッダー: 16 K

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

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

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

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

インターネット向けロードバランサーのノードにはパブリック 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