BIG-IP のセッションパーシステンスの設定手順｜Cookie と Source IP の違い

はじめに

Web サイトへのアクセス負荷を分散するためにロードバランサーを導入する際、運用面で最初に直面しやすいのが「セッション維持（Session Persistence）」の課題です。

ロードバランサー導入後に「商品を買い物かごに入れた後、別ページに遷移すると買い物かごが空になる」「ログイン後の操作中に意図せずログアウトする」といった事象が発生する場合、セッション維持（パーシステンス）の設定が原因となっている可能性が高い状況です。

F5 BIG-IP では「Persistence（パーシステンス）」、AWS などのクラウド環境では「Sticky Session（スティッキーセッション）」と呼ばれるこの機能は、複数サーバーで負荷分散される Web サービスの安定動作に欠かせない機能です。

本記事では、セッションパーシステンスが必要になる背景から、F5 BIG-IP で実務的に使われる Cookie Persistence と Source IP Affinity の違い・選び方、GUI / CLI での設定手順、HTTPS 環境での前提条件や SameSite 属性問題などの現代的なハマりポイントまでを整理します。

※ 本記事の手順は BIG-IP 17.5.x をベースに、BIG-IP 15.x / 16.x でも共通する内容で記載しています。BIG-IP 16.1.x は 2025 年 7 月 31 日に EoTS（End of Technical Support）に到達しているため、サポート対象バージョンの利用を推奨します。

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

セッションパーシステンスとは、ロードバランサーが「特定のクライアントからのアクセスを、一定時間、特定のサーバーに継続して転送する機能」を指します。

通常、ロードバランサーは「ラウンドロビン」「Least Connections」などのアルゴリズムでアクセスを複数サーバーに均等に分散します。しかし、Web アプリケーション側がサーバー単体でセッション情報（ログイン状態・買い物かごの内容など）を保持する設計の場合、振り分け先が途中で変わるとセッションが引き継がれず、アプリケーション動作に支障が出ます。

参考: F5 BIG-IP techdocs – Session Persistence Profiles
“You can configure persistence profile settings to set up session persistence on the BIG-IP system.”
（BIG-IP システムでセッションパーシステンスを設定するために、persistence プロファイルの設定をカスタマイズできます。）
https://techdocs.f5.com/

必要性の具体例（EC サイトの買い物かご）

セッションパーシステンスを設定しない場合の挙動を、EC サイトの買い物かごを例に整理します。

1. ユーザー A が商品を買い物かごに追加 → ロードバランサーがサーバー 1 にリクエストを振り分け、サーバー 1 にセッション情報が保持される
2. ユーザー A が「購入手続き」ボタンを押下
3. ロードバランサーが負荷分散のため、次のリクエストをサーバー 2 に振り分け
4. サーバー 2 にはユーザー A のセッション情報が存在しないため、買い物かごが空の状態として扱われる

この事象を防ぐため、「ユーザー A の通信は、購入完了までサーバー 1 に振り分け続ける」という制御を行うのがパーシステンス機能です。

※ アプリケーション側がセッション情報を共有データストア（Redis、DB 等）に保持する設計（ステートレス構成）であれば、パーシステンスは原則不要です。本機能は、サーバー個別にセッション情報を保持する設計で必要となる仕組みです。

主なパーシステンス方式

F5 BIG-IP には複数のパーシステンス方式が用意されており、F5 公式ドキュメントでは少なくとも 10 種類以上が定義されています。実務では Cookie Persistence と Source IP Affinity が最も多く採用されますが、特殊な要件では他の方式も選択肢になります。

参考: F5 BIG-IP techdocs – Session Persistence Profiles（方式一覧）
“The persistence types that you can enable using a persistence profile are: Cookie persistence, Destination Address Affinity persistence, Hash persistence, Microsoft Remote Desktop Protocol (MSRDP) persistence, …”
（persistence プロファイルで有効化できる種類は、Cookie / 宛先アドレス / Hash / MSRDP など複数あります。）
https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-5-1/11.html

Cookie Persistence（Cookie 挿入方式）

Web ブラウザの Cookie 機能を利用する方式で、Web アプリケーションでは最も多く採用される方式です。F5 BIG-IP では Cookie Persistence の中に 4 つのモードがあります。

通常は Cookie Insert モードが使われます。動作の流れは次のとおりです。

1. クライアントから初回リクエストが到着
2. ロードバランシングアルゴリズムによりプールメンバー（サーバー）が決定
3. サーバーからのレスポンスに対し、BIG-IP が BIGipServer<pool_name> という名前の Cookie を挿入してクライアントへ返却
4. クライアントは以降のリクエストでこの Cookie を送信
5. BIG-IP は Cookie の値をデコードし、対応するプールメンバーへ振り分け

参考: F5 BIG-IP techdocs – Cookie persistence（Cookie Insert の挙動）
“If you specify the HTTP Cookie Insert method within the Cookie persistence profile, the information about the server to which the client connects is inserted in the header of the HTTP response from the server as a cookie. By default, the cookie is named BIGipServer, and it includes the encoded address and port of the server handling the connection.”
（Cookie Insert を指定すると、接続先サーバーの情報が HTTP レスポンスヘッダに Cookie として挿入されます。デフォルトの Cookie 名は BIGipServer<pool_name> で、接続を処理するサーバーのエンコードされた IP アドレスとポートを含みます。）
https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-5-1/11.html

メリット

• プロキシ・NAT 環境でも分散の偏りが起きにくい（Cookie はブラウザごとに保存されるため、同じ送信元 IP でもユーザーごとに識別可能）
• BIG-IP 側のメモリに persistence-records を保持しないため、スケール時のメモリ消費が抑えられる
• アプリケーション側の改修が不要（Cookie Insert モード使用時）

デメリットと制約

• HTTP / HTTPS 通信でのみ利用可能
• Virtual Server に HTTP プロファイルが紐付いていることが前提
• HTTPS 通信では SSL 終端（Client SSL プロファイル）が必要（SSL Pass-through 構成では BIG-IP が Cookie を挿入できない）
• ブラウザが Cookie を無効化している場合は機能しない

詳細な制約とハマりポイントは、後述の「設定時のハマりポイントと制約事項」セクションで整理します。

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

クライアントの送信元 IP アドレスを識別子として、振り分け先を固定する方式です。F5 BIG-IP ではsource_addrというデフォルトプロファイルが用意されています。

参考: F5 BIG-IP techdocs – Configuring HTTP Load Balancing with Source Address Affinity Persistence
“Source address persistence supports the TCP and UDP protocols and directs traffic to the same server based upon the client’s source IP address. A limitation to source address persistence is when traffic transverses a NAT or proxy device, in which all connections appear to originate from a single IP.”
（Source Address persistence は TCP と UDP プロトコルをサポートし、クライアントの送信元 IP アドレスに基づいて同一サーバーへトラフィックを振り分けます。NAT やプロキシを経由すると、すべての接続が単一 IP 由来に見えるという制限があります。）
https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-implementations-12-1-0/11.html

メリット

• 設定が簡潔
• HTTP 以外のプロトコル（TCP / UDP）でも利用可能
• HTTP プロファイルや SSL 終端が不要（L4 レベルで動作）

デメリットと制約

• プロキシ・NAT 環境では分散の偏りが発生: 企業ネットワークやモバイルキャリアの CGN（Carrier-Grade NAT）環境では、複数ユーザーが同一の送信元 IP として見えるため、特定のサーバーに集中する事象が発生
• persistence-records が BIG-IP のメモリに保持される: 大規模環境では Cookie 方式と比べてメモリ使用量が増える
• HA フェイルオーバー時、Mirror Persistence 設定がない場合は records が消失する

その他の方式

特殊な要件では以下の方式も選択肢になります（詳細は後述の比較表を参照）。

• Destination Address Affinity: 宛先 IP に基づく分散
• SSL Session ID Persistence: SSL Pass-through 環境での代替策
• Hash Persistence: iRule で柔軟にハッシュキーを定義
• MSRDP Persistence: Microsoft RDP セッションでの利用
• Universal Persistence: iRule で任意の値（HTTP ヘッダ、URI、JSESSIONID 等）をキーに使用

パーシステンス方式の比較と選定ガイド

F5 BIG-IP のパーシステンス方式は多数あり、運用環境やアプリケーションの特性に応じた選定が必要です。実務でよく検討される方式を整理し、シーン別の推奨パターンを提示します。

方式別の比較表

参考: F5 BIG-IP techdocs – Session Persistence Profiles
“The persistence types that you can enable using a persistence profile are: Cookie persistence, Destination Address Affinity persistence, Hash persistence, Microsoft Remote Desktop Protocol (MSRDP) persistence, SIP persistence, SSL persistence, Source Address Affinity persistence, Universal persistence.”
https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-5-1/11.html

シーン別の推奨方式

「迷ったら Cookie Insert」が定石な理由

Web アプリで Cookie Insert が多く採用されるのは、以下の理由によります。

分散の偏りが起きにくい

Cookie はブラウザごとに保存されるため、プロキシ・NAT 環境でもユーザー単位で識別可能

アプリ側の改修が不要

BIG-IP がレスポンスに Cookie を自動で挿入するため、サーバー側のアプリケーションコードに変更を加える必要がない。

BIG-IP のメモリ消費が少ない

persistence テーブルにレコードを作らないため、大規模環境でもメモリ使用量がスケールしやすい。

F5 公式ドキュメントの第一推奨方式

HTTP Cookie Insert は Cookie 方式の中でデフォルト値として設定されている。

ただし後述のとおり、HTTPS 環境での前提条件・SameSite 属性問題・Cookie 情報漏洩など、現代の Web 環境では Cookie Insert にも考慮事項があります。

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

実際に BIG-IP の管理画面（GUI）から設定する手順を解説します。流れは「1. プロファイルの作成」→「2. Virtual Server への適用」の 2 ステップです。

STEP

Persistence プロファイルの作成

セッション維持のルール（プロファイル）を作成します。デフォルトの cookie / source_addr プロファイルをそのまま使うこともできますが、タイムアウト調整や Cookie 暗号化などのカスタマイズに備えて新規作成（親プロファイルから継承）する形を推奨します。

1. メニューから Local Traffic > Profiles > Persistence を開く
2. 画面右上の [Create] ボタンをクリック
3. Name に任意の名前を入力（例: my_cookie_persist）
4. Persistence Type（または Parent Profile）でベースとなる方式（cookie / source_addr 等）を選択
5. 必要に応じてオプションをカスタマイズし、[Finished] をクリック

※ Timeout（タイムアウト時間）はデフォルトで 180 秒（3 分）に設定されています。これは「最後の通信から 3 分間通信がなければセッション維持を解除する」という意味です。長時間の操作を想定するアプリケーション（例: オンライン申請、設定編集画面）では 1800 秒（30 分）程度への延長を検討することを推奨します。

STEP

Virtual Server への適用

作成したプロファイルを Virtual Server に紐付けます。

1. メニューから Local Traffic > Virtual Servers を開き、対象 Virtual Server 名をクリック
2. 画面上部のタブから [Resources] タブを選択
3. Default Persistence Profile のプルダウンから、作成したプロファイルを選択
4. （任意）Fallback Persistence Profile で、主要方式が機能しなかった場合のフォールバック方式を選択（例: Cookie が無効化されたクライアント向けに Source IP を設定）
5. [Update] をクリックして保存

※ HTTPS の Virtual Server で Cookie Persistence を適用する場合、HTTP プロファイル + Client SSL プロファイル（バックエンドも暗号化する場合は Server SSL も）が事前に紐付いている必要があります。HTTP プロファイルなしで Cookie Persistence を適用しようとすると、BIG-IP がエラーで適用を拒否します。

CLI（tmsh）での設定手順

GUI と同等の操作は tmsh からも実行できます。

# Cookie Persistence プロファイルの作成（cookie を親プロファイルとして継承）
tmsh create ltm persistence cookie my_cookie_persist defaults-from cookie timeout 1800

# Source IP Persistence プロファイルの作成
tmsh create ltm persistence source-addr my_srcip_persist defaults-from source_addr timeout 1800

# Virtual Server への適用
tmsh modify ltm virtual <VS名> persist replace-all-with { my_cookie_persist }

# 設定の保存
tmsh save sys config

参考: F5 BIG-IP techdocs – Configuring HTTP Load Balancing with Cookie Persistence
https://techdocs.f5.com/en-us/bigip-14-0-0/big-ip-local-traffic-manager-implementations-14-0-0/configuring-http-load-balancing-with-cookie-persistence.html

設定時のハマりポイントと制約事項

実務でセッションパーシステンスを設定する際に遭遇しやすい制約と、その対処を整理します。特に SameSite 属性と Cookie 暗号化は、現代の Web 環境では検討必須の項目です。

制約 1: HTTPS 環境では SSL 終端と HTTP プロファイルが必要

Cookie Persistence は HTTP / HTTPS の通信内容（Cookie ヘッダ）を BIG-IP が読み書きすることで成立します。HTTPS 通信では暗号化されているため、BIG-IP が SSL を終端し、平文で HTTP ヘッダを処理できる構成が前提となります。

参考: ADC Labs – Source IP and Cookie Persistence profile
“The F5 Big IP doesn’t let you apply this profile. To perform manipulation on the HTTP layer (inserting cookie), the virtual server needs a HTTP profile.”
（BIG-IP は Cookie Persistence プロファイルの適用を許可しません。HTTP レイヤーでの操作（Cookie の挿入）には、Virtual Server が HTTP プロファイルを持っている必要があります。）
https://adc-labs.net/source-ip-and-cookie-persistence-profile/

必要な構成は次のとおりです。

制約 2: SameSite 属性問題（Chrome 80+ 環境）

2020 年 2 月の Chrome 80 リリース以降、ブラウザは Set-Cookie に SameSite 属性が指定されていない Cookie を SameSite=Lax として扱うようになりました。これにより、クロスドメイン環境（iframe 埋め込み、OAuth / SAML 認証フロー）で Cookie が送信されない事象が発生する場合があります。

BIG-IP のデフォルトでは、BIGipServer Cookie に SameSite 属性が付与されないため、以下のような構成で問題が顕在化することがあります。

• iframe で別ドメインのコンテンツを埋め込んでいる Web サイト
• SAML / OAuth 認証で IdP と SP が別ドメイン
• サードパーティ Cookie として送信される Cookie

対処方法

F5 公式は SameSite 属性を付与するための iRule を提供しています。

参考: F5 K61062410 – Insert SameSite cookie attribute into the F5 persistence cookie
https://my.f5.com/manage/s/article/K61062410

# iRule 例: BIGipServer Cookie に SameSite=None; Secure を付与
when HTTP_RESPONSE_RELEASE {
    set persist_cookie "BIGipServer[LB::server pool]"
    HTTP::cookie attribute $persist_cookie insert "SameSite" "None"
    HTTP::cookie secure $persist_cookie enable
}

※ SameSite=None を指定する場合、Secure 属性も必須（HTTPS 通信でのみ送信される設定）。HTTP では機能しません。クロスドメイン要件がない場合は、SameSite=Lax または Strict の指定で十分です。

BIG-IP 14.1 以降では、HTTP プロファイル側で Cookie の SameSite 属性を統一的に制御する設定も提供されているため、iRule での個別対応の代わりに HTTP プロファイル設定での対応も検討できます。

制約 3: Cookie の情報漏洩リスクと暗号化

BIGipServer<pool_name> Cookie は、デフォルトで平文（エンコードされた状態）で発行されます。エンコードされていますが、仕様が公開されているため、デコードすると振り分け先サーバーの IP アドレスとポートが復元可能です。これはペネトレーションテストや Web アプリケーション脆弱性スキャナでも検知対象として扱われています。

参考: Invicti – F5 BIG-IP Cookie Information Disclosure
“Configure cookie encryption within the HTTP profile by setting the ‘Encrypt Cookies’ option and specifying a passphrase. … Or enable encryption directly in the cookie persistence profile by configuring the ‘Cookie Encryption’ settings.”
（HTTP プロファイルの「Encrypt Cookies」オプションでパスフレーズを設定するか、Cookie Persistence プロファイルの「Cookie Encryption」設定で暗号化を直接有効化できます。）

推奨する対策の組み合わせは次のとおりです。

セキュリティ要件が厳しい環境では、Cookie 暗号化の有効化と Cookie 名の変更をセットで実施することを推奨します。

制約 4: HA 構成での persistence-records の扱い

HA 構成（Active / Standby）の BIG-IP では、Source IP 等のテーブル記録型方式における persistence-records は、デフォルトでは Active 機にのみ保持されます。フェイルオーバーが発生した場合、Standby から Active へ昇格した機器には records が存在せず、フェイルオーバー直後にユーザーの振り分け先が変わる可能性があります。

Persistence プロファイルの Mirror Persistence オプションを有効化することで、persistence-records が Active から Standby へリアルタイムに同期されます。

# Mirror Persistence を有効化（Source IP プロファイル例）
tmsh modify ltm persistence source-addr my_srcip_persist mirror enabled

※ Cookie Insert 方式では persistence テーブルを使わないため、Mirror Persistence の影響を受けません。フェイルオーバー後も Cookie の値が維持されている限り、振り分け先は維持されます（Cookie 方式が HA 構成にも強い理由のひとつ）。

制約 5: CGN・モバイルキャリア環境での Source IP 偏り

モバイルキャリアの CGN（Carrier-Grade NAT）環境では、数千〜数万のユーザーが同一の送信元 IP として観測されるケースがあります。Source IP Affinity ではこれらのユーザーが同じサーバーに集中するため、負荷分散が事実上機能しない状況になります。

CGN や CDN 経由のトラフィックを扱う環境では、Cookie Persistence への切り替え、または X-Forwarded-For ヘッダを使った Universal Persistenceの利用を検討することを推奨します。

制約 6: Match Across 系オプションの理解

Persistence プロファイルには、複数 Virtual Server / Pool 間でセッションを共有できる Match Across 系オプションがあります。

これらはマルチサービス構成（HTTP + HTTPS、Web + API）で同一ユーザーを同一バックエンドに維持したい場合に有効ですが、設計を誤ると意図しないサーバーへ振り分けられる挙動につながります。実装前に検証環境での動作確認を推奨します。

動作確認とトラブルシュート

設定後、パーシステンスが意図どおりに動作しているかを確認します。確認方法は方式によって大きく異なる点に注意が必要です。

Source IP Persistence の確認（CLI）

Source IP Persistence は BIG-IP 内部の persistence テーブルに記録が保持されるため、tmsh から確認できます。

# すべての persistence-records を表示
tmsh show ltm persistence persist-records

# 特定の Virtual Server に絞って表示
tmsh 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

Cookie Insert Persistence の確認（ブラウザ）

Cookie Insert は BIG-IP の persistence テーブルにレコードを作成しません。Cookie の値そのものに振り分け先サーバーの情報がエンコードされて格納される仕組みのため、tmsh show ltm persistence persist-records を実行してもエントリが表示されないのが正常な挙動です。

参考: ADC Labs – F5 Big-IP: Deploy and apply Persistence profile
“Some persistence methods, such as most Cookie persistence modes (for example Cookie Insert), do not require entries in the persistence table because the persistence information is stored directly in the client cookie. In these cases, the persistence table may show no entries.”
（Cookie Insert などの一部の Cookie persistence 方式では、persistence 情報がクライアントの Cookie に直接保存されるため、persistence テーブルにエントリは作成されません。）
https://adc-labs.net/courses/f5-big-ip-deploy-and-apply-persistence-profile/

Cookie Insert の動作確認は、ブラウザの Developer Tools（開発者ツール）から Cookie を確認する方法が正解です。

確認手順

1. ブラウザで Virtual Server へアクセス
2. ブラウザの Developer Tools（Chrome / Edge / Firefox は F12 キー）を開く
3. Application（または Storage）タブの Cookies セクションを表示
4. BIGipServer<pool_name> という名前の Cookie を確認（Cookie 暗号化や Cookie 名変更を実施している場合はその名前で表示）
5. 値（例: 1677787402.20480.0000）がエンコードされた振り分け先サーバーの IP / ポート情報

persistence-records の手動削除

動作テストや負荷分散のリバランス時に、persistence-records を手動でクリアできます（Source IP 等のテーブル記録型方式に対して有効）。

# すべての persistence-records を削除
tmsh delete ltm persistence persist-records all

# 特定のクライアント IP を削除
tmsh delete ltm persistence persist-records client-addr <クライアントIP>

※ Cookie Insert で記録をリセットしたい場合は、ブラウザ側で対象 Cookie を削除する必要があります。BIG-IP 側からは制御できません。

まとめ

本記事では、F5 BIG-IP のセッションパーシステンスについて、Cookie 方式と Source IP 方式の違いと選び方を整理しました。Web アプリでは Cookie Insert が基本となり、プロキシ環境でも分散の偏りが起きにくくアプリ改修も不要です。確認方法や SameSite 属性、HA 構成での挙動といった実務上の注意点を押さえておくことが、安定運用につながります。

• サーバーごとのセッション情報を保持し、Web アプリの安定動作を支える機能
• Web アプリでは分散の偏りが少なくアプリ改修も不要な Cookie Insert が基本
• Cookie Persistence は HTTP プロファイルが前提で、HTTPS では SSL 終端が必要
• Cookie Insert は persist-records では確認できず、ブラウザの開発者ツールで確認
• BIGipServer Cookie は平文で IP とポートが復元可能なため暗号化と名称変更を推奨
• SameSite 属性問題は iRule または HTTP プロファイル設定で対処
• HA 構成の Source IP 方式は Mirror Persistence で records を同期、Cookie 方式は影響なし

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