Oracle Cloud Infrastructureドキュメント

セッション永続性

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

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

スティッキCookie

「ロード・バランシング」サービスには、セッションの永続性を有効にする2つの相互に排他的なCookieベースの構成があります:

ノート

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

クッキーなしでセッション永続性サポートを提供する製品もあります。 これらの製品は、着信リクエストのIPアドレスによって異なります。 ISPプロキシおよび企業出口ゲートウェイは、単一のIPアドレスから多くのリクエストを発行できます。 この場合、1つのバックエンド・サーバーにトラフィック量が大きくなる可能性があります。 効果的なロード・バランシングが可能であっても、バックエンドのフリートは一度に1台のサーバーに圧倒される可能性があります。

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

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

アプリケーションCookieセッションの永続性を構成するには、Cookie名を指定し、使用できないサーバーに対して「フォールバックを無効にします」を使用するかどうかを決定します。

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

要件:

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

実行される処理

ロード・バランシング・サービスは、構成された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名と異なることを確認してください。 名前の競合の可能性を最小限に抑えるために、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.comwww.example.comおよびwww.abc.example.comへのHTTPリクエストを行う際に、Cookieヘッダーに同じCookieを含めます。 Domain属性が存在しない場合、クライアントは、元のリクエストが行われたドメインに対してのみCookieを返します。

    • この属性に正しいドメイン値が指定されていることを確認してください。 Set-cookieヘッダーのDomain属性に、元のリクエストが行われたドメインが含まれていない場合は、クライアントまたはブラウザがCookieを拒否します。 RFC 6265で指定されたとおり、クライアントは、Domain属性値example.comまたはwww.example.comから送信されたCookieを受け入れます。 www.example.comから送信されたDomain属性abc.example.comまたはwww.abc.example.comでは、Cookieを受け入れません。

     

  • Cookieが有効なURIパス。 ロード・バランサによって挿入されるSet-cookieヘッダーには、指定した値を持つPath属性が含まれています。

    クライアントにHTTPリクエストにCookieが含まれるのは、request-uriのパス部分が一致するか、CookieのPath属性のサブディレクトリである場合のみです。

    デフォルト値は/です。

  • 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を制限します。

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

ノート

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

Fallback

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

警告

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

ロード・バランシング・サービスは、既存の永続セッションでdrainとマークされたサーバーを使用できると見なします。 既存の永続セッションの一部ではない新しいリクエストは、そのサーバーに送信されません。