セッション永続性

セッション永続性は、単一の論理クライアントから発生したすべてのリクエストを単一のバックエンドwebサーバーに転送するメソッドです。キャッシュを使用してパフォーマンスを向上させたり、ログイン・セッションまたはショッピング・カートを有効にするバックエンド・サーバーは、セッション永続性の恩恵を受けることができます。

セッション永続性は、ロード・バランサの作成時またはバックエンド・セットの作成時に有効化します。既存のバックエンド・セットを編集して、セッション永続性の構成を有効化、無効化または変更することもできます。

ロード・バランシング・サービスは、セッション永続性を有効にするために、相互に排他的な2つのcookieベース構成を提供: アプリケーションcookieスティッキネスとロード・バランサのcookieスティッキネス。

ノート:

IPアドレス駆動のセッション永続性

一部の製品では、Cookieなしのセッション永続性がサポートされます。このような製品は、受信リクエストのIPアドレスに依存します。 ISPプロキシおよび企業出口ゲートウェイは、1つのIPアドレスからの多数のリクエストを発行できます。この場合、1つのバックエンド・サーバーが大量のトラフィックを引き受ける可能性があります。バックエンド・フリートは、効率的なロード・バランシングが可能ですが、一度に1つのサーバーに負荷が集中することがあります。

IPアドレス駆動型セッション永続性のもう1つの弱点は、開始元のIPアドレスが変更される可能性があることです。この場合、セッション永続性が失われたり、リクエストが間違ったバックエンド・サーバーにリダイレクトされたりする可能性があります。

アプリケーションCookieスティッキー

アプリケーションcookieセッション永続性を構成するには、cookie名のみを指定する必要があります。デフォルトでは、元のサーバーが使用できないと、永続セッション・クライアントからのトラフィックは別のバックエンド・サーバーにリダイレクトされます。このフォールバック動作は無効にできません。

ロード・バランシング・サービスは、バックエンド・サーバーが認識されたcookie名を含むSet-Cookieレスポンス・ヘッダーを送信すると、アプリケーションcookieセッション永続性(スティッキネス)をアクティブ化します。 cookie名は、バックエンド・セット構成で指定された名前と一致する必要があります。構成でmatch-allパターン( " * ")が指定されている場合、サーバーによって設定されたcookieはセッション永続性をアクティブ化します。バックエンド・サーバーがセッション永続性をアクティブ化しないかぎり、サービスは、ロード・バランサの作成時に指定されたロード・バランシング・ポリシーに従います。

要件:

ロード・バランサは、サーバー側のcookie駆動型セッション永続性をサポートするには、HTTPモードで動作している必要があります。
クライアント・コンピュータは、ロード・バランシング・セッションの永続性を動作させるには、cookieを受け入れる必要があります。

仕組み:

ロード・バランシング・サービスは、構成されたcookieやその他のリクエスト・パラメータのハッシュを計算して、その値をcookieでクライアントに送信します。 cookieに格納された値により、サービスは、後続のクライアント・リクエストを正しいバックエンド・サーバーにルーティングできるようになります。バックエンド・サーバーが定義済のcookieを変更した場合、サービスはcookieの値を再計算してクライアントに再送信します。

ノート:

Oracleでは、cookieデータを不透明なエンティティとして扱うことをお薦めします。アプリケーションでは使用しないでください。

バックエンド・サーバーは、セッション永続性cookieを削除することで、アプリケーションcookieの永続性を停止できます。 match-allパターンを使用した場合は、すべてのcookieを削除する必要があります。 cookieを削除するには、有効期限が過ぎたSet-Cookieレスポンス・ヘッダーを送信します。ロード・バランシング・サービスは、構成されたロード・バランシング・ポリシーを使用して後続のリクエストをルーティングします。

ロード・バランサのCookieスティッキネス

ロード・バランサcookieスティッキネスを構成すると、ロード・バランサはcookieをレスポンスに挿入します。 cookie内に構成されているパラメータにより、セッション・スティッキネスが有効になります。このメソッドは、独自のcookieを生成できないアプリケーションおよびwebバックエンド・サービスがある場合に役立ちます。

ロード・バランサcookieセッション永続性を構成するには、次のパラメータおよび設定を指定します:

cookie名

cookie名を指定しない場合、デフォルト名はX-Oracle-BMC-LBS-Routeです。

ノート:

バックエンド・アプリケーション・サーバーで使用されるcookie名が、ロード・バランサで使用されるcookie名と異なることを確認してください。名前の競合の可能性を最小限に抑えるために、Oracleでは、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秒以上である必要があります。この属性のデフォルト値は存在しません。値を指定しない場合、ロード・バランサはSet-cookieヘッダーにMax-Age属性を含めません。通常、クライアントまたはブラウザは、クライアントによる定義どおり、現在のセッションが終了するまでcookieを保持します。

Set-cookieヘッダーにSecure属性を含めるかどうか

Secure属性は、セキュアなプロトコルのみを使用してcookieを送信するようにクライアントまたはブラウザに指示します。

ノート:

このフィールドをtrueに設定すると、対応するバックエンド・セットとHTTPリスナーを関連付けることができません。

Set-cookieヘッダーにHttpOnly属性を含めるかどうか

HttpOnly属性は、cookieのスコープをHTTPリクエストに制限します。この属性は、HTTP以外のAPIを介してcookieにアクセスする場合に、cookieを省略するようクライアントまたはブラウザに指示します。たとえば、JavaScriptチャネルからcookieを制限します。

使用できないサーバーのフォールバックを無効にするかどうか

次の"Fallback"セクションを参照してください。

ノート:

ターゲット・バックエンド・サーバーを決定するには、パス・ルート・ルールが優先されます。ロード・バランサは、バックエンド・サーバーでセッション・スティッキネスが有効になっていること、およびcookie構成がターゲットに対して有効であることを確認します。無効なcookieは無視されます。

フォール・バック

デフォルトで、ロード・バランシング・サービスは、元のサーバーが使用できないときに、永続セッション・クライアントから別のバックエンド・サーバーにトラフィックを転送します。バックエンド・セットを構成して、このフォールバック動作を無効にできます。フォールバックを無効にすると、ロード・バランサでリクエストが失敗し、HTTP 502コードが返されます。サービスは、クライアントが永続セッションcookieを提示しなくなるまで、HTTP 502を返し続けます。

注意:

フォールバックが無効になっている場合、有効期限が遠い将来のcookieを使用すると、クライアントが停止する可能性があります。

ノート:

ロード・バランシング・サービスでは、既存の永続セッションで使用可能なdrainとマークされたサーバーが考慮されます。既存の永続セッションに含まれていない新規リクエストは、そのサーバーに送信されません。