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 Verfolge eine Einsatzstrategie, die die Auswirkungen auf die Spieler minimiert

Integrieren Sie eine Implementierungsstrategie für Ihre Spielesoftware und -infrastruktur, die die Ausfallzeiten minimiert, die Spieler vom Spiel fernhalten. Bei bestimmten Arten von Updates müssen möglicherweise neue Updates für den Spielclient installiert werden. Gestalten Sie das Spiel jedoch 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 für die Bereitstellung von Spielen berücksichtigen sollten, besteht darin, festzulegen, wie Ihre Spieleinfrastruktur verwaltet werden soll. Verwalte deine Spieleinfrastruktur mit einem Infrastructure-as-Code-Tool (IaC) wie AWS CloudFormationTerraform von Hashicorp, um menschliche Fehler bei der Vorbereitung der Umgebung 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 Bereitstellungsstrategien, die für ein Spiel verwendet werden können:

Fortlaufende Substitution

Das Hauptziel einer fortlaufenden Substitution 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 vorzunehmenden Änderungen abwärtskompatibel sind und neben den vorherigen Versionen 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 von dedizierten Spieleservern zu implementieren, besteht ein typischer Ansatz darin, eine neue Auto Scaling Scaling-Gruppe von EC2 Instances zu erstellen, die die auf ihnen bereitgestellte neue Spielserver-Build-Version enthalten, und die Spieler dann schrittweise zu Spielsitzungen weiterzuleiten, die auf dieser neuen Serverflotte gehostet werden. Wenn es ein zugehöriges Spielclient-Update gibt, das als Voraussetzung für die Verwendung des neuen Spielserver-Builds erforderlich ist, müssen Sie eine Validierungsprüfung einschließen, um sicherzustellen, dass nur Spieler, auf denen dieses neue Spielclient-Update installiert ist, zu diesen Spielsitzungen weitergeleitet werden.

Serverflotten (z. B. EC2 Auto Scaling Scaling-Gruppen), die die alte Build-Version des Spieleservers enthalten, werden erst dann außer Betrieb genommen, wenn ihnen die aktiven Spielersitzungen ordnungsgemäß entzogen wurden, in der Regel durch die Einrichtung individueller Servermetriken, die es den Spielbetriebsteams ermöglichen, diesen Prozess zu automatisieren. Um den Umfang der Infrastruktur und die Zeit für die Durchführung einer fortlaufenden Bereitstellung zu reduzieren, kann alternativ ein alternativer Ansatz verfolgt werden, bei dem bestehende Produktionsinstanzen außer Betrieb genommen, mit dem neuen Spieleserver-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-Spieleserver für Spieler reduziert wird, wenn Server ersetzt werden.

Dieses Modell kann auch für die fortlaufende Bereitstellung von Backend-Diensten wie Datenbanken, Caches und Anwendungsservern verwendet werden, die kein Gameplay hosten. Solange diese Dienste auf hochverfügbare Weise mit mehreren Clusterinstanzen bereitgestellt werden, sollte die Komplexität der Bereitstellungen für diese Dienste geringer sein als die von Bereitstellungen auf dedizierten Spieleservern.

Einsatz in Blau/Grün

Das Hauptziel einer blue/green Bereitstellung in einem Spiel besteht darin, Ausfallzeiten zu minimieren und gleichzeitig ein sicheres Rollback zur vorherigen Bereitstellung 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 für die Migration bereit ist, können Sie Ihre Routing-Ebene so konfigurieren, dass der Datenverkehr auf die grüne Umgebung umgestellt wird und gleichzeitig 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-Service, um ihn so zu konfigurieren, dass er mit dem Senden von Spielsitzungen an die neue Flotte beginnt, oder 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 oder die Verschiebung der Gewichte des Application Load Balancers sein, um Traffic an Ihre neue Zielgruppe zu senden.

Einer der Nachteile der blue/green Bereitstellungsstrategie sind die mit der Standby-Umgebung verbundenen Kosten, die auf die zusätzliche Infrastruktur zurückzuführen sind, die während der Bereitstellung erforderlich ist. Eine Möglichkeit, diese zusätzlichen Infrastrukturkosten zu verringern, besteht darin, die Einführung einer 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 auch 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 in einem großen Teil der 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 Deployments on. AWS

Bereitstellung auf Canary

Die Bereitstellung auf 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 eingeschränkte oder kleine Gruppe von Spielern in der Produktion zu veröffentlichen. Ein solcher Einsatz wird als Kanarienvogel bezeichnet. Die Version kann zusätzliche Nachverfolgungs- und Berichtsfunktionen beinhalten. Wenn also echte Spieler dieses Spiel oder diese Funktion spielen, werden ihre Spieltelemetriedaten erfasst und auf Anomalien und Probleme analysiert.

Bei neuen Funktionen werden die Spieler nicht regelmäßig darüber informiert, und die Spieltelemetrie ist die wichtigste 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 die Funktion gleichzeitig weiteren Spielern zur Verfügung gestellt 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-Operationsteam koordiniert.

Als Strategie kann der Einsatz von Canary 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 mit der neuen Funktion vertraut werden sollen. Bevor weitere Spieler hinzugefügt werden, muss die Kapazität entsprechend skaliert werden. Auch wenn davon ausgegangen wird, dass diese maßgeschneiderte blue/green Technik vergleichsweise weniger kosten wird als die standardmäßige Blau/Grün-Technik, wird dennoch davon ausgegangen, dass sie Kosten verursacht, die höher sein können als die fortlaufende Substitutionstechnik bei kanarischen Installationen.

Führen Sie nur einen einzigen Canary in einer Produktionsumgebung aus und konzentrieren Sie sich auf dessen Daten und Feedback. Wenn mehrere Canaries eingesetzt werden, erschwert dies die Behebung und Isolierung von Problemen in der Produktion und beeinträchtigt die Qualität der Datensätze und des gesammelten Feedbacks.

Eine Variante des Kanariensystems besteht darin, dass ein oder mehrere Experimente (in der Regel UI-Tests) durch gezielte Bereitstellungen durchgeführt werden, wobei ein Satz der Backend-Server des Spiels eine Version einer Funktion und eine andere Gruppe derselben Größe eine andere Version derselben Funktion bereitstellt. Dafür wird keine zusätzliche oder spezielle Infrastruktur geschaffen, und nur die ausgewählten Backend-Server erhalten diese Updates. Das Ergebnis der Experimente besteht darin, zu beobachten, wie die Spieler auf die einzelnen Versionen derselben Funktion reagieren, festzustellen, ob allgemein Zustimmung oder Abneigung besteht, 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-Testing bezeichnet. Nach Abschluss dieser Experimente werden die erforderlichen Testdaten gesammelt, bevor auf den für die Tests verwendeten Servern zur aktuellen Version des Spiel-Backend-Systems zurückgekehrt wird.

Herkömmliche ältere Bereitstellungen

Bei der herkömmlichen Art der Bereitstellung wird das Spiel während eines geplanten Wartungsfensters heruntergefahren und verbundene Spieler fallen gelassen oder ausgelaugt, 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 durchgeführt wird, und die Spieler müssen im Voraus darüber informiert werden. Aus diesem Grund hat dieses Modell die meisten Auswirkungen auf die Spieler und sollte nach Möglichkeit vermieden werden.

Nach der Veröffentlichung des Spielupdates kann das Spiel einem Rauchtest unterzogen werden, bevor das Spiel für die Spieler geöffnet wird, die dann auf die Wiedereröffnung des Spiels warten würden. Dies kann zu einem Anstieg des Traffics führen, wenn Spieler versuchen, sich innerhalb kurzer Zeit einzuloggen und zu spielen. Wenn das Spiel nicht darauf ausgelegt ist, solche Verkehrsspitzen zu bewältigen, können Sie sich daher dafür entscheiden, die Spieler nach und nach stapelweise wieder ins Spiel zu lassen.

Alternativ könnt ihr euch dafür entscheiden, die Infrastruktur übermäßig bereitzustellen, um den anfänglichen Anstieg des Datenverkehrs aufrechtzuerhalten. Sobald sich der Spieldatenverkehr stabilisiert hat, können die Ressourcen heruntergefahren werden. Falls erforderlich, sollten Sie diese Art der Bereitstellung außerhalb der Spitzenzeiten durchführen, wenn die Spielerzahl am niedrigsten ist. Häufig geplante Wartungsarbeiten sowie längere Wartungsarbeiten bergen naturgemäß das Risiko einer Fluktuation von Spielern und potenziellen Umsatzeinbußen. Spieler erwarten auch nach einer neuen Version Änderungen und können das Vertrauen in das Spiel verlieren, wenn sie nach einer gewissen Zeit der Ausfallzeit zurückkehren.

Implementierungsschritte