ゲームサーバーインフラ管理：ゼロダウンタイムのコンテンツローンチのためのスケーリングRunbook

公開日 2026年7月28日

要点まとめ

ゲームサーバーインフラ管理の実践的Runbook。ゼロダウンタイムのコンテンツローンチに必要なスケーリング手法、障害検知、自動化パターン、コスト最適化を網羅。プレイヤー離脱を防ぐベストプラクティスを提供。

コンテンツローンチまであと47分。オペレーションリーダーは、CloudWatchダッシュボード、2つのGameLiftフリートモニター、Kubernetesクラスターのヘルスビュー、そしてプレイヤーがすでに待機時間について文句を言っているSlackチャンネルを同時に睨みつけている。スケールアウトのクールダウンをリセットし、US-EastとEU-West間で手動でキャパシティを再調整する合間に、彼らは単一のイベントに週の勤務時間の60％を費やそうとしている。

これは仮定の話ではない。あるスタジオの運用チームは、まさにそのパターン——ローンチイベント中にAWS Consoleのインターフェース間をコンテキストスイッチする——を文書化している。ある大規模コンテンツリリースでは、手動のスケーリング判断が2時間の待機時間スパイクを引き起こし、その結果12％のプレイヤー離脱を招いた。それらのプレイヤーはサポートチケットを提出しなかった。ただ去っただけだ。

ゲームサーバーインフラ管理は、ホワイトボード上では単純に見える（「オートスケールすればいいじゃん」）が、4リージョンにわたって1万人の同時プレイヤーがいると悪夢と化す問題の一つだ。このRunbookでは、実際に何が壊れるのか、Discordが炎上する前にそれをどう捉えるか、そして全員総出の騒動なしに次のローンチを乗り切るシステムをどう構築するかをカバーする。

ローンチ日を台無しにする3つの障害モード

ゲームサーバーのスケーリング障害はすべて、以下のカテゴリのいずれかに該当する。どの障害に直面しているかを理解することで、対応が決まる。

1. キャパシティ枯渇

何が起こるか: プレイヤー数が事前にプロビジョニングされたフリートキャパシティを超えて急増する。新しいインスタンスが起動し、マッチメイキングサービスに登録されるまでに3〜7分かかる。その間、待機時間は5秒から4分以上に跳ね上がる。平均セッション待機時間は、研究が一貫してプレイヤーがキューを完全に放棄する原因となる90秒の閾値を超える。

なぜ難しいのか: オートスケーリングは実際の需要に遅れて追従するメトリクスに反応する。使用率メトリクスが85％に達してスケールアウトをトリガーする頃には、すでに遅れている。5分のプロビジョニングウィンドウは、今日のスパイク中に昨日のキャパシティでプレイヤーにサービスを提供していることを意味する。

連鎖的損害: 60秒以内に参加できないプレイヤーは去る。ローンチウィンドウ中に去ったプレイヤーが同じ日に戻ってくることは稀である。戻ってこない者もいる。あの12％の離脱率は一回限りの収益ヒットではない——口コミの喪失、レビュースコアの低下、有機的成長の減少を通じて複合的に影響する。

2. リージョン不均衡

何が起こるか: コンテンツドロップが世界同時に固定時刻で公開される。EUのプレイヤーはUSのプレイヤーが起きる4〜6時間前にサーバーにヒットする。EUフリートは飽和する一方、USサーバーはアイドル状態。USプレイヤーが到着する頃には、EUフリートは必死のスケールアウトを引き起こし、チームは手動でキャパシティを再割り当てしている。

なぜ難しいのか: クラウドのオートスケーリングはデフォルトでリージョンごとに動作する。「EUは95％、USは35％、再配分せよ」という概念はない。その結果、あるリージョンではインスタンスに過剰な費用をかけ、別のリージョンでは過負荷サーバーによるレイテンシー低下に悩まされる。

3. コスト暴走

何が起こるか: スパイクに備えて積極的にプロビジョニングするが、スケールインポリシーは保守的（誰も早すぎるスケールダウンを恐れる）。イベントの2日後、180のインスタンスがまだ1時間あたり合計0.50ドルで稼働しているのを発見する——それは1日あたり2,160ドルのアイドルコンピューティングだ。

アイドルサーバーコストとその対処のためのアーキテクチャパターンに関する詳細なコンテキストは、Fortniteのサーバーハイバネーション提案の分析で、プロアクティブなキャパシティ管理の経済性を解説している。

検知：プレイヤーが気づく前に問題を捉える

Runbookの検知層は、次の質問に答える必要がある：プレイヤーに影響する問題が起きようとしているか？

実際に重要なメトリクス

ほとんどのゲームサーバーモニタリングダッシュボードは、CPU使用率グラフやネットワークスループットチャートで散らかっている。以下が実際にスケーリング障害を予測するものだ：

リージョンごとのキュー深度（アラート閾値：50人以上の待機者）

これが先行指標だ。キューが溜まり始めると、プレイヤーが放棄し始めるまでにおよそ60秒の猶予がある。AverageWaitTime に関するCloudWatchアラームをフリートごとに設定する：

aws cloudwatch put-metric-alarm \
  --alarm-name "game-server-east-queue-spike" \
  --namespace "GameLift" \
  --metric-name "AverageWaitTime" \
  --dimensions Name=FleetId,Value=fleet-abc123 \
  --statistic Average \
  --period 30 \
  --threshold 45 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-east-1:123456789:ops-alerts \
  --treat-missing-data notBreaching

重要な詳細：30秒間隔と2評価期間を使用する。つまり、アラートが出るまでに60秒連続のキュー蓄積が必要になる。それ以上長いと、すでに3分も経過した問題に反応していることになる。

利用可能なゲームセッション比率（アラート閾値：20％未満のバッファ）

利用可能なセッションが総キャパシティの20％を下回ると、あと一つのスパイクでキューが発生する。このメトリクスは、生のCPU使用率よりも、コンピューティングキャパシティとセッション割り当てロジックの両方を考慮するため、より有用である。

インスタンス準備完了までの時間（アラート閾値：4分以上）

新しいインスタンスが準備完了になるまでに4分以上かかる場合、AMI、userdataスクリプト、またはゲームサーバーの起動プロセスに問題がある。これをフリートごと、リージョンごとに追跡する。インスタンスの準備が遅いと、他のすべてのスケーリング問題が増幅される。

プレイヤー時間あたりのコスト（毎日追跡、ベースラインの2倍でアラート）

これはインフラ支出を実際のプレイヤーアクティビティに結びつける。プレイヤー時間あたりのコストが倍増したが、同時プレイヤー数が増えていない場合、過剰プロビジョニングである。次のように計算する：

def cost_per_player_hour(total_compute_cost_hours, total_player_hours):
    """
    total_compute_cost_hours: 全インスタンスの (instance_cost_per_hour * hours_running) の合計
    total_player_hours: 全リージョンの (average_concurrent_players * hours_of_operation) の合計
    """
    if total_player_hours == 0:
        return 0
    return total_compute_cost_hours / total_player_hours

# 例: 200インスタンス、1時間あたり$0.085、24時間 = $408
# 8,000人の平均同時プレイヤー * 24時間 = 192,000 player-hours
# プレイヤー時間あたりのコスト: $408 / 192,000 = $0.002
# この数値がプレイヤー増加なしに$0.005以上に跳ね上がったら、すぐに調査する。

手動ゲームサーバーインフラ管理のRunbook

ベアクラウドサービスでゲームサーバーインフラを管理している場合、以下の運用シーケンスが「ローンチを生き延びた」と「ポストモーテムを書く」を分ける。

フェーズ1: ローンチ前キャパシティ計画（48〜72時間前）

過去7〜14日間のピーク同時プレイヤーデータを取得する。平均値を使用してはならない——必要なのはピーク値であり、リージョンごとにセグメント化する：

import boto3
from datetime import datetime, timedelta

cloudwatch = boto3.client('cloudwatch')
regions = ['us-east-1', 'us-west-2', 'eu-west-1', 'ap-northeast-1']

def get_peak_concurrent_players(region, days=7):
    """CloudWatchからリージョンのピーク同時プレイヤー数を取得する。"""
    response = cloudwatch.get_metric_statistics(
        Namespace='Custom/Game',
        MetricName='ConcurrentPlayers',
        Dimensions=[{'Name': 'Region', 'Value': region}],
        StartTime=datetime.utcnow() - timedelta(days=days),
        EndTime=datetime.utcnow(),
        Period=3600,  # 1時間単位
        Statistics=['Maximum']
    )
    
    if not response['Datapoints']:
        return 0
    
    return max(point['Maximum'] for point in response['Datapoints'])

# キャパシティ計画を構築
PLAYERS_PER_INSTANCE = 50  # ゲームのプレイヤー密度に合わせて調整
LAUNCH_BUFFER_MULTIPLIER = 2.0  # コンテンツローンチ用の2倍の余裕

for region in regions:
    peak = get_peak_concurrent_players(region)
    required_instances = int((peak * LAUNCH_BUFFER_MULTIPLIER) / PLAYERS_PER_INSTANCE)
    print(f"{region}: peak={peak}, target={int(peak * LAUNCH_BUFFER_MULTIPLIER)}, instances={required_instances}")

この段階での重要な判断：

バッファ乗数: マイナーパッチでは1.5倍、大規模コンテンツドロップでは2.0倍、F2Pローンチイベントでは3.0倍。選択した乗数はコストとリスクの両方に直接影響する。
インスタンスあたりのプレイヤー数: ロードテストから測定すること。アーキテクチャドキュメントからではない。50人仕様のサーバーでも、マップの複雑さによって60Hzのティックレートで35人しか持たない場合がある。
リージョン分布: 過去30日間の実際のプレイヤー分布を取得する。40/30/20/10の分割を想定してはならない。コミュニティの所在地によっては、ゲームの60％がAPACである可能性もある。

フェーズ2: スケーリングポリシーの設定（24時間前）

汎用的なCPUベースのオートスケーリングはゲームワークロードを理解しない。CPUが70％のGameLiftフリートは完全に健全かもしれないが、CPUが40％でも全セッションが満杯でプレイヤーがキューイングしている場合がある。

スケーリングポリシーはゲーム関連メトリクスに基づいて設定する：

{
  "FleetId": "fleet-abc123",
  "Name": "launch-event-scaling",
  "TargetConfiguration": {
    "TargetValue": 25.0,
    "CustomizedMetricSpecification": {
      "MetricName": "AvailableGameSessions",
      "Namespace": "GameLift",
      "Dimensions": [{"Name": "FleetId", "Value": "fleet-abc123"}],
      "Statistic": "Average",
      "Unit": "Count"
    },
    "ScaleInCooldown": 600,
    "ScaleOutCooldown": 60
  }
}

重要な非自明な設定：

スケールアウトクールダウン: 60秒。 プレイヤーは待たない。クールダウンが300秒（多くのチュートリアルのデフォルト）だと、キャパシティ注入の間に5分待たせることになる。
スケールインクールダウン: 600秒（10分）。 変動するローンチイベント中に積極的なスケールインを行うと、振動が発生する——フリートがスケールダウンし、需要が再び急上昇し、再度プロビジョニングして時間とコストを浪費する。10分のクールダウンは、自然な落ち込みを吸収し、早すぎるスケールダウンを防ぐ。
ターゲット値を25（セッション）に設定： これにより、フリートごとに25の利用可能なゲームセッションが予備として保持される。メトリクスが25を下回ると、新しいインスタンスが起動する。この数値は、通常のプレイヤー到着率の約2〜3分を表すべきである。

フェーズ3: ローンチモニタリング（ローンチ後0〜6時間）

ここでほとんどの運用チームが丸一日を失う。ダッシュボードを手動でリフレッシュして座っているのではなく、 モニタリングループをスクリプト化する：

#!/bin/bash
# launch-monitor.sh — ローンチウィンドウ中に60秒ごとに実行
# 要件: aws cli, jq

FLEET_IDS=("fleet-abc123" "fleet-def456" "fleet-ghi789")
REGIONS=("us-east-1" "us-west-2" "eu-west-1")
ALERT_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"

for i in "${!FLEET_IDS[@]}"; do
  FLEET="${FLEET_IDS[$i]}"
  REGION="${REGIONS[$i]}"
  
  # 現在のメトリクスを取得
  METRICS=$(aws gamelift describe-fleet-utilization \
    --fleet-ids "$FLEET" \
    --region "$REGION" \
    --query 'FleetUtilization[0]')
  
  ACTIVE_SESSIONS=$(echo "$METRICS" | jq -r '.ActiveServerSessionCount // 0')
  MAX_SESSIONS=$(echo "$METRICS" | jq -r '.CurrentPlayerSessionCount // 0')
  AVAILABLE=$(echo "$METRICS" | jq -r '.IdleServerSessionCount // 0')
  
  # 使用率パーセンテージを計算
  if [ "$MAX_SESSIONS" -gt 0 ]; then
    UTILIZATION=$(( (ACTIVE_SESSIONS * 100) / (ACTIVE_SESSIONS + AVAILABLE) ))
  else
    UTILIZATION=0
  fi
  
  # 使用率が80%を超えたらアラート
  if [ "$UTILIZATION" -gt 80 ]; then
    curl -s -X POST "$ALERT_WEBHOOK" \
      -H 'Content-Type: application/json' \
      -d "{\"text\": \"⚠️ WARNING: Fleet $FLEET ($REGION) at ${UTILIZATION}% utilization. Available sessions: $AVAILABLE\"}"
  fi
  
  echo "[$(date)] $REGION: ${UTILIZATION}% utilization, $AVAILABLE available sessions"
done

これをローンチウィンドウ中にターミナルで実行する。適切なアラートの代わりにはならないが、オンコールエンジニアに3つのブラウザタブではなく単一のペインを提供する。

フェーズ4: ローンチ後クリーンアップ（24〜48時間後）

スパイク後、オートスケーリングが実際にスケールインしたことを確認する。孤立したインスタンスは、ローンチ後のコストサプライズの第1の原因である：

# リージョン間でまだ実行中のゲームサーバーインスタンスをすべて検索
for region in us-east-1 us-west-2 eu-west-1 ap-northeast-1; do
  echo "=== $region ==="
  aws gamelift describe-fleet-utilization \
    --region "$region" \
    --query 'FleetUtilization[?ActiveServerSessionCount==`0` && IdIdleServerSessionCount>`5`].[FleetId,IdleServerSessionCount]' \
    --output table
done

アクティブセッションが0でアイドルインスタンスが5つを超えるフリートは、すぐに調査する必要がある。スケールインポリシーがトリガーされなかったか、フリートの最小キャパシティがイベント後の需要に対して高すぎる設定になっている可能性がある。

手動管理が限界に達する時

上記のRunbookは、2〜3リージョンの単一ゲームタイトルでは機能する。以下の場合に崩壊し始める：

異なるバックエンドを持つ複数のタイトル。 GameLiftゲームにはあるダッシュボードセット、Kubernetesベースのゲームには別のセットがある。運用エンジニアは両方に習熟し、根本的に異なるインフラ間でパフォーマンスデータを相関させる能力が必要になる。これにより生じる知識のサイロ化は現実的だ——Kubernetesのスペシャリストが不在の場合、GameLiftチームはEKSのスケーリング問題に対応できず、その逆も同様である。

非標準イベントの需要予測。 予期せぬTwitchストリーマーのコサイン、競合のローンチ遅延、または予想外のバイラルモーメントは、過去のデータでは予測できない需要スパイクを生み出す。事前にプロビジョニングされたバッファだけでなく、リアルタイムの応答型スケーリングが必要である。

スポット、オンデマンド、リザーブドインスタンス間のコストとレイテンシーのバランス。 最適な組み合わせは、スポット価格と需要パターンに基づいて1時間ごとに変化する。ほとんどのチームはすべてをオンデマンドで実行することで単純化しているが、これは安全だが、最適化された混合フリート戦略よりも3〜4倍のコストがかかる。

この複雑さこそが、AWSが自然言語クエリを通じてGameLiftフリートとEKSクラスターを管理するエージェンティックAIワークフロー向けのガイダンスを構築した理由である——ゲームサーバーインフラ管理の運用オーバーヘッドが、従来のダッシュボードやCLIスクリプトを超えたことを認識したものだ。

自己修復型インフラのためのアーキテクチャパターン

ますます複雑な手動プロセスを構築するのではなく、スケーリングイベント中の人間の介入を減らすこれらのパターンに焦点を当てる。

予測型キャパシティスケジューリング

計画されたイベント（コンテンツドロップ、シーズンローンチ、週末イベント）では、需要が到着する前にキャパシティ増加をスケジュールする：

import boto3
from datetime import datetime, timedelta

def schedule_capacity_ramp(fleet_id, target_instances, ramp_start_utc, region='us-east-1'):
    """
    ramp_start_utcからフリートキャパシティを段階的に増加させる。
    現在のキャパシティからターゲットまで30分かけてスケールする。
    """
    gamelift = boto3.client('gamelift', region_name=region)
    
    # 現在のキャパシティを取得
    fleet_attrs = gamelift.describe_fleet_attributes(FleetIds=[fleet_id])
    current = fleet_attrs['FleetAttributes'][0]
    min_cap = current['MinSize']
    
    # ランプを計算: 30分で3ステップ、10分間隔
    step_size = max(1, (target_instances - min_cap) // 3)
    
    steps = []
    for i in range(3):
        step_capacity = min(min_cap + (step_size * (i + 1)), target_instances)
        steps.append({
            'minute': i * 10,
            'capacity': step_capacity
        })
    
    return steps

# 使用例
steps = schedule_capacity_ramp(
    fleet_id='fleet-abc123',
    target_instances=120,
    ramp_start_utc='2025-01-15T17:00:00Z'  # ローンチの30分前
)
# CloudWatch Events / Step Functions / cron で実行
for step in steps:
    print(f"T+{step['minute']}min: set desired capacity to {step['capacity']}")

ランプアプローチが重要な理由は、120インスタンスを同時に起動するとEBSスナップショットの競合を引き起こし、フリートの同時インスタンス制限を超える可能性があるからだ。約40インスタンスの3バッチに分散することで、プロビジョニングのボトルネックを回避できる。

自動修復ルール

モニタリングエンジニアがコーヒーを飲み終える前にトリガーされる自己修復ルールを定義する：

# remediation-rules.yaml
remediation_rules:
  - name: "queue-time-spike"
    condition:
      metric: "AverageWaitTime"
      operator: "greater_than"
      threshold_seconds: 45
      duration_seconds: 90
    action: "scale_out"
    parameters:
      scale_percent: 30  # フリートキャパシティを30%増加
      cooldown_seconds: 120  # 次のスケールアクションまで2分待機
    notification: "ops-alerts-sns-topic"
    
  - name: "idle-instance-cleanup"
    condition:
      metric: "ActiveServerSessionCount"
      operator: "equals"
      threshold: 0
      duration_seconds: 1200  # セッションゼロが20分続く
    action: "scale_in"
    parameters:
      scale_percent: 50  # アイドルインスタンスの半分を削除
      cooldown_seconds: 600
    notification: "ops-alerts-sns-topic"
      
  - name: "resource-starvation"
    condition:
      metric: "AvailableGameSessions"
      operator: "less_than"
      threshold: 10
      duration_seconds: 60
    action: "emergency_scale_out"
    parameters:
      scale_percent: 75  # 積極的な75%キャパシティ増加
      cooldown_seconds: 60
    notification: "incidents-sns-topic"  # PagerDuty連携
    priority: "critical"

リソース枯渇ルールは緊急バルブである。利用可能なセッションが10を下回り、その状態が1分続くと、プレイヤーが直面するキューまであと数秒の状態だ。75%のスケールアウトは意図的に積極的である——20分間過剰プロビジョニングする方が、待機時間でプレイヤーを失うよりは安上がりだ。

混合インスタンスフリート戦略

オンデマンドベースラインキャパシティとバースト用スポットインスタンスの組み合わせは、単一の最も影響力のあるコスト最適化だが、スポット中断を優雅に処理する必要がある。以下がパターンだ：

def calculate_fleet_composition(total_needed, baseline_percent=40):
    """
    フリートをオンデマンドベースライン + スポットバーストに分割する。
    オンデマンドは保証されたキャパシティをカバーし、スポットは急増に対応する。
    """
    on_demand = int(total_needed * (baseline_percent / 100))
    spot = total_needed - on_demand
    
    # スポット中断率を考慮（インスタンスタイプ/リージョンにより約5〜15%）
    # 実効キャパシティを維持するためにスポットに中断率分のバッファを追加
    spot_with_buffer = int(spot * 1.15)
    
    return {
        'on_demand': on_demand,
        'spot': spot_with_buffer,
        'total_provisioned': on_demand + spot_with_buffer,
        'effective_capacity': on_demand + spot,  # 中断後
        'cost_savings_estimate': f"{(spot * 0.7) / total_needed * 100:.0f}% vs all on-demand"
    }

# 例: コンテンツローンチに100サーバーが必要
composition = calculate_fleet_composition(100, baseline_percent=40)
# 戻り値:
# on_demand: 40 instances ($3.40/hr at $0.085/instance)
# spot: 69 instances ($1.77/hr at $0.026/instance)  
# effective_capacity: 100 servers
# cost_savings_estimate: "42%" vs all on-demand ($8.50/hr)

40/60の分割は出発点である。各リージョンのスポット中断履歴に基づいて調整する。セッション時間が長いゲーム（45分以上）では、セッション中のスポット中断が10分のマッチよりもはるかに破壊的であるため、オンデマンド比率を高くする必要があるかもしれない。

構築するか、購入するか：horizOn の位置づけ

これまで説明してきたもの——モニタリングスクリプト、スケーリングポリシー、修復ルール、混合インスタンスフリート管理、ローンチ後クリーンアップ——はすべて現実的で構築可能なインフラである。チームは実際に出荷している。プロダクショングレードのスケーリングシステムを構築するには、通常4〜6週間の専任エンジニアリング作業が必要であり、その後もクラウドAPIの進化やゲームのトラフィックパターンの変化に応じて継続的なメンテナンスが必要となる。

それはゲームプレイ機能、ネットコード、コンテンツに使われないエンジニアリング時間である。

horizOn は、ゲームサーバーインフラ管理を、ゲームごとのエンジニアリングプロジェクトではなく、解決済みのプラットフォーム問題として捉えている。スケーリング、リージョン分散、コスト最適化、サーバーライフサイクル管理はあらかじめ組み込まれている。運用オーバーヘッドは「ローンチイベントごとに2〜3人のエンジニア」から「スケーリングパラメーターを一度設定し、イベント中に確認する」に低下する。

トレードオフは、すべてのマネージドサービスが提示するものと同じである：より細かい制御と引き換えに、劇的に少ない運用負担。運用チームがゲームプレイチームでもあるスタジオ——ほとんどのインディーおよび中規模スタジオ——では、そのトレードオフは通常プラットフォームに有利に働く。

コスト内訳：インフラ管理の実際のコスト

4リージョンで1万人のピーク同時プレイヤーを提供するゲームについて、3つのアプローチに数字を当てはめてみる：

完全手動AWS（GameLift + EKS）

コンピューティング（200インスタンス、すべてオンデマンド）：1日あたり408ドル
保守的なスケーリングによる過剰プロビジョニング：+1日あたり122ドル（30％の無駄）
専任運用エンジニア（0.5 FTE）：1日あたり400〜600ドル
ローンチ時のインシデント対応残業：1イベントあたり200〜400ドル
月額見積もり：16,000〜24,000ドル

自動化AWS（カスタムスケーリング + 混合インスタンス）

コンピューティング（200インスタンス、40/60オンデマンド/スポット）：1日あたり245ドル
最適化スケーリングにより過剰プロビジョニングを10％に削減：+1日あたり25ドル
運用エンジニア時間（0.2 FTEメンテナンス）：1日あたり160〜240ドル
月額見積もり：13,000〜15,500ドル

マネージドプラットフォーム（horizOn）

インフラはプラットフォームサービスとして処理：使用量に応じてスケール
インフラのための運用エンジニアリングオーバーヘッド：ゼロ
コストはプランによって異なるが、固定の運用オーバーヘッドを完全に排除

手動AWSと自動化AWSの差は月額約3,000〜8,500ドルである。自動化AWSとマネージドプラットフォームの差には、機会費用——それらのエンジニアがインフラメンテナンスの代わりに出荷するもの——も含まれる。

ベストプラクティス：ゲームサーバースケーリングの5つのルール

フリート全体の平均ではなく、リージョンごとのピーク同時プレイヤーを追跡する。 グローバルで平均5,000 CCUのゲームでも、ピーク時にはUS-Eastで3,200になる可能性がある。フリート全体の数値は、最も深刻なプレイヤー向け問題を引き起こすリージョンホットスポットを隠す。キャパシティ計画のベースラインとして、少なくとも14日間のリージョン別ピークデータを保存する。
スケールアウトクールダウンを最大60秒に設定する。 標準的なクラウドオートスケーリングのクールダウン300〜600秒はWebワークロード向けに設計されており、プレイヤーが90秒以内にキューを放棄するゲームサーバーには適さない。60秒のクールダウンは、スパイク中に毎分新しいキャパシティを注入することを意味し、待機時間を管理可能に保つのに十分速い。
スケールインはより長いクールダウン（10分）で自動化する。 スケールインは、ほとんどのチームが積極的すぎる（短い落ち込み中に時期尚早にインスタンスを殺す）か、保守的すぎる（決してスケールダウンせず、金を浪費する）かのどちらかである。10分のスケールインクールダウンは、自然な需要変動を吸収し、アイドルサーバーを何時間も稼働させ続けることを防ぐ。
計画されたイベントの30〜60分前に事前プロビジョニングする。 オートスケーリングは本質的に反応的である。コンテンツドロップ、シーズンイベント、マーケティングプッシュなど、来ることがわかっているイベントについては、事前にキャパシティ増加をスケジュールする。30分間に3回の増分バッチで、100以上のインスタンスを同時に起動するプロビジョニングボトルネックを回避する。
生のコンピューティング支出ではなく、プレイヤー時間あたりのコストを測定する。 1日500ドルで1万5千人のピークプレイヤーにサービスを提供する（$0.0014/プレイヤー時間）のは健全である。1日200ドルで500人のピークプレイヤーにサービスを提供する（$0.0167/プレイヤー時間）のは12倍非効率である。このメトリクスだけが、コスト最適化の議論を財務とエンジニアリングの間の対立的なものではなく、生産的なものにする。

次のローンチ日の悲劇を防ぐ

最初のローンチ日のスケーリング障害は通常、特定のイベントのせいにされる：「あれだけのプレイヤーが来るとは思わなかった」とか「オートスケーリングポリシーにバグがあった」など。2回目の障害はプロセスのせいにされる：「十分なモニタリングがなかった」。3回目の障害までに、チームはアーキテクチャ自体が問題であることに気づく。

ゲームサーバーインフラ管理の複雑さは、サポートするゲーム、リージョン、ホスティングプラットフォームの数に対して非線形に増大する。新しいタイトルごとに、監視すべき新しいフリート、潜在的に新しいスケーリングポリシーセット、そして運用チームがローンチイベント中にチェックすべき別のダッシュボードセットが追加される。

修正策は、より良いスクリプトやより多くのダッシュボードではない——チームが管理する必要のある表面積を減らすことだ。より少ないインフラプラットフォームに統合する。反応的なスケーリングを自動化する。予測可能なイベントには事前にプロビジョニングする。そして、クラウド請求書だけでなく、プレイヤーの価値に対してコストを測定する。

現在のインフラ管理ワークフローが、コンテンツローンチ中にダッシュボードを凝視する複数の人間を必要とする場合、それはアーキテクチャを変更する必要があるというシグナルであり、より大きな運用チームが必要というわけではない。

インフラ管理システムを構築するのをやめて、ゲームを出荷する準備はできたか？ horizOn を無料で試すか、APIドキュメントを参照して、マネージドゲームバックエンドが実際にどのように動作するかを確認しよう。

出典: エージェンティックAIがゲームインフラ管理を変革する方法

前の記事 70万人のプレイヤーがインディーマルチプレイヤーゲームに同時に押し寄せたら何が起きるか（そして生き残る方法）