SSE 本番運用の『3つの壁』
SSE は実装シンプルだが、本番運用では Edge・認証・再接続で実務的な課題が出ます。本記事では編集部の視点で、深掘りした実装を公開情報をもとに整理します。SSE 実装基礎 もご参考に。
Edge での実装
(1) Cloudflare Workers：ReadableStream で実装。(2) Vercel Edge：Response with stream。(3) Hono：streamSSE helper。(4) Deno Deploy：Web 標準API。(5) レイテンシ最小。Hono 実践 もご参考に。
認証の実装
(1) Cookie ベース：最簡単。(2) URL query 経由：漏洩リスク。(3) WebSocket 風の初期メッセージ。(4) HttpOnly Cookie + CSRF。(5) JWT 期限切れ対応。JWT 実装 もご参考に。
再接続の実装
(1) EventSource は自動再接続。(2) Last-Event-ID：再開ポイント。(3) サーバー側の状態管理。(4) exponential backoff。(5) quota 制限。
LLM ストリーミング
(1) OpenAI/Anthropic 互換。(2) token 単位送信。(3) キャンセル対応：AbortController。(4) エラー処理：中断時のメッセージ。(5) レート制限。LangChain+RAG もご参考に。
負荷分散とスケール
(1) sticky session：不要なケース多い。(2) Redis Pub/Sub：複数サーバー対応。(3) 同時接続数：1サーバー数千〜数万。(4) 長時間接続のコスト。(5) サーバーレスの制約：実行時間。
監視とエラー処理
(1) 接続数モニタリング。(2) 切断率：異常検知。(3) レイテンシ p99。(4) エラー イベント送信。(5) クライアント側ログ。Observability 実践 もご参考に。
SSE が苦手な場面
(1) 双方向通信：WebSocket 必要。(2) バイナリデータ：base64 化が必要。(3) サーバーレスの長時間制限。(4) 低レイテンシのゲーム：WebRTC。(5) P2P：WebRTC。リアルタイム通信比較 もご参考に。
失敗しがちなパターン
(1) Nginx バッファリングで遅延。(2) サーバーレスでタイムアウト。(3) 認証なしで個人情報漏洩。(4) 同時接続数限界：サーバ枯渇。(5) 監視不足。対策は、(1)proxy_buffering off、(2)Cloud Run/EC2、(3)Cookie 認証、(4)スケール設計、(5)接続数監視、です。