【要約】MCPサーバーを本番でスケールさせる：Streamable HTTP・ステートレスセッション・能力発見の実装 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がMCPサーバーをロードバランサ配下にデプロイした際、特定のAPI呼び出しが404エラーで失敗する問題に直面する。これは、ローカル環境での動作と本番環境でのスケーラビリティの差に起因する。
- ・原因は、MCPのセッション状態を特定のインスタンスのメモリ内に保持していることにある。
- ・ロードバランサが別のインスタンスへリクエストを転送すると、セッション不一致が起きる。
- ・スティッキールーティングでは、オートスケール時のインスタンス削除によるセッション喪失を防げない。
// Approach
本記事では、プロトコルレベルのセッション依存を排除し、水平スケールを可能にする設計手法を提示する。各リクエストを独立したHTTPリクエストとして扱うことが鍵となる。
- ・トランスポートをStreamable HTTPへ移行し、SSEをオプション化してリクエストの独立性を高める。
- ・
stateless=Trueを設定し、プロセスのメモリにセッション状態を保持しない設計を行う。 - ・ユーザーの文脈は、セッションではなくOAuth 2.1ベースの認証トークンを用いて管理する。
- ・
.well-knownエンドポイントを実装し、接続前にサーバーの能力を公開する仕組みを導入する。
// Result
この設計を採用することで、MCPサーバーは本番環境での大規模なトラフィック処理に対応可能となる。インフラの複雑性を抑えつつ、高い可用性を実現できる。
- ・スティッキールーティングや共有セッションストアが不要になり、インフラ構成が簡素化される。
- ・インスタンスの増減や再起動がクライアントに影響を与えず、デプロイの透過性が向上する。
- ・
.well-knownによる能力発見により、レジストリやクローラーによる効率的なサーバー探索が可能になる。
Senior Engineer Insight
> 「プロトコルがステートフルであること」と「アプリケーションがステートフルであること」を明確に分離すべきだ。本記事が示す、プロトコルをステートレスに保ち、状態を認証トークンと外部DBに逃がす設計は、分散システムにおける鉄則である。プッシュ通知が必要な極めて限定的なケースを除き、原則としてステートレスを選択すべきだ。これにより、運用コストの低減とスケーラビリティの確保を両立できる。実戦投入時には、この分離が徹底されているかを厳格に評価せよ。