Study for SAA-C02: Elastic Load Balancing

Elastic Load Balancing の特徴 #

製品の比較 #

アプリケーションのニーズに応じて、最適なロードバランサーを選択できる。

• Application Load Balancer: 柔軟なアプリケーション管理が必要な場合
• Network Load Balancer: 高度なパフォーマンスと静的 IP がアプリケーションで必要な場合
• Classic Load Balancer: EC2-Classic ネットワーク内で構築された既存のアプリケーションがある場合

セキュリティ #

VPC を使用する際は、ELB に関連付けられているセキュリティグループを作成および管理して、ALB および CLB に追加のネットワーキングおよびセキュリティオプションを提供できる。任意の Load Balancer をインターネットに接続するよう設定することもできるし、パブリック IP アドレスを使用せずに内部的な (インターネットに接続しない) ロードバランサーを作成することもできる。

高可用性 #

ELB は可用性に優れている。単一のアベイラビリティーゾーンまたは複数のアベイラビリティーゾーンにある Amazon EC2 インスタンス間で受信トラフィックを分散できる。ELB は、受信するアプリケーショントラフィックに応じて、リクエスト処理能力を自動的にスケールする。ターゲットが使用可能かつ正常な状態であることを確認するために、ELB は構成可能な流れでターゲットの正常性チェックを実施する。

高スループット #

ELB は、トラフィックが増大した場合でも処理できるよう設計されており、1 秒間に数百万件ものリクエストでも負荷分散できる。また、突発的で不安定なトラフィックパターンにも対処できる。

ヘルスチェック #

ELB は、EC2 インスタンス、コンテナ、IP アドレス、マイクロサービス、Lambda 関数、アプライアンスなどの正常なターゲットにのみトラフィックをルーティングする。ELB を使用すると、アプリケーションの状態の詳細情報を次の 2 つの方法で取得できる。

1. ヘルスチェック機能が改善され、詳細なエラーコードを設定できる。ヘルスチェックを使用すると、ロードバランサーの内側にある各サービスの状態をモニタリングできる。
2. 新しいメトリクスにより、EC2 インスタンスで実行される各サービスのトラフィックに関する情報が提供される。

スティッキーセッション #

ELB はスティッキーセッションをサポートする。維持設定はターゲットグループレベルで定義される。

運用のモニタリングとログ記録 #

Amazon CloudWatch により、リクエスト数、エラー数、エラータイプ、およびリクエストレイテンシーなどの ALB および CLB のメトリクスがレポートされる。Amazon CloudWatch は、アクティブなフロー数、新規フロー数、処理済みバイト数などの NLB および GLB のメトリクスも追跡する。ELB は、ELB への API コールを追跡する AWS CloudTrail とも統合されている。

削除保護 #

ELB で削除保護を有効にして、誤って削除されることを防止できる。

Elastic Load Balancing の仕組み #

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

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

すべてのロードバランサーに対して複数のAZを有効にすることを推奨。ただし、ALB では、少なくとも 2 つ以上のAZを有効にする必要がある。この設定により、ロードバランサーが引き続きトラフィックをルーティングできるようになる。1 つのAZが利用できなくなるか、正常なターゲットがなくなった場合、ロードバランサーは別のAZの正常なターゲットにトラフィックをルーティング可能。

AZを無効にしても、そのAZのターゲットはロードバランサーに登録されたままになる。ただし、登録されたままであっても、ロードバランサーはトラフィックをルーティングしない。

クロスゾーン負荷分散 #

• クロスゾーン負荷分散が有効な場合、各ロードバランサーノードは、有効なすべてのAZの登録済みターゲットにトラフィックを分散する。
• クロスゾーン負荷分散が無効な場合、各ロードバランサーノードは、そのAZの登録済みターゲットにのみトラフィックを分散する。
• ALB では、クロスゾーン負荷分散が常に有効。
• NLB と GLB では、クロスゾーン負荷分散はデフォルトで無効。
• CLB の作成時における、クロスゾーン負荷分散のデフォルト状態は、ロードバランサーの作成方法により異なる。API または CLI を使用する場合、クロスゾーン負荷分散はデフォルトで無効化される。AWS Management Consoleを使用する場合、クロスゾーン負荷分散を有効にするオプションがデフォルトで選択される。

リクエストルーティング #

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

アプリケーションへのトラフィックが時間の経過とともに変化すると、ELB はロードバランサーをスケーリングして DNS エントリを更新する。DNS エントリは、60 秒の有効期限 (TTL) も指定する。これにより、トラフィックの変化に応じて IP アドレスを迅速に再マッピング可能。

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

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

• ALB

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

• NLB

  1. フローハッシュアルゴリズムを使用して、デフォルトルールのターゲットグループからターゲットを選択する。アルゴリズムは以下に基づきます。
     • プロトコル
     • 送信元 IP アドレスと送信元ポート
     • 送信先 IP アドレスと送信先ポート
     • TCP シーケンス番号
  2. 接続中、各 TCP 接続を単一のターゲットにルーティングする。クライアントからの TCP 接続のソースポートとシーケンス番号は異なり、別のターゲットにルーティング可能。

• CLB

  1. TCP リスナーのラウンドロビンルーティングアルゴリズムを使用する
  2. HTTP リスナーと HTTPS リスナーの最小未処理リクエストルーティングアルゴリズムを使用する

HTTP 接続 #

CLB は事前に開かれた接続(pre-open connections)¹を使用するが、ALB は使用しない。CLB と ALB はどちらも接続の多重化を使用する。つまり、複数のフロントエンド接続の複数のクライアントからのリクエストは、1 つのバックエンド接続を介して指定のターゲットにルーティング可能。接続の多重化により、レイテンシーが改善され、アプリケーションの負荷が低下する。接続の多重化を回避するには、HTTP レスポンスの keep-alives ヘッダーを設定して、HTTP Connection: close を無効にする。

ALB と CLB は、フロントエンド接続でパイプライン化された HTTP² をサポートする。バックエンド接続ではパイプライン化された HTTP をサポートしない。

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

デフォルトでは、ALB はバックエンド接続 (登録されたターゲットへのロードバランサー) で HTTP/1.1 を使用する。ただし、プロトコルバージョンを使用して、HTTP/2 または gRPC を使用するターゲットに要求を送信することが可能。

Keep-alive はデフォルトでバックエンド接続でサポートされている。ホストヘッダーを満たさないクライアントからの HTTP/1.0 リクエストの場合、ロードバランサーによりバックエンド接続で送信されたリクエストに対してHTTP/1.1ホストヘッダーを生成する。ホストヘッダーにはロードバランサーの DNS 名が含まれます。

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

HTTP ヘッダー #

ALB と CLB は、X-Forwarded-For、X-Forwarded-Proto、および X-Forwarded-Port ヘッダーを自動的にリクエストに追加する。

アプリケーションロードバランサは、HTTP ホストヘッダーのホスト名を小文字に変換してから、ターゲットに送信する。

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

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

ALB と CLB が Expect ヘッダーを受信すると、コンテンツ長ヘッダーをテストせずに HTTP 100 Continue でクライアントに即座に応答し、Expect ヘッダーを削除して、リクエストをルーティングする。

HTTP ヘッダーの制限 #

ALB の以下のサイズ制限は、変更できないハードリミットである。

• HTTP/1.x ヘッダー
  • リクエストライン: 16 K
  • 単一ヘッダー: 16 K
  • 総ヘッダー: 64 K
• HTTP/2 ヘッダー
  • リクエストライン: 16 K
  • 単一ヘッダー: 16 K
  • 総ヘッダー: 64 K

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

インターネットゲートウェイを介して送信されるトラフィックは 1500 MTU に制限される。パケットが 1500 バイト以上ある場合は、フラグメント化される。または、Don’t Fragment フラグが IP ヘッダーに設定されている場合は削除される。

ALB、NLB、または CLB ノードの MTU サイズは構成できない。ジャンボフレーム (MTU 9001) は、すべてのロードバランサーノードにおける標準である。パス MTU は、送信側ホストと受信側ホスト間のパスでサポートされている最大のパケットサイズである。2 つのデバイス間のパス MTU を判断するために、パス MTU 検出 (PMTUD) が使用される。パス MTU 検出は、クライアントまたはターゲットがジャンボフレームをサポートしていない場合に特に重要である。

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

クライアントまたはターゲットインターフェイスの MTU サイズより大きいパケットが引き続き削除される場合、Path MTU 検出 (PMTUD) が機能していない可能性がある。これを回避するには、Path MTU 検出がエンドツーエンドで動作していること、およびクライアントおよびターゲットでジャンボフレームを有効にしていることを確認する。

Amazon Web Services パターン別構築・運用ガイド 改訂第2版 amazon.co.jp