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

Application Load Balancer のターゲットグループ属性を編集する

Application Load Balancer のターゲットグループを作成すると、そのグループの属性を編集できます。

登録解除の遅延

Elastic Load Balancing は、登録解除するターゲットへのリクエストの送信を停止します。デフォルトでは、Elastic Load Balancing 登録解除プロセスを完了する前に 300 秒待って、ターゲットへ処理中のリクエストが完了するのを助けることができます。Elastic Load Balancing が待機する時間を変更するには、登録解除の遅延値を更新します。

登録解除するターゲットの初期状態は draining です。登録解除の遅延が経過すると、登録解除プロセスは完了し、ターゲットの状態は unused になります。ターゲットが Auto Scaling グループの一部である場合、ターゲットを終了して置き換えることができます。

登録解除するターゲットに未処理のリクエストやアクティブな接続がない場合は、Elastic Load Balancing は登録解除の遅延時間が経過するのを待たずに、即時登録解除プロセスを完了します。ただし、ターゲットの登録解除が完了しても、ターゲットのステータスは、登録解除の遅延タイムアウトの期限が切れるまで draining と表示されます。タイムアウトの期限が切れると、ターゲットは unused 状態に移行します。

登録解除の遅延が経過する前に登録解除するターゲットが接続を終了すると、クライアントは 500 レベルのエラー応答を受信します。

を使用して登録解除の遅延値を更新するには AWS CLI

deregistration_delay.timeout_seconds 属性を指定して modify-target-group-attributes コマンドを使用します。

スロースタートモード

デフォルトでは、ターゲットはターゲットグループを使用して登録され初期ヘルスチェックを渡した後、すぐにリクエストの全シェアを受信し始めます。スロースタートモードを使用すると、ロードバランサーがターゲットにリクエストの全シェアを送信し始めるまでの猶予期間が設定されます。

ターゲットグループのスロースタートを有効にした後、ターゲットグループによってそのターゲットが正常と見なされると、ターゲットはスロースタートモードになります。スロースタートモードのターゲットは、設定されたスロースタート期間が経過するか、ターゲットが異常になると、スロースタートモードを終了します。ロードバランサーは、スロースタートモードのターゲットに送信できるリクエスト数を直線的に増加させます。正常なターゲットがスロースタートモードを終了すると、ロードバランサーはリクエストの全シェアを送信できます。

を使用してスロースタート期間の値を更新するには AWS CLI

slow_start.duration_seconds 属性を指定して modify-target-group-attributes コマンドを使用します。

Application Load Balancer のターゲットグループのクロスゾーン負荷分散

ロードバランサーのノードは、クライアントからのリクエストを登録済みターゲットに分散させます。クロスゾーン負荷分散がオンの場合、各ロードバランサーノードは、登録されたすべてのアベイラビリティーゾーンにある登録済みターゲットに対し、トラフィックを分散します。クロスゾーン負荷分散がオフの場合、各ロードバランサーノードは、そのアベイラビリティーゾーン内で登録済みの各ターゲットにのみ、トラフィックを分散します。これは、正常なゾーンが異常なゾーンからの影響を受けないようにする、または全体的なレイテンシーを改善する目的で、リージョン範囲の障害があるドメインよりもゾーン範囲の障害があるドメインの方を優先したい場合などに使用します。

Application Load Balancer では、クロスゾーン負荷分散はロードバランサーレベルで常にオンになっており、オフにすることはできません。ターゲットグループに対しても、ロードバランサーの設定がデフォルトで使用されますが、クロスゾーン負荷分散をターゲットグループレベルで明示的にオフにすることで、デフォルト設定をオーバーライドできます。

クロスゾーン負荷分散をオフにする

Application Load Balancer のターゲットグループでは、クロスゾーン負荷分散を任意のタイミングでオフにできます。

を使用してクロスゾーン負荷分散を無効にするには AWS CLI

load_balancing.cross_zone.enabled 属性を false に設定しながら、modify-target-group-attributes コマンドを実行します。

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=false

以下に、応答の例を示します。

{
    "Attributes": [
        {
            "Key": "load_balancing.cross_zone.enabled",
            "Value": "false"
        },
    ]
}

クロスゾーン負荷分散をオンにする

Application Load Balancer のターゲットグループでは、クロスゾーン負荷分散を任意のタイミングでオンにできます。ターゲットグループレベルに対する、クロスゾーン負荷分散の設定は、ロードバランサーレベルの設定よりも優先されます。

を使用してクロスゾーン負荷分散を有効にするには AWS CLI

load_balancing.cross_zone.enabled 属性を true に設定しながら、modify-target-group-attributes コマンドを実行します。

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=true

以下に、応答の例を示します。

{
    "Attributes": [
        {
            "Key": "load_balancing.cross_zone.enabled",
            "Value": "true"
        },
    ]
}

自動ターゲット加重 (ATW)

自動ターゲット加重 (ATW) は、アプリケーションを実行しているターゲットを常時モニタリングして重大なパフォーマンスの偏差 (異常) を検出します。ATW は、リアルタイムで異常を検出することにより、ターゲットにルーティングされるトラフィックの量を動的に調整できます。

自動ターゲット加重 (ATW) は、アカウント内のすべての Application Load Balancer で異常検出を自動的に実行します。異常なターゲットが特定されると、ATW はルーティングされるトラフィックの量を減らす (異常緩和) ことによりそのターゲットの自動安定化を試みます。ATW は、ターゲットグループの失敗率を最小限に抑えながら、ターゲットごとの成功率を最大化するようにトラフィックの分散を継続的に最適化します。

異常検出

ATW の異常検出は、ターゲットグループ内の他のターゲットのうち、動作において著しく大きな偏差を示すターゲットをモニタリングします。これらの偏差 (異常) は、1 つのターゲットのエラー率と、ターゲットグループ内の他のターゲットのエラー率とを比較することで判定されます。これらのエラーは、接続エラーの場合もあれば HTTP エラーコードである場合もあります。報告されたエラー率が他のターゲットよりも著しく高いターゲットは、異常と判断されます。

異常を検出するには、ターゲットグループ内に正常なターゲットが 3 つ以上必要です。ターゲットがターゲットグループに登録されたら、まずヘルスチェックに合格して、トラフィックの受信を開始する必要があります。ターゲットがターゲットを受信すると、ATW がターゲットのモニタリングを開始し、異常検出結果を継続的に発行します。ターゲットに異常がない場合、異常検出結果は normal です。ターゲットに異常がある場合、異常検出結果は anomalous です。

ATW の異常検出はターゲットグループのヘルスチェックとは無関係に機能します。ターゲットは、ターゲットグループのすべてのヘルスチェックに合格していても、エラー率が高いために異常とマークされることがあります。ターゲットが異常となっていても、ターゲットグループのヘルスチェックのステータスには影響しません。

異常検出のステータス

ATW は、ターゲットに対して実行する異常検出のステータスを継続的に発行します。現在のステータスは、 AWS Management Console または を使用していつでも表示できます AWS CLI。

を使用して異常検出結果を表示するには AWS CLI

describe-target-health コマンドを、Include.member.N 属性値を AnomalyDetection に設定した上で使用します。

異常緩和

ATW の異常緩和は、異常なターゲットからトラフィックを自動的に避けてルーティングし、復旧を可能にします。

ATW 異常緩和をオンにする

異常緩和はいつでもオンにできます。

を使用して異常緩和を有効にするには AWS CLI

load_balancing.algorithm.anomaly_mitigation 属性を指定して modify-target-group-attributes コマンドを使用します。

異常緩和のステータス

ATW がターゲットに対して緩和を実行するたびに、 AWS Management Console または を使用していつでも現在のステータスを表示できます AWS CLI。

を使用して異常緩和ステータスを表示するには AWS CLI

describe-target-health コマンドを、Include.member.N 属性値を AnomalyDetection に設定した上で使用します。

Application Load Balancer のスティッキーセッション

デフォルトでは、Application Load Balancer は、選択したロードバランシングアルゴリズムに基づいて、登録されたターゲットに各リクエストを個別にルーティングします。ただし、スティッキーセッション機能 (セッションアフィニティとも呼ばれます) を使用して、ロードバランサーがユーザーのセッションを特定のターゲットにバインドするように設定できます。これにより、ユーザーのセッション中のすべてのリクエストが同じターゲットに送信されます。これは、クライアントに連続したエクスペリエンスを提供するために状態情報を維持するサーバーに役立ちます。スティッキーセッションを使用するには、クライアントが Cookie をサポートする必要があります。

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

スティッキーセッションの管理において重要なのは、ロードバランサーがユーザーのリクエストを同じターゲットに一貫してルーティングする期間の決定です。アプリケーションに独自のセッション Cookie がある場合は、アプリケーションベースの維持を使用でき、ロードバランサーのセッション Cookie は、アプリケーションのセッション Cookie で指定された期間に従います。アプリケーションに独自のセッション Cookie がない場合、期間ベースの維持を使用して、指定した期間を持つロードバランサーセッション Cookie を生成できます。

ロードバランサーが生成した Cookie の内容は、回転キーを使用して暗号化されます。ロードバランサーが生成した Cookie を復号化または変更することはできません。

どの維持の種類でも、Application Load Balancer はリクエストごとに生成する Cookie の有効期限をリセットします。Cookie の有効期限が切れると、セッションは維持できなくなり、クライアントは Cookie ストアから Cookie を削除する必要があります。

期間ベースの維持

期間ベースの維持は、ロードバランサーが生成した 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 を受け取ります。

を使用して期間ベースの維持を有効にするには AWS CLI

stickiness.enabled および stickiness.lb_cookie.duration_seconds 属性を指定して modify-target-group-attributes コマンドを使用します。

期間ベースの維持を有効にするには、次のコマンドを使用します。

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.lb_cookie.duration_seconds,Value=time-in-seconds

出力は次の例のようになります。

     {     
        "Attributes": [
           ...
            {
                 "Key": "stickiness.enabled",
                 "Value": "true"
              },           
              {
                  "Key": "stickiness.lb_cookie.duration_seconds",
                  "Value": "86500"
              
              },
           ...
          ]
      }           

アプリケーションベースの維持

アプリケーションベースの維持では、クライアントターゲットの維持の独自の条件を設定できます。アプリケーションベースの維持を有効にすると、ロードバランサーは、選択したアルゴリズムに基づいてターゲットグループ内のターゲットに最初のリクエストをルーティングします。ターゲットは維持を有効にするために、ロードバランサーで設定した 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 を認識します。

を使用してアプリケーションベースの維持を有効にするには AWS CLI

次の属性で modify-target-group-attributes コマンドを使用します。

アプリケーションベースの維持を有効にするには、次のコマンドを使用します。

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=app_cookie Key=stickiness.app_cookie.cookie_name,Value=my-cookie-name Key=stickiness.app_cookie.duration_seconds,Value=time-in-seconds

出力は次の例のようになります。

 
       {
            "Attributes": [
                ...
                {
                    "Key": "stickiness.enabled",
                    "Value": "true"
                },
                {
                    "Key": "stickiness.app_cookie.cookie_name",
                    "Value": "MyCookie"
                },
                {
                    "Key": "stickiness.type",
                    "Value": "app_cookie"
                },
                {
                    "Key": "stickiness.app_cookie.duration_seconds",
                    "Value": "86500"
                },
                ...
            ]
        }  
            
            

手動再分散

スケールアップ時にターゲット数が大幅に増加すると、維持による負荷の分散が不均等になる可能性があります。このシナリオでは、次の 2 つのオプションを使用して、ターゲットの負荷を再分散できます。