#ロードバランサー

この記事を読んでまず思ったのは、「これ、地味だけど本番ではかなり嫌なやつだな」ということだった。 MCP server 自体のロジックが壊れているわけではなく、replica を増やした瞬間にだけ「session not found」が出る。こういう不具合は、単体テストやローカル環境ではまず見えない。だからこそ厄介だし、運用している側からすると一番気持ち悪いタイプの障害だと思う。 特に引っかかったのは、原因がかなり素朴だという点だった。session を local memory に置いているのに、load balancer は毎回どの replica に振るかを気にしない。言われてみれば当然なのに、実際にはその「当然」を見落としてしまう。しかも SSE のように接続が長生きする transport だと、session はクライアントと server の間にある抽象的なものではなく、かなり物理的に「この replica にぶら下がっている状態」になる。そこを別 replica に投げられたら、そりゃ見つからない。 もう一つ面白かったのは、解決策がわりと王道で、だからこそ納得感があった

MCP server を load balancer の後ろに置いた瞬間、なぜか「さっきの続き」が消える。この記事は、その地味だけど厄介な事故をかなり実践的にほどいています。しかも面白いのは、壊れ方が派手なエラーではなく、静かに間違うところです。これ、運用している側からするとかなり嫌なタイプの不具合だと思います。 MCP はもともと「同じセッションが続く」前提で動きやすい でも load balancer は、基本的に「各 request は独立」と見なして振り分ける そのせいで、別の server instance に飛んだ request が session を見失う 典型的な対策は 3 つある - sticky sessions で同じ instance に固定する - Redis などの shared store に session state を逃がす - そもそも state を持たない設計に寄せ、resumable streams を使う どれが正解かは、可用性をどこまで求めるかで変わる MCP は、AI agent や tool 実行の文脈で出てくることが多い仕