Study for SAA-C02: ELB - Application Load Balancer

Application Load Balancer とは? #

ALB のコンポーネント #

ロードバランサー #

クライアントにとって単一の通信先として機能する。 受信アプリケーショントラフィックを複数のアベイラビリティーゾーンの複数のターゲット(EC2 インスタンスなど) に分散する。これにより、アプリケーションの可用性が向上する。ロードバランサーに 1 つ以上のリスナーを追加可能。

リスナー #

設定したプロトコルとポートを使用して、クライアントからの接続リクエストをチェックする。リスナーに対して定義したルールにより、ロードバランサーが登録済みターゲットにリクエストをルーティングする方法が決まる。各ルールは優先度、1 つ以上のアクション、および 1 つ以上の条件で構成されている。ルールの条件が満たされると、アクションが実行される。リスナーごとにデフォルトのルールを定義する必要があり、オプションで追加のルールを定義可能。

ターゲットグループ #

指定されたプロトコルとポート番号を使用して、1 つ以上の登録済みのターゲット (EC2 インスタンスなど) にリクエストをルーティング可能。1 つのターゲットを複数のターゲットグループに登録可能。ターゲットグループ単位でヘルスチェックを設定可能。ヘルスチェックは、ロードバランサーのリスナールールに指定されたターゲットグループに登録されたすべてのターゲットで実行される。

ALB の概要 #

ALB は、開放型システム間相互接続 (OSI) モデルの第 7 層であるアプリケーションレイヤーで機能する。ロードバランサーはリクエストを受信すると、優先度順にリスナールールを評価して適用するルールを決定し、ルールアクションのターゲットグループからターゲットを選択する。リスナールールを構成し、アプリケーショントラフィックのコンテンツに基づいて異なるターゲットグループにリクエストをルーティング可能。それぞれのターゲットグループでルーティングは個別に実行され、複数のターゲットグループに登録されているターゲットの場合も同じ。ターゲットグループレベルで使用するルーティングアルゴリズムを設定可能。デフォルトのルーティングアルゴリズムはラウンドロビンである。代わりに最小の未処理のリクエストを指定することも可能。

アプリケーションへのリクエストの流れを中断することなく、ニーズの変化に応じてロードバランサーに対してターゲットの追加と削除を行うことが可能。ELB はアプリケーションへのトラフィックが時間の経過とともに変化するのに応じてロードバランサーをスケーリングする。ELB では、大半のワークロードに合わせた自動的なスケーリングが可能である。

登録済みのインスタンスのヘルス状態をモニタリングするために使用されるヘルスチェックを設定することで、ロードバランサーは正常なターゲットにのみリクエストを送信可能。

ロードバランサー #

ロードバランサーのサブネット #

ALB を作成するときは、アベイラビリティーゾーン、ローカルゾーン、または Outpost のいずれかのタイプのサブネットを指定する必要がある。

アベイラビリティーゾーン #

少なくとも 2 つのアベイラビリティーゾーンサブネットを選択する必要がある。以下の制限が適用される。

• それぞれのサブネットは、異なるアベイラビリティーゾーンに属している必要がある。
• ロードバランサーが正しくスケールできるように、ロードバランサーのアベイラビリティーゾーンサブネットごとに CIDR ブロックを最低でも /27 ビットマスク (例: 10.0.0.0/27) にし、少なくとも各サブネットにつき 8 個の空き IP アドレスを用意する。ロードバランサーはこれらの IP アドレスを使用して、ターゲットとの接続を確立する。トラフィックプロファイルに応じて、ロードバランサーは拡張でき、すべての有効なサブネットに分散された最大 100 個の IP アドレスを消費できる。

Local Zones #

1 つ以上のローカルゾーンサブネットを指定できる。以下の制限が適用される。

• ロードバランサーで AWS WAF を使用することはできない。
• Lambda 関数をターゲットとして使用することはできない。

Outposts #

1 つの Outpost サブネットを指定できる。

ロードバランサーのセキュリティグループ #

セキュリティグループは、ロードバランサーとの間で許可されているトラフィックを制御するファイアウォールとして機能する。インバウンドトラフィックとアウトバウンドトラフィックの両方を許可するポートとプロトコルを選択できる。

ロードバランサーに関連付けられたセキュリティグループのルールは、リスナーポートとヘルスチェックポートの両方における両方向のトラフィックを許可する必要がある。

IP アドレスタイプ #

インターネット向けや内部のロードバランサーへのアクセスにクライアントが使用できる IP アドレスのタイプは、ユーザーが設定できる。

• ipv4
  • クライアントは IPv4 アドレス (192.0.2.1 など) を使用してロードバランサーに接続する必要がある。
• dualstack
  • クライアントは、IPv4 アドレス (192.0.2.1 など) と IPv6 アドレス (たとえば、2001:0db8:85a3:0:0:8a2e:0370:7334) の両方を使用してロードバランサーに接続できる。

接続のアイドルタイムアウト #

クライアントがロードバランサーを通じて行うリクエストごとに、ロードバランサーは 2 つの接続を維持する。

• フロントエンド接続は、クライアントとロードバランサーの間にある。
• バックエンド接続は、ロードバランサーとターゲットの間です。

ロードバランサーには、その接続に適用される設定済みのアイドルタイムアウト期間がある。アイドルタイムアウトが経過するまでデータが送受信されなかった場合、ロードバランサーは接続を閉じる。ファイルのアップロードなどの長いオペレーションで、完了までの時間を確保するため、各アイドルタイムアウト期間が経過するまでに少なくても 1 バイトのデータを送信し、必要に応じてアイドルタイムアウトの長さを増やす。

バックエンド接続では EC2 インスタンスで HTTP キープアライブオプションを有効にすることが推奨される。EC2 インスタンスのウェブサーバー設定で HTTP キープアライブを有効にできる。HTTP キープアライブを有効にすると、ロードバランサーはキープアライブのタイムアウト期間が終了するまで、バックエンド接続を再利用できる。また、アプリケーションのアイドルタイムアウトは、ロードバランサーに設定されたアイドルタイムアウトよりも大きな値に設定することを推奨。アプリケーションがロードバランサーへの TCP 接続を正常に閉じない場合、ロードバランサーは、接続が閉じられたことを示すパケットを受信する前に、アプリケーションにリクエストを送信することがある。この場合、サーバーはロードバランサーからのリクエストを拒否し、ロードバランサーは HTTP 502 Bad Gateway エラーをアプリケーションに送信する。

Elastic Load Balancing では、ロードバランサーのアイドルタイムアウト値はデフォルトで 60 秒に設定されている。

削除保護 #

ロードバランサーが誤って削除されるのを防ぐため、削除保護を有効にできる。デフォルトでは、ロードバランサーで削除保護が無効になっている。

desync 軽減モード #

Desync 軽減モードは、HTTP Desync¹ に伴う問題からアプリケーションを保護する。ロードバランサーは、脅威レベルに基づいて各リクエストを分類する。安全なリクエストは許可し、指定した軽減モードで指定されたリスクに対しては軽減処理を行いる。

• desync 軽減モードの種類
  • モニタリングモード
  • 防御モード(default)
    • アプリケーションの可用性を維持しながら、HTTP Desync に対する永続的な軽減を提供する。
  • 厳密モード。
    • RFC 7230 に準拠するリクエストだけを受信できる。

ALB のリスナー #

ALB の使用を開始する前に、1 つまたは複数のリスナーを追加する必要がある。リスナーとは、設定したプロトコルとポートを使用して接続リクエストをチェックするプロセス。リスナーに対して定義したルールにより、ロードバランサーが登録済みターゲットにリクエストをルーティングする方法が決まる。

リスナーの設定 #

リスナーは次のポートとプロトコルをサポートする。

• プロトコル: HTTP、HTTPS
• ポート: 1 ～ 65535

HTTPS リスナーを使用して、暗号化および復号の作業をロードバランサーに任せることができる。リスナープロトコルが HTTPS の場合は、リスナーに SSL サーバー証明書を少なくとも 1 つデプロイする必要がある。

ALB は WebSocket のネイティブ サポートを提供する。HTTP 接続のアップグレードを使用して、既存の HTTP/1.1 接続を WebSocket (ws または wss) 接続にアップグレードできる。アップグレードすると、リクエストに使用される TCP 接続 (ロードバランサーとターゲットへの) は、ロードバランサーを介したクライアントとターゲット間の永続的な WebSocket 接続になる。WebSocket は、HTTP リスナーと HTTPS リスナーの両方で使用できる。リスナーに対して選択したオプションは、HTTP トラフィックだけでなく、WebSocket 接続にも適用される。

ALB は HTTPS リスナーで HTTP/2 のネイティブサポートを提供する。1 つの HTTP/2 コネクションで最大 128 のリクエストを並行して送信できる。プロトコルバージョンを使用して、HTTP/2 を使用するターゲットに要求を送信することができる。HTTP/2 ではフロントエンド接続を効率的に使用するため、クライアントとロードバランサー間の接続数が減少する。HTTP/2 のサーバープッシュ機能は使用できない。

リスナールール #

各リスナーにはデフォルトのルールがあり、オプションで追加のルールを定義できる。各ルールは優先度、1 つ以上のアクション、および 1 つ以上の条件で構成されている。ルールの追加や編集はいつでも行うことができる。

リスナーを作成するときは、デフォルトのルールのアクションを定義する。デフォルトのルールに条件を定義することはできない。リスナーのルールに設定された条件のいずれも満たされない場合は、デフォルトのルールのアクションが実行される。

ルールの優先順位 #

各ルールには優先順位がある。ルールは優先順位の低~高順によって評価される。デフォルトのルールが最後に評価される。デフォルト以外のルールは、優先順位をいつでも変更できる。デフォルトルールの優先順位は変更できない。

ルールのアクション #

ルールのアクションごとにタイプ、順序、およびアクションを実行するために必要な情報がある。

• 固定レスポンスアクション
  • クライアントリクエストを破棄し、カスタムの HTTP レスポンスを返すには、fixed-response アクションを使用する。このアクションを使用して、2XX、4XX、または 5XX のレスポンスコードとオプションのメッセージを返すことができる。
• 転送アクション
  • forward アクションを使用して、1 つ以上のターゲットグループにリクエストをルーティングできる。forward アクションに複数のターゲットグループを指定する場合は、ターゲットグループごとに重みを指定する必要がある。各ターゲットグループの重みは、0～999 の値。加重ターゲットグループを持つリスナールールと一致するリクエストは、それらの重みに基づいてこれらのターゲットグループに分散される。たとえば、ターゲットグループを 2 つ指定し、それぞれ重みが 10 の場合、各ターゲットグループはリクエストの半分を受け取る。2 つのターゲットグループ (1 つは重みが 10 で、もう 1 つは重みが 20) を指定すると、重みが 20 のターゲットグループは他のターゲットグループの 2 倍の数のリクエストを受信する。
• リダイレクトアクション
  • クライアントリクエストを別の URL にリダイレクトするには、redirect アクションを使用する。必要に応じて、一時的 (HTTP 302) または恒久的 (HTTP 301) としてリダイレクトを設定する。

ルールの条件のタイプ #

• HTTP ヘッダー条件
  • HTTP ヘッダー条件を使用して、リクエストの HTTP ヘッダーに基づいてリクエストをルーティングするルールを設定できる。
  • 標準またはカスタムの HTTP ヘッダーフィールドの名前を指定できる。
  • ヘッダー名と一致評価では大文字と小文字は区別されない。
  • 次のワイルドカード文字は比較文字列でサポートされている。* (0 個以上の文字と一致) および ? (厳密に 1 文字と一致）
  • ワイルドカード文字はヘッダー名ではサポートされていない。
• HTTP リクエストメソッド条件
  • HTTP リクエストメソッド条件を使用して、リクエストの HTTP リクエストメソッドに基づいてリクエストをルーティングするルールを設定できる。
  • 標準またはカスタムの HTTP メソッドを指定できる。
  • 一致評価は大文字と小文字を区別する。
  • ワイルドカード文字はサポートされていない。
  • HEAD リクエストに対する応答はキャッシュされる可能性があるため、GET リクエストと HEAD リクエストを同じ方法でルーティングすることを推奨。
• ホストの条件
  • ホストの条件を使用して、ホストヘッダーのホスト名に基づいてリクエストをルーティングする (ホストベースのルーティングとも呼ばれる) ルールを定義できる。これにより、1 つのロードバランサーを使用して複数のサブドメインおよび異なるトップレベルドメインをサポートできる。
• パスの条件
  • パスの条件を使用して、リクエスト内の URL に基づいてリクエストをルーティングするルールを定義できる (パスベースのルーティングとも呼ばれる)。
  • パスパターンは URL のパスにのみ適用され、クエリパラメータには適用されない。表示可能な ASCII 文字にのみ適用される。制御文字 (0x00 ～ 0x1f および 0x7f) は除外される。
• クエリ文字列の条件
  • クエリ文字列の条件を使用して、キー/値のペアまたはクエリ文字列内の値に基づいてリクエストをルーティングするルールを設定できる。
  • 一致評価では大文字と小文字は区別されない。
  • 次のワイルドカード文字はサポートされている。* (0 個以上の文字と一致) および ? (厳密に 1 文字と一致)
• 送信元 IP アドレス条件
  • 送信元 IP アドレス条件を使用して、リクエストの送信元 IP アドレスに基づいてリクエストをルーティングするルールを設定できる。
  • IP アドレスは CIDR 形式で指定する必要がある。
  • IPv4 と IPv6 の両方のアドレスを使用できる。
  • ワイルドカード文字はサポートされていない。
  • 送信元 IP ルール条件に 255.255.255.255/32 CIDR を指定することはできない。

HTTP ヘッダー #

次の X-Forwarded ヘッダーがサポートされる。

• X-Forwarded-For
• X-Forwarded-Proto
• X-Forwarded-Port

ターゲットグループ #

各ターゲットグループは、1 つ以上の登録されているターゲットにリクエストをルーティングするために使用される。各リスナーのルールを作成するときに、ターゲットグループと条件を指定する。ルールの条件が満たされると、トラフィックが該当するターゲットグループに転送される。さまざまなタイプのリクエストに応じて別のターゲットグループを作成できる。たとえば、一般的なリクエスト用に 1 つのターゲットグループを作成し、アプリケーションのマイクロサービスへのリクエスト用に別のターゲットグループを作成できる。

ロードバランサーのヘルスチェック設定は、ターゲットグループ単位で定義する。各ターゲットグループはデフォルトのヘルスチェック設定を使用する。ただし、ターゲットグループを作成したときや、後で変更したときに上書きした場合を除く。リスナーのルールでターゲットグループを指定すると、ロードバランサーは、ロードバランサーで有効なアベイラビリティーゾーンにある、ターゲットグループに登録されたすべてのターゲットの状態を継続的にモニタリングする。ロードバランサーは、正常な登録済みターゲットにリクエストをルーティングする。

ルーティング設定 #

• プロトコル: HTTP、HTTPS
• ポート: 1 ～ 65535

ターゲットタイプ #

• instance
• ip
  • パブリックにルーティング可能な IP アドレスは指定できない。
• lambda

IP アドレスタイプ #

• IPv4
• IPv6

プロトコルバージョン #

• HTTP/1.1 (default)
• HTTP/2
• gRPC

登録済みターゲット #

ターゲットグループの属性 #

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

• ラウンドロビン(default)
• 最小未処理リクエスト
  • アプリケーションのリクエストの複雑さに差がある場合や、ターゲットの処理能力に差がある場合

登録解除の遅延 #

スロースタートモード #

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

期間ベースの Cookie とアプリケーションベースの Cookie の両方をサポートする。ターゲットグループレベルでスティッキーセッションを有効にする。ターゲットグループで、期間ベースの維持、アプリケーションベースの維持、および維持しないの組み合わせを使用できる。

期間ベースの維持 #

• ロードバランサーが生成した Cookie (AWSALB) を使用
• クロスオリジンリソース共有 (CORS) リクエストの場合、一部のブラウザは維持を有効にするために SameSite=None; Secure を要求する。この場合、ロードバランサーは は 2 番目の維持 Cookie である AWSALBCORS を生成する。この Cookie は、元の維持 Cookie と同じ情報に加えて SameSite 属性を含む。クライアントは両方の Cookie を受け取る。
• 1 秒から 7 日の間の値を指定

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