期間ベースまたはアプリケーション制御のセッション維持設定をもつ Classic Load Balancer があります。ロードバランサーは同一の登録済みインスタンスに、クライアントの HTTP または HTTPS セッションをルーティングするように設定されていますが、クライアントのリクエストは別の登録済みインスタンスへルーティングされます。Elastic Load Balancing (ELB) セッション維持設定を使用して問題をトラブルシューティングする方法を教えてください。

デフォルトでは未処理のリクエストはほとんどなしで、Classic Load Balancer が各リクエストを登録済みインスタンスにルーティングします。スティッキーセッション (セッションの親和性) を使用して、ロードバランサーがユーザーセッションを特定のインスタンスに結び付けるように構成します。こうすることで、同一セッション中の同一ユーザーからの全リクエストが同一のインスタンスへ送信されるようになります。次のような条件下でスティッキーセッションが失敗することがあります。

1.    登録済みインスタンスがアプリケーション Cookie を挿入しない。

2.    クライアントがリクエストヘッダーに Cookie を返さない。

3.    登録済みインスタンスによって挿入された Cookie が正しくフォーマットされていない。

4.    期間ベーススティッキーセッションの使用中、指定された有効期限が経過した。

5.    HTTP または HTTPS リクエストが、維持設定の有効になっているロードバランサーを 1 つ以上通過した。

注: ロードバランサーのセッションの維持機能は、HTTP または HTTPS のリスナーでのみサポートされています。

アプリケーション制御によるセッション維持

1.    Classic Load Balancer で HTTP エラーを確認します。詳細については、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.    登録済みインスタンスが、HTTP リクエストを登録済みインスタンス IP に直接送信することで、アプリケーション 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 アクセスログについて詳しくは、Classic Load Balancer のアクセスログを参照してください。

8.    アプリケーションによって挿入された Cookie が HTTP として正しくフォーマットされていることを確認します。

9.    リクエストが複数のロードバランサーを通過する場合、維持設定が 1 つのロードバランサーのみで有効になっていることを確認します。複数のロードバランサーが Cookie を挿入すると、オリジナルの Cookie は上書きされ、維持設定は失敗します。

期間ベースのセッション維持

1.    レスポンスの AWSELB Cookie を確認するために、ロードバランサーの DNS 名に次のようなコマンドを実行します。  

[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 は上書きされ、維持設定は失敗します。 


このページは役に立ちましたか? はい | いいえ

AWS サポートナレッジセンターに戻る

サポートが必要ですか?AWS サポートセンターをご覧ください。

公開日: 2018 年 3 月 30 日