メニュー
Elastic Load Balancing
ユーザーガイド

Elastic Load Balancing の詳細

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

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

Elastic Load Balancing では、ロードバランサーとして Application Load Balancer と Classic Load Balancer の 2 種類をサポートします。この 2 つのロードバランサーの構成方法には重要な相違点があります。Classic Load Balancerでは、ロードバランサーにインスタンスを登録します。Application Load Balancerでは、インスタンスをターゲットとしてターゲットグループに登録し、トラフィックをターゲットグループにルーティングします。

アベイラビリティーゾーンとインスタンス

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

Classic Load Balancerでは、複数のアベイラビリティーゾーンを有効にすることをお勧めします。Application Load Balancerでは、複数のアベイラビリティーゾーンを有効にする必要があります。複数のアベイラビリティーゾーンを有効にしておくと、1 つのアベイラビリティーゾーンが利用できなくなったか正常なインスタンスがなくなった場合でも、ロードバランサーは引き続きトラフィックを別のアベイラビリティーゾーンの正常な登録済みインスタンスにルーティングすることができます。

クロスゾーン負荷分散は、Application Load Balancerでは常に有効であり、Classic Load Balancerではデフォルトで無効になっています。クロスゾーン負荷分散が有効な場合、ロードバランサーは、有効なすべてのアベイラビリティーゾーンのすべての登録されたインスタンスにトラフィックを均等に分散します。クロスゾーン負荷分散が無効な場合、ロードバランサーは、有効なすべてのアベイラビリティーゾーンにトラフィックを均等に分散します。たとえば、アベイラビリティーゾーンの us-west-2a に 10 個のインスタンスがあり、us-west-2b に 2 個のインスタンスがあるとします。クロスゾーン負荷分散が無効になっていると、リクエストは us-west-2a と us-west-2b に均等に分散されます。その結果、us-west-2b 内の 2 個のインスタンスは、us-west-2a 内の 10 個のインスタンスと同じ量のトラフィックを処理します。一方、クロスゾーン負荷分散が有効になっていると、ロードバランサーは受信リクエストを 12 個全部のインスタンスに均等に分散します。

 クロスゾーン負荷分散とアベイラビリティーゾーン。

リクエストルーティング

クライアントがリクエストをロードバランサーに送信する前に、ドメインネームシステム (DNS) サーバーを使用してロードバランサーのドメイン名を解決します。インスタンスは amazonaws.com ドメインにあるため、DNS エントリは Amazon によって制御されます。Amazon DNS サーバーは、1 つ以上の IP アドレス (ロードバランサー用のロードバランサーノードの IP アドレス) をクライアントに返します。アプリケーションへのトラフィックが時間の経過とともに変化すると、Elastic Load Balancing はロードバランサーをスケーリングして DNS エントリを更新します。DNS エントリでは、有効期限 (TTL) も 60 秒に指定されているため、トラフィックの変化に応じて IP アドレスが迅速に再マップされる点に注意してください。

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

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

Classic Load Balancer では、リクエストを受信するロードバランサーノードによって TCP リスナーにはラウンドロビンのルーティングアルゴリズムを使用した登録されたインスタンス、HTTP と HTTPS リスナーにはルーティングアルゴリズムの最小の未処理のリクエストが選択されます。

Application Load Balancer を使用すると、リクエストを受信したロードバランサーは、優先度ルールでリスナールールを評価して適用するルールを決定し、ラウンドロビンルーティングアルゴリズムを使用してルールアクションのターゲットグループからターゲットを選択します。それぞれのターゲットグループでルーチングは個別に実行され、複数のターゲットグループに登録されているターゲットの場合も同じです。

HTTP 接続

Classic Load Balancer は事前に開かれた接続を使用しますが、Application Load Balancer はこの接続を使用しません。

Classic Load Balancer はフロントエンド接続 (ロードバランサーのクライアント) の次のプロトコールをサポートします: HTTP/0.9、HTTP/1.0、HTTP/1.1。

Application Load Balancer はフロントエンド接続の次のプロトコールをサポートします: HTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2。HTTPS/2 は HTTPS リスナーにのみ使用でき、HTTP/2 接続を使用して最大 128 のリクエストを並行して送信します。Application Load Balancer は、HTTP から Websockets への接続アップグレードもサポートします。

Classic Load Balancer および Application Load Balancer はどちらもバックエンド接続で HTTP/1.1 を使用します(登録されたインスタンスへのロードバランサー)。キープアライブによりバックエンド接続はデフォルトでサポートされます。ホストヘッダーを満たさないクライアントからの HTTP/1.0 リクエストの場合、ロードバランサーによりバックエンド接続で送信されたリクエストに対してHTTP/1.1ホストヘッダーを生成します。Classic Load Balancer においては、ホストヘッダーにはロードバランサーノードの IP アドレスが含まれています。Application Load Balancer においては、ホストヘッダーにはロードバランサーの DNS 名が含まれます。

Classic Load Balancers および Application Load Balancer のどちらにもアイドルタイムアウト値を設定できます。デフォルト値は 60 秒です。Classic Load Balancer では、フロントエンド接続とバックエンド接続がアイドルタイムアウト値を超えたアイドル状態になった場合には、接続が切断されてクライアントはエラーレスポンスを受け取ります。Application Load Balancer では、アイドルタイムアウト値はフロントエンド接続のみに適用されます。登録されたターゲットは、切断できる状態になるまでキープアライブタイムアウトを使用してバックエンド接続を確保できます。

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

[HTTP Headers]

Classic Load Balancers と Application Load Balancer は [X-Forwarded-For]、[X-Forwarded-Proto]、[X-Forwarded-Port] ヘッダーをサポートします。

HTTP/2 を使用するフロントエンド接続の場合は、ヘッダー名は小文字です。リクエストが HTTP/1.1 を使用してターゲットに送信される前に、以下のヘッダー名は、大小混合文字に変換されます: X-Forwarded-ForX-Forwarded-ProtoX-Forwarded-PortHostX-Amzn-Trace-IdUpgrade、および Connection。そのほかのヘッダー名はすべて小文字です。

Classic Load Balancer および Application Load Balancer は、クライアントに返信する応答のプロキシの後のクライアントの入力リクエストからの接続ヘッダーを優先します。

Application Load Balancer への HTTP ヘッダーには次のようなサイズ制限があります。

  • リクエスト行: 16K

  • 単一ヘッダー: 16K

  • 総ヘッダー: 64K

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

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

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

内部ロードバランサーのノードはプライベート IP アドレスのみを持ちます。内部ロードバランサーの DNS 名は、ノードのプライベート IP アドレスにパブリックに解決可能です。そのため、内部向けロードバランサーは、ロードバランサー用に VPC へのアクセス権を持つクライアントからのみ、リクエストをルーティングできます。

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

アプリケーションに複数のレイヤーがある場合 (インターネットに接続する必要があるウェブサーバーや、ウェブサーバーにのみ接続されているデータベースサーバーなど)、内部ロードバランサーとインターネット接続ロードバランサーの両方を使用するアーキテクチャーを設計できます。インターネット接続ロードバランサーを作成し、そこにウェブサーバーを登録します。内部ロードバランサーを作成し、そこにデータベースサーバーを登録します。ウェブサーバーは、インターネット接続ロードバランサーからリクエストを受け取り、データベースサーバー用のリクエストを内部ロードバランサーに送信します。データベースサーバーは、内部ロードバランサーからリクエストを受け取ります。

 インターネット向けロードバランサーと内部向けロードバランサーを使用する複数のレイヤーがあるアーキテクチャ。