Function Compute:セッション保持：一般的な制限事項と原則

1. Cookie アフィニティ固有の制限事項

• サーバーサイドの Cookie 挿入のみをサポート：
  クライアントが最初のリクエストを行うと、Function Compute は Set-Cookie ヘッダーを使用してレスポンスに Cookie を自動的に挿入します。クライアントはこの Cookie を解析して保存し、後続のリクエストに含める必要があります。
  
  

• SessionAPI 管理をサポート：
  SessionAPI を使用して、セッションの作成、更新、クエリ、終了などのセッションライフサイクル管理を行うことができます。
  
  

2. HeaderField アフィニティ固有の制限事項

• セッション ID のソース：

  • クライアントが事前に定義されたヘッダーでセッション ID を渡した場合、この値がセッション ID として使用されます。

  • ID が渡されない場合、サーバーサイドでグローバルに一意なセッション ID が生成されます。これは、CreateFunction で事前に定義されたヘッダーフィールドを使用してレスポンスヘッダーで返されます。

• ヘッダーフィールドの定義：
  関数を作成する際に、SessionAffinityConfig でセッション ID を転送するためのヘッダーフィールド名を指定します。
  
  

• SessionAPI 管理をサポート：
  SessionAPI を使用してセッションをモニターおよびコントロールできます。
  
  

3. MCP Streamable HTTP アフィニティ固有の制限事項

• プロトコルバージョンの要件：
  このアフィニティタイプは、MCP プロトコルバージョン 2025-03-26 および 2025-06-18 をサポートします。クライアントと関数は、対応するバージョンのトランスポート層の仕様に従う必要があります。
  
  

• 互換性に関する注意：関数で MCP Streamable HTTP アフィニティが有効になっている場合、Server-Sent Events (SSE) を使用した MCP HTTP で呼び出さないでください。セッション管理メカニズムに互換性がないため、呼び出しが失敗します。

• アクセス方法の制限：
  アクセスは、HTTP トリガーまたはカスタムドメイン名経由でのみサポートされます。
  
  

• HTTP トリガーの構成要件：
  HTTP トリガーは、少なくとも GET、POST、および DELETE メソッドをサポートする必要があります。
  
  

  DELETE メソッドの必要性：
  クライアントは DELETE リクエストを送信することで、セッションを能動的に終了できます。その後、Function Compute はインスタンスの同時実行クォータを含む、そのセッションのリソースを取り消します。DELETE メソッドが有効になっていない場合、システムはリクエストを拒否し、セッションは正しくリリースされません。
  
  

• SessionAPI 管理はサポートされていません。

4. MCP SSE アフィニティ固有の制限事項

• ランタイムの制限：

  • ビルトインランタイムを使用する場合、MCP SSE アフィニティはサポートされていません。

  • MCP ランタイムを使用する場合、MCP アフィニティ (SSE を含む) のみがサポートされます。

  • 他のランタイムにはこの制限はありません。

• クライアントの要件：
  リクエストは、公式の MCP 標準クライアントまたはソフトウェア開発キット (SDK) を使用して開始する必要があります。そうしないと、有効なアフィニティ接続を確立できません。
  
  

• セッションライフサイクル：
  最大セッションライフサイクルは、関数の最大タイムアウト期間と同じです。この期間が経過すると、サーバーサイドで切断されます。再接続すると新しいセッション ID が生成され、元のインスタンスへのルーティングは保証されません。
  
  

• アクセス方法の制限：
  アクセスは、HTTP トリガーまたはカスタムドメイン名経由でのみサポートされます。
  
  

• リクエストの制限：

  • 最初の SSE リクエストは、現在クエリパラメーターを含むことをサポートしていません。

  • インスタンスあたりの最大同時実行数は 200 です。

• SessionAPI 管理はサポートされていません。

1. コアフロー

クライアントがリクエストを送信 → セッション ID の識別/生成 → アクティブなインスタンスにアタッチ → 後続のリクエストをそのインスタンスにルーティング

2. リソースモデル (統一フレーム)

• 各セッションは、1 つのセッション同時実行クォータを消費します。

• 各リクエスト (POST、GET、Message を含む) は、1 つのリクエスト同時実行クォータを消費します。

• インスタンスあたりの合計同時実行クォータ：200 (調整不可)

• 複数のセッションがこの 200 のクォータを共有します。

計算式：

合計クォータ = Σ(各セッションが消費する同時実行数) ≤ 200

3. ライフサイクル管理

同時実行パラメーターの説明

単一セッションの同時実行リソースモデル

インスタンスあたりの同時セッション数の設定に関する推奨事項：

1. 隔離シナリオ：値を 1 に設定します。単一のセッションがコンピューティングリソースを排他的に使用し、セキュリティと信頼性を向上させます。

2. マルチテナント共有シナリオ：値を (1, 200] の範囲の数値に設定します。複数のセッションが単一のインスタンスのリソースを共有し、リソース使用率を向上させます。

シナリオ 1：セッションとインスタンスのバインディングルールとスケールアウトメカニズム

関数がインスタンスあたり 2 つの同時セッションで構成されていると仮定します。

1. Client1 がリクエストを送信します。Instance1 が割り当てられ、1 つのセッションクォータを消費します。

2. Client2 がリクエストを送信します。スケジューラは Instance1 に利用可能なセッションクォータがあると判断し、セッションのバインドに成功します。

3. Client3 がリクエストを送信します。Instance1 が満杯のため、新しいインスタンス Instance2 が作成され、セッションはそれに正常にバインドされます。

キーポイント：

• スケジューリングシステムは既存のインスタンスを再利用しようとしますが、これは保証されません。

• スケールアウトは、既存のすべてのインスタンスが満杯の場合にのみ発生します。

• これにより、動的負荷分散と弾性スケーリングが実装されます。

シナリオ 2：単一インスタンス上の複数セッションに対するリソース制限メカニズム

関数がインスタンスあたり 2 つの同時セッションで構成されていると仮定します。

1. Client1 がリクエストを送信し、1 つのセッションクォータと 1 ユニットのリクエスト同時実行数を消費します。

2. Client2 がリクエストを送信し、1 つのセッションクォータと 1 ユニットのリクエスト同時実行数を消費します。

3. 最初の 2 つのリクエストが完了する前に、両方のクライアントが同時にさらに 198 のリクエストを送信し、合計 200 ユニットのリクエスト同時実行数を消費します。

4. 次の同時リクエストは 200 の制限を超え、システムは `429 Too Many Requests` エラーを返します。

キーポイント：

• インスタンスあたりの最大同時実行数は 200 に固定されており、調整はできません。

• 複数のセッションがこのクォータを共有します。

• 同時実行クォータが枯渇すると、システムは新しいリクエストを拒否します。