ショッピングカート、ログイン情報、ユーザー設定、ゲームの状態などを管理する一部のアプリケーションでは、単一のクライアントからのリクエストを常に同じバックエンドサーバーにルーティングする必要があります。クライアントのリクエストが異なるサーバーに分散されると、セッション状態が失われ、ユーザーエクスペリエンスが低下する可能性があります。Application Load Balancer (ALB) のセッション維持を有効にすることで、同じクライアントからのリクエストが同じバックエンドサーバーに転送されるようになり、一貫したユーザーエクスペリエンスとデータ整合性を維持できます。
背景情報
デフォルトでは、ALB はリクエストを異なるバックエンドサーバーに分散します。セッションの永続化を有効にすると、同じクライアントからのリクエストは同じバックエンドサーバーに転送されます。これにより、バックエンドサーバーはステータス情報を維持し、クライアントに継続的なサービスを提供できます。
-
セッション維持が無効の場合:ALB は同じクライアントからの各リクエストを独立して転送するため、そのクライアントからの連続したリクエストが異なるバックエンドサーバーに分散されることがあります。対話情報を取得するためにバックエンドサーバーにログインするようなシナリオでは、複数回ログインする必要がある場合があります。
-
セッション維持が有効の場合:ALB は、同じクライアントからのリクエストを同じバックエンドサーバーに転送します。対話情報を取得するためにバックエンドサーバーにログインするようなシナリオでは、複数回ログインする必要はありません。
ALB でセッション維持を有効にする場合、Cookie の処理方法を選択する必要があります。ALB では、Cookie の挿入と Cookie の書き換えの 2 つの方法がサポートされています。
-
Cookie の挿入: クライアントの初回リクエストで、ALB はレスポンスに Cookie を挿入します。 具体的には、ALB は、
SERVERIDとSERVERCORSIDの 2 つの Cookie を挿入します。SERVERCORSIDCookie はSERVERIDに基づいており、samesite=None属性を含みます。 クライアントがこの Cookie を含む後続のリクエストを送信すると、ALB はそのリクエストを以前に記録されたバックエンドサーバーに転送します。説明Cookie 挿入方式では
SameSite=Noneが自動的に含まれるため、追加の設定は不要です。これにより、ALB 転送ルールを含むクロスオリジンリソース共有 (CORS) シナリオでブラウザが Cookie を保存できない問題が、効果的に解決されます。 -
Cookie の書き換え: ALB がユーザー定義の Cookie を検出すると、元の Cookie を書き換えます。 クライアントが新しい Cookie を使用して後続のリクエストを行うと、ALB は、以前に記録されたバックエンドサーバーにリクエストを転送します。
制限事項
-
ALB Extensible Edition はセッション維持をサポートしていません。
-
Function Compute サーバーグループでは、セッション維持は不要です。詳細については、「サーバーグループの作成と削除」をご参照ください。
前提条件
-
インターネット向けの ALB インスタンスが 実行中 状態である必要があります。 詳細については、「ALB インスタンスの作成と管理」をご参照ください。
-
サーバータイプまたは IP タイプのサーバーグループを作成済みであること。詳細については、「サーバーグループの作成と削除」をご参照ください。
-
リクエストを受信するために、2 つのバックエンドサーバー ECS01 と ECS02 が作成されています。各インスタンスは異なるバックエンドサービスを実行して、それぞれ異なるレスポンスを返します。たとえば、ECS01 へのリクエストは
"Hello World ! This is ECS01."を返し、ECS02 へのリクエストは"Hello World ! This is ECS02."を返します。セキュリティグループで、必要なサービスポートのインバウンドトラフィックが許可されていることを確認してください。 -
バックエンドサーバー ECS01 と ECS02 をサーバーグループに追加済みであること。詳細については、「バックエンドサーバーの追加と削除」をご参照ください。
-
インスタンスのリスナーを設定済みであること。詳細については、「HTTP リスナーの追加」、「HTTPS リスナーの追加」、または「QUIC リスナーの追加」をご参照ください。
ステップ 1:セッション維持の設定
-
ALB コンソールにログインします。
-
上部メニューで、サーバーグループがデプロイされているリージョンを選択します。
-
左側のナビゲーションペインで、を選択します。
-
サーバーグループ ページで、目的のサーバーグループを見つけ、操作 列の サーバーグループの編集 をクリックします。
-
基本情報の変更 ダイアログボックスで、セッション維持を有効にします。
セッション維持 を有効にし、Cookie の持続性 を選択します。
-
Cookie の挿入 を選択し、セッション持続性のタイムアウト期間 を設定してから、保存 をクリックします。
セッション維持のタイムアウトは、アプリケーション側のセッションのライフサイクルと一致させることを推奨します。タイムアウトが長すぎると、クライアントのリクエストが新しく追加されたバックエンドサーバーに長期間転送されなくなり、負荷の不均衡を引き起こす可能性があります。タイムアウトが短すぎると、セッション維持が失敗する可能性があります。
-
Cookie の上書き を選択し、Cookie [名前] を設定してから、保存 をクリックします。
この例では、クッキー名は
BACKEND_SERVERに設定されています。この名前は説明のみを目的としており、カスタム名を指定できます。
-
(任意) ステップ 2:バックエンドサーバーでの Cookie の設定
セッション維持に Cookie の書き換え方法を使用する場合にのみ、バックエンドサーバーで Cookie を設定します。
-
ECS インスタンスに接続します。詳細については、「ECS インスタンスの接続ガイド」をご参照ください。
-
お使いの Web サーバーに応じて Cookie を設定します。
説明Cookie の設定は Web サーバーによって異なります。以下の例は一般的な Web サーバーを対象としています。お使いの Web サーバーがリストにない場合は、その公式ドキュメントで正しい設定方法をご確認ください。
Nginx
このセクションでは、CentOS 7.9 で実行されている NGINX 1.20.1 サーバーを設定する例を示します。設定はお使いの環境によって異なる場合があります。
-
Nginx 設定ファイルを変更して保存します。必要な変更については、以下の手順をご参照ください。
nginx -tコマンドを実行して、設定ファイルのパスを確認します。通常、設定ファイルは/etc/nginxディレクトリにあるnginx.confですが、実際のパスは環境によって異なる場合があります。http { # ... server { listen 80; # BACKEND_SERVER を、Cookie の書き換え方法を設定したときに指定した Cookie 名に設定します。 値にはカスタム文字列を使用できます。 add_header Set-Cookie "BACKEND_SERVER=value"; # ... } } -
次のコマンドを実行して、NGINX 設定ファイルをリロードします。
sudo nginx -s reload
Apache
このセクションでは、CentOS 7.9 で実行されている Apache 2.4.6 サーバーを設定する例を示します。設定はお使いの環境によって異なる場合があります。
-
Apache サービス設定ファイルを変更して保存します。必要な変更については、以下の手順をご参照ください。デフォルトのパスは通常
/etc/httpd/conf/httpd.confですが、実際のパスは環境によって異なります。# ... Listen 80 # BACKEND_SERVER を、Cookie の書き換え方法を設定したときに指定した Cookie 名に設定します。 値にはカスタム文字列を使用できます。 Header always set Set-Cookie "BACKEND_SERVER=value" # ... -
次のコマンドを実行して、Apache 設定ファイルをリロードし、変更を適用します。
sudo systemctl reload httpd.service
-
-
前の手順を繰り返して、サーバーグループ内の他のバックエンドサーバーの設定を変更します。
ステップ 3:セッション維持の確認
-
ALB コンソールにログインします。
-
上部メニューでリージョンを選択します。対象の ALB インスタンスを見つけ、そのドメイン名をコピーします。
-
ブラウザーにドメイン名を入力します。いずれかのサーバーのページが表示されます。ページを複数回更新します。ページの内容は同じままであるはずです。
たとえば、最初のリクエストが ECS01 にルーティングされた場合、ページを更新した後の後続のリクエストもすべて ECS01 にルーティングされます。
複数回更新した後にレスポンスが ECS01 と ECS02 の間で交互に切り替わる場合は、セッション維持が正しく機能していません。設定にエラーがないか確認し、再度テストしてください。
関連ドキュメント
-
設定中に問題が発生した場合は、「ALB に関する FAQ」をご参照ください。
-
ヘルスチェックの問題が発生した場合は、「ALB のヘルスチェック問題のトラブルシューティング」をご参照ください。