セッションパーシステンスとは？仕組みから F5 BIG-IP 設定手順まで

はじめに

Web サイトへのアクセス負荷を分散させるために導入される「ロードバランサー」。サーバーの負荷を下げる便利な装置ですが、導入すると必ず直面するのが 「セッション維持（Session Persistence）」 の問題です。

「せっかく買い物かごに入れたのに、次のページに行ったら空っぽになった！」 「ログインしたはずなのに、突然ログアウトされた！」

もしロードバランサー導入後にこのようなトラブルが起きる場合、十中八九この「セッション維持」の設定がうまくいっていません。 F5 BIG-IP などの製品では 「Persistence（パーシステンス）」、AWS などのクラウド環境では 「Sticky Session（スティッキーセッション）」 と呼ばれるこの機能は、Web サービスの正常な動作に不可欠なものです。

本記事では、そもそもなぜセッション維持が必要なのかという基礎から、実務でよく使われる方式の選び方、そして F5 BIG-IP を使った具体的な設定手順までを解説します。

セッションパーシステンスとは

セッションパーシステンスとは、ロードバランサーが 「特定のユーザーからのアクセスを、一定時間、特定のサーバーだけに転送し続ける機能」 のことです。

通常、ロードバランサーは「ラウンドロビン」などのアルゴリズムを使って、アクセスを複数のサーバーに均等に振り分けようとします。 しかし、Web アプリケーションの仕様によっては、これが逆にトラブルの原因になることがあります。

クラウドサービス（AWS ELB など）では 「スティッキーセッション（Sticky Session）」 と呼ばれることもありますが、機能としては同じです。

なぜ必要なのか？（EC サイトの買い物かご問題）

最もわかりやすい例が、EC サイトの「買い物かご」 です。 もし、セッションパーシステンス機能がなかったらどうなるでしょうか？

1. A さんが「商品」を買い物かごに入れる → サーバー1 が記憶する。
2. A さんが「購入手続き」ボタンを押す。
3. ロードバランサーが（負荷分散のために）次のリクエストを サーバー2 に送る。
4. サーバー2 は A さんのことを知らないので、「買い物かごは空です」 となってしまう。

このように、ユーザーの情報（セッション情報）をサーバー内で管理している場合、途中でサーバーが変わると情報が引き継げず、エラーになってしまいます。 これを防ぐために、「A さんは最初にサーバー1に繋いだから、買い物が終わるまではずっとサーバー1に案内しよう」とするのがパーシステンス機能です。

主なパーシステンス方式

BIG-IP には複数の維持方式がありますが、実務で頻繁に使われるのは以下の 2 つです。 それぞれの特性と、メリット・デメリットをしっかり理解して使い分ける必要があります。

Source IP Affinity（送信元 IP アドレス方式）

クライアントの「送信元 IP アドレス」を識別子として、振り分け先を固定する方式です。 「IP アドレス 192.168.1.10 から来た通信は、前回サーバー A に行ったから、今回もサーバー A に送ろう」というシンプルな仕組みです。F5 BIG-IP では source_addr というプロファイル名で用意されています。

メリット

• 設定が非常に簡単。
• HTTP 以外のプロトコル（TCP/UDP）でも利用できます。

デメリット

• プロキシや NAT 環境に弱い（負荷が偏る）
• 企業や学校などのネットワークでは、数百人のユーザーが「1つのグローバル IP（プロキシサーバーの IP）」を共有してアクセスしてくることがあります。

この場合、ロードバランサーは「全員同じ人」と判定してしまい、その数百人のアクセスを全て「サーバーA」だけに集中させてしまいます。 これでは負荷分散になりません。

Cookie Persistence（クッキー挿入方式）

Web ブラウザの機能である「Cookie（クッキー）」を利用する方式です。Web アプリケーションではこれが最も推奨される方式です。

ロードバランサーがレスポンスを返す際に、「あなたはサーバー A 担当ですよ」という目印（Cookie） をブラウザに埋め込みます。次回以降、ブラウザはその Cookie を持ってアクセスしてくるので、ロードバランサーは迷わずサーバー A に案内できます。

F5 BIG-IP では 「Cookie Insert」 モードが一般的です。

メリット

• 最も確実で、負荷の偏りが少ない。
• Cookie は「ブラウザごと」に保存されるため、たとえ全員が同じプロキシ経由（同じ IP アドレス）でアクセスしてきても、ユーザー一人ひとりを識別して綺麗に分散できます。

デメリット

• HTTP/HTTPS 通信でしか使えない（Web サイト専用）
• ガラケーなど、Cookie に対応していない古い端末では使えない（現在はほぼ考慮不要）

結局どっちを使えばいい？

基本的には 「Web サイトなら Cookie、それ以外なら Source IP」 と覚えておけば間違いありません。

迷ったら、まずは Cookie Persistence（Cookie Insert）を検討してください。 F5 BIG-IP を導入する案件の多くは Web システムなので、大半のケースで Cookie 方式が採用されます。

F5 BIG-IP での設定手順（GUI）

それでは、実際に BIG-IP の管理画面（GUI）を使って設定を行いましょう。 流れとしては 「1. プロファイルの作成」 → 「2. バーチャルサーバーへの適用」 の 2 ステップです。

STEP

Persistence プロファイルの作成

まずは、セッション維持のルール（プロファイル）を作成します。 既存のデフォルトプロファイル（cookie や source_addr）をそのまま使うこともできますが、パラメータ調整が必要になった時のために、新規作成（継承）するのがベストプラクティス です。

1. メニューから Local Traffic > Profiles > Persistence を開きます。
2. 画面右上の 「Create」 ボタンをクリックします。
3. Name に任意の名前を入力し、Parent Profile でベースとなる方式（cookie や source_addr）を選択します。

💡 タイムアウト時間について

設定画面にある 「Timeout」 という項目に注目してください。 デフォルトでは 「180秒（3分）」 に設定されています。 これは、「最後の通信から 3 分間何も通信がなければ、セッション維持を解除する（＝次は別のサーバーに振られる可能性がある）」という意味です。一般的な Web サイトではこのままで問題ありませんが、アプリの仕様に合わせて調整してください。

STEP

Virtual Server への適用

プロファイルを作っただけでは動きません。稼働しているバーチャルサーバー（VS）に紐付ける必要があります。

1. メニューから Local Traffic > Virtual Servers を開き、対象の VS 名をクリックします。
2. 上部タブの中から 「Resources」 をクリックします（ここが少し分かりにくいので注意）
3. Default Persistence Profile のプルダウンから、先ほど作成したプロファイルを選択します。
4. 「Update」 をクリックして保存します。

これで設定は完了です。この瞬間から、そのバーチャルサーバーを経由する通信は、設定したルールに従ってセッション維持が行われます。

運用コマンド（確認とクリア方法）

設定が完了したら、実際にセッション維持が効いているかを確認しましょう。 GUI でも確認できますが、リアルタイムな状況把握やトラブルシューティングには、SSH で接続して実行する CLI（tmsh）が圧倒的に便利です。

状態確認: show コマンド

現在、どのクライアント（ユーザー）が、どのサーバーに紐付いているかを確認するには、以下のコマンドを使用します。

show ltm persistence persist-records

特定のバーチャルサーバー（VS）に絞って見たい場合は、以下のように指定します。

show ltm persistence persist-records virtual <VS名>

▼ コマンド出力の見方

Sys::Persistent Connections
source-address  10.0.0.100:0  172.16.0.101:80  (tmm: 0)
Total records returned: 1

• 10.0.0.100: クライアント（ユーザー）の IP アドレス
• 172.16.0.101: 振り分け先のサーバー（Pool Member）の IP アドレス

この表示が出ていれば、「10.0.0.100 からの通信は、今は 172.16.0.101 に固定されているよ」 ということがわかります。

セッション削除: delete コマンド

動作テストをしている時など、「負荷分散のテストをしたいのに、パーシステンスが効いていてずっと同じサーバーに繋がってしまう！」ということがあります。 そんな時は、手動でセッション情報をクリア（削除）して、リセットすることができます。

すべてのセッション情報を削除する場合

delete ltm persistence persist-records

特定のクライアントIPだけ削除する場合

delete ltm persistence persist-records client-address <クライアントIP>

このコマンドを打つと、記憶されていた紐付けが消去されます。 その直後のアクセスでは、ロードバランシングのアルゴリズム（ラウンドロビンなど）に従って、改めて接続先サーバーが決定されます。

まとめ

本記事では、ロードバランサー運用に欠かせない 「セッションパーシステンス（Sticky Session）」 について解説しました。重要なポイントは以下の 3 点です。

EC サイトやログイン画面には必須

途中でサーバーが変わると「買い物かご」や「ログイン状態」が消えてしまうのを防ぐ機能

基本は Cookie 方式

Web サイトなら、プロキシ環境でも均等に分散できる 「Cookie Persistence（Cookie Insert）」 が推奨

困ったら Source IP

Cookie が使えない通信では 「Source IP Affinity」 を使うが、特定のサーバーに負荷が偏るリスクに注意する。

以上、最後までお読みいただきありがとうございました。