Function Compute:MCP SSE アフィニティの概要

セッション ID の生成とアフィニティ実装メカニズム

サーバーレスサービスとして、Function Compute は、柔軟なスケジューリング、コンピューティングホスティング、および運用と保守（O&M）不要の機能を提供します。Function Compute のコアコンポーネントは、次の 3 つの部分に抽象化できます。

1. ゲートウェイ: ゲートウェイ層はユーザートラフィックのエントリポイントであり、ユーザーリクエストの受信、認証、速度制限などの機能を担当します。

2. スケジューラ: スケジューリングエンジン層は、ユーザーリクエストを適切なノードとインスタンスにスケジューリングする役割を担います。

3. インスタンス: リソース層は、関数の実行環境です。

お客様が Function Compute で MCP サービスをホストし、MCP Client を介してリクエストを開始する場合、ユーザーリクエストは次の 2 つのカテゴリに分類できます。

• SSE リクエスト

• メッセージリクエスト

SSE リクエスト (セッションの初期化)

1. クライアントが最初の SSE リクエストを開始し、それが Function Compute ゲートウェイノードにルーティングされます。ゲートウェイノードで権限検証に合格すると、リクエストはスケジューラモジュールに転送されます。

2. スケジューラモジュールは、特定の識別子に基づいてリクエストタイプを SSE として識別し、リクエストを使用可能なインスタンスにスケジューリングします。

3. リクエストがインスタンスにバインドされると、インスタンスはユーザーコードを開始します。

4. ユーザーコードが開始されると、event: endpoint イベントの data フィールドに sessionId が配置され、最初のデータパケットが返されます。

5. レスポンスがゲートウェイ層を通過すると、ゲートウェイ層は SSE リクエストの最初のレスポンスパケットをインターセプトし、SessionID を解析し、SessionID とインスタンス間のマッピングを DB に永続化します。

メッセージリクエスト (リクエスト処理)

1. クライアントが SSE リクエストを完了した後、複数のメッセージリクエストを開始します。Function Compute ゲートウェイノードはステートレスであるため、メッセージリクエストは複数のゲートウェイノードに分散されます。

2. ゲートウェイがメッセージリクエストを受信すると、キャッシュでメッセージリクエストの SessionID のアフィニティ情報を確認します。キャッシュにレコードが見つからない場合は、DB からオリジンフェッチを実行して関連データを取得します。

3. ゲートウェイは、キャッシュまたは DB から SessionID とインスタンスのバインディング関係を取得した後、関連情報を含むリクエストをスケジューラモジュールに転送します。

4. スケジューラモジュールは、特定の識別子に基づいてリクエストタイプをメッセージとして識別し、リクエスト内のインスタンス情報を解析し、リクエストを特定のインスタンスにスケジューリングします。

5. リクエストがインスタンスにバインドされると、MCP サーバーはリクエストを検証します。検証に成功すると、202 Accepted が返され、リクエストが受信されたことがクライアントに通知されます。実際のデータは、SSE リクエストによって確立された接続を介して返されます。

セッションの同時実行管理

MCP SSE セッションリソース要件モデルでは、単一のセッションライフサイクルには 2 種類の同時実行要件があります。

• 1 つの永続的な SSE 接続。1 つの同時実行クォータを占有します。

• N（N >= 1）個のメッセージリクエスト。N 個の同時実行クォータを占有します。

$$TotalQuota(s)=1+N(N\ge 1)$$

ビジネスシナリオの要件に基づいて、適切な制限を設定する必要があります。

• 非アフィニティモードのシナリオでは、必要に応じてインスタンスごとの同時実行数を調整できます。

• アフィニティモードでは、インスタンスごとの同時セッションの最大数のみが制限されます。単一インスタンス上のすべてのセッションの同時リクエストの最大数は 200 です。

セッションアフィニティの予期される動作 (インスタンススケジューリングルール)

シナリオ 1: セッションとインスタンスのバインディングルール、およびセッションによってトリガーされるインスタンススケールアウトメカニズム

Function Compute は、ポリシーを使用してインスタンスごとの同時セッション数を管理します。このポリシーでは、各インスタンスの最大セッション数が n に制限されます。プロセスは次のとおりです。

1. 関数が 2 つのセッションをバインドするように設定されているとします。Client1 が SSE リクエストを開始すると、リクエストは Instance1 に割り当てられ、1 つのセッションの同時実行数が使用されます。

2. Client2 が SSE リクエストを開始すると、スケジューラは Instance1 に使用可能なセッションが 1 つあると判断し、リクエストを Instance1 にバインドします。

3. Client3 が SSE リクエストを開始すると、スケジューラは Instance1 の 2 つの同時セッションが使用されていると判断します。したがって、スケジューラはリクエストを新しいインスタンス Instance2 にスケジューリングし、インスタンスバインディングを完了します。

シナリオ 2: 単一インスタンスを共有する複数のセッションのリソース速度制限メカニズム

1. 関数が 2 つの同時セッションをバインドするように設定されているとします。Client1 が SSE リクエストを開始すると、Instance1 が割り当てられます。インスタンスは 1 つの同時セッション + 1 つのリクエストの同時実行数を消費します。

2. Client2 が SSE リクエストを開始すると、スケジューラは Instance1 に使用可能な同時セッションが 1 つあると判断し、リクエストを Instance1 にバインドします。この時点で、インスタンスは 2 つの同時セッション + 2 つのリクエストの同時実行数を消費します。

3. Client1 と Client2 は同時に 198 件のメッセージリクエストを送信します。この時点で、インスタンスは 2 つの同時セッション + 200 件のリクエストの同時実行数を消費します。

4. 199 番目のメッセージリクエストが開始されると、単一インスタンスのリクエスト同時実行制限 200 に達し、リクエストは 429 エラーで速度制限されます。