Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# GAMEOPS03-BP04 Entwickeln Sie eine Einsatzstrategie, die die Auswirkungen auf die Spieler minimiert
Integrieren Sie eine Bereitstellungsstrategie für Ihre Spielsoftware und Infrastruktur, die die Anzahl der Ausfallzeiten minimiert, durch die Spieler von Ihrem Spiel ferngehalten werden. Bei bestimmten Arten von Updates müssen möglicherweise neue Updates für den Spielclient installiert werden, aber gestalte das Spiel so, dass Ausfallzeiten während der Bereitstellung minimiert oder vermieden werden.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Einer der wichtigsten Schritte, die Sie bei der Entwicklung einer Strategie zur Bereitstellung eines Spiels berücksichtigen sollten, ist die Festlegung, wie Ihre Spielinfrastruktur verwaltet wird. Verwalte deine Spieleinfrastruktur mithilfe eines Infrastructure as Code (IaC) -Tool wie [AWS CloudFormation](https://aws.amazon.com/cloudformation/) [ Terraform von ](https://www.terraform.io/) [ Hashicorp, um menschliche Fehler bei der Vorbereitung der Umgebung ](https://www.terraform.io/) zu vermeiden. Infrastrukturvorlagen können in automatisierten Pipelines bereitgestellt und getestet werden, wodurch eine einheitliche Konfiguration der verschiedenen Spielumgebungen gewährleistet wird.
Es gibt verschiedene Einsatzstrategien, die für ein Spiel verwendet werden können:
**Fortlaufende Substitution **
Das primäre Ziel einer fortlaufenden Auswechslung für den Einsatz besteht darin, die Veröffentlichung durchzuführen, ohne das Spiel zu beenden und ohne die Spieler zu beeinträchtigen. Es ist wichtig, dass das Upgrade oder die Änderungen, die durchgeführt werden sollen, abwärtskompatibel sind und parallel zu den Vorgängerversionen des Systems funktionieren.
Bei dieser Bereitstellung werden die Serverinstanzen schrittweise durch Instanzen ersetzt (ersetzt oder eingeführt), auf denen die aktualisierte Version ausgeführt wird. Diese fortlaufende Substitution kann auf verschiedene Arten durchgeführt werden. Um beispielsweise fortlaufende Updates für eine Flotte dedizierter Spieleserver zu implementieren, besteht ein typischer Ansatz darin, eine neue Auto Scaling-Gruppe von EC2-Instances zu erstellen, die die auf ihnen bereitgestellte neue Build-Version des Spielservers enthalten, und die Spieler dann schrittweise zu Spielsitzungen weiterzuleiten, die auf dieser neuen Serverflotte gehostet werden. Falls es ein entsprechendes Update für den Spielclient gibt, das als Voraussetzung für die Nutzung des neuen Spieleserver-Builds erforderlich ist, müssen Sie eine Überprüfung durchführen, um sicherzustellen, dass nur Spieler, die dieses neue Spielclient-Update installiert haben, zu diesen Spielsitzungen weitergeleitet werden.
Serverflotten (z. B. EC2 Auto Scaling-Gruppen), die die alte Build-Version des Spielservers enthalten, werden erst außer Betrieb genommen, nachdem ihnen die Sitzungen mit aktiven Spielern auf elegante Weise entzogen wurden. In der Regel werden individuelle Server-Metriken eingerichtet, die es den Spielbetriebsteams ermöglichen, diesen Prozess zu automatisieren. Um den Umfang der Infrastruktur und den Zeitaufwand für die Durchführung einer fortlaufenden Bereitstellung zu reduzieren, kann alternativ ein anderer Ansatz gewählt werden, bei dem bestehende Produktionsinstanzen außer Betrieb genommen, mit dem neuen Gameserver-Build aktualisiert und dann wieder in die Produktionsflotte aufgenommen werden. Dieser Ansatz reduziert den Umfang der benötigten Infrastruktur, erhöht aber auch das Risiko, da die Anzahl der verfügbaren Live-Spielserver für Spieler reduziert wird, da Server ausgetauscht werden.
Dieses Modell kann auch für fortlaufende Bereitstellungen auf Backend-Diensten wie Datenbanken, Caches und Anwendungsservern verwendet werden, die das Gameplay nicht hosten. Solange diese Dienste auf hochverfügbare Weise mit mehreren geclusterten Instanzen bereitgestellt werden, sollte die Komplexität der Bereitstellung dieser Dienste geringer sein als die Bereitstellung auf dedizierten Spieleservern.
**Blue/green Bereitstellung **
Das Hauptziel eines blue/green Einsatzes in einem Spiel besteht darin, Ausfallzeiten zu minimieren und gleichzeitig ein sicheres Rollback zum vorherigen Einsatz zu ermöglichen, falls Probleme festgestellt werden. Es eignet sich für Bereitstellungen, bei denen zwei Versionen des Spiel-Backends kompatibel sind und Spielern gleichzeitig zur Verfügung stehen.
In der blue/green Bereitstellungsstrategie werden zwei identische Umgebungen (blau und grün) eingerichtet. Die bestehende Spielversion ist blau gekennzeichnet, während die neue Spielversion, die das Einsatzziel ist, grün gekennzeichnet ist. Wenn die grüne Umgebung bereit für die Migration ist, können Sie Ihre Routing-Ebene so konfigurieren, dass der Datenverkehr in die grüne Umgebung umgeleitet wird, während die alte Umgebung (blau) verfügbar bleibt, falls ein Failback erforderlich ist. In diesem Szenario erfordern die Routing-Updates möglicherweise eine Aktualisierung des Matchmaking-Dienstes, um ihn so zu konfigurieren, dass er mit dem Senden von Spielsitzungen an die neue Flotte beginnt. Im Fall von Backend-Diensten für Spiele könnte dies die Aktualisierung der DNS-Einträge in Amazon Route 53 für Ihren Service sein oder die Gewichtung des Application Load Balancer-Gewichts [https://aws.amazon.com/blogs/aws/new-application-load-balancer-simplifies-deployment-with-weighted-target-groups/](https://aws.amazon.com/blogs/aws/new-application-load-balancer-simplifies-deployment-with-weighted-target-groups/) ändern, um Traffic an Ihre neue Zielgruppe zu senden.
Einer der Nachteile der blue/green Bereitstellungsstrategie sind die inhärenten Kosten der Standby-Umgebung aufgrund der zusätzlichen Infrastruktur, die während der Bereitstellung erforderlich ist. Eine Option zur Minderung dieser zusätzlichen Infrastrukturkosten besteht darin, eine blue/green Bereitstellungsvariante in Betracht zu ziehen, bei der neue Spielesoftware auf denselben Servern bereitgestellt wird, die bereits in der Produktion eingesetzt werden. In diesem Szenario kann neben dem bestehenden Blue-Server-Prozess ein neuer umweltfreundlicher Serverprozess mit der neuen Software gestartet werden, wobei die Umstellung zwischen Serverprozessen und nicht zwischen separaten physischen Infrastrukturen erfolgt. Dieser Ansatz kann auch die Bereitstellung von Spielen auf einer großen Menge an Infrastruktur beschleunigen, da nicht mehr auf den Start neuer Server in der Cloud gewartet werden muss. Bewährte Methoden für diesen Bereitstellungsansatz finden Sie unter [ Blue/Green Bereitstellungen auf. AWS](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html)
**Einsatz von Canary **
Der Einsatz von Canary ist für Spieleentwickler nützlich, da die Strategie angewendet werden kann, um eine frühe Alpha- oder Betaversion eines Spiels oder eine Spielfunktion wie einen neuen Spielmodus, eine neue Karte oder eine Herausforderung für eine begrenzte oder kleine Anzahl von Spielern in der Produktion zu veröffentlichen. Ein solcher Einsatz wird als * Canary * bezeichnet. Die Veröffentlichung enthält möglicherweise zusätzliche Nachverfolgungs- und Berichtsfunktionen. Wenn also echte Spieler dieses Spiel oder Feature spielen, werden ihre Spieltelemetriedaten erfasst und auf Anomalien und Probleme hin analysiert.
Bei neuen Funktionen werden die Spieler nicht ständig darüber informiert, und die Spieltelemetrie ist die primäre Quelle, anhand derer festgestellt wird, ob bei Spielern Probleme auftreten und die Veröffentlichung rückgängig gemacht werden sollte. Wenn keine nennenswerten Probleme festgestellt werden, kann das Feature gleichzeitig für weitere Spieler bereitgestellt werden, um zusätzliche Daten zu erhalten. Wenn die Spieler benachrichtigt werden, können sie gebeten werden, regelmäßig Feedback zu ihren Erfahrungen zu geben. Solche Testaktivitäten würden idealerweise von einem Live-Betriebsteam koordiniert.
Als Strategie kann Canary Deployment auch für Standardversionen verwendet werden, um den Spielern schrittweise ein neues Feature zur Verfügung zu stellen. Ein potenzieller Vorteil gegenüber der blue/green Standardumgebung besteht darin, dass keine vollständige zweite Umgebung erforderlich ist. Die Kapazität der neuen, herunterskalierten Umgebung bestimmt, wie viele Spieler in das neue Feature aufgenommen werden sollen. Bevor weitere Spieler hinzugefügt werden, muss die Kapazität entsprechend skaliert werden. Auch wenn diese maßgeschneiderte blue/green Technik voraussichtlich vergleichsweise weniger kostet als die Standardtechnik, wird dennoch davon ausgegangen blue/green, dass sie Kosten verursacht, die höher sein können als die rollende Substitutionstechnik bei Canary-Installationen.
Führen Sie in einer Produktionsumgebung nur einen einzigen Canary aus und konzentrieren Sie sich auf die Daten und das Feedback. Wenn mehrere Canaries eingesetzt werden, erschwert dies die Behebung und Isolierung von Problemen in der Produktion und beeinträchtigt die Qualität der gesammelten Datensätze und Rückmeldungen.
Eine Variante des Canary besteht darin, dass ein oder mehrere Experimente (in der Regel UI-Tests) gezielt eingesetzt werden, wobei ein Satz der Backend-Server des Spiels eine Version eines Features bereitstellt und ein anderer Satz derselben Größe eine andere Version desselben Features bereitstellt. Dafür wird keine zusätzliche oder spezielle Infrastruktur eingerichtet, und nur die ausgewählten Backend-Server erhalten diese Updates. Das Ergebnis der Experimente ist es, zu beobachten, wie die Spieler auf die einzelnen Versionen derselben Funktion reagieren, festzustellen, ob ein Konsens darüber besteht, ob sie allgemein mögen oder nicht, und zu beobachten, ob Probleme mit der Benutzerfreundlichkeit oder Funktionalität festgestellt wurden. Solche strategischen Experimente werden auch als A/B Tests bezeichnet, und der gesamte Prozess wird als * A/B Testen * bezeichnet. Nach Abschluss dieser Experimente werden die notwendigen Testdaten gesammelt, bevor die aktuelle Version des Spiel-Backend-Systems auf den für die Tests verwendeten Servern wiederhergestellt wird.
**Herkömmliche, traditionelle Bereitstellungen **
Beim traditionellen Bereitstellungsstil wird das Spiel während eines geplanten Wartungsfensters heruntergefahren und verbundene Spieler werden gelöscht oder entladen, bevor die Serverinstanzen im Spiel-Backend mit den neuesten Code-Builds aktualisiert werden. Diese Bereitstellung wirkt sich jedes Mal auf die Spieler aus, wenn sie ausgeführt wird, und die Spieler müssen vor dem Zeitplan benachrichtigt werden. Daher hat dieses Modell die meisten Auswirkungen auf die Spieler und sollte nach Möglichkeit vermieden werden.
Nachdem das Spielupdate veröffentlicht wurde, kann das Spiel einem Rauchtest unterzogen werden, bevor das Spiel für die Spieler geöffnet wird, die dann darauf warten würden, dass das Spiel wieder geöffnet wird. Dies kann zu einem Anstieg des Datenverkehrs führen, wenn Spieler versuchen, sich innerhalb kurzer Zeit anzumelden und zu spielen. Wenn das Spiel also nicht darauf ausgelegt ist, solche Verkehrsspitzen zu bewältigen, kannst du Spieler schrittweise stapelweise wieder ins Spiel einsteigen lassen.
Alternativ kannst du dich dafür entscheiden, die Infrastruktur zu überfordern, um die anfänglichen Verkehrsspitzen zu verkraften. Sobald sich der Verkehr im Spiel beruhigt hat, können die Ressourcen reduziert werden. Falls erforderlich, führt diese Art der Bereitstellung außerhalb der Spitzenzeiten durch, wenn die Anzahl der Spieler am niedrigsten ist. Häufig geplante Wartungsarbeiten sowie erweiterte Wartungsarbeiten bergen naturgemäß das Risiko, dass Spieler abwandern und möglicherweise Einnahmen verloren gehen. Spieler erwarten außerdem Änderungen nach einer neuen Veröffentlichung und können das Vertrauen in das Spiel verlieren, wenn sie nach einer gewissen Zeit der Ausfallzeit zurückkehren.
### Implementierungsschritte
+ **Minimiere Ausfallzeiten: ** Implementiere Einsatzstrategien, die Ausfallzeiten reduzieren und die Spieler im Spiel halten.
+ **Infrastruktur als Code (IaC): ** Verwenden Sie Tools wie Terraform AWS CloudFormation oder Terraform, um die Spielinfrastruktur zu verwalten und menschliche Fehler zu reduzieren.
+ **Einsatzstrategien: ** Nutze eine oder eine Kombination aus laufender Substitution und Canary-Deployments blue/green, um für reibungslose Updates zu sorgen und die Auswirkungen auf die Spieler zu reduzieren.