HeaderField アフィニティ機能は、HTTP リクエストヘッダーの指定されたフィールドに基づいて、リクエストを同じ関数インスタンスにルーティングします。クライアントが提供するセッション ID を使用することも、サーバーで生成されたセッション ID を使用することもできます。
基本設定
関数の設定ページで、[詳細設定] > [分離とアフィニティ] に移動します。[セッション保持] スイッチをオンにし、[HeaderField アフィニティ] を選択して、[ヘッダー名] (例：mySessionId)、[インスタンスあたりの同時セッション数]、および [セッションライフサイクル設定] を設定します。[デプロイ] をクリックして機能を有効にします。
クライアントは、リクエストヘッダーにカスタムセッション ID を含めることができます。または、サーバーが自動的にセッション ID を生成し、レスポンスヘッダーで返すこともできます。
適用範囲
一般的な制限：詳細については、「セッション保持の一般的な制限と原則」をご参照ください。
セッション ID のソース：
クライアントが事前定義されたヘッダーでセッション ID を渡した場合、この値がセッション ID として使用されます。
長さ：1～64 文字。
英字、数字、またはアンダースコア (_) で始まり、その後に英字、数字、アンダースコア (_)、またはハイフン (-) が続く文字列である必要があります。
ID が渡されない場合、サーバーはグローバルに一意なセッション ID を生成します。この ID は、関数作成時に指定したヘッダーフィールドを使用してレスポンスヘッダーで返されます。
ヘッダーフィールドの定義：関数を作成する際に、
SessionAffinityConfigでセッション ID を渡すためのヘッダーフィールド名を指定します。リクエストの制限
1 つのインスタンスで複数のセッションを同時に処理できます。デフォルト値は 20、最大値は 200 です。インスタンスにアタッチされたセッション数が上限に達すると、システムは自動的に新しいインスタンスを作成します。
複数のセッションは、インスタンスの同時実行クォータである 200 を共有します。
SessionAPI 管理サポート：SessionAPI を使用して、セッションの作成、更新、クエリ、終了など、セッションライフサイクルを管理できます。
HeaderField アフィニティの設定
プロセスの概要
HeaderField アフィニティの設定には、セッション保持の有効化、HeaderField タイプの選択、ヘッダー名の設定、および関数をデプロイする前のパラメーター設定の 4 つのステップが含まれます。この設定は、関数の作成時、または既存の関数に追加するときに実行できます。
セッション保持の有効化
Function Compute コンソールにログインします。
関数リストで、対象の関数を選択するか、関数を作成します。
関数を作成するときは、[詳細設定] セクションに移動します。[アイソレーションとアフィニティ] 設定を見つけ、関数を作成する前に設定します。
関数の詳細ページで、[設定] タブをクリックします。
[高度な設定] セクションで、[アイソレーションとアフィニティ] 設定を探します。
[アイソレーション・アフィニティ] をクリックして、構成パネルを展開します。
[セッションアフィニティ] スイッチをオンにします。
HeaderField アフィニティタイプの選択
セッション保持の構成セクションで、[HeaderField Affinity] ラジオボタンを選択します。
HeaderField アフィニティの設定オプションが自動的に表示されます。
ヘッダー名の設定
目的：セッション ID を渡すために使用される HTTP リクエストヘッダーの名前を指定します。
手順：
[ヘッダー名] 入力ボックスに、カスタムヘッダー名を入力します。
命名規則：
x-fc-プレフィックスで始まってはいけません。英字で始まる必要があります。
後続の文字には、数字、ハイフン、アンダースコア、英字を使用できます。
長さ：5～40 文字。
例：
mySessionId、session-id、customSessionId。推奨事項：識別とメンテナンスを容易にするために、意味のある名前を使用することを推奨します。
セッションパラメーターの設定
目的：セッション数、ライフサイクル期間、アイドル時間を設定して、セッションのアタッチとリソース使用量を制御します。
手順：
インスタンスあたりの同時セッション数: 単一のインスタンスが同時に処理できるセッションの最大数を指定します。
デフォルト値：20。
値の範囲：1～200。
推奨事項：テストシナリオでは、10 などの小さい値を指定します。本番環境では、必要に応じて値を調整してください。
セッションライフサイクル: セッションの作成から破棄までの最大期間を指定します。
デフォルト値：21,600 秒 (6 時間)。
説明：この期間が経過すると、システムは自動的にセッションを破棄し、アフィニティは保証されなくなります。
セッションアイドル時間: セッションが非アクティブになってから自動的に破棄されるまでの時間を指定します。
デフォルト値：1,800 秒 (30 分)。
説明：この期間中にインスタンスがリクエストを受信しない場合、セッションはアイドル状態になり、自動的に破棄されます。
構成を保存するには、[デプロイ] ボタンをクリックします。
重要：
セッション保持を有効にすると、システムは自動的に [インスタンスあたりの同時実行数] を 200 に設定します。これはシステムのデフォルト値であり、手動で調整することはできません。
設定後は[ヘッダー名]を変更しないでください。変更した場合は、クライアントも更新する必要があります。
HeaderField アフィニティ機能の検証
目的：同じ HeaderField 値を持つリクエストが同じインスタンスにルーティングされること、およびインスタンスの自動スケーリングメカニズムが期待どおりに機能することを確認します。
インスタンスのスケーリングの変更は、コンソールの関数の詳細ページで確認できます。
手順：
テスト環境の準備
関数がデプロイされ、HeaderField アフィニティが設定されていることを確認します。たとえば、ヘッダー名として
mySessionIdを指定し、[インスタンスあたりの同時セッション数] を 2 に設定します。関数の詳細ページで、[トリガー] をクリックして関数の HTTP トリガー URL を取得します。
HTTP トリガーが署名認証を使用している場合は、テストのために匿名アクセスを許可するように変更できます。
サーバー生成モードのテスト
# 最初のりクエスト。ヘッダーなし。サーバーは自動的にセッション ID を生成します。
curl -v http://your-function-url/your-pathレスポンスヘッダーから、設定したヘッダー名の値を抽出します。この値がサーバーによって生成されたセッション ID です。
レスポンスからインスタンス ID を記録します。
同じセッションが同じインスタンスにルーティングされることの確認
# 後続のリクエストには、抽出したセッション ID を使用します。
curl -v -H "mySessionId: <Session ID extracted from the response>" http://your-function-url/your-path検証ポイント：複数のリクエストが同じインスタンスにルーティングされる必要があります。関数の詳細ページで、[インスタンス] ボタンをクリックして、新しいインスタンスが作成されていないか確認します。
クライアント提供モードのテスト
# クライアントが能動的にセッション ID を提供します。
curl -v -H "mySessionId: session-2" http://your-function-url/your-path検証ポイント：[インスタンスあたりの同時セッション数] が 2 に設定されている場合、新しいセッションは同じインスタンスにアタッチされる必要があります。
インスタンスの自動スケーリングの検証
# クライアントが新しいセッション ID を提供します。
curl -v -H "mySessionId: session-3" http://your-function-url/your-path検証ポイント：インスタンス上のセッション数が上限に達すると、新しいセッションは新しく作成されたインスタンスにアタッチされる必要があります。
期待される結果：
同じ HeaderField 値を持つリクエストが同じインスタンスにルーティングされます。
クライアント提供モードとサーバー生成モードの両方が期待どおりに機能します。
インスタンスのセッション数が上限に達すると、システムは自動的に新しいインスタンスを作成します。
よくある質問
クライアント提供モードとサーバー生成モードの違いは何ですか？
相違点：
クライアント提供モード：クライアントが能動的にセッション ID を制御します。これは、カスタムセッション ID を使用する必要があるシナリオに適しています。
サーバー生成モード：サーバーが自動的にセッション ID を生成します。クライアントは、レスポンスヘッダーからセッション ID を抽出し、後続のリクエストにこの ID を含めるだけで済みます。これは、クライアント側の実装を簡素化したいシナリオに適しています。
推奨事項：
カスタムセッション ID が必要な場合や、既存のシステムと統合する必要がある場合は、クライアント提供モードを使用します。
クライアント側の実装を簡素化したい場合は、サーバー生成モードを使用します。