WebSocket 本番運用は『接続を維持』の設計が肝
WebSocket は双方向通信に強い一方、本番運用では接続管理・認証・スケールが複雑です。本記事では編集部の視点で、運用の要点を公開情報をもとに整理します。WebSocket 実践ロードマップ もご参考に。
主要なユースケース
(1) チャット：1対1/グループ。(2) 共同編集：Google Docs 風。(3) ライブダッシュ：株価/IoT。(4) ゲーム：マルチプレイ。(5) 通知配信：プッシュより細かい。
接続認証
(1) 初回接続時のトークン検証：JWT/Session。(2) クエリパラメータ：簡易だがURL ログに残る。(3) cookie 経由：SameSite 注意。(4) STOMP/MQTT：プロトコル内認証。(5) 定期的なトークン更新：長期接続向け。OAuth/OIDC 実装 もご参考に。
スケール戦略
(1) 水平スケール：複数サーバー。(2) 共通 Pub/Sub：Redis/Kafka でメッセージ配信。(3) sticky session：同一ユーザー同サーバー。(4) マネージドサービス：Pusher/Ably/AWS API Gateway WS。(5) 1サーバーで10万接続が現実的(公開情報をもとに)。
接続断対応
(1) 自動再接続：指数バックオフ。(2) 未送信メッセージのバッファ。(3) 状態同期：再接続時の差分取得。(4) heartbeat (ping/pong)：接続死活監視。(5) ロードバランサのタイムアウト確認。
本番監視
(1) 接続数：リアルタイム把握。(2) メッセージレート：QPS。(3) レイテンシ p99。(4) 切断率：異常検知。(5) サーバ別の偏り。Prometheus+Grafana 実践 もご参考に。
セキュリティ
(1) WSS 強制：暗号化。(2) Origin チェック：CSRF 防止。(3) メッセージ検証：入力サニタイズ。(4) レート制限：spam 防止。(5) ペイロード上限：DoS 対策。Webセキュリティ実践 も合わせて。
失敗しがちなパターン
(1) シングルサーバー前提：スケール不能。(2) 認証なし：誰でも接続可能。(3) 切断検知遅い：ゾンビ接続増。(4) 監視なし：問題発見遅延。(5) クライアント側のメモリリーク。対策は、(1)Pub/Sub 連携、(2)JWT 検証、(3)heartbeat、(4)接続数アラート、(5)cleanup フック、です。