Application Load Balancer のセッション維持機能問題をトラブルシューティングにはどうすればよいですか?

最終更新日: 2022 年 8 月 16 日

スティッキーセッションは cookie を使用して、クライアントが cookie の存続期間全体を通じて同じインスタンスへの接続を維持できるようにします。スティッキーセッションの使用は、ユーザーセッションが特定のインスタンスにバインドされるようにロードバランサーを設定します。これは、セッション中におけるユーザーからのリクエストのすべてが同じインスタンスに送信されることを意味します。ただし、接続に関するこの想定は、時間の経過とともに不均衡を引き起こす可能性があります。

スティッキーセッションは、以下の場合に失敗する可能性があります。

• 登録されたターゲットが cookie を生成しなかった
• クライアントがリクエストヘッダーで cookie を返さなかった
• Cookie が正しくフォーマットされていない
• 期間ベースのセッションの期間が終了した
• セッションリクエストが複数のロードバランサーを経由している
• ターゲットのヘルスステータスが変化して異常になった
• AWS のサービスが維持機能を無効にした

注意: 手順を開始する前に、Application Load Balancer のスティッキーセッションにある要件と考慮事項のセクションを確認するようにしてください。

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

2.    バックエンドインスタンス、またはロードバランサーに設置された cookie をチェックするには、以下のような curl コマンドを実行します。

注意: DNS 名は、お使いのロードバランサー名に置き換えてください。

注意: Linux の curl ユーティリティは、Windows OS にインストールすることもできます。

出力例:

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

出力例:

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

5.    ターゲットがアプリケーション cookie を生成し、ロードバランサーが AWSALBAPP cookie を生成した場合は、クライアントが後続のリクエストで両方の cookie を送信することを確認してください。クライアントがアプリケーション cookie または AWSELB cookie のいずれかを含めなかった場合は、維持機能が失敗します。クライアントがアプリケーション cookie と AWSALBAPP cookie の両方を送信することを確認するには、クライアントでパケットキャプチャを実行します。分析用の tcpdump または Wireshark ユーティリティを使用、またはブラウザの web デバッグツールを使用して、リクエストヘッダー内の cookie 情報を取得します。

注意:AWS サポートと連携している場合は、 HAR ファイルを生成することでこの情報を収集できます。HAR ファイルは、ユーザー名、パスワード、キーなどの機密情報をキャプチャできるので、HAR ファイルから機密情報を削除してください。

6.    ロードバランサーがどのバックエンドインスタンスにリクエストをルーティングしたのかをチェックします。以下のようなスクリプトを実行することによって、インスタンスメタデータを使用してインスタンス ID を表示することができます。

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

8.    維持機能が有効化されているターゲットグループで、すべてのターゲットのヘルスステータスが正常であることを確認します。ターゲットのヘルスステータスが「unhealthy」(異常) に変わると、維持機能が破損し、ロードバランサーはそのターゲットへのリクエストのルーティングを停止します。その後、ロードバランサーが新しい正常なターゲットを自動的に選択し、スティッキーセッションを確立します。ロードバランサーは、ヘルスステータスが「unhealthy」(異常) になっていても、その新しいターゲットへのリクエストのルーティングを継続します。 ヘルスチェックの詳細については、ターゲットグループのヘルスチェックを参照してください。

9.    ロードバランサーの維持機能を無効にした可能性がある AWS のサービス (Amazon Elastic Kubernetes Service (Amazon EKS) など) をチェックします。API 名「ModifyTargetGroupAttributes」と属性「stickiness.enabled」を使用して CloudTrail イベントの表示をチェックします。

1.    ロードバランサー DNS 名を使用して以下のようなコマンドを実行し、応答に AWSALB cookie があるかどうかをチェックします。

出力例:

注意: 応答に AWSALB cookie がない場合は、クライアントとバックエンドインスタンス間に維持機能がありません。

2.    ロードバランサーが AWSALB cookie を生成した場合は、クライアントが後続のリクエストでこの cookie を送信することを確認してください。クライアントが AWSALB cookie を含めなかった場合、維持機能は機能しません。クライアントが AWSALB cookie を送信することを確認するには、クライアントでパケットキャプチャを実行します。分析用の tcpdump または Wireshark ユーティリティを使用、またはブラウザの web デバッグツールを使用して、リクエストヘッダー内の cookie 情報を取得します。

注意:AWS サポートと連携している場合は、 HAR ファイルを生成することでこの情報を収集できます。HAR ファイルは、ユーザー名、パスワード、キーなどの機密情報をキャプチャできるので、HAR ファイルから機密情報を削除してください。

3.    ロードバランサーで設定されている期間をチェックします。cookie の有効期限が過ぎると、ロードバランサーが新しい cookie を発行するまで、クライアントセッションの登録されたターゲットに対する維持機能が失われます。

4.    リクエストが複数のロードバランサーを経由する場合は、維持機能が 1 つのロードバランサーだけで有効になっていることを確認します。複数のロードバランサーが cookie を生成すると、ロードバランサーが元の cookie を置き換えるので、維持機能が失敗します。

Classic Load Balancerについては、Classic Load Balancer のセッション維持機能をトラブルシューティングするにはどうすればよいですか? を参照してください。