ロード・バランサのセッション永続性
ロード・バランサでセッション永続性を使用して、単一の論理クライアントで発生したすべてのリクエストを単一のバックエンドWebサーバーに転送する方法について説明します。
セッション永続性は、単一の論理クライアントで発生したすべてのリクエストを単一のバックエンドWebサーバーに転送する方法です。キャッシュを使用してパフォーマンスを向上したり、ログイン・セッションやショッピング・カートを有効にするバックエンド・サーバーは、セッション永続性からメリットを得ることができます。
セッション永続性は、ロード・バランサの作成時またはバックエンド・セットの作成時に有効化します。既存のバックエンド・セットを編集して、セッション永続性の構成を有効化、無効化または変更することもできます。
スティッキーCookie
ロード・バランサ・サービスには、セッション永続性を有効にするために、相互に排他的な2つのCookieベースの構成が用意されています:
IPアドレス駆動型のセッション永続性
一部の製品では、Cookieなしのセッション永続性サポートが提供されています。これらの製品は、受信リクエストのIPアドレスに依存します。ISPプロキシおよび企業出口ゲートウェイは、単一のIPアドレスからの多数のリクエストを発行できます。この場合、1つのバックエンド・サーバーが大量のトラフィックを引き受ける可能性があります。バックエンド・フリートは、効率的なロード・バランシングが可能ですが、一度に1つのサーバーに負荷が集中することがあります。
IPアドレス駆動型セッション永続性のもう1つの弱点は、開始元のIPアドレスが変更される可能性があることです。この場合、セッション永続性が失われるか、リクエストが間違ったバックエンド・サーバーにリダイレクトされる可能性があります。
アプリケーションCookieスティッキネス
アプリケーションCookieセッション永続性を構成するには、Cookie名を指定して、使用できないサーバーのフォールバックを無効にするかどうかを決定します。
ロード・バランサ・サービスは、バックエンド・サーバーが認識済のCookie名を含むSet-Cookie
レスポンス・ヘッダーを送信すると、アプリケーションCookieセッション永続性(スティッキネス)をアクティブにします。Cookie名は、バックエンド・セットの構成で指定されている名前と一致する必要があります。構成ですべて一致パターンの'*'が指定されている場合、サーバーによって設定された任意のCookieでセッション永続性がアクティブになります。バックエンド・サーバーがセッション永続性をアクティブ化しないかぎり、サービスは、ロード・バランサの作成時に指定されたロード・バランシング・ポリシーに従います。
要件:
-
ロード・バランサは、サーバー側のCookie駆動型セッション永続性をサポートするには、HTTPモードで動作している必要があります。
-
クライアント・コンピュータは、ロード・バランサ・セッション永続性機能を動作させるには、Cookieを受け入れる必要があります。
仕組み
ロード・バランサ・サービスは、構成済のCookieやその他のリクエスト・パラメータのハッシュを計算して、その値をCookieでクライアントに送信します。Cookieに格納された値により、サービスは、後続のクライアント・リクエストを正しいバックエンド・サーバーにルーティングできるようになります。バックエンド・サーバーが定義済のCookieを変更した場合、サービスはCookieの値を再計算してクライアントに再送信します。
Oracleでは、Cookieデータを不透明なエンティティとして扱うことをお薦めします。アプリケーションでは使用しないでください。
バックエンド・サーバーは、セッション永続性Cookieを削除することで、アプリケーションCookie永続性を停止できます。すべて一致パターンを使用した場合は、すべてのCookieを削除する必要があります。過去の有効期限を持つSet-Cookie
レスポンス・ヘッダーを送信して、Cookieを削除できます。ロード・バランサ・サービスは、構成済のロード・バランシング・ポリシーを使用して、後続のリクエストをルーティングします。
ロード・バランサCookieスティッキネス
ロード・バランサCookieスティッキネスを構成すると、ロード・バランサによってCookieがレスポンスに挿入されます。Cookie内で構成されたパラメータにより、セッション・スティッキネスが有効になります。この方法は、独自のCookieを生成できないアプリケーションやWebバックエンド・サービスがある場合に役立ちます。
ロード・バランサのCookieセッション永続性を構成するには、次を指定します:
-
Cookie名。
Cookie名を指定しない場合、デフォルト名は
X-Oracle-BMC-LBS-Route
です。ノート
バックエンド・アプリケーション・サーバーで使用されるCookie名が、ロード・バランサで使用されるCookie名と異なっていることを確認してください。名前競合の可能性を最小限にするために、
X-Oracle-OCI-
などの接頭辞を使用することをお薦めします。バックエンド・サーバーとロード・バランサが両方とも同じ名前のCookieを挿入した場合、クライアントまたはブラウザの動作は、Cookieに関連付けられているドメイン値に応じて異なる可能性があります。(バックエンド・サーバーによって生成された)
Set-cookie
ヘッダーおよび(ロード・バランサによって生成された)Set-cookie
ヘッダーの名前とドメインの値が同じ場合、クライアントまたはブラウザではそれらを1つのCookieとして処理します。クライアントは、後続のリクエストでそれらのCookie値の1つのみを戻します。両方のSet-cookie
名が同じで、ドメイン名が異なる場合、クライアントまたはブラウザではそれらを2つの異なるCookieとして処理します。 -
Cookieが有効なドメイン。ロード・バランサによって挿入された
Set-cookie
ヘッダーには、指定された値を持つドメイン属性が含まれます。この属性にデフォルト値はありません。値を指定しない場合、ロード・バランサはドメイン属性を
Set-cookie
ヘッダーに挿入しません。ノート
-
RFC 6265 - HTTP状態管理メカニズムは、ドメイン属性が
Set-cookie
ヘッダー内に存在する場合または存在しない場合のクライアントおよびブラウザの動作を説明しています。Set-cookie
ヘッダー内のDomain
属性の値がexample.com
である場合、example.com
、www.example.com
およびwww.abc.example.com
に対してHTTPリクエストを送信する際、クライアントのCookie
ヘッダーには同じCookieが含まれます。Domain
属性が存在しない場合、クライアントは、元のリクエストが送信されたドメインに対してのみCookieを返します。 -
この属性が正しいドメイン値を指定していることを確認してください。
Set-cookie
ヘッダーのDomain
属性に元のリクエストが送信されたドメインが含まれていない場合、クライアントまたはブラウザではCookieが拒否されることがあります。RFC 6265で指定されているように、クライアントは、www.example.com
から送信されたDomain
属性値がexample.com
またはwww.example.com
のCookieを受け入れます。www.example.com
から送信されたDomain
属性がabc.example.com
またはwww.abc.example.com
のCookieは受け入れません。
-
-
Cookieが有効なURIパス。ロード・バランサによって挿入された
Set-cookie
ヘッダーには、指定された値を持つPath
属性が含まれます。クライアントでは、
request-uri
のパス部分がCookieのPath
属性と一致する(またはそのサブディレクトリである)場合にのみ、HTTPリクエストにCookieが含まれます。デフォルト値は`/`です。
-
Cookieが有効な期間。ロード・バランサによって挿入された
Set-cookie
ヘッダーには、指定された値を持つMax-Age
属性が含まれます。指定された値は、1秒以上である必要があります。この属性のデフォルト値は存在しません。値を指定しない場合、ロード・バランサは
Max-Age
属性をSet-cookie
ヘッダーに含めません。通常、クライアントまたはブラウザは、クライアントによる定義どおり、現在のセッションが終了するまでCookieを保持します。 -
Set-cookie
ヘッダーにSecure
属性を含めるかどうか。Secure
属性は、セキュア・プロトコルを使用している場合にのみ、Cookieを送信するようクライアントまたはブラウザに指示します。ノート
このフィールドをtrueに設定した場合、対応するバックエンド・セットをHTTPリスナーに関連付けることはできません。
-
Set-cookie
ヘッダーにHttpOnly
属性を含めるかどうか。HttpOnly
属性は、CookieのスコープをHTTPリクエストに制限します。この属性は、HTTP以外のAPIを介してCookieにアクセスする場合に、Cookieを省略するようクライアントまたはブラウザに指示します。たとえば、JavaScriptチャネルからCookieを制限します。 -
使用できないサーバーのフォールバックを無効にするかどうか。
パス・ルート・ルールが優先され、ターゲット・バックエンド・サーバーが決定されます。ロード・バランサは、セッション・スティッキネスがバックエンド・サーバーに対して有効であること、およびCookie構成がターゲットに対して有効であることを検証します。無効なCookieは無視されます。
フォールバック
デフォルトで、ロード・バランサ・サービスは、元のサーバーが使用できないときに、永続セッション・クライアントから別のバックエンド・サーバーにトラフィックを転送します。このフォールバック動作を無効にするようにバックエンド・セットを構成できます。フォールバックを無効にすると、ロード・バランサでリクエストが失敗し、HTTP 502コードが返されます。サービスは、クライアントが永続セッションCookieを提示しなくなるまで、HTTP 502を返し続けます。
フォールバックが無効の場合、将来の有効期限が遠いCookieによってクライアントが停止する可能性があります。
ロード・バランサ・サービスは、drain
とマークされているサーバーを、既存の永続化セッションで使用可能であるとみなします。既存の永続化セッションに含まれない新規リクエストは、そのサーバーに送信されません。