Navigation überspringen

Minecraft Earth und Azure Cosmos DB Teil 1: Wie Minecraft Einzug in unsere reale Welt hält

Veröffentlicht am 6 Mai, 2020

Azure Cosmos DB

Dieser Beitrag ist der erste Teil einer zweiteiligen Reihe und beschreibt, wie Unternehmen Azure Cosmos DB nutzen, um den Anforderungen der realen Welt gerecht zu werden, und welchen Unterschied dieser Ansatz für sie ausmacht. In Teil 1 gehen wir auf die Herausforderungen ein, die Entwickler des Minecraft Earth-Diensts veranlasst haben, sich für Azure Cosmos DB zu entscheiden, und beschreiben, wie sie den Dienst nutzen, um praktisch jede Aktion jedes Spielers rund um die Welt zu erfassen – all das bei einer extrem niedrigen Latenz. In Teil 2 befassen wir uns mit der Workload der Lösung und damit, wie Entwickler von Minecraft Earth davon profitieren, den Dienst auf Azure Cosmos DB aufzusetzen.

Wie die Welt von Minecraft Einzug in unsere reale Welt hält

Wahrscheinlich haben Sie schon von dem Spiel Minecraft gehört, auch wenn Sie es noch nicht selbst gespielt haben. Es ist das meistverkaufte Videospiel aller Zeiten, von dem seit 2011 mehr als 176 Millionen Exemplare verkauft wurden. Heute verzeichnet Minecraft jeden Monat mehr als 112 Millionen Spieler, die die immersive, prozedural generierte 3D-Welt des Spiels nutzen, um Rohstoffe zu suchen und abzubauen, Werkzeuge anzufertigen, Häuser zu bauen und Erdarbeiten durchzuführen. Je nach Spielmodus können Spieler auch computergesteuerte Gegner bekämpfen und mit anderen Spielern zusammenarbeiten oder gegen sie antreten.

Im Mai 2019 kündigte Microsoft das bevorstehende Release von Minecraft Earth an, dessen weltweite Einführung im Dezember 2019 begann. Im Gegensatz zu vorangegangenen Spielen unter dem Minecraft-Franchise erobert Minecraft Earth eine völlig neue Dimension, indem Spieler die Welt von Minecraft dank den Möglichkeiten von AR (Augmented Reality) in unserer realen Welt erleben können.

Spielern von Minecraft Earth ist die Erfahrung sofort vertraut, obwohl sie nahtlos in die Welt um sie herum integriert ist. Die Entwickler im Minecraft-Team von Microsoft mussten bei der Bereitstellung von Minecraft Earth – insbesondere bei den autorisierenden Back-End-Diensten zur Unterstützung des Spiels – jedoch völlig neue Wege beschreiten.

Nathan Sosnovske, leitender Softwareentwickler im Minecraft Earth-Team für die Entwicklung des Diensts, erklärt:

„Bei Vanilla Minecraft konnte man zwar einen eigenen Server hosten, allerdings gab es keine zentrale Dienstautorität. Minecraft Earth basiert auf einem zentralisierten, autorisierenden Dienst – dem ersten „massiven“ Dienst, den wir jemals für das Minecraft-Franchise entwickeln mussten.“

In dieser Fallstudie sehen wir uns einige der Herausforderungen an, die die Entwickler von Minecraft Earth bei ihrer Aufgabenstellung bewältigen mussten – und wie sie diese Anforderungen mit Azure Cosmos DB gemeistert haben.

Die technische Herausforderung: In-Game-Verzögerungen vermeiden

Innerhalb des Minecraft Earth-Clients, der auf AR-fähigen iOS- und Android-Geräten läuft, führt fast jede Aktion, die ein Spieler ausführt, zu einem Schreibvorgang im Minecraft Earth-Kerndienst. Jeder Schreibvorgang ist eine REST POST-Anforderung, die sofort akzeptiert und bestätigt werden muss, um spürbare In-Game-Verzögerungen zu vermeiden.

„Aus Sicht des Diensts erfordert Minecraft Earth Schreibvorgänge mit niedriger Latenz und Lesevorgänge mit mittlerer Latenz“, erläutert Sosnovske. „Schreibvorgänge müssen schnell sein, da der Client für jeden einzelnen Vorgang eine Bestätigung benötigt, z. B. wenn er Objekte rendern muss. Wenn ein Spieler beispielsweise auf eine Ressource tippt, um zu sehen, was darin enthalten ist, dürfen visuelle Objekte nicht hängen bleiben, während die zugehörige REST-Anforderung verarbeitet wird. Lesevorgänge mit mittlerer Latenz sind akzeptabel, da wir die clientseitige Simulation verwenden können, bis das unterstützende Modell hinter dem Dienst für das Lesen aktualisiert werden kann.“

Was die Herausforderung noch erschwerte: Die Entwickler von Minecraft Earth mussten dafür sorgen, dass Schreibvorgänge unabhängig vom Standort eines Spielers mit niedriger Latenz ausgeführt wurden. Dazu mussten innerhalb jeder Geografie, in der Minecraft Earth angeboten werden sollte, Kopien des Diensts an mehreren Standorten ausgeführt werden. Zusätzlich mussten intelligente Routeninformationen integriert werden, um den Minecraft Earth-Client zum nächstgelegenen Standort zu routen, an dem der Dienst bereitgestellt wird.

„Die typische Netzwerklatenz zwischen der Ost- und Westküste in den USA beträgt 70 bis 80 Millisekunden“, bemerkt Sosnovske. „Wenn ein Spieler in New York von einem Dienst in San Francisco abhängig ist, oder umgekehrt, wäre die In-Game-Verzögerung nicht akzeptabel. Außerdem heißt das Spiel „Minecraft Earth“ – was bedeutet, dass Spieler in San Francisco und New York in der Lage sein müssen, die gleiche Spielerfahrung zu machen. Um all dies zu gewährleisten, müssen wir den Dienst – und die zugehörigen Daten – in mehreren geografisch verteilten Rechenzentren innerhalb der einzelnen Geografien replizieren.“

Die Lösung: Ein ES (Event Sourcing)-Muster auf Grundlage von Azure Cosmos DB

Um die technischen Anforderungen zu erfüllen, implementierten die Entwickler von Minecraft Earth Event Sourcing-Muster auf Basis von Azure Cosmos DB.

„Wir hatten anfänglich Azure-Tabellenspeicher zum Speichern unseres Append-Only-Ereignisprotokolls in Erwägung gezogen. Da jedoch keine SLAs für Lese- und Schreiblatenzen verfügbar waren, mussten wir umdenken“, beschreibt Sosnovske. „Letztendlich haben wir uns für Azure Cosmos DB entschieden, da sowohl für Lese- als auch für Schreibvorgänge SLAs von 10 Millisekunden verfügbar waren. Darüber hinaus überzeugte die Lösung durch ihre globalen Verteilungs- und Multimasterfunktionen, die zum Replizieren des Diensts an mehrere Standorte innerhalb der einzelnen Geografien erforderlich waren.“

Bei Verwendung eines Event Sourcing-Musters geschieht Folgendes: Anstatt einfach nur den aktuellen Zustand der Daten zu speichern, verwendet der Minecraft Earth-Dienst einen auf Azure Cosmos DB basierenden Append-Only-Datenspeicher, um die gesamte Abfolge von Aktionen aufzuzeichnen, die auf die Daten angewendet wurden – in diesem Fall die Zuordnung zu jeder vom Spieler getätigten In-Game-Aktion. Nachdem die sofortige Bestätigung eines erfolgreichen Schreibvorgangs an den Client zurückgegeben wurde, übernehmen Warteschlangen, die den Append-Only-Ereignisspeicher abonnieren, die Nachverarbeitung und wenden die gesammelten Ereignisse asynchron auf einen Domänenzustand an, der im Azure Blob Storage verwaltet wird. Zur weiteren Optimierung kombinierten die Entwickler von Minecraft Earth das Event Sourcing-Muster mit einem domänengesteuerten Design, in dem für jede App-Domäne – z. B. Inventargegenstände, Charakterprofile oder Erfolge – ein eigener Ereignisstream verwendet wird.

„Wir haben unsere Daten als Ereignisstreams modelliert, die in einem Append-Only-Protokoll gespeichert werden und in einen In-Memory-Modellzustand mutieren, der zur Steuerung verschiedener Clientansichten verwendet wird“, so Sosnovske. „Dieser zwischengespeicherte Zustand wird in Azure Blob Storage verwaltet, der genügend Geschwindigkeit für Lesevorgänge bietet und hilft, die Kosten der Anforderungseinheiten für Azure Cosmos DB auf ein Minimum zu beschränken. In vielerlei Hinsicht haben wir mit Azure Cosmos DB praktisch einen Schreibcache aufgebaut, der wirklich extrem resilient ist.“

Das folgende Diagramm zeigt, wie das auf Azure Cosmos DB basierte Event Sourcing-Muster funktioniert:

Workflowdiagramm: Event Sourcing-Muster auf Basis von Azure Cosmos DB

Einführung von Azure Cosmos DB

Bei der Inbetriebnahme von Azure Cosmos DB mussten die Entwickler einige Entwurfsentscheidungen treffen:

Azure Cosmos DB-API: Die Entwickler entschieden sich für die Azure Cosmos DB-Core-API (SQL), da sie über die beste Leistung, die höchste Benutzerfreundlichkeit und weitere erforderliche Funktionen verfügte.

„Da wir das System von Grund auf neu erstellt haben, benötigten wir keine Kompatibilitätsebene, um die Migration von vorhandenem Code zu erleichtern“, erläutert Sosnovske. „Darüber hinaus werden einige Azure Cosmos DB-Funktionen wie TransactionalBatch, von denen wir abhängig sind, nur von der Core-API (SQL) unterstützt. Ein zusätzlicher Vorteil der Core-API (SQL) bestand darin, dass sie sehr intuitiv war, dass sie für unser Team sehr intuitiv war, da wir generell bereits mit SQL vertraut waren.“

Weitere Informationen finden Sie im Thema zur Einführung von TransactionalBatch im .NET SDK.

Partitionsschlüssel: Die Entwickler entschieden sich zum Schluss dafür, die Daten in Azure Cosmos DB benutzerbasiert logisch zu partitionieren.

„Ursprünglich hatten wir die Daten nach Benutzern und Domänen partitioniert – hier erneut Inventargegenstände oder Erfolge als Beispiel. Allerdings stellte sich heraus, dass diese Aufteilung zu granular war und uns daran hinderte, das Potenzial der Datenbanktransaktionen in Azure Cosmos DB voll auszuschöpfen“, bemerkt Sosnovske.

Konsistenzebene: Von den fünf Konsistenzebenen, die Azure Cosmos DB unterstützt, wählten die Entwickler Sitzungskonsistenz, die sie mit einer eingehenden ETag-Überprüfung kombinierten, um sicherzustellen, dass die Daten ordnungsgemäß geschrieben werden.

„Das funktioniert aufgrund der Art und Weise, wie wir Daten speichern. Sie werden als Append-Only-Protokoll mit einem Hauptdokument modelliert, das auf das Ende des Protokolls verweist“, erklärt Sosnovske. „Beim Schreiben in die Datenbank werden das Hauptdokument und dessen ETag gelesen. Anschließend wird die N+1-Protokoll-ID abgeleitet, und dann wird ein Transaktionsbatchvorgang konstruiert, in dem der Hauptzeiger mit dem zuvor gelesenen ETag überschrieben und ein neues Dokument für den Protokolleintrag erstellt wird. In dem unwahrscheinlichen Fall, dass das Protokoll bereits geschrieben wurde, führen die ETag-Überprüfung und der Versuch, ein bereits vorhandenes Dokument zu erstellen, zu einem Transaktionsfehler. Dies geschieht unabhängig davon, ob eine andere Anforderung uns beim Schreiben „zuvorkommt“ oder ob von der Anforderung leicht veraltete Daten gelesen werden.“

In Teil 2 dieser Reihe befassen wir uns mit der aktuellen Workload der Lösung und damit, wie Entwickler von Minecraft Earth davon profitieren, den Dienst auf Azure Cosmos DB aufzusetzen.

Erste Schritte mit Azure Cosmos DB