Function Compute:セッション保持の構成プラクティス

制限事項

• 一般的な制限事項

  • セッション分離を有効にすると、セッションアフィニティ機能は自動的に有効になり、無効にすることはできません。 次のアフィニティタイプのいずれかを選択する必要があります。MCP SSE アフィニティ、HeaderField アフィニティ、または Cookie アフィニティ。

  • リクエスト分離を有効にすると、セッションアフィニティ機能は使用できません。

  • セッションアフィニティは、非同期タスクリクエストではサポートされていません。

  • 組み込みランタイムを選択した場合、インスタンスあたりの同時実行数は 1 に制限されます。 この場合、インスタンスあたりの同時セッション数も 1 に制限されます。

  • インスタンスあたりの同時セッション数は、インスタンスあたりの最大同時リクエスト数を超えることはできません。

• MCP Streamable HTTP アフィニティに固有の制限

  • MCP Streamable HTTP アフィニティの Function Compute 実装は、MCP プロトコルバージョン 2025-03-26 および 2025-06-18 に基づいています。MCP Streamable HTTP アフィニティが有効になっている関数にアクセスする場合、クライアントと MCP 関数の両方が MCP バージョン 2025-03-26 または 2025-06-18 のトランスポートプロトコル規則に従う必要があります。

  • MCP トランスポートレイヤーの下位互換性ルールによると、単一の Web サーバーは MCP HTTP with SSE と MCP Streamable HTTP の両方のトランスポートモードをサポートできます。ただし、関数が両方のトランスポートメソッドをサポートし、MCP Streamable HTTP アフィニティで構成されている場合、セッション管理メカニズムに互換性がないため、MCP HTTP with SSE を使用して行われた MCP 呼び出しは失敗します。

    したがって、MCP Streamable HTTP アフィニティが有効になっている場合、MCP HTTP with SSE トランスポートを使用する関数を正しく呼び出すことはできません。

  • MCP Streamable HTTP アフィニティが有効になっている関数には、HTTP トリガーまたはカスタムドメイン名からのみアクセスできます。

  • HTTP トリガーを使用して関数にアクセスする場合、構成された HTTP トリガーは、少なくとも GET、POST、および DELETE リクエストメソッドをサポートする必要があります。

• MCP SSE アフィニティに固有の制限事項

  • 関数を作成する際、MCP SSE アフィニティは組み込みランタイムではサポートされていません。MCP ランタイムを選択した場合、MCP SSE アフィニティのみがサポートされます。

  • MCP SSE アフィニティが有効になっている関数にアクセスするには、公式の MCP クライアントまたは SDK を使用する必要があります。

• HeaderField アフィニティに固有の制限事項

  • 現在、HeaderField アフィニティは HTTP プロトコルのみをサポートしています。

• Cookie アフィニティに固有の制限事項

  • サーバー側の Cookie 挿入モードのみがサポートされています。 つまり、クライアントが初めて関数にアクセスすると、Function Compute は自動的にレスポンスに Cookie を挿入します。

セッションアフィニティの予期される動作（アフィニティ、スロットリング、および新しいインスタンスへのスケジューリング）

セッション保持タイプを選択すると、インスタンスあたりの同時実行数は自動的に最大 200 に設定され、変更できません。複数のセッションからのリクエストは、単一インスタンスの最大同時実行クォータ 200 を共有します。単一インスタンスの同時実行数制限を超えるリクエストは、他のインスタンスにルーティングされるか、スロットリングされます。

• アフィニティ

  単一インスタンス上のすべてのセッションでの同時リクエストの合計数が最大同時実行クォータ 200 を超えない場合に限り、システムは セッションライフサイクル 内でセッションアフィニティを保証します。

• スロットリング

  単一インスタンス上のすべてのセッションでの同時リクエストの合計数が最大同時実行クォータ 200 を超えると、既存のセッションへの新しいリクエストはスロットリングされ、429 エラーが返されます。 新しいセッションは、新しく作成された関数インスタンスに自動的にスケジューリングされます。

  たとえば、インスタンスあたりの同時セッション数が 30 に設定されているとします。あるインスタンスで 20 のアクティブなセッションが実行されており、各セッションが 10 の同時リクエストを処理している場合、インスタンス上の同時リクエストの総数は最大クォータの 200 (20 × 10 = 200) に達します。この場合、これら 20 セッションに対する新しいリクエストはすべてスロットリングされます。21 番目のセッションなどの新しいセッションのリクエストは、新しい関数インスタンスに自動的にスケジュールされます。

• 新しいインスタンスへのスケジューリング

  構成された インスタンスあたりの同時セッション数 を超えると、新しいセッションリクエストは新しく作成された関数インスタンスに自動的にスケジューリングされます。

パラメーター構成ガイド

1. インスタンスあたりの同時セッション数を低い値に設定すると、システムはより多くの関数インスタンスを作成するため、コストが増加します。 関数のリソース仕様をダウングレードすることでコストを削減できます。

2. リソースは、単一インスタンス上の複数のセッション間で共有されます。ユースケースでリソース共有が許容できるかどうかを評価する必要があります。これにより、リソース使用率が向上し、コストが削減されます。

手順

1. Function Compute コンソールにログインします。左側のナビゲーションウィンドウで、[関数管理] > [関数] を選択します。

2. 上部のナビゲーションバーでリージョンを選択します。[関数] ページで、[関数の作成] をクリックします。

3. 表示されるダイアログボックスで、関数タイプを選択します。[関数の作成] ページで、[分離とアフィニティ] セクションを見つけます。次の手順で説明するようにパラメーターを構成し、[作成] をクリックします。

   1. インスタンスの分離

      インスタンス分離機能は無効のままにします。

   2. セッションアフィニティ

   • MCP Streamable HTTP アフィニティ

     構成項目	説明	例
     セッション保持タイプ	MCP Streamable HTTP アフィニティを選択します。システムは、同じ MCP Streamable HTTP セッションに属するリクエストが、常にセッションを生成した関数インスタンスにルーティングされるようにします。	MCP Streamable HTTP アフィニティ
     インスタンスあたりの同時セッション数	単一のインスタンスが同時に処理できるセッションの最大数。デフォルト値は 20 です。同時セッションの最大数は 200 です。	20
     単一セッションのライフサイクル	セッションの作成、使用から最終的な破棄までの全プロセス。単一セッションのライフサイクルを超えると、サーバーはプラットフォーム側で MCP Streamable HTTP に関連付けられたセッションを自動的に破棄し、その MCP Streamable HTTP セッションのアフィニティを保証しなくなります。	21600 秒
     セッションアイドル期間	一定期間リクエストを関数インスタンスが受信しない場合、セッションはアイドル状態になります。構成されたセッションアイドル期間を超えると、サーバーはプラットフォーム側で MCP Streamable HTTP に関連付けられたセッションを自動的に破棄し、その MCP Streamable HTTP セッションのアフィニティを保証しなくなります。	1800 秒

   • MCP SSE アフィニティ

     構成項目	説明	例
     セッションアフィニティタイプ	[MCP SSE affinity] を選択します。MCP SSE プロトコルの仕様に基づき、同じセッション ID を持つクライアントリクエストが常に同じインスタンスにルーティングされることで、アフィニティ動作が実装されます。	MCP SSE アフィニティ
     SSE パス	SSE 接続リクエストを開始するためのパス。	/sse
     インスタンスあたりの同時セッション数	単一インスタンスで同時に処理できるセッションの最大数。 デフォルト値は 20 です。同時セッションの最大数は 200 です。	20

   • HeaderField アフィニティ

     構成項目	説明	例
     セッションアフィニティ	[HeaderField] を選択すると、HTTP リクエストヘッダー内の指定されたフィールドの値に基づいてセッション保持を実装します。	HeaderField アフィニティ
     ヘッダー名	アフィニティのクライアント ID を送信するために使用されるヘッダーの名前。 たとえば、送信するアフィニティ ID が mySessionId で、[ヘッダー名] が x-custom-affinity-header の場合、HTTP プロトコルを使用して呼び出しを行うときに、次のヘッダーと値を送信する必要があります。x-custom-affinity-header:mySessionId.	x-custom-affinity-header
     インスタンスあたりの同時セッション数	単一インスタンスで同時に処理できるセッションの最大数。 デフォルト値は 20 です。同時セッションの最大数は 200 です。	20
     単一セッションのライフサイクル	セッションの作成と使用から最終的な破棄までの一連のプロセス。単一セッションのライフサイクルを超過した場合、サーバーはセッションを自動的に破棄し、アフィニティは保証されなくなります。	21600 秒
     セッションのアイドル時間	一定期間操作が実行されない場合、セッションはアイドル状態になります。設定された[セッションアイドル期間]を超過した場合、サーバーは自動的にセッションを破棄し、アフィニティを保証しなくなります。	1800 秒

   • Cookie アフィニティ

     構成項目	説明	例
     セッションアフィニティ	HTTP クッキーの属性値に基づいてセッション保持を実装するには、[Cookie アフィニティ] を選択します。	Cookie アフィニティ
     Cookie 処理方法	現在、Cookie 挿入方法のみがサポートされています。 つまり、クライアントが初めて関数にアクセスすると、Function Compute は自動的にレスポンスに Cookie を挿入します。 具体的には、Set-Cookie:x-fc-cookie-session-id={CookieID} が HTTP/HTTPS レスポンスメッセージに挿入されます。 クライアントが後で Cookie:x-fc-cookie-session-id={CookieID} を使用して関数にアクセスすると、Function Compute は最初のリクエストが配置された関数インスタンスにリクエストを転送します。	[Cookie を挿入]
     インスタンスあたりの同時セッション数	単一インスタンスで同時に処理できるセッションの最大数。 デフォルト値は 20 です。同時セッションの最大数は 200 です。	20
     単一セッションのライフサイクル	セッションの作成から使用、最終的な破棄までの一連のプロセス。単一セッションのライフサイクルを超えた場合、サーバーは自動的にセッションを破棄し、アフィニティを保証しなくなります。	21600 秒
     セッションのアイドル時間	一定期間、操作が実行されない場合、セッションはアイドル状態になります。設定された[セッションアイドル期間]を超過した場合、サーバーはセッションを自動的に破棄し、アフィニティを保証しなくなります。	1800 秒

結果の確認

このセクションでは、HeaderField アフィニティを例として使用します。アフィニティを有効にした後、HTTP リクエストヘッダーを指定して関数を呼び出すことができます。その後、構成されたインスタンスあたりの同時セッション数を超えない限り、同じセッションのリクエストが同じ関数インスタンスにルーティングされるかどうかを確認できます。

1. テストのために、異なる HTTP リクエストヘッダーを使用して関数を複数回呼び出します。 このトピックでは、cURL コマンドを例として使用します。

   次の例はコマンドを示しています。`example` と `regionID` を関数の URL に置き換えてください。関数の URL は、関数詳細ページの [トリガー] タブにある HTTP トリガーの [設定情報] 列で確認できます。

   curl -H "x-custom-affinity-header:mySessionId" https://example.{regionID}.fcapp.run

   [Cookie アフィニティ] を選択した場合、cURL コマンドのフォーマットは次のとおりです:

   curl -H "Cookie:x-fc-cookie-session-id={CookieID}" https://example.{regionID}.fcapp.run

2. 関数詳細ページで、[ログ] タブをクリックします。構成されたインスタンスあたりの同時セッション数を超えない限り、同じセッション ID を持つリクエストが同じ関数インスタンスにルーティングされることがわかります。

よくある質問