翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Application Load Balancer のターゲットグループ属性を編集する
Application Load Balancer のターゲットグループを作成すると、そのグループの属性を編集できます。
登録解除の遅延
ELB は、登録解除中のターゲットへのリクエストの送信を停止します。デフォルトでは、ELB は登録解除プロセスを完了するまで 300 秒待機します。これにより、ターゲットへの処理中のリクエストが完了するのに役立ちます。ELB が待機する時間を変更するには、登録解除遅延値を更新します。
登録解除するターゲットの初期状態は draining です。登録解除の遅延が経過すると、登録解除プロセスは完了し、ターゲットの状態は unused になります。ターゲットが Auto Scaling グループの一部である場合、ターゲットを終了して置き換えることができます。
登録解除ターゲットに進行中のリクエストがなく、アクティブな接続がない場合、ELB は登録解除の遅延が経過するのを待たずに、登録解除プロセスを直ちに完了します。ただし、ターゲットの登録解除が完了しても、ターゲットのステータスは、登録解除の遅延タイムアウトの期限が切れるまで draining と表示されます。タイムアウトの期限が切れると、ターゲットは unused 状態に移行します。
登録解除の遅延が経過する前に登録解除するターゲットが接続を終了すると、クライアントは 500 レベルのエラー応答を受信します。
ルーティングアルゴリズム
ルーティングアルゴリズムとは、ロードバランサーがリクエストを受信するターゲットを決定する際に使う方法です。ターゲットグループレベルのリクエストのルーティングには、ラウンドロビンのルーティングアルゴリズムがデフォルトで使用されます。アプリケーションのニーズに応じて最小の未処理のリクエストと加重ランダムのルーティングアルゴリズムも利用できます。ターゲットグループは一度に 1 つのアクティブなルーティングアルゴリズムしか使用できませんが、ルーティングアルゴリズムは必要に応じて更新が可能です。
スティッキーセッションを有効にすると、選択したルーティングアルゴリズムが最初のターゲット選択に使用されます。それ以降の同じクライアントからのリクエストは、同じターゲットに、選択したルーティングアルゴリズムをバイパスして転送されます。ターゲットオプティマイザを有効にしている場合、ルーティングアルゴリズムはラウンドロビンのみです。
ラウンドロビン
-
ラウンドロビンのルーティングアルゴリズムは、ターゲットグループ内の正常なターゲットにリクエストを均等かつ順番のとおりにルーティングします。
-
このアルゴリズムは、受信するリクエスト間で複雑さが類似している場合、登録されたターゲットの処理能力が類似している場合、またはターゲット間でリクエストを均等に分散する必要がある場合によく使用されます。
最小の未処理のリクエスト
-
最も未処理のリクエストのルーティングアルゴリズムは、進行中のリクエストの数が最も少ないターゲットにリクエストをルーティングします。
-
このアルゴリズムは通常、受信するリクエスト間で複雑さが異なり、登録されたターゲットの処理能力が異なる場合に使用されます。
-
HTTP/2 をサポートするロードバランサーが HTTP/1.1 のみをサポートするターゲットを使用している場合、リクエストは複数の HTTP/1.1 リクエストに変換されます。この設定では、最小の未処理のリクエストのアルゴリズムは、各 HTTP/2 リクエストを複数のリクエストとして扱います。
-
WebSockets を使用すると、ターゲットは最小の未処理のリクエストのアルゴリズムを使用して選択されます。ターゲットが選択された後、ロードバランサーはこのターゲットへの接続を作成して、すべてのメッセージをこの接続を介して送信します。
-
最小の未処理のリクエストのルーティングアルゴリズムは、スロースタートモードでは使用できません。
加重ランダム
-
加重ランダムのルーティングアルゴリズムは、ターゲットグループ内の正常なターゲットにリクエストを均等に、ランダムな順序でルーティングします。
-
このアルゴリズムは、自動ターゲット加重 (ATW) の異常緩和をサポートします。
-
加重ランダムのルーティングアルゴリズムは、スロースタートモードでは使用できません。
-
加重ランダムルーティングアルゴリズムは、スティッキーセッションでは使用できません。
スロースタートモード
デフォルトでは、ターゲットはターゲットグループを使用して登録され初期ヘルスチェックを渡した後、すぐにリクエストの全シェアを受信し始めます。スロースタートモードを使用すると、ロードバランサーがターゲットにリクエストの全シェアを送信し始めるまでの猶予期間が設定されます。
ターゲットグループのスロースタートを有効にした後、ターゲットグループによってそのターゲットが正常と見なされると、ターゲットはスロースタートモードになります。スロースタートモードのターゲットは、設定されたスロースタート期間が経過するか、ターゲットが異常になると、スロースタートモードを終了します。ロードバランサーは、スロースタートモードのターゲットに送信できるリクエスト数を直線的に増加させます。正常なターゲットがスロースタートモードを終了すると、ロードバランサーはリクエストの全シェアを送信できます。
考慮事項
-
ターゲットグループのスロースタートを有効にした時点で、ターゲットグループに登録されていた正常なターゲットは、スロースタートモードになりません。
-
空のターゲットグループでスロースタートを有効にし、その後、単一登録オペレーションを使用してターゲットを登録した場合、それらのターゲットはスロースタートモードになりません。新しく登録されたターゲットは、スロースタートモードになっていない正常なターゲットが 1 つ以上ある場合にのみ、スロースタートモードになります。
-
スロースタートモードのターゲットを登録解除すると、そのターゲットはスロースタートモードを終了します。同じターゲットを再度登録すると、ターゲットグループによって正常と見なされたときに、スロースタートモードになります。
-
スロースタートモードのターゲットが異常になった場合、ターゲットはスロースタートモードを終了します。ターゲットが正常になると、再びスロースタートモードになります。
-
[最小の未処理のリクエスト] または [加重ランダム] のルーティングアルゴリズムを使用するときは、スロースタートモードを有効にすることはできません。
ヘルス設定
デフォルトでは、Application Load Balancer はターゲットの状態をモニタリングし、リクエストを正常なターゲットにルーティングします。ただし、ロードバランサーに十分な正常なターゲットがない場合、登録されたすべてのターゲットにトラフィックが自動的に送信されます (フェイルオープン）。ターゲットグループのターゲットグループヘルス設定を変更して、DNS フェイルオーバーとルーティングフェイルオーバーのしきい値を定義できます。詳細については、「ターゲットグループの正常性」を参照してください。
クロスゾーンロードバランサー
ロードバランサーのノードは、クライアントからのリクエストを登録済みターゲットに分散させます。クロスゾーン負荷分散がオンの場合、各ロードバランサーノードは、登録されたすべてのアベイラビリティーゾーンにある登録済みターゲットに対し、トラフィックを分散します。クロスゾーン負荷分散がオフの場合、各ロードバランサーノードは、そのアベイラビリティーゾーン内で登録済みの各ターゲットにのみ、トラフィックを分散します。これは、正常なゾーンが異常なゾーンからの影響を受けないようにする、または全体的なレイテンシーを改善する目的で、リージョン範囲の障害があるドメインよりもゾーン範囲の障害があるドメインの方を優先したい場合などに使用します。
Application Load Balancer では、クロスゾーン負荷分散はロードバランサーレベルで常にオンになっており、オフにすることはできません。ターゲットグループに対しても、ロードバランサーの設定がデフォルトで使用されますが、クロスゾーン負荷分散をターゲットグループレベルで明示的にオフにすることで、デフォルト設定をオーバーライドできます。
考慮事項
-
クロスゾーン負荷分散がオフの場合、ターゲットに対するスティッキーなセッションはサポートされません。
-
クロスゾーン負荷分散がオフの場合、ターゲットとしての Lambda 関数はサポートされません。
-
いずれかのターゲットでパラメータ
AvailabilityZoneがallに設定されている場合に、ModifyTargetGroupAttributesAPI を介してクロスゾーン負荷分散をオフにしようとすると、エラーが発生します。 -
ターゲットの登録時は、
AvailabilityZoneパラメータは必須です。特定のアベイラビリティゾーン値は、クロスゾーン負荷分散がオフの場合にのみ使用できます。これ以外の場合、このパラメータは無視されallが適用されます。
ベストプラクティス
-
ターゲットグループごとに、使用する予定のすべてのアベイラビリティーゾーンで十分なターゲット容量を予約します。参加しているすべてのアベイラビリティーゾーンで十分な容量を確保できない場合は、クロスゾーン負荷分散をオンにしておくことをお勧めします。
-
Application Load Balancer で複数のターゲットグループを設定する場合には、すべてのターゲットグループが、設定されたリージョン内の同じアベイラビリティーゾーンに参加していることを確認してください。これにより、クロスゾーン負荷分散がオフの状態でアベイラビリティーゾーンが空になり、そのアベイラビリティーゾーンが受け取るすべての HTTP リクエストに対して、503 エラーが返されるようになるのを防ぎます
-
空のサブネットを作成することは避けます。空のサブネットに対しても、Application Load Balancer は、そのゾーン IP アドレスを DNS 経由で公開します。これにより、HTTP リクエストには 503 エラーが返されます。
-
クロスゾーン負荷分散がオフになっているターゲットグループで、アベイラビリティーゾーンごとに十分なターゲット容量が予約されているのにも関わらず、アベイラビリティーゾーンのすべてのターゲットに障害が発生することがあります。ターゲットのすべてが障害を起こしているターゲットグループが少なくとも 1 つある場合、対応するロードバランサーノードの IP アドレスは DNS から削除されます。ターゲットグループ内で、ターゲットが 1 つでも正常状態に復帰すると、対象の IP アドレスは DNS に復元されます。
クロスゾーン負荷分散をオフにする
Application Load Balancer のターゲットグループでは、クロスゾーン負荷分散を任意のタイミングでオフにできます。
クロスゾーン負荷分散をオンにする
Application Load Balancer のターゲットグループでは、クロスゾーン負荷分散を任意のタイミングでオンにできます。ターゲットグループレベルに対する、クロスゾーン負荷分散の設定は、ロードバランサーレベルの設定よりも優先されます。
自動ターゲット加重 (ATW)
自動ターゲット加重 (ATW) は、アプリケーションを実行しているターゲットを常時モニタリングして重大なパフォーマンスの偏差 (異常) を検出します。ATW は、リアルタイムで異常を検出することにより、ターゲットにルーティングされるトラフィックの量を動的に調整できます。
自動ターゲット加重 (ATW) は、アカウント内のすべての Application Load Balancer で異常検出を自動的に実行します。異常なターゲットが特定されると、ATW はルーティングされるトラフィックの量を減らす (異常緩和) ことによりそのターゲットの自動安定化を試みます。ATW は、ターゲットグループの失敗率を最小限に抑えながら、ターゲットごとの成功率を最大化するようにトラフィックの分散を継続的に最適化します。
考慮事項:
-
異常検出は、現在は、ターゲットからの HTTP 5xx レスポンスコードとターゲットへの接続失敗をモニタリングしています。異常検出は常時オンになっており、オフにすることはできません。
-
Lambda をターゲットとして使用している間は、ATW はサポートされません。
異常検出
ATW の異常検出は、ターゲットグループ内の他のターゲットのうち、動作において著しく大きな偏差を示すターゲットをモニタリングします。これらの偏差 (異常) は、1 つのターゲットのエラー率と、ターゲットグループ内の他のターゲットのエラー率とを比較することで判定されます。これらのエラーは、接続エラーの場合もあれば HTTP エラーコードである場合もあります。報告されたエラー率が他のターゲットよりも著しく高いターゲットは、異常と判断されます。
異常を検出するには、ターゲットグループ内に正常なターゲットが 3 つ以上必要です。ターゲットがターゲットグループに登録されたら、ヘルスチェックに合格して、トラフィックの受信を開始する必要があります。ターゲットがトラフィックの受信を開始すると、ATW がターゲットのモニタリングを開始し、異常検出結果を継続的に発行します。ターゲットに異常がない場合、異常検出結果は normal です。ターゲットに異常がある場合、異常検出結果は anomalous です。
ATW の異常検出はターゲットグループのヘルスチェックとは無関係に機能します。ターゲットは、ターゲットグループのすべてのヘルスチェックに合格していても、エラー率が高いために異常とマークされることがあります。ターゲットが異常となっていても、ターゲットグループのヘルスチェックのステータスには影響しません。
異常検出のステータス
現在の異常検出ステータスを表示できます。取り得る値には以下のものがあります。
-
normal– 異常は検出されませんでした。 -
anomalous– 異常が検出されました。
異常緩和
ATW の異常緩和は、異常なターゲットからトラフィックを自動的に避けてルーティングし、復旧を可能にします。
要件
ATW の異常緩和関数は、加重ランダムのルーティングアルゴリズムを使用する場合のみ使用できます。
緩和中、
-
ATW は、異常なターゲットにルーティングされるトラフィックの量を、定期的に調整します。現在、その間隔は 5 秒ごとです。
-
ATW は、異常なターゲットにルーティングされるトラフィックの量を、異常緩和の実行に必要な最小量まで削減します。
-
異常として検出されなくなったターゲットは、ターゲットグループ内の他の正常なターゲットと同等になるまで、ルーティングするトラフィックの量を徐々に増やしていきます。
緩和ステータス
ATW がターゲットに対して緩和を実行しているかどうかを確認できます。取り得る値には以下のものがあります。
yes– 緩和は進行中です。no– 緩和は進行中ではありません。
スティッキーセッション
デフォルトでは、Application Load Balancer は、選択したロードバランシングアルゴリズムに基づいて、登録されたターゲットに各リクエストを個別にルーティングします。ただし、スティッキーセッション機能 (セッションアフィニティとも呼ばれます) を使用して、ロードバランサーがユーザーのセッションを特定のターゲットにバインドするように設定できます。これにより、ユーザーのセッション中のすべてのリクエストが同じターゲットに送信されます。これは、クライアントに連続したエクスペリエンスを提供するために状態情報を維持するサーバーに役立ちます。スティッキーセッションを使用するには、クライアントが Cookie をサポートする必要があります。
Application Load Balancer は、期間ベースの Cookie とアプリケーションベースの Cookie の両方をサポートします。ターゲットグループレベルでスティッキーセッションを有効にします。ターゲットグループで、期間ベースの維持、アプリケーションベースの維持、および維持しないの組み合わせを使用できます。
スティッキーセッションの管理において重要なのは、ロードバランサーがユーザーのリクエストを同じターゲットに一貫してルーティングする期間の決定です。アプリケーションに独自のセッション Cookie がある場合は、アプリケーションベースの維持を使用でき、ロードバランサーのセッション Cookie は、アプリケーションのセッション Cookie で指定された期間に従います。アプリケーションに独自のセッション Cookie がない場合、期間ベースの維持を使用して、指定した期間を持つロードバランサーセッション Cookie を生成できます。
ロードバランサーが生成した Cookie の内容は、回転キーを使用して暗号化されます。ロードバランサーが生成した Cookie を復号化または変更することはできません。
どの維持の種類でも、Application Load Balancer はリクエストごとに生成する Cookie の有効期限をリセットします。Cookie の有効期限が切れると、セッションは維持できなくなり、クライアントは Cookie ストアから Cookie を削除する必要があります。
要件
-
HTTP/HTTPS ロードバランサー。
-
各アベイラビリティーゾーンに少なくとも 1 つの正常なインスタンスがあること。
考慮事項
-
クロスゾーン負荷分散が無効な場合、スティッキーセッションはサポートされません。クロスゾーン負荷分散が無効なときにスティッキーセッションを有効にしようとしてもできません。
-
アプリケーションベースの Cookie の場合、ターゲットグループごとに Cookie 名を個別に指定する必要があります。ただし、期間ベースの Cookie の場合、
AWSALBはすべてのターゲットグループで使用される唯一の名前です。 -
Application Load Balancers の複数のレイヤーを使用している場合、アプリケーションベースの Cookie を使用して、すべてのレイヤーでスティッキーセッションを有効にできます。ただし、期間ベースの Cookie の場合、
AWSALBが使用可能な唯一の名前であるため、1 つのレイヤーでのみスティッキーセッションを有効にできます。 -
Application Load Balancer が期間ベースの維持設定 Cookie である
AWSALBCORSとAWSALBの両方を受け取っている場合、AWSALBCORSの値が優先されます。 -
アプリケーションベースの維持は、加重ターゲットグループでは動作しません。
-
複数のターゲットグループを含む転送アクションがあり、1 つ以上のターゲットグループでスティッキーセッションが有効になっている場合、ターゲットグループレベルの維持を有効にする必要があります。
-
WebSocket 接続は本来はスティッキーです。クライアントが WebSockets へ接続アップグレードをリクエストする場合、接続アップグレードを受け入れるために HTTP 101 のステータスコードを返したターゲットが、WebSockets 接続で使用されるターゲットです。WebSockets のアップグレードが完了したら、Cookie ベースの維持は使用されません。
-
Application Load Balancer は
Max-Age属性の代わりに Cookie ヘッダーのExpires属性を使用します。 -
Application Load Balancer は、URL エンコードされた Cookie 値をサポートしていません。
-
登録解除によるターゲットのドレイン中に Application Load Balancer が新しいリクエストを受信すると、リクエストは正常なターゲットにルーティングされます。
-
ターゲットオプティマイザが有効になっている場合、スティッキーセッションはサポートされていません。
スティッキータイプ
期間ベースの維持
期間ベースの維持は、ロードバランサーが生成した Cookie (AWSALB) を使用して、ターゲットグループ内の同じターゲットにリクエストをルーティングします。 Cookie は、セッションをターゲットにマッピングするために使用します。アプリケーションに独自のセッション Cookie がない場合、独自の維持期間を指定し、ロードバランサーがユーザーのリクエストを同じターゲットに一貫してルーティングする期間を管理できます。
ロードバランサーは、クライアントから最初のリクエストを受信すると、選択したアルゴリズムに基づいてリクエストをターゲットにルーティングし、AWSALB という名前の Cookie を生成します。これは、選択したターゲットに関する情報をエンコードしてCookie を暗号化し、クライアントへの応答に Cookie を含めます。ロードバランサーが生成した cookie には 7 日間の有効期限がありますが、これは設定できません。
後続のリクエストでは、クライアントは AWSALB Cookie を含める必要があります。ロードバランサーは Cookie を含むクライアントからリクエストを受信すると、それを検出し、同じターゲットにリクエストをルーティングします。Cookie は存在するがデコードできない場合、あるいは登録解除されたターゲットまたは異常なターゲットを参照している場合、ロードバランサーは新しいターゲットを選択し、新しいターゲットに関する情報で Cookie を更新します。
クロスオリジンリソース共有 (CORS) リクエストの場合、一部のブラウザは維持を有効にするために SameSite=None; Secure を要求します。こうしたブラウザをサポートするため、ロードバランサーは常に 2 番目の維持設定 Cookie である AWSALBCORS を生成します。この Cookie には元の維持設定 Cookie と同じ情報に加えて SameSite 属性も含まれます。クライアントは、CORS 以外のリクエストを含む両方の Cookie を受け取ります。
アプリケーションベースの維持
アプリケーションベースの維持では、クライアントターゲットの維持の独自の条件を設定できます。アプリケーションベースの維持を有効にすると、ロードバランサーは、選択したアルゴリズムに基づいてターゲットグループ内のターゲットに最初のリクエストをルーティングします。ターゲットは維持を有効にするために、ロードバランサーで設定した Cookie と一致するカスタムアプリケーション Cookie を設定することが想定されています。このカスタム Cookie には、アプリケーションが要求する Cookie 属性を含めることができます。
Application Load Balancer は、ターゲットからカスタムアプリケーション Cookie を受信すると、持続性情報をキャプチャする新しい暗号化アプリケーション Cookie を自動的に生成します。このロードバランサーが生成するアプリケーション Cookie は、アプリケーションベースの持続性が有効になっている各ターゲットグループの持続性情報をキャプチャします。
ロードバランサーが生成するアプリケーション Cookie は、ターゲットが設定するカスタムアプリケーション Cookie の属性をコピーしません。それには独自の 7 日の有効期限があり、設定できません。クライアントへの応答では、Application Load Balancer は、カスタム Cookie がターゲットグループレベルで設定された際に使用された名前のみが検証され、そのカスタム Cookie の値または有効期限属性は検証されません。名前が一致している限り、ロードバランサーは、ターゲットによって設定されたカスタム Cookie とロードバランサーによって生成されたアプリケーション Cookie の両方をクライアントへの応答で送信します。
後続のリクエストでは、クライアントは維持しておくために両方の Cookie を返送する必要があります。ロードバランサーは、アプリケーション Cookie を復号し、設定した持続期間がまだ有効かどうかを確認します。次に、Cookie 内の情報を使用して、ターゲットグループ内の同じターゲットにリクエストを送信し、維持しておきます。また、ロードバランサーは、カスタムアプリケーション Cookie を検査または変更することなく、ターゲットにプロキシします。それ以降の応答では、ロードバランサーが生成したアプリケーション Cookie の有効期限と、ロードバランサーで設定された持続期間がリセットされます。クライアントとターゲット間の持続性を維持するため、Cookie の有効期限と持続時間が経過しないようにします。
ターゲットが失敗した場合または異常が発生した場合、ロードバランサーはそのターゲットへのリクエストのルーティングを停止し、選択した負荷分散アルゴリズムに基づいて、新しい正常なターゲットを選択します。ロードバランサーは、セッションを新しい正常なターゲットに「スタック」しているものとして処理し、失敗したターゲットが戻った場合でも、新しい正常なターゲットへのリクエストのルーティングを続行します。
クロスオリジンリソース共有 (CORS) リクエストの場合、持続性を有効にするために、ロードバランサーはユーザーエージェントのバージョンが Chromium80 以上の場合にのみ SameSite=None; Secure 属性をロードバランサーが生成するアプリケーション Cookie に追加します。
ほとんどのブラウザは Cookie のサイズを 4K に制限しているため、ロードバランサーは 4K を超えるアプリケーション Cookie を複数の Cookie にシャードします。Application Load Balancer は、最大 16K のサイズの Cookie をサポートするため、クライアントに送信するシャードを最大 4 つ作成できます。クライアントが認識するアプリケーション Cookie 名は「AWSALBAPP-」で始まり、フラグメント番号が含まれています。例えば、Cookie のサイズが 0～4K の場合、クライアントは AWSALBAPP-0 を認識します。Cookie のサイズが 4～8k の場合、クライアントは AWSALBAPP-0 と AWSALBAPP-1 を認識します。
手動再分散
スケールアップ時にターゲット数が大幅に増加すると、維持による負荷の分散が不均等になる可能性があります。このシナリオでは、次の 2 つのオプションを使用して、ターゲットの負荷を再分散できます。
-
アプリケーションが生成した Cookie に現在の日付と時刻より前の有効期限を設定します。これにより、クライアントが Application Load Balancer に Cookie を送信できなくなり、維持の確立プロセスが再開されます。
-
ロードバランサーのアプリケーションベースの維持設定で、1 秒など短い時間を設定します。これにより、ターゲットが設定した Cookie の有効期限が切れていない場合でも、Application Load Balancer は維持を再確立します。
