今日は過去2つのブログで構築したエンハンスドロードバランサーの環境で２つの機能を見ていきます。
セッション維持 / Sticky Session
通常、ロードバランサ（LB）は複数の実サーバに対して、各リクエストを最適なサーバへ分散（振り分け）します。しかし、ユーザーのセッション情報（ログイン状態やショッピングカートなど）が各サーバのローカルメモリ上に保持されている場合、リクエストが別サーバに飛ぶとセッションが切れてしまう、という問題が起こります。
本来アプリケーション側で外部データストア（インメモリキャッシュやNoSQLなどが一般的）でそれらの情報を保存し、動的にサーバがクライアントからのリクエストに応じで読みに行く構成をとることができれば、サーバが１台障害を起こしたとしてもユーザーからすればセッションおよびサービスは維持されますので望ましいのですが、アプリケーションの対応が必要となるため難しいケースもあります。
これを防ぐために導入されるのが セッション維持（Sticky Session） 機能です。
これは、同一ユーザー（同一ブラウザなど）からのリクエストを同じ実サーバに固定的に送るようにする仕組みです。
これはクライアント側のクッキーにより制御されます。
さっそくやってみる
エンハンスドロードバランサの詳細設定画面から以下を有効化します。
その後エンハンスドロードバランサーにアクセスを行います。ブラウザのデベロッパーツールでは以下の通りクッキーがセットされていることがわかります。
f0324ef4090f3fa3はさくらのクラウド内部では直接特定の実サーバを指す符号となっています。
次回以降のアクセスではセッションの有効期間の間、クッキーがブラウザから提出されれば紐づいた実サーバへ通信がルーティングされます。
ブラウザが閉じられた時点でこのクッキーは破棄されます。
KeepAlive
本機能は、ロードバランサ（LB）からバックエンドの実サーバへの TCP 接続を、可能な限り長時間維持し、複数リクエストを１つの接続で処理することで、接続確立・切断のオーバーヘッドを削減し、実サーバのリソースを効率的に活用するための仕組みです。
本サービスでは、この動作モードを以下の２種類から選択できます：
SAFE（デフォルト）：クライアントからの接続に応じて実サーバとの持続接続を用いる方式です。つまり、クライアントが新しい接続を開いた際には実サーバ側にも新しい接続を張る可能性があり、「確実かつ安定的な振る舞い」に重点を置いています。
AGGRESSIVE：再利用可能な実サーバとの既存接続が存在する場合、可能な限りその接続を利用して転送を行い、新規の TCP 接続数を削減します。これによりレスポンス速度の改善・リソースオーバーヘッドの軽減が見込めます。
シンプルにSAFEモードでは「クライアント接続が生きている間だけ、同じ実サーバ接続を再利用する」
「新しいクライアント接続が来たら、サーバ側も新しく作る」という動作となります。これに対してAGGRESSIVEモードでは「クライアント接続のライフサイクルとは無関係に、実サーバへの接続をプール（保持）して再利用する」「新しいクライアントが来ても、LBが既に持っている実サーバ接続を共有して使い回す」となります。
一見SAFEモードの方がAGRESSIVEモードよりも効率が悪いように見えますが、これはクライアントからの接続状況により異なります。AGRESSIVEモードの方が、接続を再利用するためしばらく接続を残します。このため細かい接続リクエストが続く環境では、時間とともに接続が積み上がりAGRESSIVEモードの方がサーバ負荷が高くなるケースもあります。
一概には言えませんが、まずはデフォルトのSAFEを試していただき負荷状況を見て切り替えるかどうかの検討を行うのがよいかもしれません。
先ほどと同じ場所に設定項目があります。
こちらは、エンハンスドロードバランサとサーバ間のセッションでありクライアントからはみえないところになるため検証は割愛します
Discussion