さくらのクラウドネットワーク入門 11. エンハンスドロードバランサのセッション維持とKeep Alive

公開：2026.04.24最終更新日：2026.04.24

このネットワーク入門では、第9回と第10回で「エンハンスドロードバランサ」アプライアンスを取り上げ、ドメイン名かつHTTPSでアクセスできるようになりました。このWeb環境を引き続き改善していきましょう。

本記事では、クライアントとのセッション維持（Sticky Session）と、実サーバーとのHTTP持続接続（Keep Alive）という2つの機能を紹介します。ともにコントロールパネルの「設定変更」画面から設定できます。ここでは他にも「エンハンスドロードバランサ」の動作に関していくつもの項目を調整できます。

👉 エンハンスドロードバランサの動作に関わる設定 | エンハンスドロードバランサ

1. セッション維持機能とは

ロードバランサーでは、複数の実サーバーに対してリクエストを最適に分散（振り分け）します。このとき、それぞれのサーバーで動作するアプリケーションが、ユーザーのセッション情報（ログイン状態やショッピングカートの中身など）をローカルメモリ上に保持していることがあります。しかし、セッションの途中でリクエストが別のサーバーに振り分けられると、セッション情報にアクセスできなくてセッションが切れてしまいます。

本来であれば、そういった情報をアプリケーションが外部のデータストア（一般的にはインメモリキャッシュやNoSQLなど）で保存し、クライアントからのリクエストに応じてサーバーがセッション情報ごと動的に読み取る構成にしたいところです。それなら1台のサーバーが障害を起こしてもユーザーからはセッションやサービスが維持されるので望ましいのですが、アプリケーション対応が必要となるため難しいケースもあります。

これを防ぐために導入されるのが、セッション維持（Sticky Session）機能です。同一ユーザー（同一ブラウザー）からのリクエストを、同じ実サーバーに固定的に送るようにする仕組みで、クライアント側のクッキーにより制御されます。

👉 セッション維持機能 | エンハンスドロードバランサ

エンハンスドロードバランサでセッションを維持する

さくらのクラウドのコントロールパネルの「エンハンスドLB」メニューから、対象とするエンハンスドロードバランサの詳細を表示します。右上の「設定変更」をクリックするとロードバランサーとしてのさまざまな機能を設定できます。

この「設定変更」画面の一番上にある「セッション維持」の「有効にする」をチェックします。

これでセッション維持が有効になり、以降のWebアクセスはクッキーによって振り分け先の実サーバーが固定されます。

Webブラウザーでクッキーを確認する

実際にクッキーが設定されていることをWebブラウザーで確認できます。

エンハンスドロードバランサに割り当てたドメインにアクセスし、コンテキストメニューの「検証」などからデベロッパーツールを起動します。上部の「アプリケーション（Application）」を選択して「ストレージ（Storage）」の「Cookies」を展開し、対象のドメインを選択すると、クッキーの名前や値などの詳細を確認できます。

この「sac-elb-session」という名前のクッキーの「f0324ef4090f3fa3」という値が、エンハンスドロードバランサの内部で特定の実サーバーを指す符号として扱われます。次回以降、このクッキーがブラウザーから提出されれば、同一のセッションとして紐づいた実サーバーへ通信がルーティングされます。

このクッキーはWebブラウザーが閉じられた時点で破棄されます。

2. 実サーバーとのHTTP接続を持続する

HTTP持続接続（Keep Alive）とは、ロードバランサーからバックエンドの実サーバーへのTCP接続を可能な限り長時間にわたって維持する仕組みです。複数リクエストを1つの接続で処理することで、接続の確立と切断にかかるオーバーヘッドを削減し、実サーバーのリソースを効率的に活用します。

「エンハンスドロードバランサ」では、「HTTP持続接続」の動作モードとして次の2種類を選択できます。

モード	説明
SAFE	クライアントからの接続に応じて、実サーバーとの持続接続を用いる（デフォルト）
AGGRESSIVE	再利用可能な既存の接続が存在すれば可能な限り利用し、新規のTCP接続数を削減する

デフォルトの「SAFE」モードでは、シンプルに「クライアント接続が生きている間だけ、同じ実サーバー接続を再利用する」「新しいクライアント接続が来たら、サーバー側も新しく作る」という動作となります。つまり「確実かつ安定的な振る舞い」に重点を置いています。

これに対して「AGGRESSIVE」モードでは「クライアント接続のライフサイクルとは無関係に、実サーバーへの接続をプール（保持）して再利用する」「新しいクライアントが来ても、既にロードバランサーが持っている実サーバー接続を共有して使い回す」ことになります。これにより、レスポンス速度の改善やリソースオーバーヘッドの軽減が見込めます。

一見するとSAFEモードの方が効率が悪いように見えますが、これはクライアントからの接続状況により異なります。AGRESSIVEモードでは接続を再利用するため、しばらく接続を残します。細かい接続リクエストが続く環境では時間とともに接続が積み上がり、AGRESSIVEモードの方がサーバー負荷が高くなるケースもあります。

一概には言えませんが、まずデフォルトの「SAFE」を試してみて、負荷状況を見ながら切り替えるかどうかを検討するのがよいでしょう。