アプリケーションベースの Cookie を使用したスティッキーセッション - AWS 規範ガイダンス
一般的なユースケースbasic.yml からのコード変更ステップ期待される結果仕組み

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

アプリケーションベースの Cookie を使用したスティッキーセッション

アプリケーションベースの Cookie で Application Load Balancer を使用する場合：

  • Application Load Balancer は、ターゲットグループの重みを使用して、ターゲットグループ間で受信トラフィックのバランスをとる方法を決定します。

  • デフォルトでは、Application Load Balancer はラウンドロビンメソッドを使用して、送信先ターゲットグループの EC2 インスタンスにリクエストをルーティングします。

  • トラフィックが最初に EC2 インスタンスにルーティングされた後、EC2 インスタンスアプリケーションのレスポンスにはカスタムアプリケーション Cookie が含まれ、自動 Application Load Balancer Cookie とともにクライアントに返されます。

  • クライアントがアプリケーション Cookie と Application Load Balancer Cookie を返送すると、それ以降のトラフィックは EC2 インスタンスに保持されます。

  • アプリケーションベースの Cookie は、設定した期間使用しない場合に期限切れになります。

テンプレート： AWS CloudFormation テンプレート stickysessionsapp.yml (サンプルコードの .zip ファイルに含まれる) を使用して、アプリケーションベースの Cookie でスティッキーセッションを試します。

一般的なユースケース

これらのシナリオで追加の制御が必要な場合は、アプリケーション生成 Cookie でスティッキーセッションを使用します。

  • PHP ウェブサーバー

  • ログ、ショッピングカート、チャット会話などの一時的なセッションデータを保持するサーバー

basic.yml からのコード変更

唯一のコード変更は、ターゲットグループ設定です。Application Load Balancer とターゲットグループ属性に維持設定を追加しました。アプリケーション Cookie の期間が指定され、ターゲットグループでアプリケーション Cookie の維持が有効になっています。

basic.yml stickysessionsapp.yml 
TG1:
   Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
   Properties:
     Name: TG1
     Protocol: HTTP
     Port: 80
     TargetType: instance
     Targets:
       - Id: !Ref Instance1
       - Id: !Ref Instance2
VpcId: !Ref CustomVPC
 
TG1:
  Type: 'AWS::ElasticLoadBalancingV2::TargetGroup'
  Properties:
    Name: TG1
    Protocol: HTTP
    Port: 80
    TargetType: instance
    Targets:
      - Id: !Ref Instance1
      - Id: !Ref Instance2
    VpcId: !Ref CustomVPC
    TargetGroupAttributes:
      - Key: stickiness.enabled
        Value: true
      - Key: stickiness.type
        Value: app_cookie
      - Key: stickiness.app_cookie.duration_seconds
        Value: 10
      - Key: stickiness.app_cookie.cookie_name
        Value: TESTCOOKIE

ステップ

メモ

  • NAT ゲートウェイには少額のコストがかかります。

  • 複数の EC2 インスタンスは、1 つの EC2 インスタンスよりも速く無料利用枠の時間を使い果たします。

  1. CloudFormation テンプレートstickysessionslb.ymlをラボ環境にデプロイします。

  2. ターゲットグループインスタンスのヘルスステータスが初期から正常に変わるまで待ちます。

  3. HTTP (TCP/80) を使用して、ウェブブラウザの Application Load Balancer URL に移動します。

    例: http://alb-123456789.us-east-1.elb.amazonaws.com/

    ウェブページには、インスタンス 1 - TG1、インスタンス 2 - TG1、インスタンス 3 - TG2、またはインスタンス 4 - TG2 のいずれかが表示されます。

  4. ページを複数回更新します。

期待される結果

注記

この例の CloudFormation テンプレートは、維持期間を 10 秒に設定しています。有効な維持期間の設定は 1 秒から 1 週間です。

ウェブページをロードするインスタンスは、ページテキストで示されているように、同じままにする必要があります。

維持期間は更新されませんが、EC2 インスタンスによって生成されるアプリケーション Cookie の Application Load Balancer で設定された有効期限に基づいています。

例 1: ページを更新するまで 5 秒待ちます。同じインスタンスがロードされ、維持状態がさらに 10 秒間更新されます。

例 2: ページを再ロードするまで 10 秒以上待ちます。アプリケーション Cookie の有効期限が切れ、別の EC2 インスタンスにルーティングされます。この新しいインスタンスは、10 秒の期間で別のアプリケーション Cookie を生成します。

仕組み

  • この例では、EC2 インスタンスに Apache ウェブサーバー (httpd) がインストールされています。httpd.conf ファイルは、静的なSet-Cookie値をクライアント (ウェブブラウザ) に返すように設定されています。Set-Cookie 値は にハードコードされていますTESTCOOKIE=<somevalue>。

  • ブラウザの Inspect Element オプションを開き、Network タブを選択し、Get メソッドを選択してページをロードします。Cookie タブが表示されます。

  • ブラウザは、サーバーSet-Cookieレスポンスで受信した Cookie を使用してサーバーに後続の更新を返すように自動的に設定されるクライアントアプリケーションです。

  • ページを再ロードすると、最初のページのロードで受信した Cookie が自動的に Application Load Balancer に返されます。

    • Cookie の有効期限が切れている場合 (つまり、前回の呼び出しから 10 秒が経過している場合）、Application Load Balancer は新しいロジックを使用してトラフィックをルーティングする EC2 インスタンスを決定します。

    • Cookie の有効期限が切れていない場合、Application Load Balancer はトラフィックを同じ EC2 インスタンスにルーティングします。