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 を削除する必要があります。

要件

HTTP/HTTPS ロードバランサー。
各アベイラビリティーゾーンに少なくとも 1 つの正常なインスタンスがあること。

考慮事項

クロスゾーン負荷分散が無効な場合、スティッキーセッションはサポートされません。クロスゾーン負荷分散が無効なときにスティッキーセッションを有効にしようとしてもできません。
アプリケーションベースの Cookie の場合、ターゲットグループごとに Cookie 名を個別に指定する必要があります。ただし、期間ベースの Cookie の場合、AWSALB はすべてのターゲットグループで使用される唯一の名前です。
Application Load Balancers の複数のレイヤーを使用している場合、アプリケーションベースの Cookie を使用して、すべてのレイヤーでスティッキーセッションを有効にできます。ただし、期間ベースの Cookie の場合、AWSALB が使用可能な唯一の名前であるため、1 つのレイヤーでのみスティッキーセッションを有効にできます。
アプリケーションベースの維持は、加重ターゲットグループでは動作しません。
複数のターゲットグループを含む転送アクションがあり、1 つ以上のターゲットグループでスティッキーセッションが有効になっている場合、ターゲットグループレベルの維持を有効にする必要があります。
WebSocket 接続は本質的にスティッキーです。クライアントがへの接続アップグレードをリクエストする場合 WebSockets、接続アップグレードを受け入れるために HTTP 101 ステータスコードを返すターゲットが、接続で使用される WebSocketsターゲットです。 WebSockets アップグレードが完了すると、Cookie ベースの維持は使用されません。
Application Load Balancer は Max-Age 属性の代わりに Cookie ヘッダーの Expires 属性を使用します。
Application Load Balancer は、URL エンコードされた Cookie 値をサポートしていません。

期間ベースの維持

期間ベースの維持は、ロードバランサーが生成した Cookie (AWSALB) を使用して、ターゲットグループ内の同じターゲットにリクエストをルーティングします。 Cookie は、セッションをターゲットにマッピングするために使用します。アプリケーションに独自のセッション Cookie がない場合、独自の維持期間を指定し、ロードバランサーがユーザーのリクエストを同じターゲットに一貫してルーティングする期間を管理できます。

ロードバランサーは、クライアントから最初のリクエストを受信すると、選択したアルゴリズムに基づいてリクエストをターゲットにルーティングし、AWSALB という名前の Cookie を生成します。これは、選択したターゲットに関する情報をエンコードしてCookie を暗号化し、クライアントへの応答に Cookie を含めます。ロードバランサーが生成した cookie には 7 日間の有効期限がありますが、これは設定できません。

後続のリクエストでは、クライアントは AWSALB Cookie を含める必要があります。ロードバランサーは Cookie を含むクライアントからリクエストを受信すると、それを検出し、同じターゲットにリクエストをルーティングします。Cookie は存在するがデコードできない場合、あるいは登録解除されたターゲットまたは異常なターゲットを参照している場合、ロードバランサーは新しいターゲットを選択し、新しいターゲットに関する情報で Cookie を更新します。

Cross-Origin Resource Sharing (CORS) リクエストの場合、一部のブラウザでは維持を有効にするSameSite=None; Secureためにが必要です。これらのブラウザをサポートするために、ロードバランサーは常に 2 つ目の維持 Cookie であるを生成します。これにはAWSALBCORS、元の維持 Cookie と同じ情報と SameSite 属性が含まれます。クライアントは、CORS 以外のリクエストを含む両方の Cookie を受け取ります。

コンソールを使用して期間ベースの維持を有効にするには

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインの [ Load Balancing (ロードバランシング) ] で [ Target Groups (ターゲットグループ) ] を選択します。
ターゲットグループの名前を選択して、その詳細ページを開きます。
[グループの詳細] タブの [属性] セクションで、[編集] を選択します。
[Edit attributes] ページで、以下を実行します。
1. [維持] を選択します。
2. [ 維持の種類 ] で、[ Load balancer generated cookie (ロードバランサーが生成した Cookie) ] を選択します。
3. [Stickiness duration] で、1 秒から 7 日の間の値を指定します。
4. [変更の保存] をクリックします。

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 などが表示されます。

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインの [ Load Balancing (ロードバランシング) ] で [ Target Groups (ターゲットグループ) ] を選択します。
ターゲットグループの名前を選択して、その詳細ページを開きます。
[グループの詳細] タブの [属性] セクションで、[編集] を選択します。
[Edit attributes] ページで、以下を実行します。
1. [維持] を選択します。
2. [ 維持の種類 ] で、[ アプリケーションベース Cookie ] を選択します。
3. [Stickiness duration] で、1 秒から 7 日の間の値を指定します。
4. [ アプリ Cookie 名 ] に、アプリケーションベースの Cookie 名を入力します。
  
  Cookie 名に AWSALB、AWSALBAPP、または AWSALBTG を使用しないでください。これらは、ロードバランサーで使用するために予約されています。
5. [変更の保存] をクリックします。

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

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

stickiness.enabled
stickiness.type
stickiness.app_cookie.cookie_name
stickiness.app_cookie.duration_seconds

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


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 つのオプションを使用して、ターゲットの負荷を再分散できます。

アプリケーションが生成した Cookie に現在の日付と時刻より前の有効期限を設定します。これにより、クライアントが Application Load Balancer に Cookie を送信できなくなり、維持の確立プロセスが再開されます。
ロードバランサーのアプリケーションベースの維持設定で、1 秒など非常に短い時間を設定します。これにより、ターゲットが設定した Cookie の有効期限が切れていない場合でも、Application Load Balancer は維持を再確立します。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

ターゲットの登録

ターゲットとしての Lambda 関数