MCP ストリーマブル HTTP アフィニティ機能により、Function Compute は、同じ MCP セッションに属するリクエストを、そのセッションを作成したバックエンド関数インスタンスにルーティングできます。MCP ストリーマブル HTTP セッションが初期化されると、Function Compute は関数の応答の HTTP ヘッダーにある `Mcp-Session-Id` フィールドを解析し、この ID をプラットフォーム上のセッションに関連付けます。同じ `Mcp-Session-Id` を持つ後続のリクエストは、同じセッションの一部と見なされ、それを初期化した関数インスタンスにルーティングされます。セッションを停止するための DELETE リクエストを受信すると、システムはプラットフォーム上の関連セッションをパージ (消去) し、セッションが占有していた同時実行リソースを解放します。
注意事項
クライアントが MCP ストリーマブル HTTP アフィニティセッションを終了するために DELETE リクエストを送信すると、Function Compute はシステムレベルでセッションのリソースを取り消します。これには、インスタンスの同時セッションクォータなどのリソースが含まれます。関数に設定された HTTP トリガーが DELETE リクエストをサポートしていることを確認してください。そうでない場合、Function Compute システムは DELETE リクエストを拒否し、MCP ストリーマブル HTTP セッションが正常に終了できなくなります。
仕組み
Function Compute のアーキテクチャ
サーバーレスサービスとして、Function Compute は、エラスティックなスケジューリング、マネージドコンピューティング、およびメンテナンスフリーの機能を提供します。Function Compute のコアコンポーネントは、次の 3 つの部分に抽象化できます。
ゲートウェイ： ユーザートラフィックのエントリポイントです。ゲートウェイは、ユーザーリクエストの受け入れ、認証、トラフィックスロットリングなどの機能を担当します。
スケジューラ： スケジューリングエンジンです。スケジューラは、ユーザーリクエストを適切なインスタンスにスケジューリングする役割を担います。
インスタンス： 特定の関数インスタンスです。
ゲートウェイがセッションを処理する方法の詳細は複雑です。これらの詳細は、Function Compute で MCP ストリーマブル HTTP セッション保持がどのように機能するかを理解するために不可欠ではありません。明確にするために、このトピックのすべてのフローチャートではゲートウェイを省略し、クライアントリクエストが直接スケジューラに送られるように示しています。実際には、クライアントと Function Compute コンポーネント間のやり取りは、常に Function Compute ゲートウェイを通過します。
セッションの同時実行管理
MCP Streamable HTTP セッションのリソースモデルでは、単一セッションのライフサイクルには 2 種類の同時リソース要件があります:
M (M >= 1) 個の持続的な Server-Sent Events (SSE) 接続は M 個の同時クォータを占有し、N (N >= 1) 個の POST リクエストは N 個の同時クォータを占有します。
TotalQuota(s)=M+N(M>=1,N>=1)
必要に応じて適切な制限を設定できます：
アフィニティモードでは、インスタンスあたりの最大同時セッション数のみを制限できます。単一インスタンス上のすべてのセッションに対する最大同時リクエスト数は 200 です。
同時実行パラメータータイプ | 説明 | 調整可能 | 制限 | 消費ルール | 同時実行数解放メカニズム |
インスタンスあたりの最大同時実行数 | 単一のインスタンスが同時に処理できる最大同時リクエスト数。この制限を超えるリクエストは、他のインスタンスにルーティングされるか、スロットリングによって拒否されます。 | 調整不可 | 200 | 各リクエストまたは持続的接続は、1 つの同時実行ユニットを占有します。 | リクエストが処理された後、非同期に解放されます。 |
インスタンスあたりの同時セッション数 | 単一のインスタンスが同時に処理できる最大セッション数。複数のセッションからのリクエストは、200 の同時実行数制限を共有します。 | 調整可能 | [1, 200] | 各 MCP ストリーマブル HTTP セッションは、1 つのセッションカウントを占有します。 | DELETE セッションリクエストへの応答によって非同期に解放されるか、TTL または IdleTimeout によってトリガーされます。 |
期待されるセッション保持の動作 (インスタンスのスケジューリングルール)
シナリオ 1：セッションとインスタンスのバインディングルールおよびセッションによってトリガーされるインスタンスのスケールアウト
Function Compute は、インスタンスあたりの同時セッション数ポリシーを使用して、各インスタンスにバインドできるセッションの最大数 (n) を制限します。プロセスは次のとおりです。
関数が 2 つのセッションのバインドを許可するように設定されていると仮定します。クライアント 1 が MCP ストリーマブル HTTP セッションの初期化リクエストを開始すると、リクエストはインスタンス 1 に割り当てられ、1 つの同時セッションクォータを占有します。
クライアント 2 が MCP ストリーマブル HTTP セッションの初期化リクエストを開始すると、スケジューラはインスタンス 1 にまだ利用可能なセッションクォータが 1 つあると判断します。その後、セッションはインスタンス 1 に正常にバインドされます。
クライアント 3 が MCP ストリーマブル HTTP セッションの初期化リクエストを開始すると、スケジューラはインスタンス 1 の 2 つの同時セッションクォータがすでに占有されていると判断します。新しいバインディングは不可能です。その後、リクエストは新しいインスタンスであるインスタンス 2 にスケジューリングされ、そこでバインディングが完了します。
シナリオ 2：単一インスタンス上の複数セッション間での共有リソースのスロットリングメカニズム
シナリオ 2.1：クライアントが MCP ストリーマブル HTTP トランスポートを使用する関数をリクエストする際に、同期 POST リクエストのみを使用する場合
関数が 2 のセッションクォータで設定されていると仮定します。クライアント 1 がセッション 1 のリクエストを開始すると、リクエストはインスタンス 1 に割り当てられます。
クライアント 2 がセッション 2 のリクエストを開始すると、スケジューラはインスタンス 1 にまだ利用可能な同時セッションクォータが 1 つあると判断します。セッションはインスタンス 1 に正常にバインドされます。インスタンスは現在、2 つの同時セッションクォータを消費しています。
セッション 1 とセッション 2 は、同時に 200 件の POST リクエストを送信します。インスタンスは現在、2 つの同時セッションクォータと 200 のリクエスト同時実行数を消費しています。
201 番目の POST リクエストが開始されると、単一インスタンスの 200 のリクエスト同時実行数が使い果たされます。リクエストはスロットリングされ、429 エラーが返されます。
シナリオ 2.2：クライアントが MCP ストリーマブル HTTP トランスポートを使用する関数をリクエストする際に、持続的 SSE 接続と同期 POST リクエストの両方を使用する場合
関数が 2 のセッションクォータで設定されていると仮定します。クライアント 1 がセッション 1 のリクエストを開始すると、リクエストはインスタンス 1 に割り当てられます。その後、クライアント 1 は GET リクエストを送信し、インスタンス 1 との持続的 SSE 接続を確立します。
クライアント 2 がセッション 2 のリクエストを開始すると、スケジューラはインスタンス 1 にまだ利用可能な同時セッションクォータが 1 つあると判断します。セッションはインスタンス 1 に正常にバインドされます。インスタンスは現在、2 つの同時セッションクォータを消費しています。その後、クライアント 2 は GET リクエストを送信し、インスタンス 1 との持続的 SSE 接続を確立します。
セッション 1 とセッション 2 は、同時に 198 件の POST リクエストを送信します。インスタンスは現在、2 つの同時セッションクォータを使用しています。消費される合計リクエスト同時実行数は 200 で、これには SSE 接続用の 2 と POST リクエスト用の 198 が含まれます。
199 番目の POST リクエストが開始されると、単一インスタンスの 200 のリクエスト同時実行数が使い果たされます。リクエストはスロットリングされ、429 エラーが返されます。
スムーズな関数更新
MCP シナリオでは、データリクエストはリクエストレベルでステートレスである代わりに、セッションレベルのバインディングでステートフルになります。関数が更新された後、既存のセッションに関連付けられたリクエストが新しいインスタンスにルーティングされると、新しいインスタンスは SessionID を認識できず、エラーを返します。この問題を解決するために、Function Compute はグレースフルアップデート機能をステートレスなリクエストレベルからステートフルなセッションレベルにアップグレードします。ユーザーが関数を更新した後も、既存のセッションのリクエストは古いインスタンスにルーティングされ、新しいセッションのリクエストは新しいインスタンスにルーティングされます。これにより、MCP アフィニティシナリオでスムーズなアップグレード体験が提供されます。
課金
セッション保持のコスト = リクエストを処理するアクティブなエラスティックインスタンスのコスト + キープアライブ期間中のアイドル状態のエラスティックインスタンスのコスト
アクティブなエラスティックインスタンスとアイドル状態のエラスティックインスタンスのコスト計算方法の詳細については、「課金の概要」をご参照ください。