Round-robinは設計上、各リクエストを異なるバックエンドに送ります。ステートレスなサービスには理想的です。しかしユーザーがログインし、カートを埋め、リモートデスクトップを開始した瞬間、アプリケーションは特定の1つのバックエンドに状態を保持し始めます。リクエスト#2が別のバックエンドに到達すると、ユーザーは空のカート、ログアウト画面、またはフリーズしたRDPセッションを見ます。
セッション永続化（または「アフィニティ」）はユーザーをセッション期間中に選択したバックエンドに固定することでこれを解決します。落とし穴：固定する方法は1つではありません。Source-IPはIPが多様なユーザーには機能しますが、企業NATの背後では壊れます。Cookieはブラウザでは機能しますが生のTCPには機能しません。URLパラメータハッシュはステートレスURLには機能しますが、ユーザースコープのフローには機能しません。各メソッドはどこかで正しい答えです。
解決策はすべてのメソッドを提供し、vServiceごとに選択することです。
各vServiceはドロップダウンから永続化メソッドを選択します — 負荷分散アルゴリズムと並んで。両方のレイヤーは独立しています：バックエンド選択にFastest+を選び、アフィニティにTR7 cookieを選ぶか、source-IPとround-robinを組み合わせるか、ワークロードに合う任意の組み合わせを選べます。メソッドの変更はホットスワップ対応、再起動不要。
5つの自己永続的な負荷分散アルゴリズム（source、URI、URLパラメータ、ヘッダー、RDP cookie）に加え、4つの明示的な永続化メソッド（TR7 cookie、バックエンドcookie、動的、SAM）。すべての一般的なケースをカバーします。
Session Affinity Managerにより、cookieソース（TR7生成またはバックエンド生成）、セッション形式（UUID、IP-timestamp-random、IP-random、カスタム）、セキュリティフラグ（HttpOnly、Secure、SameSite=Strict/Lax）を — バックエンドコードに触れずに設定できます。
永続化は負荷分散アルゴリズムの上で動作します：アルゴリズムが最初のリクエストのバックエンドを選択し、永続化が同じユーザーのその後のリクエストを固定します。コールドスタートにFastest+、セッションにスティッキーcookie — 組み合わせて機能します。
ライブvServiceで永続化メソッドを変更すると、新しいセッションはすぐに新しいメソッドを採用します。既存の固定されたセッションは有効期限が切れるまで中断なく継続します。
プロトコル、クライアント集団、アプリケーションのセッションモデルに合ったメソッドを選択します。9つすべてがvServiceごとに利用可能 — コードなし、プラグインなし。
同じクライアントIPは常に同じバックエンドに到達します。シンプルでコード不要、任意のプロトコルで動作します。クライアントIPが多様な場合に最適 — 共有NATや企業プロキシの背後では機能しません。
URL長でハッシュし、URL複雑度で負荷を分散しながら同一URLを同じバックエンドに固定します。キャッシュアフィニティシナリオに有用です。
特定のクエリパラメータ（例：?user_id、?session_token）でハッシュします。cookieを必要とせずに同一ユーザースコープのリクエストを同じバックエンドにルーティングします。
カスタムHTTPヘッダーでハッシュします。上流の呼び出し元がテナントまたは相関IDを挿入する場合、またはヘッダーベースのA/Bルーティングに有用です。
プロトコルネゴシエーションに埋め込まれたRDPセッションcookieを読み取ります。RDPゲートウェイとリモートデスクトップファームに必要 — 再接続後もユーザーを同じRDPホストに固定します。
TR7 ADCがアフィニティcookieを自身で生成・管理します — バックエンドコード不要。オペレーターはcookie名と最大アイドルタイムアウトを設定します。ADCは各リクエストでcookieを読み取り、バックエンドはcookieを無視します。レガシーアプリへの追加に最も簡単な永続化方法です。
アプリケーション自身のセッションcookieをアフィニティに使用します — オペレーターはcookie名（PHPSESSID、JSESSIONID、app-id、任意のカスタム名）を指定し、TR7 ADCが既存の値を読み取ります。新規cookieは追加されません。アプリケーションがすでにセッションを追跡しており、2番目のcookieを重ねたくない場合に適切です。
メモリに保持されるハッシュキー永続化テーブル。各エントリはキー（リクエストヘッダー、cookie、source IP、URLパラメータの任意の組み合わせ）をバックエンドにマッピングします。オペレーターはテーブルサイズ（10Kから1億エントリ、デフォルト300万）とエントリ有効期限を設定します。永続化ルールが単一固定のcookieやヘッダーより柔軟性を必要とする場合に使用します。
高度なcookieベースの永続化エンジン。cookieを生成する主体、セッションID形式、セキュリティフラグをすべてUIから選択できます — バックエンドの変更なし。詳細は下記をご参照ください。
SAMはTR7の最も柔軟な永続化メソッドです。プレーンcookieがセッションを固定するのに対し、SAMはcookieのすべてのプロパティをドロップダウンから制御できます — バックエンドの変更なし、ルールコードの記述なし。
アフィニティcookieを生成する主体を選択します：TR7生成（デフォルト — バックエンドの関与なし）またはバックエンド生成（アプリケーションの既存セッションcookieを使用）。アクティブなセッションを壊さずに切り替えられます。
セッション識別子形式の選択肢：UUID（ランダム128ビット）、IP-timestamp-random（追跡可能、時間順）、IP-random（テナント内で匿名）、またはカスタム。カスタムモードはトラフィック変数サーフェスを全開放します — 任意のリクエストヘッダー、cookie、URLコンポーネント、TLSセッション情報、source IP（生またはマスク済み）、JWTクレーム、クエリパラメータ、リクエストボディフィールドをオペレーター定義の変換関数（マスキング、ハッシュ化、部分文字列抽出、大文字小文字正規化、連結）と組み合わせられます。同じ変数と変換エンジンが動的永続化ハッシュキーも動作させます。
Cookieセキュリティフラグ：HttpOnly（JavaScriptアクセス禁止 — XSS保護）、Secure（HTTPSのみ）、SameSite=Strict（クロスサイト送信なし — CSRF保護）、SameSite=Lax（互換性重視のバリアント）。必要に応じて組み合わせてください。
上記のすべてはSAMパネルのvServiceごとのドロップダウンです。カスタムルールコードなし、バックエンド統合なし、cookie処理のための別途WAAProールなし。SAMは設定であり、スクリプトではありません。
SAMカスタム形式と動的永続化ハッシュキーはTR7 ADCが認識するすべてのトラフィック変数を受け付けます — 組み合わせ、変換し、アプリケーションに必要な正確な永続化ルールを構築します
ユーザーが複数のページロードをまたいで商品を追加します。バックエンドcookieまたはTR7 cookieがカートの状態を1つのバックエンドに保持します — チェックアウト時に空のカートになることはありません。
ユーザーの権限キャッシュが1つのバックエンドに存在するログイン済みセッション。TR7生成cookie + HttpOnly + SecureによるSAMはバックエンドコードの変更なしで機能します。
RDPセッションは同じホストに再接続する必要があります。RDP cookie永続化はプロトコルネイティブのセッションIDを読み取ります — 追加設定なし、cookie注入なし。
セッション自体を追跡しないアプリケーション。Source-IPまたはURLパラメータ永続化がレガシーアプリへのコード変更なしにユーザーを固定します。
RDPゲートウェイからレガシーアプリ、SAM制御cookieまで、9つの永続化メソッドがすべての一般的なケースをカバーする方法をご覧ください。