#redis

この記事を読んでまず思ったのは、「これ、地味だけど本番ではかなり嫌なやつだな」ということだった。 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 実行の文脈で出てくることが多い仕

Microsoft（Hotmail / Live / MSN / Outlook）宛てのメールだけが、SendGrid上で Deferred になった エラーは `451 4.7.650`。内容は「IP reputation を理由に一時的に rate limit した」というもの 筆者は最初、Microsoft側の障害や誤判定を疑った しかし調べるうちに、「急に多くのメールを送ったこと」が引き金ではないかと考え始めた 対策として、Redis を使った送信レート制限を実装し、Microsoft宛てのメールを 1 IP あたり毎分 10通までに抑えた その後、Microsoft側の担当者から制限レベルを調整したという返信があり、送信は復旧した 筆者の結論は、「Microsoftの判定が厳しかった可能性が高いが、送信側でもスパiky な配信を抑える仕組みが必要」というもの 元記事は、Microsoft系メールアドレスにだけメールが届かなくなったというトラブルの記録です。 ここでいう Microsoft 系とは、Hotmail、Live、MSN、Outlook など。昔からあるメール

REST APIが遅くなる最大の原因は、だいたいdatabaseアクセス Redisのような in-memory cache を使うと、読み込みをかなり速くできる Spring Bootでは `@EnableCaching` や `@CachePut`、`@CacheEvict` が実用的 更新時は「DBとcacheを同時に整える」設計が大事 人気データが一斉に失効すると cache stampede が起きるので、distributed lock で守る 最後は JMeter で load test して、ちゃんと速くなったか確認するのが重要 元記事の主張はかなりシンプルです。 高トラフィックなREST APIは、databaseアクセスがボトルネックになりやすい、という話です。 これは現場感としてもすごく納得感があります。 どんなにSQLを改善して、indexを貼って、ちょっと頑張っても、DBに毎回取りに行く構成だと限界が見えやすいんですよね。記事では、DBの応答が数百ミリ秒かかる一方で、Redisを使えばずっと速くなると説明しています。しかも、Redisはメモリ上で動くの