© saicle/Shutterstock.com
Reimplementierung eines Onlineshops für die Cloud

For the Cloud - Global skalieren


Im ersten Artikel haben wir einen grundsätzlichen Überblick über den neu zu implementierenden Onlineshop von Goodgame Studios gegeben. Der zweite Artikel fokussierte auf den Umgang mit großen Datenmengen und NoSQL-Datenbanken. In diesem Artikel wollen wir auf die Architektur und weitere besondere Bedingungen eingehen, die zu beachten sind, wenn man Software für den Einsatz in der Cloud schreibt.

Der Artikel ist dafür wie folgt aufgebaut: Zuerst beschreiben wir das Setting und die Herausforderung an unsere Verteilung. Daran anschließend gehen wir näher auf die technischen Details rund um Cloud-Rechenzentren ein. Danach zeigen wir das Zusammenspiel zwischen den Cloud-Regionen und beschreiben abschließend die Ausfallszenarien, denen wir uns nun stellen können, und die als Nächstes anzugehenden Anforderungen.

Das Setting

Mehr als 220 Mio. Nutzer greifen aus 230 Ländern (Google Analytics) auf unsere Systeme zu. Eine schnelle, weltweite Verfügbarkeit ist daher unsere primäre Anforderung. Die Netzwerklatenzen wären viel zu groß, wenn wir von einem zentralen Punkt aus unseren Onlineshop betreiben würden. Deshalb haben wir das System so konzipiert, dass es an vielen Orten der Erde gleichzeitig laufen kann, um möglichst nah am Endanwender zu sein.

28 Mio. Spieler kaufen in diesem Onlineshop Produkte. Insbesondere zu Rabattaktionen bedeutet das eine große Anzahl von Seitenabrufen. Der Onlineshop muss auch in dieser Situation zuverlässig und performant reagieren.

Die Herausforderung

Unsere Herausforderung ist es, mit der Shopfunktionalität in den Regionen der Kunden präsent zu sein, um einen zügigen Kaufvorgang zu ermöglichen – deswegen müssen wir die Shopapplikation auf einen verteilten Betrieb auslegen. Da es heutzutage unwirtschaftlich erscheint, eigene Rechenzentren in allen Kontinenten zu betreiben, bietet es sich an, Cloud-Dienstleistungen in Anspruch zu nehmen. Diese bieten ganz neue Möglichkeiten, zu Skalieren. Dafür müssen wir unsere Applikation Cloud-fähig machen. Cloud-fähig heißt dabei, wir können keine Annahmen darüber machen

  • an welchem Standort wir laufen

  • an wie vielen Standorten wir laufen

  • von wo der Nutzer mit uns kommuniziert

  • wie viele Nodes eines Typs laufen

Vielmehr müssen wir uns darüber hinaus darauf einstellen, dass

  • einzelne Systeme ausfallen können (und dürfen)

  • einzelne Standorte ausfallen

  • die gebuchten Rechner nur im Rahmen des Service-Level-Agreements Leistung erbringen (Speicher, CPU, I/O usw.)

  • Wartungsfenster des Cloud-Anbieters beachtet werden müssen

Verteilter Betrieb

Wir haben uns für einen verteilten Betrieb entschieden, damit wir regionsbezogene Lasten abfangen können und um Latenzen so gering wie möglich zu halten. Wir haben deshalb unterschieden zwischen lokal auftretenden Daten, die wir nur in der Region speichern, und weltweit notwendigen Daten, die wir synchron halten.

Alle anfallenden Kundendaten werden in Couchbase-Clustern gespeichert, die sich regionsübergreifend via Master-to-Master-Replikation aktuell halten.

Transaktionsdaten, die lokal in den Regionen anfallen, werden in einer MySQL-Datenbank gespeichert. Die Transaktionsdaten beinhalten u. a. Preis, Währung, gekaufte Artikel und zahlungsanbieterspezifische Informationen.

Als Programmiersprache und Applikationsplattform haben wir PHP gewählt. Ausschlaggebender Grund dafür war, dass wir bereits viel Erfahrung im Umgang damit gesammelt haben. Weiterhin eignet es sich hervorragend für einen verteilten Betrieb, da es sich in der FastCGI-Variante (wir haben uns für PHP-FPM entschieden) extrem stark auf die eigenen Bedürfnisse anpassen lässt.

Technische Details

Da wir PHP als Programmiersprache gewählt haben und sowohl eine Verteilung in Cloud-Regionen als auch eine Verteilung auf verschiedene Maschinen eines Clusters umsetzen wollen, um Lasten abzufangen, müssen wir eine Reihe technischer Probleme lösen. Dazu zählt zu allererst die Implementierung als Stateless Application, damit wir bei einem folgenden Seitenaufruf nicht gezwungen sind, auf demselben Server die Anfrage weiterzuverarbeiten. Wir müssen den Zustand, der die Sitzung des Anwenders beschreibt, auslagern. Dies kann durch Cookie-Nutzung und durch geschicktes URL-Rewriting bzw. Query-Parameter umgesetzt werden.

Während die Regionszuordnung relativ statisch ist – ein Nutzer aus Nordamerika wird mit hoher Wahrscheinlichkeit immer wieder in Nordamerika im Rechenzentrum landen – ist die Zuordnung auf eine Webnode eines Cloud-Rechenzentrums nicht garantiert. Der Load Balancer wird die Session nach seinem Verteilungsschema den Rechnern zuordnen.

Ein problematischer Aspekt an Sessions ist, dass sie standardmäßig auf dem Webserver gespeichert werden, auf dem sich der Benutzer befindet. Ist dies der Fall, müssen im Load Balancer sticky Sessions aktiviert werden, was zur Folge hat, dass derselbe Benutzer innerhalb eines Zeitfensters auf dieselbe Webnode geschickt wird.

Zwingt man den Load Balancer mit sticky Sessions zu arbeiten, dann entsteht eine Ungleichverteilung. In Abbildung 1 sieht man bis zu 10 Pr...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang