Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

セッションアフィニティ

最終更新 Markdown で表示Agent セットアップ

セッションアフィニティを有効にすると、ロードバランサーは特定のエンドユーザーからのリクエストを、すべて同じエンドポイントへ送ります。この継続性により、ショッピングカートの中身など、複数サーバーにリクエストが分散すると失われる可能性のあるユーザーセッション情報を保てます。

セッションアフィニティはネットワークリクエストの削減にもつながり、従量課金のお客様はコストを抑えられます。

種類

セッションアフィニティは、"none" または ""(デフォルト)を指定しない限り、ロードバランサーが使うセッションアフィニティの種類を指定します。

プロキシされたロードバランサーへの最初のリクエストで、リクエストの転送先エンドポイント情報をエンコードした cookie が生成されます。同じクライアントから同じロードバランサーへの後続リクエストは、cookie の有効期間中、かつエンドポイントが健全なあいだ、その cookie が示すエンドポイントに送られます。cookie の期限が切れた場合、またはエンドポイントが不健全な場合は、新しいエンドポイントが計算されて使われます。

仕組み

セッションアフィニティは、同じクライアントからのリクエストを自動で同じエンドポイントに送ります。

  1. クライアントが最初のリクエストを送ると、Cloudflare はクライアントに __cflb cookie を設定します(関連するエンドポイントを追跡するため)。
  2. 同じクライアントからの後続リクエストは、cookie の有効期間中、かつエンドポイントが健全なあいだ、そのエンドポイントへ転送されます。
  3. cookie の期限が切れた場合、またはエンドポイントが不健全になった場合、Cloudflare は新しいフェイルオーバーエンドポイントを追跡する新しい cookie を設定します。
    flowchart LR
      accTitle: セッションアフィニティの処理
      accDescr: セッションアフィニティは、同じクライアントからのリクエストを同じサーバーに送ります。
     A[クライアント] --リクエスト--> B{<code>__cflb</code> cookie 設定済み?}
     B -->|はい| C[以前のエンドポイントへルーティング]
     C --> O2
     B ---->|いいえ| E[通常のルーティングに従う]
     E --> O2
     E --<code>__cflb</code> cookie を設定--> A
     subgraph P1 [Pool 1]
        O1[Endpoint 1]
        O2[Endpoint 2]
     end

Cookie ベースのセッションは、カスタムのセッション Time to live(TTL)を設定しない限り、デフォルトで 23 時間です。

Always Use HTTPS が有効な場合、セッション cookie はセキュアです。加えて、クロスサイトスクリプティング攻撃を防ぐため、cookie では HttpOnly が常に有効です。

cookie と似た動作ですが、最初のエンドポイント選択は安定しており、クライアントの IP アドレスに基づきます。

HTTP ヘッダー

プロキシされたロードバランサーへの最初のリクエストで、設定した HTTP ヘッダーに基づくセッションキーが生成されます。セッションキーは、ロードバランサーのセッション状態でリクエストの転送先エンドポイントを保存するために使うリクエストヘッダーをエンコードします。同じヘッダーを持つ後続リクエストは、セッションの有効期間中、かつエンドポイントが健全なあいだ、同じエンドポイントに送られます。セッションアフィニティの TTL 秒のあいだアイドルだった場合、またはエンドポイントが不健全な場合は、新しいエンドポイントが計算されて使われます。

ヘッダーの使い方を制御する

デフォルトでは、HTTP ヘッダーによるセッションアフィニティを設定したヘッダーのうち、少なくとも 1 つがロードバランサーへのリクエストに含まれている必要があります。これがないと、ヘッダーベースのセッションは作成されません。クライアントがリクエストの HTTP ヘッダーを追加または削除し、すでにセッションがある場合は、後続リクエストで見つかった新しい HTTP ヘッダーに基づいて新しいセッションが作成されます。ただし、そのヘッダーが設定に含まれている場合に限ります。

セッション作成のために、設定した HTTP ヘッダーがすべてリクエストに必要になるようにするには、Cloudflare API で session_affinity_attributes.require_all_headerstrue に設定するか、ロードバランサーの編集時に Cloudflare ダッシュボードで Require all headersenabled に切り替えます。


Cloudflare ダッシュボードでセッションアフィニティを有効にする

セッションアフィニティは、ロードバランサーの作成または編集 時の Hostname ステップで有効にします。

セッションアフィニティを有効にした場合は、次のいずれかを選びます。

  • By Cloudflare cookie only: __cflb cookie を設定し、関連するエンドポイントを追跡します。
  • By Cloudflare cookie and Client IP fallback: __cflb cookie を設定し、セッションアフィニティ cookie がない場合はクライアント IP アドレスも使います。
  • By HTTP header

Cloudflare API でセッションアフィニティを有効にする

セッションアフィニティはロードバランサーのプロパティです。次のエンドポイントで設定できます。

session_affinitysession_affinity_ttlsession_affinity_attributes パラメーターで、セッションアフィニティの動作をカスタマイズできます。

HTTP ヘッダーによるセッションアフィニティを有効にするには、session_affinity の値を header に設定し、HTTP ヘッダー名を session_affinity_attributes.headers に追加します。

API コマンドの具体的な使い方は、API でロードバランサーを作成する を参照してください。


Endpoint Drain

Endpoint Drain を使うと、アクティブな顧客に影響を与えずに、エンドポイントからトラフィックを徐々に減らしたり取り除いたりできます。Endpoint Drain の詳細は、計画メンテナンスの実施 を参照してください。

Zero-Downtime Failover

Zero-Downtime Failover は、一時的なネットワーク障害のあいだ、プール内のエンドポイントへトラフィックを自動で送ります。アクティブなヘルスモニターの合間に問題が起きても、ユーザーに表示されるエラーを減らせます。

次の 3 つのオプションのいずれかを有効にできます。

  • None: フェイルオーバーは行われず、ユーザーにエラーが表示されることがあります。
  • Temporary: もともとピン留めされていたエンドポイントが利用可能になるまで、ほかのエンドポイントにトラフィックが送られます。
  • Sticky: セッションアフィニティ cookie が更新され、以降のリクエストは必要に応じて新しいエンドポイントに送られます。

役に立ちましたか?