Überblick über die Cloud-Spieleinfrastruktur

Diese Lösung enthält einen Überblick über allgemeine Komponenten und Designmuster für das Hosten der Spieleinfrastruktur auf Cloudplattformen.

Videospiele haben sich in den letzten Jahrzehnten zu einem blühenden Unterhaltungsgeschäft entwickelt. Nachdem sich das Breitbandinternet immer weiter verbreitet, sind Onlinespiele einer der Schlüsselfaktoren für das Wachstum der Spieleindustrie.

Onlinespiele werden in verschiedenen Formen angeboten, wie sitzungsbasierte Multiplayer-Spiele, virtuelle Massen-Multiplayer-Welten und miteinander verflochtene Einzelspielerumgebungen.

Früher mussten für Spiele mit einem Client/Server-Modell dedizierte lokale oder zusammengelegte Server zur Ausführung der Onlineinfrastruktur erworben und gewartet werden. Dies konnten sich nur große Studios und Publisher leisten. Außerdem waren umfangreiche Projektionen und eine gründliche Kapazitätsplanung erforderlich, um die Kundenanforderungen zu erfüllen, ohne zu hohe Ausgaben für fest installierte Hardware tätigen zu müssen. Mit den heutigen cloudbasierten Computing-Ressourcen können Spieleentwickler und Publisher jeder Größe Ressourcen nach Bedarf anfordern und erhalten, sodass kostspielige Ausgaben im Vorfeld und die Gefahr von übermäßiger oder nicht ausreichender Bereitstellung von Hardware umgangen werden.

Allgemeine Komponenten

Im folgenden Diagramm wird der Onlineteil einer Spielearchitektur dargestellt.

Diagramm der Spielinfrastruktur auf der GCP mit Front-End- und Back-End-Komponenten

Die Front-End-Komponenten der Spielearchitektur umfassen:

  • Spieleplattformdienste für zusätzliche Spielefunktionalität
  • Dedizierte Spieleserver, die das Spiel hosten

Die Back-End-Komponenten der Spielearchitektur umfassen:

  • Spielstatus, der im Erfassungssystem beibehalten und in der Regel in der Spieledatenbank gespeichert wird
  • Analysestack, in dem Analysen und Gameplay-Ereignisse gespeichert und abgefragt werden

Diese Komponenten können in einer Vielzahl von Umgebungen gehostet werden: lokal, in einer privaten oder öffentlichen Cloud oder sogar in einer vollständig verwalteten Lösung. Solange das System die Latenzanforderungen zur Kommunikation zwischen den Komponenten und Endnutzern erfüllt, kann jede dieser Lösungen funktionieren.

Front-End

Das Front-End enthält Schnittstellen, mit denen Clients interagieren können, entweder direkt oder über eine Load-Balancing-Schicht.

In einem sitzungsbasierten First Person Shooter zum Beispiel umfasst das Front-End in der Regel einen Zuordnungsdienst. Dieser Dienst verteilt Verbindungsinformationen für dedizierte Spieleserverinstanzen an Clients:

  1. Ein Client sendet eine Anfrage an den Zuordnungsdienst.
  2. Der Zuordnungsdienst sendet Verbindungsinformationen an den Client.
  3. Der Client kann dann per User Datagram Protocol (UDP) eine direkte Verbindung zur dedizierten Spieleserverinstanz herstellen.

Front-End-Dienste müssen nicht exklusiv von externen Clients verwendet werden. Front-End-Dienste kommunizieren im Allgemeinen miteinander und mit dem Back-End.

Da Front-End-Dienste über das Internet verfügbar sind, besteht ein erhöhtes Angriffsrisiko. Sie sollten den Front-End-Dienst gegen DoS-Angriffe (Denial-of-Service) und fehlerhafte Pakete absichern, um diese Sicherheits- und Zuverlässigkeitsprobleme zu umgehen. Im Vergleich dazu sind Back-End-Dienste im Allgemeinen nur für vertrauenswürdigen Code zugänglich und daher möglicherweise schwerer anzugreifen.

Spieleplattformdienste

Gängige Namen für diese Komponente sind Plattformdienste oder Onlinedienste. Plattformdienste bieten Schnittstellen für wichtige Meta-Spielefunktionen, wie die Möglichkeit, dass Spieler derselben dedizierten Spieleserverinstanz beitreten können, oder das Speichern des Social Graph der "Freundesliste" Ihres Spiels. Häufig enthält die Plattform (wie Steam, Xbox Live oder Google Play Games), auf der Ihr Spiel ausgeführt wird, die folgenden Dienste:

  • Bestenliste und Spielverlauf
  • Zuordnung
  • Onlinelobby
  • Chat
  • Bestandsverwaltung
  • Autorisierung
  • Party/Gruppe
  • Profil
  • Gilde
  • Plattformübergreifendes Entsperren
  • Feeds
  • Zuordnung der sozialen Identität
  • Analyse
  • Präsenz

Die Dienste für Spieleplattformen entwickelten sich im Vergleich zu Webdiensten ähnlich:

  • Zu Beginn der 2000er-Jahre wurde eine typische Suite von Plattformdiensten als monolithischer Dienst ausgeführt und häufig als Singleton implementiert. Selbst in der föderierten Form wird dieses Muster für Cloud-Deployments nicht empfohlen.

  • Das jetzt gebräuchliche serviceorientierte Architekturmuster (SOA) wurde Mitte der 2000er populär, als die Industrie die verschiedenen Dienste in unabhängig skalierbare Dienste geändert hat. Außerdem konnte jetzt auf die Dienste nicht nur von Spieleclients und -servern zugegriffen werden, sondern auch von Webdiensten und letztendlich Smartphone-Apps.

  • In den letzten fünf Jahren haben sich viele Entwickler für die Mikrodienstelösung entschieden, die von schnell wachsenden Webunternehmen bevorzugt wird. Viele der grundlegenden Herausforderungen von Plattformdiensten und Webanwendungen sind identisch, wie schnelle Entwicklungszyklen und die Ausführung von Diensten, die auf der ganzen Welt verteilt werden. Mikrodienste können diese Probleme lösen und sind eine sehr gute Wahl beim Entwurf von Anwendungen zur Ausführung auf Cloudplattformen.

  • Darüber hinaus gibt es jetzt viele gehostete oder verwaltete Dienste, mit denen Sie entweder Plattformdienste oder vollständig verwaltete Plattformdienste erstellen können.

Back-End-Plattformdienste

Auch wenn auf die meisten Plattformdienste von externen Clients zugegriffen wird, ist es gelegentlich sinnvoll, wenn nur von anderen Teilen der Onlineinfrastruktur auf einen Plattformdienst zugegriffen wird, beispielsweise von einem nicht freigegebenen Rankingdienst für Turnierspieler. Auch wenn solche Back-End-Plattformdienste im Allgemeinen keine externe Netzwerkroute und IP-Adresse haben, folgen sie demselben Designmuster wie Front-End-Plattformdienste.

Google Cloud-Dienstlösungen

Die folgenden Lösungen enthalten weitere Informationen zum Erstellen von Back-End-Diensten in Google Cloud.

Dedizierter Spieleserver

Dedizierte Spieleserver enthalten die Spielelogik. Um die Latenz für den Nutzer zu reduzieren, kommunizieren Client-Spiele-Apps im Allgemeinen direkt mit den dedizierten Spieleservern. Dadurch werden sie Teil der Front-End-Dienstarchitektur.

Es gibt keine Standardterminologie für diese Industrie. Deshalb gilt für diesen Artikel Folgendes:

  • Maschine bezieht sich auf die physische oder virtuelle Maschine, auf der die Prozesse des Spieleservers ausgeführt werden.
  • Spieleserver bezieht sich auf den Spieleserverprozess. Mehrere Spieleserverprozesse können gleichzeitig auf einer Maschine ausgeführt werden.
  • Instanz bezieht sich auf einen einzelnen Spieleserverprozess.

Typen von dedizierten Spieleservern

Der Begriff dediziert kann für die heutigen Back-End-Spieleserver irreführend sein. Im ursprünglichen Kontext hat sich dediziert auf Spieleserver bezogen, die in einem Verhältnis von 1:1 auf dedizierter Hardware ausgeführt wurden. Heute verwalten die meisten Spiele-Publisher mehrere Spieleserverprozesse, die gleichzeitig auf einer Maschine ausgeführt werden. Auch wenn heute für diese Prozesse nur selten ganze Maschinen dediziert werden, wird der Begriff dedizierter Spieleserver häufig in der Spieleindustrie verwendet.

Dedizierte Spieleserver sind so unterschiedlich wie die Spieletypen, die mit ihnen ausgeführt werden. Im folgenden Abschnitt werden einige Spieleserverkategorien der obersten Ebene beschrieben.

Echtzeitsimulationen

Bis vor Kurzem war nahezu jeder dedizierte Spieleserver für ein im Handel erhältliches Produkt Bestandteil des Front-Ends für ein Echtzeitsimulationsspiel. Echtzeitsimulations-Spieleserver haben die Grenzen der vertikalen Skalierung in historischem Ausmaß verschoben. Die anspruchsvollsten Spiele sind zu manuell-horizontalen Skalierungstaktiken übergegangen, wie der Ausführung mehrerer Serverprozesse pro Maschine oder dem geografischen Sharding der Welt. Die UDP-Kommunikation mit benutzerdefinierter Ablaufsteuerung, Zuverlässigkeit und Vermeidung von Überlastungen ist das vorrangige Ziel für Netzwerke.

Die meisten Echtzeitsimulations-Spieleserver sind als Endlosschleife implementiert, wobei die Schleife innerhalb eines bestimmten Zeitrahmens beendet werden soll. Typische Zeitrahmen betragen 16 oder 33 Millisekunden. Dies führt zu einer Statusaktualisierungsrate von 60 bzw. 30 Aktualisierungen pro Sekunde. Die Aktualisierungsrate wird auch als Frame-Rate oder Tick-Rate bezeichnet. Auch wenn der Server die Simulation mit hoher Frequenz aktualisiert, ist es nicht ungewöhnlich, wenn der Server Statusaktualisierungen erst nach Abschluss mehrerer Aktualisierungen an Clients kommuniziert. Dadurch bleiben die Anforderungen an die Netzwerkbandbreite in einem vernünftigen Rahmen. Die Auswirkungen einer weniger häufigen Aktualisierung können durch Strategien wie Verzögerungskompensierung, Interpolation und Extrapolation abgemildert werden.

All dies bedeutet, dass Echtzeitsimulations-Spieleserver latenzempfindliche, computing- und bandbreiten-intensive Arbeitslasten ausführen, für die das Design des Spieleservers und die Computing-Plattformen sorgfältig abgewogen werden müssen.

Sitzungs- oder spielebasierte Spiele

Spiele, bei denen die Server eigenständige Sitzungen ausführen sollen, sind heute allgemein üblich. Typische Beispiele sind die Multiplayer-Sitzungen von FPS-Spielen (First Person Shooter), etwa Call of Duty™, Overwatch™ oder Titanfall™, oder MOBA-Spielen (Multiplayer Online Battle Arena) wie Dota 2™ oder Vainglory™. Diese Spiele haben Server, die ein reaktionsschnelles Spiel und detaillierte Spielstatusberechnungen erfordern, häufig mit Threads für KI oder physische Simulation.

Persistente Massen-Multiplayer-Welten

Vor nahezu zwei Jahrzehnten hat Ultima Online™ den Weg für ein gewaltiges Anwachsen von MMO-(Massively Multiplayer Online-)Spielen geebnet. Heute sind die populärsten MMOs, wie World of Warcraft™ und Guild Wars™, durch komplizierte Serverdesigns mit sich ständig weiter entwickelnden Funktionen gekennzeichnet.

Komplexe Probleme treten bei MMO-Spieleservern immer wieder auf, wie Übergabe von Spieleentitäten zwischen Serverinstanzen, Sharding oder Phasing der Spielewelt und gemeinsame physische Speicherung der Instanzen, um angrenzende Spieleweltbereiche zu simulieren. Die Computing- und Speicheranforderungen zur Berechnung von Statusaktualisierungen für eine persistente Welt mit Hunderten oder Tausenden von Spielern kann zu Lösungen wie der Zeitdilatation bei Eve Online™ führen.

Anfrage/Antwort-basierte Server

Vom technischen Standpunkt aus gesehen basieren alle dedizierten Spieleserver auf einer Reihe von Anfragen und Antworten. Besonders mobile Spieleserver ohne kritische Anforderungen an Echtzeitkommunikation, haben jedoch die HTTP-Anfrage- und Antwortsemantik wie beim Web-Hosting übernommen.

Die Herausforderungen bei Anfrage/Antwort-Spieleservern sind identisch mit den Herausforderungen bei jedem Webservice, einschließlich:

  • Möglichst schnelle Antwortzeit des Spieleservers
  • Globale Verteilung der Spieleserver für weniger Latenz und mehr Redundanz
  • Validierung der Aktionen des Spieleclients auf dem Server als Schutz vor Exploits oder Betrug
  • Absicherung der Spieleserver gegen Denial of Service- und andere Angriffe
  • Implementierung einer exponentiellen Verzögerung bei Kommunikationswiederholungen auf der Clientseite
  • Erstellen von fest verknüpften Sitzungen oder Externalisieren des Prozessstatus

Die Stärken der Anfrage/Antwort-Spieleserver, wie kompakte Kommunikationssemantik und einfache Wiederholungen nach einem Anwendungs- oder Netzwerkfehler eignen sich besonders gut für rundenbasierte und mobile Spiele.

Spieleweltstatus externalisieren

Spieler erwarten immer mehr, dass es zu keinen Spieleausfallzeiten kommt. Deshalb muss ihr Spielerlebnis vor Problemen geschützt werden, die sich auf einzelne Serverinstanzen auswirken. Dazu muss ein Spiel den Spielerstatus außerhalb eines einzelnen Spieleserverprozesses speichern. Das bringt viele Vorteile, wie Resistenz gegen abgestürzte Serverprozesse, und die Möglichkeit eines effizienten Lastenausgleichs.

Leider kann die Verwendung von externalisierten Statusmustern, die bei Webdiensten beliebt ist, aus einer Reihe von Gründen problematisch sein, unter anderem:

  • Die Geschwindigkeit, mit der Aktualisierungen in den externen Status geschrieben werden können, kann eine Herausforderung sein, wenn viele eindeutige Entitäten Dutzende von Malen pro Sekunde aktualisiert werden. Das gilt selbst dann, wenn Sie im Arbeitsspeicher abgelegte Speicher für Schlüssel/Wert-Paare wie Memcache oder Redis verwenden.
  • Die Latenz von Abfragen am Ende gegenüber externen Status-Caches stellt ein großes Problem dar. Zeitlimits für die Statusaktualisierung können nur schwer eingehalten werden, wenn 1 % oder selbst 0,1 % der Abfragen eine Latenz haben, die etwas größer ist als das Aktualisierungszeitlimit.
  • Die Bestimmung, welche Prozesse schreibgeschützten oder Lese-/Schreibvorrang gegenüber Objekten in dem externen Status-Cache haben, macht das Servermodell sehr komplex.

Die Lösung dieser Probleme hat jedoch mehrere vorteilhafte Nebenwirkungen. Ein erfolgreich externalisierter Status, der für viele Prozesse mit der richtigen Zugriffsverwaltung verfügbar ist, kann die Möglichkeit zur Berechnung von Teilen der Spielstatusaktualisierung im Parallelverfahren wesentlich vereinfachen. Er ist bei der Migration von Entitäten zwischen Instanzen ähnlich vorteilhaft.

Dedizierte Spieleserverlösungen in der Cloud Platform

In den folgenden Artikeln wird beschrieben, wie Sie dedizierte Spieleserver in der Cloud Platform ausführen.

Back-End

Back-End-Dienste bieten nur Schnittstellen zu anderen Front-End- und Back-End-Diensten. Externe Clients können nicht direkt mit einem Back-End-Dienst kommunizieren. Back-End-Dienste ermöglichen im Allgemeinen das Speichern und Abrufen von Daten, wie Spielstatusdaten in einer Datenbank, oder Logging- und Analyseereignisse in einem Data Warehouse.

Spieledatenbank

Zu den Szenarien, die zu einer Abwanderung von Spielern führen können, gehören ausfallende Server und verlorener Spielfortschritt. Leider sind beide Szenarien möglich, wenn die Datenbankebene nicht sorgfältig konzipiert wurde.

Die Datenbank, die den Spielweltstatus und die Daten des Spielfortschritts enthält, wird als der kritischste Teil der Spieleinfrastruktur betrachtet.

Sie sollten gewährleisten, dass die Datenbank nicht nur die erwartete Arbeitslast bewältigen kann, sondern auch die Arbeitslast, die anfällt, wenn Ihr Spiel zu einem Riesenerfolg wird. Ein Back-End, das für eine geschätzte Spielerbasis konzipiert und getestet wird, jedoch plötzlich eine ungleich größere Arbeitslast bewältigen muss, kann sehr wahrscheinlich nicht alle Spieleranforderungen zuverlässig erfüllen. Wenn ein unerwarteter Erfolg nicht mit eingeplant wird, kann Ihr Spiel zu einem Flop werden, weil Spieler das Spiel verlassen, wenn es wegen Datenbankproblemen nicht mehr spielbar ist.

Spiele sind für dieses Problem besonders anfällig. Die meisten Geschäfte mit einem erfolgreichen Produkt können ein schrittweises, organisches Wachstum erwarten. Ein typisches Spiel sieht sich jedoch mit einem starken anfänglichen Interesse, gefolgt von einem schnellen Abfall auf eine wesentlich niedrigere Nutzung konfrontiert. Wenn Ihr Spiel ein Erfolg ist, kann eine überforderte Datenbank zu massiven Verzögerungen vor dem Speichern des Nutzerfortschritts führen, oder kann den Fortschritt insgesamt sogar gar nicht speichern. Kein Spieleentwickler möchte sich in einer Lage befinden, in der er entscheiden muss, welche Funktionen des Spiels keine Echtzeitaktualisierungen mehr unterstützen. Deshalb müssen die Datenbankressourcen sorgfältig geplant werden.

Beim Konzipieren einer Spieledatenbank müssen Sie Folgendes beachten:

  • Eine fundierte Entscheidung treffen. Während der Entwicklung sollten Sie möglichst keine Datenbank verwenden, weil sie einfach getestet werden kann und dann zur Produktionsdatenbank wird, ohne dass alle Optionen ausgewertet werden. Typ und Häufigkeit der Datenbankzugriffe Ihres Spiels mit der erwarteten Spielerbasis und einem Wert, der zehn Mal höher liegt als diese Schätzungen, müssen unbedingt berücksichtigt werden. Danach können Sie eine fundierte Entscheidung für das Back-End fällen, das diese Szenarien am besten bewältigen kann. Sie sollten vermeiden, sich in eine Situation zu bringen, in der Sie lernen müssen, wie Sie mit einer Datenbankkrise umgehen, wenn die Krise bereits da ist.
  • Nicht davon ausgehen, dass eine einzige Lösung die richtige Lösung ist. Es gibt keine Regel, die besagt, dass Sie nur einen Datenbanktyp ausführen können. Viele erfolgreiche Spiele speichern Konteninformationen und verarbeiten In-Game-Käufe mit einer relationalen Datenbank, während Spielstatusinformationen in einer separaten NoSQL-Datenbank gespeichert werden. Die NoSQL-Datenbank eignet sich besser zur Verarbeitung von umfangreichen Arbeitslasten mit niedriger Latenz, während die relationale Datenbank besser für garantierte Transaktionen verwendet wird.
  • Sicherung Ihrer Daten. Regelmäßige und geografisch verteilte Sicherungen sind für eine Wiederherstellung nach einem Datenbankfehler wichtig.

Relationale Datenbanken

Viele Spieleentwicklungsteams beginnen mit einer einzigen relationalen Datenbank. Wenn die Daten und der Traffic bis zu einem Punkt anwachsen, an dem die Datenbankleistung nicht mehr akzeptabel ist, wird im Allgemeinen als erstes die Datenbank skaliert. Wenn dann die Skalierung nicht mehr machbar ist, implementieren viele Entwickler eine benutzerdefinierte Datenbankdienstschicht. In dieser Schicht können Sie die Priorität von Abfragen festlegen und Ergebnisse im Cache speichern. Dies sind beides Vorgänge, die den Datenbankzugriff begrenzen. Durch Skalierung und Hinzufügen einer Datenbankdienstschicht können Sie ein Spiele-Back-End erzeugen, das eine große Anzahl von Spielern bewältigen kann. Diese Methoden können jedoch einige allgemeine Probleme enthalten:

  • Skalierung – Herkömmliche relationale Datenbanken verwenden bevorzugt eine vertikale Skalierungslösung. Bei der Planung eines cloud-nativen Spiele-Back-Ends wird jedoch unbedingt stattdessen eine horizontale Skalierungslösung empfohlen, weil die Anzahl von Kernen, die in einer einzelnen VM vorhanden sein können, immer begrenzt ist, während das Hinzufügen von zusätzlichen VMs zu dem Cloud-Projekt recht einfach ist. Relationale Datenbanken enthalten Muster zur horizontalen Skalierung, wie z. B. Fragmentierung, Clustering und abgestufte Replikate. Es kann jedoch schwierig sein, diese einer gerade ausgeführten Datenbank ohne Ausfallzeit hinzuzufügen. Wenn die Möglichkeit besteht, dass der Traffic oder die Daten den Rahmen einer einzelnen Datenbank sprengen, beginnen Sie mit einem kleinen Cluster. In diesem Fall müssen Sie nicht erst lernen, wie die Datenbank skaliert wird, wenn die Krise bereits da ist. Das Hinzufügen von Knoten zu einem Cluster, während dieses ausgeführt wird, stellt zwar auch Herausforderungen, ist jedoch machbar.
  • Schemaänderungen – Sehr wenig erfolgreiche Spiele beginnen mit einem Datenbankschema, das während der gesamten Lebensdauer des Spiels bestehen bleibt. Spieler fordern neue Funktionen und Inhalte, und wenn diese hinzugefügt werden, müssen neue Datentypen in der Datenbank gespeichert werden. Ganz am Anfang des Entwicklungsprozesses müssen Sie festlegen, wie Sie das Schema aktualisieren möchten. Wenn Sie versuchen, das Schema ohne einen festgelegten Prozess nach dem Start des Spiels zu aktualisieren, könnte es zu einer ungeplanten Ausfallzeit oder sogar zu einem Verlust von Spielerdaten kommen.
  • Administration – Die Skalierung einer gerade ausgeführten relationalen Datenbank und die Aktualisierung von deren Schema sind beides komplexe Vorgänge. Automatisch verwaltete relationale Datenbanken sind gängige Dienste von Cloudplattformen, für Spiele-Back-Ends sind sie derzeit jedoch nicht weit verbreitet. Dies ist auf die schreibintensiven Arbeitslasten von Spiele-Back-Ends zurückzuführen.

NoSQL-Datenbanken

Nicht-relationale Datenbanken können die Lösung für einen skalierten Betrieb bieten, insbesondere bei schreibintensiven Arbeitslasten. Dazu müssen Sie jedoch die NoSQL-Datenmodelle, Zugriffsmuster und Transaktionsgarantien verstehen.

Es gibt viele Typen von NoSQL-Datenbanken. Solche, die sich zur Speicherung des Spieleweltstatus eignen, haben folgende Merkmale:

  • Skalierung – Sie sind mit Blick auf die horizontale Skalierung konzipiert und verwenden diese auch häufig standardmäßig. Die Skalierung von Clustern kann im Allgemeinen ohne Ausfallzeit durchgeführt werden. Gelegentlich kommt es jedoch zu einem gewissen Leistungsverlust, bis die zusätzlichen Knoten vollständig integriert sind.

  • Schemaänderungen – Das Schema ist dynamisch und wird von der Anwendungsebene durchgesetzt. Dies ist ein großer Vorteil und bedeutet, dass ein neues Feld für ein neues Spielemerkmal auf einfache Weise hinzugefügt werden kann.

  • Administration – Die meisten Clouddienstleister bieten mindestens eine gehostete oder verwaltete NoSQL-Datenspeicher-Engine an, die Google Cloud Platform bietet mehrere.

Lösungen für Spieledatenbanken bei der Google Cloud Platform

Analyse

Die Analyse ist zu einer wichtigen Komponente bei modernen Spielen geworden. Sowohl Onlinedienste als auch Spieleclients können Analyse- und Telemetrieereignisse an eine gängige Sammelstelle senden. Dort werden die Ereignisse in einer Datenbank gespeichert. Sie können dann von jedem abgefragt werden, von Gameplay-Programmierern und -Designern bis zu Business Intelligence-Analytikern und Kundenservicemitarbeitern. Während die erfassten Analysen immer komplexer werden, müssen diese Ereignisse umso mehr in einem Format gehalten werden, das einfach und schnell abgefragt werden kann.

In den letzten zehn Jahren wurde Apache™ Hadoop® immer populärer. Das Open-Source-Framework basiert auf veröffentlichten Daten von Google. Durch die Erweiterung des Hadoop-Ökosystems werden immer mehr komplexe ETL-(Extrahieren, Transformieren und Laden-)Batchvorgänge verwendet, um Analyseereignisse zu formatieren und in ein Data Warehouse einzufügen. Die Verwendung von MapReduce hat die Zustellungsrate von anwendbaren Ergebnissen beschleunigt. Diese Geschwindigkeit wiederum hat neue, rechenintensive Analysevorgänge ermöglicht.

In der Zwischenzeit haben sich die in der Cloud verfügbaren Technologien weiterentwickelt. Viele von ihnen sind als verwaltete Dienste verfügbar, die schnell erlernt werden können und kein speziell abgestelltes Personal erfordern. Das neueste Streaming-ETL-Paradigma von Google bietet eine einheitliche Lösung sowohl für die Batch- als auch die Streamverarbeitung. Es ist als verwalteter Clouddienst und als Open-Source-Projekt Apache Beam verfügbar. Durch kontinuierliche Verbesserungen bei den Preisen für die Clouddatenspeicherung können jetzt sehr große Mengen von Logs und Analyseereignissen in umfangreichen, verwalteten Clouddatenbanken gespeichert werden, die das Schreiben und Lesen dieser Daten optimieren. Die neuesten Abfragemodelle für diese Datenbanken können Datenmengen im TB-Bereich innerhalb von Sekunden zusammenfassen. Ein Beispiel dafür finden Sie unter 50 Milliarden Wikipedia-Seitenaufrufe in 5 Sekunden analysieren.

Lösungen für Spieleanalyse bei der Google Cloud Platform

Weitere Informationen

Lösungen für Onlinespiele folgen einem gängigen Muster: Clients kommunizieren mit einem Front-End aus Diensten und Spieleservern, die mit einem Back-End für Analyse und Statusspeicherung kommunizieren. Sie können jede dieser Komponenten lokal, in der Cloud oder verteilt auf beide Möglichkeiten ausführen. Umfassendere Muster finden Sie in Spielelösungen.

  • Referenzarchitekturen, Diagramme, Anleitungen und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center