ゲームラグ白書 › L13 サーバー構成と運用
オートスケーリングの遅れ Autoscaling lag
原因ID in-autoscale · 主担当 インフラチーム・サーバーインフラ · 副担当 ゲーム開発チーム・サーバー開発
図と実験のあるメインページでこのカードを開く →
人が集中するとサーバーを自動で増やしますが、準備に数分かかり、その間は既存のサーバーが過負荷になります。
なぜ イベント開始で接続が急増 → すると 新しいサーバーが起動して準備が整うまで数分 → 画面では イベント開始直後の数分間、スローモーション・接続不可
- 症状
- スローモーション, 接続不可・無限ロード
- 要因
- ストール
- 誰に起きるか
- サーバー全体
- いつ
- 人が集中したとき, 接続直後・メンテ明け
- 担当
- 主担当 インフラチーム・サーバーインフラ · 副担当 ゲーム開発チーム・サーバー開発
- ゲーム開発チームの対応
- チャンネル分散（すでに混雑しているチャンネルにいる人は新しいサーバーに移せない）、新しいサーバーの起動・データロード時間の短縮。
- インフラチームの対応
- イベント前の事前スケールアウト、ウォームアップ済みの予備サーバー、縮小時は残っている人が抜けてから停止。
- 数値の目安
- 負荷の検知に1〜数分（メトリクスを数分間平均して見るため）、新しいサーバーを起動してゲームデータを読み込み、キャッシュを埋めるのにさらに数分。
- グラフでは
- 接続直後・メンテ明けに急増 · インスタンス数、CPU使用率、接続待ち
- 確認箇所
- オートスケーリングのアクティビティ履歴（スケールアウトを決めた時刻、新しいインスタンスがサービスに入った時刻）をCPU使用率・接続数のグラフに重ねて確認。AWSではAuto Scalingグループのメトリクス（有効にしないと表示されない）GroupDesiredCapacity（目標台数）・GroupPendingInstances（準備中）・GroupInServiceInstances（サービス中）
- 該当する場合
- 接続が急増してから数分間、目標台数と準備中のインスタンスだけが増えて既存サーバーのCPUが上限に張り付き、サービス中のインスタンスが増えた時刻から解消する
- 該当しない場合
- 新しいインスタンスが入った後も遅いなら、サーバー台数以外の原因（DBなどの共用リソース、カスケード障害）側
- 確認手段
- インフラのツールで確認（ゲームコード不要）
- もっと詳しく
- オートスケーリングは主に、ログイン・ゲートウェイ・ダンジョンのように、新しいサーバーで新しい人を受け入れればよい所に使います。縮小するときにも問題が起きます。人が減った明け方にサーバーを減らすとき、残っている人が抜けるのを待たずに止めると、その人たちは切断されます。
- 実際の事例
- AWS 2021: AWS us-east-1の内部ネットワーク輻輳
AWS 2025: AWS us-east-1のDynamoDB DNS障害と長引いた復旧
出典
- Target tracking scaling policies for Amazon EC2 Auto Scaling AWS
EC2の基本メトリクスは5分間隔（詳細モニタリングを有効にすると1分）なので、素早く反応させるには1分以下の間隔のメトリクスを推奨 - Amazon CloudWatch metrics for Amazon EC2 Auto Scaling AWS
グループメトリクスは有効にすると1分単位で発行される、GroupDesiredCapacity（維持しようとする台数）・GroupPendingInstances（まだサービス前のインスタンス数）・GroupInServiceInstances（サービス中のインスタンス数） - Scheduled scaling for Amazon EC2 Auto Scaling AWS
予測できる負荷の変化に合わせ、決めた時刻に容量を前もって増減 - Decrease latency for applications with long boot times using warm pools AWS
起動に時間がかかるアプリは、事前に初期化しておいたインスタンスのプール（ウォームプール）でスケールアウトの遅れを減らす
あわせて読みたい原因
同じ層：L13 サーバー構成と運用
同じ症状（スローモーション）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る