Application Load Balancer セッションのスティッキネスに関する問題をトラブルシューティングする方法を教えてください。

簡単な説明

スティッキーセッションは Cookie を使用して、クライアントが Cookie の有効期間にわたって同じターゲットへの接続を維持できるようにします。スティッキーセッションは、ユーザーセッションを特定のターゲットにバインドするようにロードバランサーを設定します。つまり、セッション期間において、ユーザーからの要求はすべて同じターゲットに送信されます。ただし、この想定に基づく接続では、時間の経過とともに不均衡が発生する可能性があります。

スティッキーセッションは、次の理由で機能しなくなる場合があります。

• 登録されたターゲットが Cookie を生成していない。
• クライアントがリクエストヘッダーに Cookie を返していない。
• Cookie の形式が誤っている。
• 期間ベースのセッションが終了済みである。
• セッションリクエストが複数のロードバランサーを通過している。
• ターゲットのヘルスステータスが異常に変更された。
• AWS サービスでスティッキネスが無効になった。

注: 始める前に、「Application Load Balancer 用のスティッキーセッション」の、要件および考慮事項に関するセクションを必ず確認してください。

解決策

アプリケーションベースのセッションスティッキネス

1. ロードバランサーで HTTP エラーをチェックします。手順については、「Application Load Balancer のトラブルシューティング」を参照してください。

2. バックエンドインスタンスまたはロードバランサーに配置された Cookie を確認するには、curl コマンドを実行します。例を次に示します。DNS 名をロードバランサー名に置き換えます。

   [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-EXAMPLE-ELB-1430759361.eu-central-1.elb.amazonaws.com

   注: Windows オペレーティングシステム (OS) に Linux curl ユーティリティをインストールすることもできます。詳細については、curl のウェブサイトで curl 8.10.1 for Windows を参照してください。

   curl コマンドの出力は次のようになります。

   ...
   < Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/
   
   < Set-Cookie:
   
   AWSALBAPP-0=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/
   
   ...

3. 登録されたターゲットがアプリケーション Cookie を生成したことを確認するには、次のような HTTP リクエストをインスタンスの IP アドレスに送信します。

   [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null 172.31.30.168

   このコマンドによる出力例を次に示します。

   ...
   < Set-Cookie: PHPSESSID=5pq74110nuir60kpapj04mglg4; path=/
   
   ...

4. 登録されたターゲットによって生成された Cookie の名前が、ステップ 2 と 3 で取得したロードバランサーの Cookie の名前であることを確認します。

5. ターゲットがアプリケーション Cookie を生成し、ロードバランサーが AWSALBAPP Cookie を生成したら、クライアントが後続のリクエストで両方の Cookie を送信していることを確認します。クライアントにアプリケーション Cookie、AWSELB Cookie のいずれかが含まれていない場合、スティッキネスは機能しません。クライアントがアプリケーション Cookie、AWSALBAPP Cookie の両方を送信していることを確認するには、クライアントでパケットキャプチャを行います。リクエストヘッダーの Cookie 情報を取得するには、次のいずれかのオプションを使用します。

   tcpdump (tcpdump のウェブサイトで入手)
   Wireshark ユーティリティ (Wireshark のウェブサイトで入手)
   ブラウザのウェブデバッグツール

   注: AWS サポートを利用している場合は、HAR ファイルを作成してこの情報を収集します。HAR ファイルはユーザー名、パスワード、キーなどの機密情報をキャプチャする可能性があるため、必ず HAR ファイルから機密情報を削除してください。

6. ロードバランサーがリクエストをルーティングしたバックエンドインスタンスを確認します。インスタンスメタデータを使用してインスタンス ID を表示するには、次のようなスクリプトを実行します。

   <?php $instance_id =file_get_contents('http://169.254.169.254/latest/meta-data/instance-id');echo "instance id = " . $instance_id . "\\xA";?>

7. 同じユーザーからのリクエストが別の登録済みターゲットにルーティングされているかどうかを確認するには、Elastic Load Balancing (ELB) のアクセスログを確認します。手順については、「Application Load Balancer のアクセスログ」を参照してください。

8. スティッキネスが有効になっているターゲットグループにおいて、すべてのターゲットのヘルスステータスが正常であることを確認します。ターゲットのヘルスステータスが異常になると、スティッキネスが失われるため、ロードバランサーはリクエストをそのターゲットにルーティングしません。その後、ロードバランサーによって新しい正常なターゲットが自動的に選択され、スティッキーセッションが確立されます。ロードバランサーは、ヘルスステータスが異常であっても、引き続きリクエストを新しいターゲットにルーティングします。ヘルスチェックの詳細については、「Application Load Balancer ターゲットグループに対するヘルスチェック」を参照してください。

9. Amazon Elastic Kubernetes Service (Amazon EKS) などの AWS サービスで、ロードバランサーのスティッキネス機能が無効になっていないかを確認してください。CloudTrail イベント履歴を確認します。API 名 ModifyTargetGroupAttributes および、属性 stickiness.enabled を参照します。

期間に基づくセッションのスティッキネス

1. AWSALB クッキーを確認するには、次のような curl コマンドを実行します。必ず、ロードバランサーの DNS 名を使用してください。

   [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-TESTELB-1430759361.eu-central-1.elb.amazonaws.com

   curl コマンドの出力は次のようになります。

   ...
   < Set-Cookie: AWSALB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/
   ...

   注: 応答に AWSALB Cookie が含まれていない場合は、クライアントとバックエンドインスタンスの間にスティッキネスが機能していません。

2. ロードバランサーが AWSALB Cookie を生成した場合は、クライアントが後続のリクエストでこの Cookie を送信していることを確認します。クライアントが AWSALB Cookie を含めて送信しない場合、スティッキネスは機能しません。クライアントが AWSALB Cookie を送信していることを確認するには、クライアントでパケットキャプチャを行います。リクエストヘッダーの Cookie 情報を取得するには、次のいずれかのオプションを使用します。

   tcpdump (tcpdump のウェブサイトで入手)
   Wireshark ユーティリティ (Wireshark のウェブサイトで入手)
   ブラウザのウェブデバッグツール

   注: AWS サポートを利用している場合は、HAR ファイルを作成してこの情報を収集します。HAR ファイルはユーザー名、パスワード、キーなどの機密情報をキャプチャする可能性があるため、必ず HAR ファイルから機密情報を削除してください。

3. ロードバランサーに設定されている期間を確認します。Cookie の有効期限が過ぎると、ロードバランサーによって新しい Cookie が発行されるまで、クライアントセッションは登録されたターゲットに保持されなくなります。

4. リクエストが複数のロードバランサーを経由する場合は、1 つのロードバランサーでのみスティッキネスが有効になっていることを確認します。複数のロードバランサーが Cookie を生成すると、ロードバランサーが元の Cookie を置き換えるため、スティッキネスは機能しません。

Classic Load Balancer については、「Classic Load Balancer セッションで、スティッキネス機能をトラブルシューティングする方法を教えてください」を参照してください。

関連情報

Elastic Load Balancing がロードバランサーのトラフィックを不均等にルーティングする理由を知りたいです

Classic Load Balancer にスティッキーセッションを設定する

Application Load Balancer に加重ターゲットグループを設定する方法を教えてください