Classic Load Balancer のセッション維持機能をトラブルシューティングするにはどうすればよいですか?
Classic Load Balancer には、期間ベースまたはアプリケーションによって制御されるのセッション維持機能が備わっています。ロードバランサーは、クライアント HTTP または HTTPS セッションを、同じ登録済みインスタンスにルーティングするように設定されていますが、クライアントリクエストは別の登録済みインスタンスにルーティングされます。Elastic Load Balancing (ELB) セッションの維持に関する問題をトラブルシューティングするにはどうすればよいですか?
簡単な説明
デフォルトでは、Classic Load Balancer は、未処理のリクエストが最も少ない登録済みインスタンスに各リクエストをルーティングします。スティッキーセッション (セッションアフィニティ) を使用すると、ユーザーセッションを特定のインスタンスにバインドするようにロードバランサーが設定され、セッション中のユーザーからのリクエストはすべて同じインスタンスに送信されます。スティッキーセッションは、次の場合に失敗することがあります。
1. 登録されたインスタンスがアプリケーション Cookie を挿入していない。
2. クライアントがリクエストヘッダーに Cookie を返していない。
3. 登録されたインスタンスによって挿入された Cookie が正しくフォーマットされていない。
4. 時間ベースのスティッキーセッションを使用するときに指定した有効期限が過ぎた。
5. HTTP または HTTPS リクエストが、持続性が有効になっている複数のロードバランサーを通過している。
注: ロードバランサーのセッション維持機能は、HTTP または HTTPS リスナーでのみサポートされます。
解決方法
1. Classic Load Balancer で HTTP エラーをチェックします。詳細については、「Troubleshoot a Classic Load Balancer: HTTP Errors」(Classic Load Balancer のトラブルシューティング: HTTP エラー) を参照してください。
2. ロードバランサーの DNS 名に対して、次のようなコマンドを実行します。レスポンスで次の 2 つの Cookie を確認します。
- アプリケーション Cookie は、バックエンドインスタンスで実行されているアプリケーションによって挿入されます。
- AWSELB Cookie は、ロードバランサーによって挿入されます。
注: このコマンドを実行する前に、DNS 名をロードバランサーの名前に置き換えてください。
[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-TESTELB-1430759361.eu-central-1.elb.amazonaws.com
注: curl ユーティリティは Linux にネイティブですが、Windows にもインストールできます。
コマンドに対するレスポンスの例を次に示します。
... < Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/ < Set-Cookie: AWSELB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/ ...
注: レスポンスに AWSELB Cookie が含まれていない場合、クライアントとバックエンドインスタンス間に持続性はありません。
3. 次のようなコマンドを実行して、登録済みインスタンス IP に HTTP リクエストを直接送信し、登録済みインスタンスがアプリケーション Cookie を挿入していることを確認します。
[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null 172.31.30.168
このコマンドでは次の例のようなレスポンスが返されます。
... < Set-Cookie: PHPSESSID=5pq74110nuir60kpapj04mglg4; path=/ ...
4. 登録されたインスタンスによって生成された Cookie 名が、ロードバランサーで設定された Cookie 名と同じであることを確認します。
5. 登録されたインスタンスがレスポンスにアプリケーション Cookie を挿入し、ロードバランサーが AWSELB Cookie を挿入する場合は、後続のリクエストでクライアントがこれらの Cookie の両方を送信するようにしてください。クライアントがアプリケーション Cookie または AWSELB Cookie のいずれかを含めなかった場合、持続性は機能しません。クライアントがアプリケーション Cookie と AWSELB Cookie の両方を送信していることを確認するには、クライアントでパケットキャプチャを取得するか、ブラウザのウェブデバッグツールを使用して、リクエストヘッダーの Cookie 情報を取得します。
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. ELB アクセスログを確認して、同じユーザーからのリクエストが別の登録済みインスタンスにルーティングされたかどうかを確認します。ELB アクセスログの確認の詳細については、「Access logs for your Classic Load Balancer」(Classic Load Balancer のアクセスログ) を参照してください。
8. アプリケーションによって挿入された Cookie が HTTP 用に正しくフォーマットされていることを確認します。
9. リクエストが複数のロードバランサーを通過する場合は、1 つのロードバランサーでのみ持続性が有効になっていることを確認します。複数のロードバランサーが Cookie を挿入すると、元の Cookie が置き換えられ、持続性は失敗します。
1. ロードバランサーの DNS 名に対して次のようなコマンドを実行して、レスポンスに AWSELB Cookie が含まれるかどうかを確認します。
[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-TESTELB-1430759361.eu-central-1.elb.amazonaws.com
このコマンドでは次の例のようなレスポンスが返されます。
... < Set-Cookie: AWSELB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/ ...
注: レスポンスに AWSELB Cookie が含まれていない場合、クライアントとバックエンドインスタンス間に持続性はありません。
2. ロードバランサーが AWSELB Cookie を挿入する場合は、後続のリクエストでクライアントがこの Cookie を送信するようにしてください。クライアントが AWSELB Cookie を含めなかった場合、持続性は機能しません。クライアントが AWSELB Cookie を送信していることを確認するには、クライアントでパケットキャプチャを取得するか、ブラウザのウェブデバッグツールを使用して、リクエストヘッダーの Cookie 情報を取得します。
3. ロードバランサーで設定されている期間を確認します。Cookie の有効期限が過ぎると、ロードバランサーによって新しい Cookie が発行されるまで、クライアントセッションは登録済みインスタンスに維持されなくなります。
4. リクエストが複数のロードバランサーを通過する場合は、1 つのロードバランサーでのみ持続性が有効になっていることを確認します。複数のロードバランサーが Cookie を挿入すると、元の Cookie が置き換えられ、持続性は失敗します。
関連情報
Configure sticky sessions for your Classic Load Balancer (Classic Load Balancer のスティッキーセッションを設定する)
関連するコンテンツ
- AWS公式更新しました 6年前
