© Rovio

Dank der Skalierbarkeit von Amazons Webdiensten brechen der Angry-Birds-Shop und seine Datenbanken auch beim Massenanflug der Vogelliebhaber nicht zusammen.

Bekannt geworden ist Rovio 2009 mit einem kleinen Spiel, das zuerst als Smartphone-App erschien. Darin ließen verärgerte Vögel unter vollem Federeinsatz Gebäude kollabieren. Heute machen die Finnen vor allem mit T-Shirts, Plüschtieren und Schlüsselanhängern den größten Teil ihres Umsatzes. Ihren Angry-Birds-Webshop in der Cloud besuchen bis zu eine Million Nutzer am Tag. Zu Spitzenzeiten sind 5000 Besucher zugleich online und das System verarbeitet mehrere Bestellungen pro Sekunde.

Rovio setzt dabei auf Magento, die Open-Source-Anwendung für E-Commerce, und kombiniert sie mit Amazons Web Services (AWS), um den Shop auch in ruhigeren Zeiten wirtschaftlich zu betreiben. Rovios Magento-Universum besteht aus dem Shop mit seinen Store-Frontends für Europa, Asien und Amerika. Auch ERP und Warenwirtschaft wickeln die Finnen komplett mit Magento ab.

Extern angebunden sind die weltweite Lagerverwaltung, der Versand, ein DRM-Server für die Lizenzvergabe bei Spielen, ein E-Mail- und Geschenkkartendienst sowie der Bezahlservice Braintree.

Stets wie neu

Während viele Onlineshop-Betreiber die Last auf ihrem System gut kalkulieren können, muss der Rovio-Shop beim Veröffentlichen neuer Spieleversionen, neuer Merchandising-Artikel oder nach Facebook-Aktionen oft ein sehr hohes Besucheraufkommen verarbeiten.

Zu Beginn des Projekts beschloss Rovio daher, zusammen mit dem Webteam von AOE Media, den Angry-Birds-Shop in Form agiler Software-Entwicklung zu betreiben und fortlaufend neue Releases einzuspielen – das Stichwort lautet Continuous Deployment. Das bedeutet, eine Webseite wie ein Softwareprojekt regelmäßig neu zu generieren und automatisch sowie manuell zu testen: Bei jeder Änderung baut das System die Webseite komplett oder teilweise neu.

Voraussetzung dafür ist ein ausgefeiltes System für die automatische Qualitätssicherung und Bereitstellung. Auch Rollbacks muss es beherrschen, damit neue Funktionen, Module, Layoutänderungen und Templates binnen Minuten auf Test- und Produktivsystemen landen.

Schnelltest im Backshop

Im Fall des Rovio-Shops holen sich die Entwickler vor Aufnahme der Arbeit die aktuelle Version aus dem Systemspeicher, den das Produktivsystem über Nacht füllt. Änderungen an der Webseite fließen zurück in eine Versionsverwaltung. Die veränderte Seite wird dann mit Bildern und Texten der Seitenbetreiber zusammengeführt, die im Backup-Storage warten.

Nach ersten Unit-Tests installieren die Entwickler die Seite auf dem so genannten Latest System, wo weitere Tests folgen (Abbildung 1). Sie wird dann auf einen Staging-Server in die S3-Cloud geschoben und landet, nach letzten Integration Tests, auf dem Produktivsystem. Sämtliche Builds der Webseite, egal ob automatische oder manuell unterstützte, übernimmt der freie Continuous Integration Server Jenkins CI [1].

Abbildung 1: Mit Hilfe eines automatisierten Test- und Buildsystems wird Rovios Shop verändert, intensiv getestet und dann in die Cloud geschoben.

AWS zu Diensten

Die ganze Infrastruktur des Angry-Birds-Shops läuft virtualisiert auf Basis von Amazons Webdiensten. Die stellen etwa per Knopfdruck Datenbanken (MySQL, Oracle, MS SQL Server) in verschiedenen Versionen bereit und bieten auch die Option, automatisch die Upgrades auf Minor-Versionen einzuspielen.

Die Kapazität der Datenbankserver lässt sich nach erfolgtem Setup flexibel anpassen, was aber Ausfallzeiten verursacht – es dauert etwa 10 Minuten, bis eine neue Datenbankinstanz läuft. Auf Knopfdruck lassen sich Snapshots erzeugen, aus denen man bei Bedarf neue Datenbanken generiert.

Amazon erstellt zugleich permanent Backups der letzten Versionen. Über »Restore point in time« lassen sich frühere Zustände wiederherstellen. Zudem garantiert das Unternehmen hohe Redundanz und Ausfallsicherheit, Konfigurierbarkeit der Security Group [2] zum Absichern der Datenbank nach außen und eine garantierte Anzahl an I/O-Operationen pro Sekunde (Provisioned IOPS). Das schafft eine sehr gute Basis für einen vollständig virtualisierten Webshop. Cloudwatch [3], das integrierte Monitoringtool, gibt zu jedem Zeitpunkt einen umfassenden Überblick über den Zustand des Systems.

Read Replicas

In Amazons Cloud nutzt der Shop den Amazon Relational Database Service (RDS), der das Einrichten, Betreiben und Skalieren relationaler Datenbanken enorm vereinfacht [4]. Er lässt sich über die AWS Management Console, die Benutzeroberfläche für AWS, konfigurieren. Bei leseintensiven Zugriffen – und die kommen weit häufiger vor als Schreibzugriffe – legt der Admin zum Beispiel über »Create Read Replica« mehrere Slave-Datenbankinstanzen an (Abbildung 2). Die orientieren sich am Master-Slave-Replikationsmodell von MySQL [5], Rovio nutzt solche Read Replicas jedoch ausschließlich zur Reportgenerierung.

Abbildung 2: Read Replicas von Datenbanken lassen sich per Knopfdruck einrichten und federn die Last auf die Masterinstanz ab.

Die Read Slaves verhindern, dass beim Generieren der Reports Datenbanklocks und Deadlocks auftreten, indem sie eine Art Load Balancing einführen. Updates der Datenbank landen so erst auf der Masterinstanz und werden dann asynchron an die Read Slaves verteilt.

Caching

Doch auch Caching entlastet den Ansturm auf die Datenbank von Magento. Die hohe Verfügbarkeit des Shops bei gleichzeitiger Minimierung der Datenbankabfragen gelingt durch den Einsatz von Varnish Cache [6]. Der Dienst ist für das Load Balancing zuständig: Er nimmt überlastete Server, die zu langsam oder gar nicht mehr reagieren, aus dem Load Balancing heraus und ersetzt sie vollautomatisch durch neue Instanzen.

Die AOE-Entwickler haben zudem einen Großteil des Rovio-Shops statisch gebaut, was ihn sehr gut auf den Caching-Einsatz vorbereitet. Indem er den Browsercache und einen Reverse-Proxy-Cache geschickt nutzt, übernehmen die Clients viel Arbeit. Lediglich Warenkörbe, Bezahlfunktionen und Nutzerprofile generiert der Shop dynamisch.

Kommen tatsächlich 5000 Besucher auf einmal in den Shop, fragt Varnish Cache beim Backend nur einmal pro Seite und Lebenszeit des Cache (TTL) an und liefert ansonsten die vorgehaltenen Inhalte an die Besucher aus. Nur dynamische Anfragen lässt Varnish zu Magento durch, was die Geschwindigkeit insgesamt um etwa das 400-fache erhöht.

Auch die Applikation bietet Optimierungspotenzial: Reduzieren der Loglevel, Abschalten von Logging-Funktionen und das regelmäßige Aufräumen von Daten (Logs, abgelaufene Cache-Inhalte) sorgen für einen Geschwindigkeitsschub.

Um die Hauptdatenbank zu entlasten, arbeiteten die Entwickler des Shops ursprünglich mit einer separaten Datenbank, bis sie das Cache-Backend irgendwann durch Redis ersetzten. Die NoSQL-Datenbank legt Schlüssel-Wert-Paare direkt im Arbeitsspeicher ab und beschleunigt so die Zugriffe.

Amazons Datenbanken einrichten

Die Konfiguration von Amazons Datenbankdiensten klappt über die Management Console recht komfortabel. Neue Instanzen lassen sich einfach starten und die Datenbank samt Versionsnummer auswählen (Abbildung 3).

Abbildung 3: Die Infrastruktur in AWS lässt sich über eine einfache Weboberfläche einrichten, die Management Console.

Die Security Groups regeln den Zugriff auf die Instanzen, was für die nötige Sicherheit sorgt. Über die Parameter Groups passt der Admin bei Bedarf einzelne Konfigurationsparameter der Datenbank an. Ist AWS eingerichtet, legt er Datenbankparameter wie Host, Benutzer und Passwort spezifisch für die jeweilige Umgebung (etwa Production oder Staging) fest und aktiviert sie dann für den Onlinezugriff. Für Magento macht es am Ende keinen Unterschied, ob die eigene Datenbank in einer virtuellen Umgebung wie dem RDS von Amazon läuft oder auf einem dedizierten Server.

Der Import der Daten in die Cloud funktioniert wie gewohnt, zum Beispiel über einen MySQL-Client. Das System ist jedoch durch eine gewisse Statik seitens der Datenbank begrenzt. Überraschende Besucheranstürme kann es nicht dynamisch abfangen, auch wenn die Application Server automatisch skalieren. Die Bedürfnisse sollte man daher im Vorfeld projektbezogen korrekt kalkulieren, da Änderungen im laufenden Betrieb eine Downtime mit sich bringen. Zur Verfügung stehen Instanzgrößen zwischen 5 und 3370 GByte Speicherplatz mit wählbarer CPU-Leistung und RAM.

Neu bei Amazon ist eine Option für garantierte I/O-Leistung [7], die zwar Mehrkosten verursacht, aber eine deutlich bessere Performance aufweist. Für weitere Ausfallsicherheit und einen nahtlosen Betrieb ohne Downtimes sorgen die Standby Replicas [8], die Amazon automatisch in getrennten Rechenzentren, den so genannten Availability Zones (AZ), anlegt. Sie ermöglichen es, geplante Wartungsfenster für die Datenbank abzufangen und zu kompensieren. Beim Ausfall der Haupt-AZ springt automatisch die Standby-Datenbank in einer anderen Zone ein (Hot Standby), sodass der Betrieb ohne Eingriffe weiterläuft.

Das komplette Ensemble

Abgerechnet wird bei den Webdiensten pro Stunde Laufzeit, die sich je nach Größe der genutzten Datenbank-Instanz-Klasse unterscheiden [9]. Beim Angry-Birds-Shop kommen dabei weltweit unterschiedliche Dienste zum Einsatz: EC 2 (Elastic Cloud 2) fährt virtualisierte Server hoch oder runter. S3 speichert Daten, etwa Bilder, die er langfristig aufbewahrt und an die verschiedenen Server verteilt. RDS verwaltet Datenbanken, Cloud-Front liefert Produktbilder oder Skins möglichst schnell aus. Elastic Load Balancing (ELB) verteilt den Traffic und kümmert sich um die SSL-Terminierung, während der DNS-Service Route 53 für Server-übergreifende statische IP-Adressen sorgt.

Unterteilt man die Server noch in Gruppen (Arrays), ergibt sich ein Gesamtbild für Rovios AWS-Cloudarchitektur (Abbildung 4). Die im grünen Bereich gezeigte Deploy-Infrastruktur betreiben die Entwickler gleich doppelt – einmal mit der neuen und einmal mit der vorherigen Version des Shops. Bei einem Rollback auf eine ältere Version, genügt es, Amazons DNS-Service Route 53 [10] umzuschalten.

Abbildung 4: Der Angry-Birds-Shop ist in eine komplizierte Struktur aus Diensten eingebunden, um auch Lastspitzen auszuhalten.

Als Frontend-Array kommen ansonsten nur die Magento-Server (und die dazugehörigen Datenbanken) zum Einsatz. Sicherheitshalber gibt es jedoch redundante Server – fällt einer aus, muss ein anderer nicht erst hochfahren. Die Aufgabe des Frontend-Array besteht darin, alle dynamischen Requests (Warenkörbe, Sitzungen, Accounts) zu verarbeiten und die Besucher zur Kasse zu führen. Das Varnish-Array besteht aus zwei EC-2-Instanzen, auf denen das Caching läuft – der zweite Server dient ebenfalls der Ausfallsicherheit. Das Backend-Array verwaltet auf einem Server die Rovio-Produkte in Magento. Schließlich verarbeitet ein Worker-Array alle Hintergrundprozesse.

Fazit

Mit dem nötigen Kleingeld erlaubt AWS den Aufbau von Shops, die bei Lastspitzen nicht mehr in die Knie gehen. Der Shopbetreiber muss keine Verkaufsausfälle befürchten, der Admin hat weniger Arbeit mit der Datenbank. Läuft der Verkauf ruhiger, lassen sich die Ressourcen manuell oder automatisch zurückfahren. Auch auf den Einsatz freier Software muss man nicht verzichten.

Zugleich schafft die Kombination aus AWS und einem Magento mit replizierten Datenbanken eine skalierbare und stabile Lösung. Gebäude zum Einsturz bringen soll schließlich allein die Aufgabe der Angry Birds bleiben.