Oyun Sunucu Altyapı Yönetimi: Kesintisiz İçerik Lansmanları için Ölçeklendirme Runbook'u

İçerik lansmanına 47 dakika kaldı. Operasyon lideriniz aynı anda bir CloudWatch panosuna, iki GameLift filo monitörüne, bir Kubernetes küme sağlık görünümüne ve oyuncuların şimdiden sıra sürelerinden şikayet ettiği bir Slack kanalına bakıyor. Scale-out bekleme sürelerini sıfırlamak ve US-East ile EU-West arasında kapasiteyi manuel olarak yeniden dengelemek arasında, tek bir etkinlik için haftalık çalışma sürelerinin %60'ını harcamak üzereler.

Bu varsayımsal değil. Bir stüdyonun operasyon ekibi, lansman etkinlikleri sırasında AWS Console arayüzleri arasında bağlam değiştirme modelini tam olarak belgeledi. Büyük bir içerik sürümü sırasında, manuel ölçeklendirme kararları 2 saatlik sıra süresi artışına ve %12 oyuncu kaybına yol açtı. Bu oyuncular destek bileti açmadı. Sadece gittiler.

Oyun sunucu altyapı yönetimi, beyaz tahtada basit görünen ("sadece otomatik ölçeklendir, kanka") ve dört bölgede 10.000 eşzamanlı oyuncuda kabusa dönüşen sorunlardan biridir. Bu runbook, gerçekte neyin bozulduğunu, Discord'unuz alev almadan önce nasıl yakalanacağını ve bir sonraki lansmanı tüm ekibi seferber etmeden atlatacak sistemlerin nasıl inşa edileceğini kapsar.

Lansman Günlerini Öldüren Üç Hata Modu

Her oyun sunucu ölçeklendirme felaketi bu kategorilerden birine girer. Hangisiyle karşı karşıya olduğunuzu anlamak, yanıtınızı belirler.

1. Kapasite Tükenmesi

Ne olur: Oyuncu sayıları, önceden sağlanan filo kapasitenizin üzerine çıkar. Yeni örneklerin başlatılması ve eşleştirme hizmetinize kaydolması 3-7 dakika sürer. Bu süre zarfında sıra süreleri 5 saniyeden 4+ dakikaya fırlar. Araştırmaların oyuncuların sırayı tamamen terk etmesine neden olduğunu gösterdiği 90 saniyelik eşik aşılır.

Neden zor: Otomatik ölçeklendirme, gerçek talebin gerisinde kalan metriklerle tepki verir. Kullanım metriğiniz %85'e ulaşıp ölçeği tetiklediğinde, çoktan geride kalmışsınızdır. 5 dakikalık sağlama penceresi, bugünkü artış sırasında dünün kapasitesiyle oyunculara hizmet verdiğiniz anlamına gelir.

Kademeli hasar: 60 saniyeden kısa sürede katılamayan oyuncular ayrılır. Lansman penceresi sırasında ayrılan oyuncular nadiren aynı gün geri döner. Bazıları asla geri dönmez. Bu %12'lik oyuncu kaybı tek seferlik bir gelir darbesi değildir — kaçırılan kulaktan kulağa, düşük inceleme puanları ve azalan organik büyüme yoluyla birikir.

2. Bölgesel Dengesizlik

Ne olur: İçerik düşüşünüz küresel olarak sabit bir saatte canlı yayına girer. AB oyuncuları, ABD oyuncuları uyanmadan 4-6 saat önce sunuculara ulaşır. AB filonuz doygunluğa ulaşırken ABD sunucuları boşta kalır. ABD oyuncuları geldiğinde, AB filosu çılgınca ölçeklendirme işlemlerini tetiklemiş olur ve ekibiniz manuel olarak kapasite yönlendirmesi yapar.

Neden zor: Bulut otomatik ölçeklendirmesi varsayılan olarak bölge bazında çalışır. "AB %95'te, ABD %35'te, yeniden dağıt" kavramı yoktur. Bir bölge örnekler için aşırı harcama yaparken, başka bir bölgedeki oyuncular aşırı yüklenmiş sunuculardan kaynaklanan gecikme yaşar.

3. Maliyet Kaçağı

Ne olur: Artış için agresif bir şekilde sağlama yaparsınız, ancak ölçek içe politikaları muhafazakârdır (herkes çok erken ölçek küçültmekten korkar). Etkinlikten iki gün sonra, hala çalışan 180 örneğin her biri saatte 0,50$'a mal oluyor — bu, günde 2.160$ boşta bilgi işlem demektir.

Boşta sunucu maliyetleri ve bunlarla başa çıkmak için mimari desenler hakkında daha fazla bağlam için, Fortnite'ın sunucu hazırda bekletme önerisi analizimiz, proaktif kapasite yönetiminin ekonomisini ayrıntılı olarak açıklıyor.

Algılama: Sorunları Oyuncularınızdan Önce Yakalamak

Runbook'un algılama katmanı tek bir soruyu yanıtlamalıdır: oyuncuya yönelik bir sorunla mı karşı karşıyayız?

Gerçekten Önemli Olan Metrikler

Çoğu oyun sunucu izleme panosu, CPU kullanım grafikleri ve ağ verimi tablolarıyla doludur. İşte bir ölçeklendirme hatasını gerçekten tahmin edenler:

Bölge başına sıra derinliği (uyarı eşiği: 50+ oyuncu bekliyor)

Bu sizin öncü göstergenizdir. Bir sıra dolmaya başladığında, oyuncuların terk etmeye başlamasından önce kabaca 60 saniyeniz vardır. Filo başına AverageWaitTime üzerinde CloudWatch alarmları kurun:

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

Kritik ayrıntı: 30 saniyelik periyot ile 2 değerlendirme periyodu kullanın. Bu, alarm vermeden önce 60 saniyelik sürekli sıra birikimi anlamına gelir. Daha uzun süreler, zaten 3 dakikalık bir soruna tepki veriyorsunuz demektir.

Kullanılabilir oyun oturumları oranı (uyarı eşiği: %20 tamponun altında)

Kullanılabilir oturumlar toplam kapasitenin %20'sinin altına düştüğünde, sıralardan bir artış uzaktasınız. Bu metrik, hem bilgi işlem kapasitesini hem de oturum atama mantığını hesaba kattığı için ham CPU kullanımından daha kullanışlıdır.

Örnek hazır olma süresi (uyarı eşiği: 4 dakikanın üzerinde)

Yeni örneklerin hazır hale gelmesi 4 dakikadan uzun sürüyorsa, AMI'nizde, userdata betiklerinizde veya oyun sunucu başlatma sürecinizde bir sorun var demektir. Bunu filo ve bölge bazında takip edin. Yavaş örnek hazırlığı, diğer tüm ölçeklendirme sorunlarını büyütür.

Oyuncu-saat başına maliyet (günlük takip, 2x taban çizgisinde uyarı)

Bu, altyapı harcamasını gerçek oyuncu etkinliğine bağlar. Oyuncu-saat başına maliyetiniz iki katına çıktıysa ancak eşzamanlı oyuncu sayınız artmadıysa, aşırı sağlama yapıyorsunuzdur. Şu şekilde hesaplayın:

def cost_per_player_hour(total_compute_cost_hours, total_player_hours):
    """
    total_compute_cost_hours: tüm örneklerde (instance_cost_per_hour * hours_running) toplamı
    total_player_hours: tüm bölgelerde (average_concurrent_players * hours_of_operation) toplamı
    """
    if total_player_hours == 0:
        return 0
    return total_compute_cost_hours / total_player_hours

# Örnek: 200 örnek saatte 0,085$ ile 24 saat = 408$
# 8.000 ortalama eşzamanlı oyuncu * 24 saat = 192.000 oyuncu-saat
# Oyuncu-saat başına maliyet: 408$ / 192.000 = 0,002$
# Bu sayı oyuncu büyümesi olmadan 0,005$+ seviyesine fırlarsa, hemen araştırın.

Manuel Oyun Sunucu Altyapı Yönetimi Runbook'u

Oyun sunucu altyapısını çıplak bulut hizmetlerinde yönetiyorsanız, işte "lansmanı atlattık" ile "ölüm raporu yazıyoruz" arasındaki farkı belirleyen operasyonel sıra.

Aşama 1: Lansman Öncesi Kapasite Planlaması (Lansmandan 48-72 Saat Önce)

Son 7-14 gündeki en yüksek eşzamanlı oyuncu verilerinizi çekin. Ortalamaları kullanmayın — zirvelere ihtiyacınız var, bölgelere göre ayrıştırılmış:

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):
    """Bir bölge için CloudWatch'tan en yüksek eşzamanlı oyuncu sayısını çeker."""
    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,  # Saatlik detay
        Statistics=['Maximum']
    )
    
    if not response['Datapoints']:
        return 0
    
    return max(point['Maximum'] for point in response['Datapoints'])

# Kapasite planı oluştur
PLAYERS_PER_INSTANCE = 50  # Oyununuzun oyuncu yoğunluğuna göre ayarlayın
LAUNCH_BUFFER_MULTIPLIER = 2.0  # İçerik lansmanları için 2x yedek

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}")

Bu aşamadaki kilit kararlar:

• Tampon çarpanı: Küçük bir yama için 1.5x, büyük bir içerik düşüşü için 2.0x, free-to-play lansman etkinliği için 3.0x. Seçtiğiniz çarpan, hem maliyeti hem de riski doğrudan etkiler.
• Örnek başına oyuncu: Bunu yük testinizden ölçün, mimari dokümanlarınızdan değil. 50 oyuncu için tasarlanmış bir sunucu, harita karmaşıklığınızla 60Hz tik hızında yalnızca 35 oyuncuyu kaldırabilir.
• Bölge dağılımı: Son 30 gündeki gerçek oyuncu dağılımınızı çekin. 40/30/20/10 bölünmesi varsaymayın — oyununuz topluluğunuzun bulunduğu yere bağlı olarak %60 APAC olabilir.

Aşama 2: Ölçeklendirme Politikalarını Yapılandırma (Lansmandan 24 Saat Önce)

Genel CPU tabanlı otomatik ölçeklendirme, oyun iş yüklerini anlamaz. %70 CPU'daki bir GameLift filosu tamamen sağlıklı olabilirken, %40 CPU'daki bir filonun tüm oturumları dolu ve oyuncular sırada bekliyor olabilir.

Ölçeklendirme politikalarınızı oyunla ilgili metrikler etrafında yapılandırın:

{
  "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
  }
}

Önemli olan az bilinen ayarlar:

• Scale-out cooldown: 60 saniye. Oyuncular beklemeyecek. Cooldown'unuz 300 saniyeyse (çoğu eğitimde varsayılan), oyunculara kapasite enjeksiyonları arasında 5 dakika beklemelerini söylüyorsunuz.
• Scale-in cooldown: 600 saniye (10 dakika). Dalgalı bir lansman etkinliği sırasında agresif ölçek içe, salınıma neden olur — filonuz küçülür, talep tekrar artar ve yeniden sağlama yaparsınız, hem zaman hem de para yakar. 10 dakikalık bir cooldown, doğal durgunlukları erken ölçek küçültme olmadan emer.
• Hedef değer 25 (oturum): Bu, filo başına 25 kullanılabilir oyun oturumunu yedekte tutar. Metrik 25'in altına düştüğünde yeni örnekler başlatılır. Bu sayı, filonuz için normal oyuncu geliş hızının kabaca 2-3 dakikasını temsil etmelidir.

Aşama 3: Lansman İzleme (Lansmandan Sonra 0-6 Saat)

Çoğu operasyon ekibinin tüm gününü kaybettiği yer burasıdır. Panoları manuel olarak yenileyerek oturmayın. Bunun yerine izleme döngünüzü betikleyin:

#!/bin/bash
# launch-monitor.sh — Lansman penceresi sırasında her 60 saniyede bir çalıştırın
# Gerekenler: 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]}"
  
  # Mevcut metrikleri al
  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')
  
  # Kullanım yüzdesini hesapla
  if [ "$MAX_SESSIONS" -gt 0 ]; then
    UTILIZATION=$(( (ACTIVE_SESSIONS * 100) / (ACTIVE_SESSIONS + AVAILABLE) ))
  else
    UTILIZATION=0
  fi
  
  # Kullanım %80'i aşarsa uyarı
  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

Bunu lansman pencereniz sırasında bir terminalde çalıştırın. Uygun alarm sisteminin yerini almaz, ancak nöbetçi mühendisinize üç tarayıcı sekmesi yerine tek bir cam sunar.

Aşama 4: Lansman Sonrası Temizlik (Lansmandan 24-48 Saat Sonra)

Artıştan sonra, otomatik ölçeklendirmenin gerçekten ölçek içe yaptığını doğrulayın. Yetim örnekler, lansman sonrası maliyet sürprizlerinin 1 numaralı kaynağıdır:

# Tüm bölgelerde hala çalışan oyun sunucu örneklerini bul
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 aktif oturumu ve 5'ten fazla boşta örneği olan herhangi bir filo derhal incelenmelidir. Ya ölçek içe politikası tetiklenmedi ya da filonun minimum kapasitesi etkinlik sonrası talep için çok yüksek ayarlandı.

Manuel Yönetimin Tavan Yaptığı Yer

Yukarıdaki runbook, 2-3 bölgeli tek bir oyun için işe yarar. Şu durumlarda çökmeye başlar:

Farklı arka uçlara sahip birden çok oyun. GameLift oyununuzun bir dizi panosu, Kubernetes tabanlı oyununuzun başka bir panosu vardır. Operasyon mühendisiniz artık her ikisinde de akıcı olmalı ve temelde farklı altyapılar arasında performans verilerini ilişkilendirebilmelidir. Bunun yarattığı bilgi siloları gerçektir — Kubernetes uzmanınız müsait olmadığında, GameLift ekibi bir EKS ölçeklendirme sorununa yardımcı olamaz ve bunun tersi de geçerlidir.

Standart dışı etkinlikler için talep tahmini. Sürpriz bir Twitch yayıncısı onayı, bir rakibin lansman gecikmesi veya beklenmedik bir viral an, hiçbir geçmiş verinin tahmin edemediği talep artışları yaratabilir. Yalnızca önceden sağlanmış tamponlara değil, gerçek zamanlı duyarlı ölçeklendirmeye ihtiyacınız var.

Spot, on-demand ve ayrılmış örnekler arasında maliyet ve gecikmeyi dengeleme. En uygun karışım, spot fiyatlandırma ve talep modellerine bağlı olarak saatlik olarak değişir. Çoğu ekip her şeyi on-demand çalıştırarak işi basitleştirir, bu güvenlidir ancak optimize edilmiş bir karma filo stratejisinden 3-4 kat daha pahalıdır.

AWS'nin, GameLift filolarını ve EKS kümelerini doğal dil sorguları aracılığıyla yöneten ajan AI iş akışları için rehberlik oluşturmasına yol açan tam da bu karmaşıklıktır — oyun sunucu altyapı yönetiminin operasyonel yükünün geleneksel panoları ve CLI betiklerini aştığının bir kabulü.

Kendi Kendini İyileştiren Altyapı için Mimari Desenler

Giderek karmaşıklaşan manuel süreçler oluşturmak yerine, ölçeklendirme olayları sırasında insan müdahalesini azaltan bu desenlere odaklanın.

Tahmine Dayalı Kapasite Zamanlaması

Planlı etkinlikler (içerik düşüşleri, sezonluk lansmanlar, hafta sonu etkinlikleri) için, talep gelmeden önce kapasite artışlarını zamanlayın:

import boto3
from datetime import datetime, timedelta

def schedule_capacity_ramp(fleet_id, target_instances, ramp_start_utc, region='us-east-1'):
    """
    Fleto kapasitesini ramp_start_utc'den itibaren kademeli olarak artırır.
    Mevcut kapasiteden hedefe 30 dakika içinde ölçeklenir.
    """
    gamelift = boto3.client('gamelift', region_name=region)
    
    # Mevcut kapasiteyi al
    fleet_attrs = gamelift.describe_fleet_attributes(FleetIds=[fleet_id])
    current = fleet_attrs['FleetAttributes'][0]
    min_cap = current['MinSize']
    
    # Ramp hesapla: 30 dakika boyunca 10 dakikalık aralıklarla 3 adım
    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

# Kullanım
steps = schedule_capacity_ramp(
    fleet_id='fleet-abc123',
    target_instances=120,
    ramp_start_utc='2025-01-15T17:00:00Z'  # Lansmandan 30 dk önce
)
# CloudWatch Events / Step Functions / cron ile çalıştırın
for step in steps:
    print(f"T+{step['minute']}min: set desired capacity to {step['capacity']}")

Ramp yaklaşımı önemlidir çünkü aynı anda 120 örneği başlatmak, EBS anlık görüntü çekişmesi yaratır ve filonuzun eşzamanlı örnek limitini aşabilir. Üç parti halinde ~40 örneğe yaymak, sağlama darboğazlarını önler.

Otomatik Düzeltme Kuralları

İzleme mühendisiniz kahvesini bitirmeden tetiklenecek kendi kendini iyileştirme kuralları tanımlayın:

# 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  # Filo kapasitesini %30 artır
      cooldown_seconds: 120  # Sonraki ölçek eyleminden önce 2 dk bekle
    notification: "ops-alerts-sns-topic"
    
  - name: "idle-instance-cleanup"
    condition:
      metric: "ActiveServerSessionCount"
      operator: "equals"
      threshold: 0
      duration_seconds: 1200  # Sıfır oturumla 20 dakika
    action: "scale_in"
    parameters:
      scale_percent: 50  # Boşta örneklerin yarısını kaldır
      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  # Agresif %75 kapasite artışı
      cooldown_seconds: 60
    notification: "incidents-sns-topic"  # PagerDuty entegreli
    priority: "critical"

Kaynak yetersizliği kuralı acil durum vananızdır. Kullanılabilir oturumlar 10'un altına düştüğünde ve tam bir dakika boyunca orada kaldığında, oyuncuya yönelik sıralardan saniyeler uzaktasınız. %75'lik ölçek dışı, kasıtlı olarak agresiftir — 20 dakika boyunca aşırı sağlama yapmak, oyuncuları bekleme sürelerine kaybetmekten daha ucuzdur.

Karma Örnek Filo Stratejisi

Talep artışları için spot örneklerle birlikte on-demand taban kapasitesini birleştirmek, en yüksek etkili maliyet optimizasyonudur, ancak spot kesintilerini zarif bir şekilde ele almayı gerektirir. İşte desen:

def calculate_fleet_composition(total_needed, baseline_percent=40):
    """
    Filoyu on-demand taban + spot artış olarak böl.
    On-demand garantili kapasiteyi karşılar; spot artışı yönetir.
    """
    on_demand = int(total_needed * (baseline_percent / 100))
    spot = total_needed - on_demand
    
    # Spot kesinti oranını hesaba kat (~%5-15, örnek tipi/bölgeye bağlı)
    # Etkin kapasiteyi korumak için spot'u kesinti oranı kadar aşırı sağlama
    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,  # Kesintilerden sonra
        'cost_savings_estimate': f"{(spot * 0.7) / total_needed * 100:.0f}% vs all on-demand"
    }

# Örnek: Bir içerik lansmanı için 100 sunucu gerekiyor
composition = calculate_fleet_composition(100, baseline_percent=40)
# Döndürür:
# on_demand: 40 örnek (3,40$/saat, 0,085$/örnek)
# spot: 69 örnek (1,77$/saat, 0,026$/örnek)  
# effective_capacity: 100 sunucu
# cost_savings_estimate: "42%" vs all on-demand (8,50$/saat)

40/60 bölünmesi bir başlangıç noktasıdır. Her bölgedeki spot kesinti geçmişinize göre ayarlayın. Uzun oturum süreli (45+ dakika) oyunlar, daha yüksek bir on-demand oranı gerektirebilir çünkü bir oturum ortasında spot kesintisi, 10 dakikalık bir maça göre çok daha yıkıcıdır.

Kendiniz Yapmak vs. Satın Almak: horizOn Nerede Duruyor

Yukarıda açıklanan her şey — izleme betikleri, ölçeklendirme politikaları, düzeltme kuralları, karma örnek filo yönetimi, lansman sonrası temizlik — gerçek, inşa edilebilir altyapıdır. Ekipler bunu yayınlar. Üretim kalitesinde bir ölçeklendirme sistemi oluşturmak genellikle 4-6 haftalık özel mühendislik çalışması gerektirir, ardından bulut API'leri geliştikçe ve oyununuzun trafik modelleri değiştikçe sürekli bakım yapılır.

Bu, oyun özellikleri, netcode veya içerik için harcanmayan mühendislik zamanıdır.

horizOn, oyun sunucu altyapı yönetimine oyun başına bir mühendislik projesi olarak değil, çözülmüş bir platform sorunu olarak yaklaşır. Ölçeklendirme, bölgesel dağıtım, maliyet optimizasyonu ve sunucu yaşam döngüsü yönetimi önceden oluşturulmuş olarak gelir. Operasyonel yük, "her lansman etkinliğinde 2-3 mühendis" seviyesinden "ölçeklendirme parametrelerinizi bir kez yapılandırın ve etkinlik sırasında doğrulayın" seviyesine düşer.

Takas, her yönetilen hizmetin sunduğuyla aynıdır: daha az ayrıntılı kontrol karşılığında önemli ölçüde daha az operasyonel yük. Operasyon ekibinin aynı zamanda oyun geliştirme ekibi olduğu stüdyolar için — ki bu çoğu bağımsız ve orta ölçekli stüdyodur — bu takas genellikle platform lehine olur.

Maliyet Dökümü: Altyapı Yönetiminin Gerçek Maliyeti

Üç yaklaşım için 4 bölgede 10.000 en yüksek eşzamanlı oyuncuya hizmet veren bir oyun için sayıları koyalım:

Tamamen Manuel AWS (GameLift + EKS)

• Bilgi işlem (200 örnek, tamamı on-demand): 408$/gün
• Muhafazakar ölçeklendirmeden kaynaklanan aşırı sağlama: +122$/gün (%30 israf)
• Özel operasyon mühendisi (0,5 TZ): 400-600$/gün
• Lansmanlar sırasında olay müdahale fazla mesaisi: 200-400$/olay
• Aylık tahmin: 16.000-24.000$

Otomatik AWS (özel ölçeklendirme + karma örnekler)

• Bilgi işlem (200 örnek, 40/60 on-demand/spot): 245$/gün
• Optimize edilmiş ölçeklendirme aşırı sağlamayı %10'a düşürür: +25$/gün
• Operasyon mühendisi süresi (0,2 TZ bakım): 160-240$/gün
• Aylık tahmin: 13.000-15.500$

Yönetilen Platform (horizOn)

• Altyapı platform hizmeti olarak ele alınır: kullanıma göre ölçeklenir
• Altyapı için operasyon mühendisliği yükü: sıfır
• Maliyet plana göre değişir, ancak sabit operasyon yükünü tamamen ortadan kaldırır

Manuel ve otomatik AWS arasındaki fark ~3.000-8.500$/ay'dır. Otomatik AWS ile yönetilen bir platform arasındaki fark ayrıca fırsat maliyetini de içerir — bu mühendislerin altyapıyı sürdürmek yerine göndereceği şeyler.

En İyi Uygulamalar: Oyun Sunucu Ölçeklendirme için Beş Kural

1. Filo genelindeki ortalamaları değil, bölge başına en yüksek eşzamanlı oyuncuyu takip edin. Küresel olarak ortalama 5.000 CCU'ya sahip bir oyunun, zirvede ABD-Doğu'da 3.200'ü olabilir. Filo genelindeki sayılar, en kötü oyuncuya yönelik sorunlara neden olan bölgesel sıcak noktaları gizler. Kapasite planlama taban çizginiz olarak en az 14 günlük bölge bazında en yüksek veriyi saklayın.

2. Scale-out cooldown'larını maksimum 60 saniyeye ayarlayın. Standart bulut otomatik ölçeklendirme cooldown'ları 300-600 saniye, web iş yükleri için tasarlanmıştır, oyuncuların sıraları 90 saniyeden kısa sürede terk ettiği oyun sunucuları için değil. 60 saniyelik bir cooldown, bir artış sırasında her dakika yeni kapasite enjekte ettiğiniz anlamına gelir — sıra sürelerini yönetilebilir tutmak için yeterince hızlı.

3. Ölçek içe işlemini daha uzun bir cooldown (10 dakika) ile otomatikleştirin. Ölçek içe, çoğu ekibin ya çok agresif (kısa durgunluklarda örnekleri erken öldürme) ya da çok muhafazakar (asla ölçek küçültmeme, para yakma) olduğu yerdir. 10 dakikalık bir ölçek içe cooldown, doğal talep dalgalanmalarını emer, boşta sunucuları saatlerce çalışır durumda tutmaz.

4. Planlı etkinliklerden 30-60 dakika önce ön sağlama yapın. Otomatik ölçeklendirme doğası gereği tepkiseldir. Bildiğiniz etkinlikler için — içerik düşüşleri, sezonluk etkinlikler, pazarlama hamleleri — kapasite artışlarını önceden zamanlayın. 30 dakika boyunca üç kademeli parti, aynı anda 100+ örneği başlatmanın sağlama darboğazını önler.

5. Ham bilgi işlem harcamasını değil, oyuncu-saat başına maliyeti ölçün. 15.000 en yüksek oyuncuya hizmet veren 500$/günlük bir fatura (0,0014$/oyuncu-saat) sağlıklıdır. 500 en yüksek oyuncuya hizmet veren 200$/günlük bir fatura (0,0167$/oyuncu-saat) 12 kat daha az verimlidir. Bu metrik, maliyet optimizasyonu tartışmalarını finans ve mühendislik arasında düşmanca değil, üretken kılan tek metrikdir.

Bir Sonraki Lansman Günü Felaketini Önlemek

İlk lansman günü ölçeklendirme hatası genellikle belirli etkinliğe atfedilir: "bu kadar oyuncu beklemiyorduk" veya "otomatik ölçeklendirme politikasında bir hata vardı." İkinci hata sürece atfedilir: "yeterli izlememiz yoktu." Üçüncü hatada ekip, asıl sorunun mimarinin kendisi olduğunu fark eder.

Oyun sunucu altyapı yönetimi, desteklediğiniz oyun, bölge ve barındırma platformu sayısıyla doğrusal olmayan bir şekilde karmaşıklaşır. Her yeni oyun, izlenecek yeni bir filo, potansiyel olarak yeni bir dizi ölçeklendirme politikası ve lansman etkinlikleri sırasında operasyon ekibinin kontrol etmesi için başka bir pano ekler.

Düzeltme, daha iyi betikler veya daha fazla pano değil — ekibinizin yönetmesi gereken yüzey alanını azaltmaktır. Daha az altyapı platformunda birleşin. Tepkisel ölçeklendirmeyi otomatikleştirin. Tahmin edilebilir etkinlikler için ön sağlama yapın. Ve maliyeti, yalnızca bulut faturanıza karşı değil, oyuncu değerine göre ölçün.

Mevcut altyapı yönetimi iş akışınız, bir içerik lansmanı sırasında panolara bakan birden fazla kişi gerektiriyorsa, bu, mimarinin değişmesi gerektiğine dair bir işarettir — daha büyük bir operasyon ekibine ihtiyacınız olduğuna değil.

Altyapı yönetim sistemleri kurmayı bırakıp oyun göndermeye hazır mısınız? horizOn ile ücretsiz deneyin veya yönetilen oyun arka uçlarının pratikte nasıl çalıştığını görmek için API dokümantasyonunu keşfedin.

---

Kaynak: Agentic AI Oyun Altyapı Yönetimini Nasıl Dönüştürüyor