Zarządzanie infrastrukturą serwerów gier: Runbook skalowania dla uruchomień zawartości z zerowym przestojem
W skrócie
Dowiedz się, jak zarządzać infrastrukturą serwerów gier, uniknąć przestojów i optymalizować koszty dzięki runbookowi skalowania i automatyzacji.
Twoja premiera zawartości za 47 minut. Kierownik operacyjny jednocześnie wpatruje się w dashboard CloudWatch, dwa monitory flot GameLift, widok stanu klastra Kubernetes oraz kanał Slack, w którym gracze już narzekają na czasy oczekiwania. Pomiędzy resetowaniem limitów skalowania a ręcznym równoważeniem wydajności między US-East a EU-West, spędzą 60% swojego tygodnia pracy na jednym wydarzeniu.
To nie jest hipotetyczna sytuacja. Zespół operacyjny jednego studia udokumentował dokładnie ten wzorzec – przełączanie kontekstu między interfejsami AWS Console podczas wydarzeń premierowych. Podczas jednej dużej aktualizacji treści ręczne decyzje o skalowaniu doprowadziły do skoku czasu oczekiwania w kolejce o 2 godziny, co spowodowało 12% odpływ graczy. Ci gracze nie zgłaszali zgłoszeń do supportu. Po prostu odeszli.
Zarządzanie infrastrukturą serwerów gier to jeden z tych problemów, które na tablicy wyglądają prosto („po prostu auto-scale, brachu”), a stają się koszmarem przy 10 000 jednoczesnych graczy w czterech regionach. Ten runbook opisuje, co faktycznie się psuje, jak to wychwycić, zanim Twój Discord zapłonie, oraz jak zbudować systemy, które przetrwają następną premierę bez ogólnej paniki.
Trzy tryby awarii, które zabijają dni premierowe
Każda katastrofa skalowania serwerów gier wpada do jednej z tych kategorii. Zrozumienie, z którą masz do czynienia, determinuje twoją odpowiedź.
1. Wyczerpanie przepustowości
Co się dzieje: Liczba graczy przekracza wstępnie przygotowaną przepustowość floty. Nowe instancje potrzebują 3–7 minut na uruchomienie i rejestrację w usłudze matchmaking. W tym czasie czasy oczekiwania w kolejce rosną z 5 sekund do 4+ minut. Średni czas oczekiwania na sesję przekracza próg 90 sekund, który według badań konsekwentnie powoduje, że gracze całkowicie rezygnują z kolejki.
Dlaczego to trudne: Auto-skalowanie reaguje na metryki, które pozostają w tyle za rzeczywistym popytem. Zanim wskaźnik wykorzystania osiągnie 85% i uruchomi skalowanie w górę, już jesteś spóźniony. Okno 5-minutowego przygotowania oznacza, że obsługujesz graczy na wczorajszej przepustowości podczas dzisiejszego skoku.
Kaskadowe szkody: Gracze, którzy nie mogą dołączyć w ciągu 60 sekund, odchodzą. Gracze, którzy odchodzą podczas okna premierowego, rzadko wracają tego samego dnia. Niektórzy nigdy nie wracają. Ta liczba 12% odpływu nie jest jednorazowym ciosem w przychody – kumuluje się przez utracone poczucie pychy, niższe oceny recenzji i zmniejszony organiczny wzrost.
2. Brak równowagi regionalnej
Co się dzieje: Twoja zawartość jest publikowana w stałym czasie globalnie. Gracze z UE wchodzą na serwery 4–6 godzin przed obudzeniem się graczy z USA. Twoja flota UE nasyca się, podczas gdy serwery w USA pozostają bezczynne. Zanim gracze z USA dotrą, flota UE uruchomiła gorączkowe operacje skalowania, a Twój zespół ręcznie przekierowuje wydajność.
Dlaczego to trudne: Auto-skalowanie w chmurze działa domyślnie per region. Nie ma pojęcia o „UE jest na 95%, USA na 35%, redystrybuuj”. Kończysz z jednym regionem wydającym nadmierne środki na instancje, podczas gdy gracze w innym regionie doświadczają opóźnień z powodu przeciążonych serwerów.
3. Ucieczka kosztów
Co się dzieje: Agresywnie przygotowujesz się na skok, ale polityki skalowania w dół są konserwatywne (wszyscy boją się zbyt wczesnego skalowania w dół). Dwa dni po wydarzeniu odkrywasz, że 180 instancji wciąż działa, każda kosztując 0,50 USD/h – to 2160 USD/dzień za bezczynne obliczenia.
Więcej kontekstu na temat kosztów bezczynnych serwerów i wzorców architektonicznych, aby sobie z nimi radzić, znajdziesz w naszej analizie propozycji hibernacji serwerów Fortnite, która omawia ekonomię proaktywnego zarządzania przepustowością.
Wykrywanie: Wyłapywanie problemów, zanim zrobią to Twoi gracze
Warstwa wykrywania w runbooku musi odpowiedzieć na jedno pytanie: czy będziemy mieć problem widoczny dla graczy?
Metryki, które faktycznie mają znaczenie
Większość dashboardów monitorujących serwery gier jest zaśmiecona wykresami wykorzystania CPU i przepustowości sieci. Oto, co faktycznie przewiduje awarię skalowania:
Głębokość kolejki na region (próg alertu: 50+ oczekujących graczy)
To jest Twój wiodący wskaźnik. Gdy kolejka zaczyna się zapełniać, masz około 60 sekund, zanim gracze zaczną rezygnować. Skonfiguruj alarmy CloudWatch na AverageWaitTime na flotę:
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
Krytyczny detal: użyj okresu 30 sekund z 2 okresami oceny. Oznacza to 60 sekund ciągłego narastania kolejki przed alertem. Cokolwiek dłuższego, a reagujesz na problem, który ma już 3 minuty.
Wskaźnik dostępnych sesji gry (próg alertu: poniżej 20% bufora)
Gdy dostępne sesje spadną poniżej 20% całkowitej przepustowości, jesteś o jeden skok od kolejek. Ta metryka jest bardziej przydatna niż surowe wykorzystanie CPU, ponieważ uwzględnia zarówno wydajność obliczeniową, jak i logikę przypisywania sesji.
Czas gotowości instancji (próg alertu: powyżej 4 minut)
Jeśli nowe instancje potrzebują więcej niż 4 minuty, aby stać się gotowe, coś jest nie tak z Twoim AMI, skryptami userdata lub procesem uruchamiania serwera gry. Śledź to na flotę i region. Wolna gotowość instancji potęguje każdy inny problem ze skalowaniem.
Koszt na graczogodzinę (śledź dziennie, alert przy 2x wartości bazowej)
To łączy wydatki na infrastrukturę z rzeczywistą aktywnością graczy. Jeśli Twój koszt na graczogodzinę się podwoił, ale liczba jednoczesnych graczy nie wzrosła, jesteś nadmiernie przygotowany. Oblicz to jako:
def cost_per_player_hour(total_compute_cost_hours, total_player_hours):
"""
total_compute_cost_hours: suma (instance_cost_per_hour * hours_running) dla wszystkich instancji
total_player_hours: suma (average_concurrent_players * hours_of_operation) dla wszystkich regionów
"""
if total_player_hours == 0:
return 0
return total_compute_cost_hours / total_player_hours
# Przykład: 200 instancji po 0,085 USD/h przez 24 godziny = 408 USD
# 8 000 średnich jednoczesnych graczy * 24 godziny = 192 000 graczogodzin
# Koszt na graczogodzinę: 408 USD / 192 000 = 0,002 USD
# Jeśli ta liczba wzrośnie do 0,005 USD+ bez wzrostu liczby graczy, sprawdź natychmiast.
Ręczny runbook zarządzania infrastrukturą serwerów gier
Jeśli zarządzasz infrastrukturą serwerów gier na surowych usługach chmurowych, oto sekwencja operacyjna, która oddziela „przetrwaliśmy premierę” od „piszemy postmortem”.
Faza 1: Planowanie przepustowości przed premierą (48–72 godziny przed)
Pobierz dane szczytowej liczby jednoczesnych graczy z ostatnich 7–14 dni. Nie używaj średnich – potrzebujesz szczytów, podzielonych na regiony:
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):
"""Pobierz szczytową liczbę jednoczesnych graczy z CloudWatch dla regionu."""
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, # Ziarnistość godzinowa
Statistics=['Maximum']
)
if not response['Datapoints']:
return 0
return max(point['Maximum'] for point in response['Datapoints'])
# Zbuduj plan przepustowości
PLAYERS_PER_INSTANCE = 50 # Dostosuj do gęstości graczy w Twojej grze
LAUNCH_BUFFER_MULTIPLIER = 2.0 # 2x zapas na premiery zawartości
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}")
Kluczowe decyzje na tym etapie:
- Mnożnik bufora: 1,5x dla drobnej łatki, 2,0x dla dużej aktualizacji treści, 3,0x dla wydarzenia startowego free-to-play. Wybrany mnożnik bezpośrednio wpływa zarówno na koszty, jak i ryzyko.
- Gracze na instancję: Zmierz to z testów obciążeniowych, nie z dokumentacji architektury. Serwer zaprojektowany na 50 graczy może wytrzymać tylko 35 przy częstotliwości 60 Hz i złożoności mapy.
- Dystrybucja regionalna: Pobierz rzeczywisty rozkład graczy z ostatnich 30 dni. Nie zakładaj podziału 40/30/20/10 – Twoja gra może być w 60% APAC, w zależności od tego, gdzie mieszka społeczność.
Faza 2: Konfiguracja polityk skalowania (24 godziny przed)
Ogólne auto-skalowanie oparte na CPU nie rozumie obciążeń gier. Flota GameLift przy 70% CPU może być całkowicie zdrowa, podczas gdy inna przy 40% CPU może mieć wszystkie sesje pełne i graczy w kolejce.
Skonfiguruj swoje polityki skalowania wokół metryk istotnych dla gry:
{
"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
}
}
**
**Nietrywialne ustawienia, które mają znaczenie:**
- **Cooldown skalowania w górę: 60 sekund.** Gracze nie będą czekać. Jeśli Twój cooldown wynosi 300 sekund (domyślnie w wielu tutorialach), mówisz graczom, aby czekali 5 minut między wstrzyknięciami przepustowości.
- **Cooldown skalowania w dół: 600 sekund (10 minut).** Agresywne skalowanie w dół podczas zmiennego wydarzenia premierowego powoduje oscylację – flota skaluje się w dół, popyt rośnie, a Ty znowu przygotowujesz, spalając zarówno czas, jak i pieniądze. 10-minutowy cooldown absorbuje naturalne spadki bez przedwczesnego skalowania w dół.
- **Wartość docelowa na 25 (sesje):** Pozostawia 25 dostępnych sesji gry w rezerwie na flotę. Gdy metryka spadnie poniżej 25, uruchamiane są nowe instancje. Liczba powinna odpowiadać mniej więcej 2–3 minutom normalnego tempa przybywania graczy dla Twojej floty.
### Faza 3: Monitorowanie premiery (0–6 godzin po premierze)
To tutaj większość zespołów operacyjnych traci cały dzień. **Nie siedź i nie odświeżaj dashboardów ręcznie.** Zamiast tego zautomatyzuj pętlę monitorowania:
```bash
#!/bin/bash
# launch-monitor.sh — Uruchamiaj co 60 sekund podczas okna premierowego
# Wymaga: 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]}"
# Pobierz bieżące metryki
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')
# Oblicz procent wykorzystania
if [ "$MAX_SESSIONS" -gt 0 ]; then
UTILIZATION=$(( (ACTIVE_SESSIONS * 100) / (ACTIVE_SESSIONS + AVAILABLE) ))
else
UTILIZATION=0
fi
# Alert, jeśli wykorzystanie przekracza 80%
if [ "$UTILIZATION" -gt 80 ]; then
curl -s -X POST "$ALERT_WEBHOOK" \
-H 'Content-Type: application/json' \
-d "{\"text\": \"⚠️ OSTRZEŻENIE: Flota $FLEET ($REGION) na ${UTILIZATION}% wykorzystania. Dostępne sesje: $AVAILABLE\"}"
fi
echo "[$(date)] $REGION: ${UTILIZATION}% wykorzystania, $AVAILABLE dostępnych sesji"
done
Uruchom to w terminalu podczas okna premierowego. Nie zastąpi to właściwego alertowania, ale daje inżynierowi dyżurnemu jeden panel zamiast trzech kart przeglądarki.
Faza 4: Czyszczenie po premierze (24–48 godzin po)
Po szczycie sprawdź, czy auto-skalowanie faktycznie skalowało w dół. Porzucone instancje to główne źródło niespodzianek kosztowych po premierze:
# Znajdź wszystkie instancje serwerów gier wciąż działające w regionach
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
Każda flota z 0 aktywnymi sesjami i więcej niż 5 bezczynnymi instancjami powinna zostać natychmiast sprawdzona. Albo polityka skalowania w dół nie zadziałała, albo minimalna przepustowość floty jest ustawiona zbyt wysoko dla popytu po wydarzeniu.
Gdzie ręczne zarządzanie napotyka sufit
Powyższy runbook działa dla pojedynczej gry z 2–3 regionami. Zaczyna się sypać, gdy:
Wiele tytułów z różnymi backendami. Twoja gra na GameLift ma jeden zestaw dashboardów, a Twoja gra oparta na Kubernetes – inny. Twój inżynier operacyjny musi teraz biegle posługiwać się oboma, a także umieć korelować dane wydajnościowe z fundamentalnie różnej infrastruktury. Silosy wiedzy, które to tworzy, są realne – gdy Twój specjalista od Kubernetes jest niedostępny, zespół GameLift nie może pomóc w problemie ze skalowaniem EKS i odwrotnie.
Przewidywanie popytu na niestandardowe wydarzenia. Nagły tweet streamera Twitcha, opóźnienie premiery konkurenta lub nieoczekiwany wiral mogą stworzyć skoki popytu, których żadne historyczne dane nie przewidziały. Potrzebujesz skalowania w czasie rzeczywistym, a nie tylko wstępnie przygotowanych buforów.
Równoważenie kosztów i opóźnień między instancjami spot, on-demand i reserved. Optymalna mieszanka zmienia się co godzinę w zależności od cen spot i wzorców popytu. Większość zespołów upraszcza, uruchamiając wszystko na on-demand, co jest bezpieczne, ale kosztuje 3–4x więcej niż zoptymalizowana strategia mieszanej floty.
To jest właśnie ta złożoność, która skłoniła AWS do stworzenia wytycznych dla agentowych przepływów AI, które zarządzają flotami GameLift i klastrami EKS za pomocą zapytań w języku naturalnym – uznanie, że operacyjne obciążenie związane z zarządzaniem infrastrukturą serwerów gier przerosło tradycyjne dashboardy i skrypty CLI.
Wzorce architektoniczne dla samonaprawiającej się infrastruktury
Zamiast budować coraz bardziej złożone procesy ręczne, skup się na tych wzorcach, które zmniejszają interwencję człowieka podczas zdarzeń skalowania.
Predykcyjne planowanie przepustowości
Dla planowanych wydarzeń (aktualizacje treści, sezonowe premiery, weekendowe wydarzenia) zaplanuj zwiększenie przepustowości przed nadejściem popytu:
import boto3
from datetime import datetime, timedelta
def schedule_capacity_ramp(fleet_id, target_instances, ramp_start_utc, region='us-east-1'):
"""
Stopniowo zwiększaj przepustowość floty, zaczynając od ramp_start_utc.
Skaluj od bieżącej przepustowości do docelowej w ciągu 30 minut.
"""
gamelift = boto3.client('gamelift', region_name=region)
# Pobierz bieżącą przepustowość
fleet_attrs = gamelift.describe_fleet_attributes(FleetIds=[fleet_id])
current = fleet_attrs['FleetAttributes'][0]
min_cap = current['MinSize']
# Oblicz rampę: 3 kroki w ciągu 30 minut w odstępach 10-minutowych
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
# Użycie
steps = schedule_capacity_ramp(
fleet_id='fleet-abc123',
target_instances=120,
ramp_start_utc='2025-01-15T17:00:00Z' # 30 min przed premierą
)
# Wykonaj przez CloudWatch Events / Step Functions / cron
for step in steps:
print(f"T+{step['minute']}min: ustaw żądaną przepustowość na {step['capacity']}")
Podejście z rampą ma znaczenie, ponieważ uruchomienie 120 instancji jednocześnie powoduje rywalizację o snapshoty EBS i może przekroczyć limit jednoczesnych instancji floty. Rozłożenie na trzy partie po ~40 instancji zapobiega wąskim gardłom przy przygotowaniu.
Zautomatyzowane reguły naprawcze
Zdefiniuj samonaprawiające się reguły, które uruchamiają się, zanim inżynier monitoringu zdąży dopić kawę:
# 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 # Zwiększ przepustowość floty o 30%
cooldown_seconds: 120 # Odczekaj 2 min przed następnym skalowaniem
notification: "ops-alerts-sns-topic"
- name: "idle-instance-cleanup"
condition:
metric: "ActiveServerSessionCount"
operator: "equals"
threshold: 0
duration_seconds: 1200 # 20 minut z zerem sesji
action: "scale_in"
parameters:
scale_percent: 50 # Usuń połowę bezczynnych instancji
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 # Agresywny wzrost przepustowości o 75%
cooldown_seconds: 60
notification: "incidents-sns-topic" # Zintegrowane z PagerDuty
priority: "critical"
Reguła resource-starvation to Twój zawór awaryjny. Gdy dostępne sesje spadną poniżej 10 i utrzymają się tam przez pełną minutę, jesteś sekundy od kolejek widocznych dla graczy. 75% skalowanie w górę jest celowo agresywne – taniej jest nadmiernie przygotować na 20 minut niż stracić graczy z powodu czasu oczekiwania.
Strategia mieszanej floty instancji
Połączenie bazowej przepustowości on-demand z instancjami spot dla skoków to pojedyncza zmiana o największym wpływie na optymalizację kosztów, ale wymaga obsługi przerwań spot w elegancki sposób. Oto wzorzec:
def calculate_fleet_composition(total_needed, baseline_percent=40):
"""
Podziel flotę na bazę on-demand + skok spot.
On-demand pokrywa gwarantowaną przepustowość; spot obsługuje skok.
"""
on_demand = int(total_needed * (baseline_percent / 100))
spot = total_needed - on_demand
# Uwzględnij wskaźnik przerwań spot (~5-15% w zależności od typu instancji/regionu)
# Nadmiernie przygotuj spot o wskaźnik przerwań, aby utrzymać efektywną przepustowość
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, # Po przerwaniach
'cost_savings_estimate': f"{(spot * 0.7) / total_needed * 100:.0f}% vs all on-demand"
}
# Przykład: 100 serwerów potrzebnych na premierę
composition = calculate_fleet_composition(100, baseline_percent=40)
# Zwraca:
# on_demand: 40 instancji (3,40 USD/h przy 0,085 USD/instancję)
# spot: 69 instancji (1,77 USD/h przy 0,026 USD/instancję)
# effective_capacity: 100 serwerów
# cost_savings_estimate: "42%" vs all on-demand (8,50 USD/h)
Podział 40/60 to punkt wyjścia. Dostosuj go na podstawie historii przerwań spot w każdym regionie. Gry z długimi sesjami (45+ minut) mogą wymagać wyższego udziału on-demand, ponieważ przerwanie spot w trakcie sesji jest znacznie bardziej uciążliwe niż w 10-minutowym meczu.
Budować vs. kupować: gdzie pasuje horizOn
Wszystko opisane powyżej – skrypty monitorowania, polityki skalowania, reguły naprawcze, zarządzanie mieszaną flotą instancji, czyszczenie po premierze – to realna, możliwa do zbudowania infrastruktura. Zespoły to wdrażają. Zazwyczaj zajmuje to 4–6 tygodni dedykowanej pracy inżynieryjnej, aby zbudować system skalowania na poziomie produkcyjnym, a następnie bieżące utrzymanie w miarę ewolucji API chmury i zmian wzorców ruchu w grze.
To czas inżynieryjny, który nie jest przeznaczony na funkcje rozgrywki, netcode czy zawartość.
horizOn podchodzi do zarządzania infrastrukturą serwerów gier jako do rozwiązanego problemu platformowego, a nie projektu inżynieryjnego dla każdej gry. Skalowanie, dystrybucja regionalna, optymalizacja kosztów i zarządzanie cyklem życia serwerów są wbudowane. Obciążenie operacyjne spada z „2–3 inżynierów podczas każdego wydarzenia premierowego” do „skonfiguruj parametry skalowania raz i sprawdź podczas wydarzenia”.
Kompromis jest ten sam, co w przypadku każdej zarządzanej usługi: mniej szczegółowej kontroli w zamian za znacznie mniejsze obciążenie operacyjne. Dla studiów, w których zespół operacyjny to także zespół rozgrywki – co dotyczy większości niezależnych i średnich studiów – ten kompromis zwykle przemawia na korzyść platformy.
Podział kosztów: ile faktycznie kosztuje zarządzanie infrastrukturą
Przełóżmy liczby na trzy podejścia dla gry obsługującej 10 000 szczytowych jednoczesnych graczy w 4 regionach:
W pełni ręczne AWS (GameLift + EKS)
- Obliczenia (200 instancji, wszystkie on-demand): 408 USD/dzień
- Nadmierne przygotowanie z konserwatywnego skalowania: +122 USD/dzień (30% marnotrawstwa)
- Dedykowany inżynier operacyjny (0,5 etatu): 400–600 USD/dzień
- Nadgodziny reakcji na incydenty podczas premier: 200–400 USD/wydarzenie
- Szacunkowo miesięcznie: 16 000–24 000 USD
Zautomatyzowane AWS (niestandardowe skalowanie + mieszane instancje)
- Obliczenia (200 instancji, 40/60 on-demand/spot): 245 USD/dzień
- Zoptymalizowane skalowanie zmniejsza nadmierne przygotowanie do 10%: +25 USD/dzień
- Czas inżyniera operacyjnego (0,2 etatu utrzymanie): 160–240 USD/dzień
- Szacunkowo miesięcznie: 13 000–15 500 USD
Zarządzana platforma (horizOn)
- Infrastruktura obsługiwana jako usługa platformy: skaluje się z użyciem
- Narzut inżynieryjny na infrastrukturę: zero
- Koszt zależy od planu, ale eliminuje stały narzut operacyjny
Różnica między ręcznym a zautomatyzowanym AWS wynosi około 3 000–8 500 USD/miesiąc. Różnica między zautomatyzowanym AWS a zarządzaną platformą obejmuje również koszt alternatywny – to, co ci inżynierowie wdrażają zamiast utrzymywania infrastruktury.
Najlepsze praktyki: pięć zasad skalowania serwerów gier
Śledź szczytową liczbę jednoczesnych graczy na region, nie średnie dla całej floty. Gra ze średnią 5 000 CCU globalnie może mieć 3 200 w US-East w szczycie. Średnie dla całej floty maskują regionalne punkty zapalne, które powodują najgorsze problemy dla graczy. Przechowuj co najmniej 14 dni danych szczytowych na region jako punkt odniesienia do planowania przepustowości.
Ustaw cooldown skalowania w górę na maksymalnie 60 sekund. Standardowe cooldowny auto-skalowania w chmurze wynoszące 300–600 sekund są zaprojektowane dla obciążeń webowych, a nie dla serwerów gier, gdzie gracze rezygnują z kolejki w ciągu 90 sekund. 60-sekundowy cooldown oznacza, że wstrzykujesz nową przepustowość co minutę podczas skoku – wystarczająco szybko, aby utrzymać czasy oczekiwania w kolejce na akceptowalnym poziomie.
Zautomatyzuj skalowanie w dół z dłuższym cooldownem (10 minut). Skalowanie w dół to miejsce, w którym większość zespołów jest albo zbyt agresywna (przedwczesne zabijanie instancji podczas krótkich spadków), albo zbyt konserwatywna (nigdy nie skaluje w dół, marnując pieniądze). 10-minutowy cooldown skalowania w dół absorbuje naturalne fluktuacje popytu bez utrzymywania bezczynnych serwerów przez godziny.
Przygotuj przepustowość 30–60 minut przed planowanymi wydarzeniami. Auto-skalowanie jest z natury reaktywne. W przypadku wydarzeń, o których wiesz, że nadejdą – aktualizacje treści, wydarzenia sezonowe, kampanie marketingowe – zaplanuj zwiększenie przepustowości z wyprzedzeniem. Trzy przyrostowe partie w ciągu 30 minut unikają wąskiego gardła przygotowania przy uruchamianiu 100+ instancji jednocześnie.
Mierz koszt na graczogodzinę, a nie surowe wydatki na obliczenia. Rachunek 500 USD/dzień obsługujący 15 000 szczytowych graczy (0,0014 USD/graczogodzinę) jest zdrowy. Rachunek 200 USD/dzień obsługujący 500 szczytowych graczy (0,0167 USD/graczogodzinę) jest 12 razy mniej wydajny. Ta metryka jest jedyną, która sprawia, że dyskusje o optymalizacji kosztów są produktywne, a nie antagonistyczne między finansami a inżynierią.
Zapobieganie kolejnej katastrofie w dniu premiery
Pierwsza awaria skalowania w dniu premiery jest zwykle obwiniana za konkretne wydarzenie: „nie spodziewaliśmy się tak wielu graczy” lub „polityka auto-skalowania miała błąd”. Druga awaria jest obwiniana za proces: „nie mieliśmy wystarczającego monitoringu”. Przy trzeciej awarii zespół zdaje sobie sprawę, że sama architektura jest problemem.
Zarządzanie infrastrukturą serwerów gier skaluje się w złożoności nieliniowo wraz z liczbą gier, regionów i platform hostingowych, które obsługujesz. Każdy nowy tytuł dodaje nową flotę do monitorowania, potencjalnie nowy zestaw polityk skalowania i kolejny zestaw dashboardów dla zespołu operacyjnego do sprawdzania podczas wydarzeń premierowych.
Rozwiązaniem nie są lepsze skrypty ani więcej dashboardów – to zmniejszenie powierzchni, którą Twój zespół musi zarządzać. Skonsoliduj się na mniejszej liczbie platform infrastrukturalnych. Zautomatyzuj reaktywne skalowanie. Przygotuj przepustowość na przewidywalne wydarzenia. I mierz koszt w stosunku do wartości dla graczy, a nie tylko w stosunku do rachunku za chmurę.
Jeśli Twój obecny przepływ pracy związany z zarządzaniem infrastrukturą wymaga więcej niż jednej osoby wpatrującej się w dashboardy podczas premiery zawartości, to sygnał, że architektura musi się zmienić – a nie że potrzebujesz większego zespołu operacyjnego.
Gotowy, aby przestać budować systemy zarządzania infrastrukturą i zacząć wydawać gry? Wypróbuj horizOn za darmo lub zapoznaj się z dokumentacją API, aby zobaczyć, jak zarządzane backendy gier działają w praktyce.
Źródło: Jak Agentic AI zmienia zarządzanie infrastrukturą gier