セッション永続性

セッション永続性はCompute Cloud@Customerでサポートされています。

ヒント

Cookieベースのセッション永続性は、デフォルトでは提供されません。特定の実装を有効にするために定義済タグが適用されている場合、アプリケーション・ロード・バランサで使用できます。詳細は、LBaaS「実装オプション」を参照してください。

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

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

ロード・バランシング・サービスには、セッション永続性を有効にするための、相互に排他的な2つのCookieベースの構成(アプリケーションCookieスティッキネスとロード・バランサの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の値を再計算してクライアントに再送信します。

ノート

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.comwww.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は受け入れません。

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

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

ノート

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

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

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

これらのパラメータは使用できません。

Cookieが有効な期間。

ロード・バランサによって挿入されたSet-cookieヘッダーの最大経過時間属性(maxAgeInSeconds)を指定しないでください。また、デフォルト値もありません。クライアントまたはブラウザは通常、クライアントによる定義どおり、現在のセッションが終了するまでCookieを保持します。

Cookieが有効なURIパス。

ロード・バランサによって挿入されたSet-cookieヘッダーのパス属性を指定しないでください。デフォルト値("/")は常に使用されます。

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

次のフォールバックセクションを参照してください。

Fallback

デフォルトで、ロード・バランシング・サービスは、元のサーバーが利用できないときに、永続セッション・クライアントから別のバックエンド・サーバーにトラフィックの転送を行います。このフォールバック動作を無効にするようにバックエンド・セットを構成することはできません。

ノート

ロード・バランシング・サービスは、ドレインとマークされたサーバーを、既存の永続化セッションで使用可能であるとみなします。既存の永続化セッションに含まれない新規リクエストは、そのサーバーに送信されません。