• 4 min read

Entwickeln des Xbox-Spielstreamings mit bewährten Methoden für die Sitezuverlässigkeit

Letzen Monat haben wir die DevOps-Journey bei Microsoft mit Storys verschiedener Microsoft-Teams begonnen und die Einführung von DevOps in diese Teams thematisiert.

Letzen Monat haben wir die DevOps-Journey bei Microsoft mit Storys verschiedener Microsoft-Teams begonnen und die Einführung von DevOps in diese Teams thematisiert. Im folgenden Artikel der Serie möchten wir den Übergang eines Teams der klassischen Rolle zur SRE-Rolle (Site Reliability Engineering) genauer beleuchten und die Geschichte des xREO-Teams (Xbox Reliability Engineering and Operations) erzählen.

Diese Umstellung gestaltete sich nicht gerade einfach, war aber notwendig, da Microsoft Spielern mithilfe von Cloudstreaming Xbox-Spiele an jedem beliebigen Ort zur Verfügung stellen möchte (xCloud-Projekt). Das Team musste die Arbeitsweise umstrukturieren, die Zusammenarbeit mit dem Entwicklungsteam verbessern, in die Automatisierung investieren und bereits in den frühen Phasen des Anwendungslebenszyklus mitarbeiten, um innovative Technologien mit erstklassigen Funktionen bereitstellen zu können. In diesem Blog werden einige der wichtigsten Erkenntnisse des Teams genannt. Die ganze Geschichte des Teams finden Sie im Beitrag zur xREO-Journey.

Konsistente Spielanforderungen und Notwendigkeit der Zusammenarbeit

Eine konsistente Nutzung ist entscheidend für eine erfolgreiche Spielstreamingsitzung. Spieler müssen bei einem über die Cloud gestreamten Spiel den Eindruck haben, als würden sie diese auf einer Konsole in der Nähe spielen. Hierfür ist eine global verteilte Cloudlösung nötig, die in vielen Rechenzentren in der Nähe der Endbenutzer ausgeführt wird. Die globale Azure-Infrastruktur ermöglicht dies zwar, allerdings stellt die Ausführung eines Systems zusätzlich zu den vielen Azure-Regionen eine ernsthafte Herausforderung dar.

Die für das Entwerfen und Entwickeln dieser Technologie zuständigen Xbox-Entwickler erkannten früh, dass sie dieses System nicht einfach nur erstellen und dann problemlos bereitstellen können. Beide Teams mussten während der gesamten Planungsphase zusammenarbeiten, damit schon beim Entwerfen Überlegungen hinsichtlich der Funktionsweise in einer Produktionsumgebung berücksichtigt werden konnten.

Smartphonedisplay mit über die Cloud gestreamtem Rennsportspiel

Vorausschauendes Entwerfen von Cloudlösungen

In vielen großen Organisationen ist es üblich, dass Entwicklungs- und Betriebsteams in Silos arbeiten. Entwickler berücksichtigen beim Planen und Erstellen eines Systems nicht alle für das Betriebsteam wichtigen Punkte, während letzteres keine Änderungen am Code vornehmen darf, obwohl es diesen bereitstellt und in der Produktionsphase damit arbeitet. Beim SRE-Ansatz wird die Systemzuverlässigkeit in den gesamten Anwendungslebenszyklus integriert, und das in der Produktionsumgebung für das System zuständige Team kann bereits in der Planungsphase mitwirken. Mit dem neuen Ansatz, bei dem das xREO-Team in die Entwurfsphase involviert ist, wird eine Umgebung für Zusammenarbeit geschaffen, die das gemeinsame Treffen von Entscheidungen hinsichtlich Technologie und Systementwurf erleichtert und dadurch alle Anforderungen des Unternehmens erfüllt.

Nutzen von Containern für deutliche Besitzdefinitionen

Eine der ersten gemeinsamen Entscheidungen des Entwicklungs- und xREO-Teams hinsichtlich der Technologie bestand darin, mithilfe von Containertechnologien eine Microservicearchitektur zu implementieren. So konnten die Entwicklungsteams eigene .NET Core-Microservices containerisieren und die Abhängigkeit von der Cloudinfrastruktur des xREO-Teams vermeiden, in der die Container ausgeführt wurden.

Eine weitere technologische Entscheidung, die beide Teams frühzeitig getroffen haben, war die Verwendung von Kubernetes als zugrunde liegende Containerorchestrierungsplattform. Dies ermöglichte dem xREO-Team die Nutzung von Azure Kubernetes Service (AKS), einer verwalteten Kubernetes-Cloudplattform, die die Bereitstellung von Kubernetes-Clustern vereinfacht und so eine Menge Komplexität beseitigt, mit der das Team bei der Ausführung mehrerer Cluster in mehreren Azure-Regionen konfrontiert worden wäre. Die gemeinsamen Entscheidungen verdeutlichen die jeweiligen Rollen: Entwickler sind für alles innerhalb der Container und das xREO-Team für die AKS-Cluster verantwortlich. Andere Azure-Dienste ermöglichen das Hosting der Cloudinfrastruktur für diese Container. Jedes Team ist für die Bereitstellung, Überwachung und Inbetriebnahme der jeweiligen Teile in der Produktionsumgebung zuständig.

Dieser Ansatz sorgt für eine klare Verantwortlichkeit und ermöglicht eine komplikationslose Verwaltung von Zwischenfällen in der Produktionsumgebung, was in einer monolithischen Architektur sehr schwierig sein kann, da die Infrastruktur und die Anwendungslogik Codeabhängigkeiten aufweisen, die nur schwer zu lösen sind.

Zwei Mitglieder des xREO-Teams mit Laptops im Konferenzraum

Skalieren durch Infrastrukturautomatisierung

Eine weitere bewährte Methode besteht darin, dass das xREO-Team in die Automatisierung der Infrastruktur investiert hat. Das manuelle Bereitstellen mehrerer Clouddienste in jeder Azure-Region war nicht skalierbar und zu zeitintensiv. Im Rahmen der IaC-Vorgehensweise (Infrastructure-as-Code) hat das Team Azure Resource Manager-Vorlagen zum Erstellen deklarativer Definitionen von Cloudumgebungen verwendet, die Bereitstellungen in mehreren Azure-Regionen mit nur minimalem Aufwand ermöglichen.

Wenn die Infrastruktur als Code verwaltet wird, kann sie auch mithilfe von Continuous Integration und Continuous Delivery (CI/CD) bereitgestellt werden, um folglich den Bereitstellungsprozess neuer Azure-Ressourcen in vorhandenen Rechenzentren zu automatisieren, Infrastrukturdefinitionen zu aktualisieren oder bei Bedarf neue Azure-Regionen online zu schalten. Sowohl IaC als auch CI/CD garantieren eine schlanke Organisation und unterstützen das Team dabei, sich wiederholende und alltägliche Arbeiten zu vermeiden und einen Großteil der durch menschliche Fehler verursachten Risiken bei manuell ausgeführten Schritten zu beseitigen. Anstatt Zeit mit der Ausführung manueller Arbeiten und dem Überprüfen von Checklisten zu verbringen, kann sich das Team auf eine weitere Verbesserung der Plattform und deren Resilienz konzentrieren.

SRE in der Praxis 

Die Journey des xREO-Teams begann mit der Notwendigkeit, den Spielern ein optimales Spielerlebnis zu bieten. Dies ist ein gutes Beispiel, das zeigt, wie Teams, die Kunden durch Innovationen und neue Möglichkeiten begeistern möchten, die Art und Weise des Entwerfens, Erstellens und Bereitstellens von Software optimieren müssen. Das Verlagern des Ansatzes in die Produktionsumgebung und die enge Zusammenarbeit mit Entwicklungsteams stellen die tatsächliche Transformation des xREO-Teams dar.

Mit dieser neuen Herangehensweise ist das Team nun gut positioniert, um eine höhere Resilienz zu erzielen und das System weiter zu skalieren und infolgedessen jedem Spieler ein optimales Spielerlebnis über die Cloud zu ermöglichen.

Ressourcen