ゲームラグ白書 › L13 サーバー構成と運用
デプロイ・再起動 Deploy / rolling restart
原因ID in-deploy · 主担当 ゲーム開発チーム・サーバー開発 · 副担当 インフラチーム・サーバーインフラ
図と実験のあるメインページでこのカードを開く →
アップデートのためにサーバーを再起動するとき、接続を移さずに止めると、そのサーバーにいた人は切断され、終了直前の保存と再接続が一気に集中します。
なぜ ホットフィックスのデプロイでサーバーを順番に再起動 → すると 接続を別のサーバーに移さずに終了、そのサーバーにいた全ユーザーの保存がDBに集中 → 画面では 告知なしの切断、再接続の殺到
- 症状
- 切断, 接続不可・無限ロード, 入力遅延
- 要因
- ストール
- 誰に起きるか
- サーバー全体, 特定の場所・チャンネル
- いつ
- ときどきランダムに, 接続直後・メンテ明け
- 担当
- 主担当 ゲーム開発チーム・サーバー開発 · 副担当 インフラチーム・サーバーインフラ
- ゲーム開発チームの対応
- ドレイン機能（新規接続だけを止め、既存のユーザーが抜けるまで待つ）、キャラクターを別のサーバーへ移す、終了前の保存を分散して行う、再起動後はキャッシュのロード・JITウォームアップを終えてから準備完了を通知、ホットリロードは別スレッドで先に読み込んでおき、ティックの合間に一度に差し替え。
- インフラチームの対応
- デプロイツールが1台ずつドレインを待ってから再起動、再起動したサーバーは準備完了（ウォームアップ完了）を確認してからトラフィックを受ける、デプロイ時刻の告知。
- 数値の目安
- サーバー1台に5,000人いれば、終了直前の数秒間に5,000件の保存がDBに集中します。
- グラフでは
- 接続が一斉に切れる · サーバーごとの接続数、DB書き込み数
- 確認箇所
- デプロイツールの作業記録（サーバーごとの再起動時刻）を、接続数・切断数・DB書き込み・ログインリクエストのグラフに縦線（アノテーション）として重ねて確認
- 該当する場合
- サーバーごとの接続数が再起動時刻に1台ずつ順番に急落し、その直前にDB書き込みが、直後にログインリクエストが跳ね上がる
- 該当しない場合
- 切断の時刻がデプロイ・再起動の記録と重ならなければ、サーバークラッシュかネットワーク機器側
- 確認手段
- インフラのツールで確認（ゲームコード不要）
- もっと詳しく
- 再起動した直後の数分間も遅くなります。キャッシュが空なのでDBへの問い合わせが集中し、Java・C#のサーバーは実行しながらコードを最適化する過程（JITウォームアップ）が終わる前なので、同じ処理により時間がかかります。サーバーを止めずにスクリプトやデータテーブルを読み直す方式（ホットリロード）でも、読み込み中はティックが止まるため、短い停止が起きます。
出典
- Site Reliability Engineering, Chapter 20: Load Balancing in the Datacenter Google
SIGTERMを受けたサーバーはlame duck状態になり、新しいリクエストを別のサーバーへ回して処理中のリクエストだけを終える、再起動直後の数分はJIT最適化前でリソースを多く使うため、ウォームアップ後にトラフィックを受けさせる - Liveness, Readiness, and Startup Probes Kubernetes
Readiness Probeで、接続の確立・ファイルのロード・キャッシュのウォームアップが終わるまでトラフィックを送らない - Edit target group attributes for your Network Load Balancer AWS
ターゲットの登録を解除すると、新しい接続は送らず既存の接続はドレイン（デフォルト300秒）
あわせて読みたい原因
同じ層：L13 サーバー構成と運用
同じ症状（切断）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る