Erinnerung zum Start von Pokémon Go: Warum „Auf Skalierbarkeit ausgelegt“ genauso wichtig ist wie „Auf Ausfälle ausgelegt“

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Eines der Schlagwörter rund um DevOps und Cloud lautet seit, ach, vielen Jahren „Build to Fail“. Dahinter steht die Annahme, dass zu viele Unternehmen aufgrund kapazitätsbedingter Leistungsprobleme mit kostspieligen Ausfallzeiten sowie Umsatz- und Produktivitätseinbußen konfrontiert sind. Deshalb sollten Sie Ihre Anwendung und Infrastruktur so konzipieren, dass Ausfälle einkalkuliert sind, damit solche schaurigen Ereignisse Sie nicht erneut heimsuchen. Hehe. Haben Sie das Wortspiel bemerkt? Ja, ich arbeite allein im Homeoffice. Manchmal muss ich mich eben selbst unterhalten.

Abgesehen von den schlechten Wortspielen führte der jüngste phänomenale Erfolg von Pokémon Go (Sie haben doch davon gehört, oder?) für viele zugleich zu einem äußerst frustrierenden Erlebnis. Besonders für Eltern mit völlig überdrehten Kindern, die SOFORT losziehen wollten, es aber nicht konnten, weil die Erstellung neuer Konten aufgrund der überwältigenden Nachfrage vorübergehend ausgesetzt und anschließend stark begrenzt wurde.

Nun könnten einige auf das Angebot von Amazon-CTO Werner Vogels verweisen, dem Unternehmen bei der Bewältigung seiner Kapazitätsprobleme zu helfen, und daraus schließen, dass es ursprünglich gar nicht „in die Cloud gegangen“ sei und genau darin das eigentliche Problem gelegen habe. Das setzt allerdings voraus, dass es tatsächlich nicht in die Cloud gegangen ist – und das ist für mich derzeit keineswegs eindeutig. Im Ernst: Laut den Aktualisierungen auf Wikipedia zum Augmented-Reality-Entwickler verarbeitet das System „mehr als 200 Millionen Spielaktionen pro Tag, während Menschen mit realen und virtuellen Objekten in der physischen Welt interagieren“. Ich denke, da können wir ihnen ein wenig Nachsicht entgegenbringen – zumindest diejenigen unter uns, die verstehen, was das im Hinblick auf Systeminteraktionen und die Übertragung von Datenpaketen bedeutet. In den Aktualisierungen war von „Serverproblemen“ die Rede, aber mal ehrlich: Wir alle wissen, dass „Server“ im Technikjargon für „15 verschiedene Komponenten steht, die über die App- und Netzwerkinfrastruktur verteilt sind“.

Wie dem auch sei, die grundlegende Erkenntnis ist nicht, dass die Cloud zwangsläufig besser mit unerwartetem Erfolg umgehen kann. Das mag durchaus der Fall sein, aber nicht, weil es sich um eine Cloud handelt. Sondern weil die Cloud nicht nur darauf ausgelegt ist, Ausfälle zu verkraften, sondern auch darauf, zu skalieren.

Ich kann nicht beurteilen, warum Niantic Labs nicht mit der Nachfrage Schritt halten konnte. Vielleicht mangelte es an Kapazitäten – in diesem Fall wäre die Cloud eine gute Wahl gewesen. Vielleicht waren aber auch die Apps und/oder die Infrastruktur nicht auf Skalierbarkeit ausgelegt – dann hätte die Cloud möglicherweise überhaupt nicht geholfen. Es geht hier wirklich nicht darum, gegen sie zu sticheln (kleines Wortspiel) oder ihnen vorzuhalten, was sie getan beziehungsweise nicht getan haben. Vielmehr sind sie ein perfektes Beispiel für die Realität in einer von Anwendungen geprägten Welt: Unternehmen sollten sich ebenso intensiv darauf vorbereiten, mit Ausfällen umzugehen, wie darauf, Erfolge zu bewältigen. Und zwar nicht nur allmähliche Erfolge, sondern auch einen schlagartigen Erfolg über Nacht wie bei Pokémon Go.

Denn wenn es passiert, möchten Sie nicht, dass dieses erfolgreiche Scheitern im ganzen Internet breitgetreten wird.

Eine häufige Ursache für Skalierbarkeitsprobleme sind Datenquellen. Langjährige Twitter-Nutzer werden sich daran erinnern, dass das soziale Netzwerk in seinen Anfangsjahren mit Problemen bei der Skalierbarkeit seiner Datenbanken zu kämpfen hatte. PayPal gehörte zu den ersten und entschiedensten Befürwortern des Shardings als Skalierungsstrategie, um die Herausforderungen durch die enorme Nutzerzahl zu bewältigen. Inzwischen hat sich diese Technik als allgemeiner Ansatz etabliert, der gleichermaßen auf Datenbanken, Performance-Dienste, und Anwendungen anwendbar ist. Als einer der Vorteile von NoSQL-Datenquellen gilt ihre bessere Skalierbarkeit im Vergleich zu herkömmlichen relationalen Datenbanken.

Eine weitere Ursache für Skalierbarkeitsprobleme liegt allein bei der Infrastruktur. Die automatische Skalierung in der Cloud setzt voraus, dass nicht nur automatisch zusätzliche Rechenressourcen bereitgestellt werden können, sondern auch die Kapazität des „App-Endpunkts“ erhöht werden kann. In jeder Architektur, die zur Kapazitätssteigerung auf Skalierung setzt, ist dafür eine Art Lastverteilungsdienst erforderlich. Werden die Rechenressourcen erweitert, müssen sie beim Lastverteilungsdienst registriert werden. Dies erfordert den Einsatz von APIs und Skripten sowie Automatisierung und Orchestrierung. Diese Komponenten müssen bereits vorhanden sein, bevor sie benötigt werden, da es andernfalls zu Verzögerungen kommt, wenn die Nachfrage eine Kapazitätserhöhung erfordert.

Die Einbindung eines Load-Balancing-Dienstes sollte für jede App-Architektur zwingend vorgeschrieben sein. Ein Load-Balancing-Dienst erfüllt dank seiner inhärenten Unterstützung für das Failover zwischen zwei Anwendungsinstanzen nicht nur die Anforderung, Systeme ausfallsicher zu konzipieren („Build to Fail“), sondern unterstützt auch die für den Erfolg notwendige Skalierbarkeit („Build to Scale“). Man sollte jedoch nicht glauben, es genüge, einer App (oder einem Microservice, wenn das Ihr Ansatz ist) einfach einen Load-Balancing-Dienst vorzuschalten. Für den IT-Betrieb ist es wichtig, die Automatisierung (Skripte) und Orchestrierung (Prozesse) einzurichten, die es der automatischen Skalierung ermöglichen, den Bedarf zu decken, sobald er entsteht. Bei der Skalierung geht es heute um Architektur, nicht um Algorithmen, und es ist wichtig, diese Architektur von Anfang an zu berücksichtigen, bevor die Architekturschulden so große Einschränkungen verursachen, dass Sie mit dem Vorhandenen auskommen müssen.

Ehrlich gesagt hat Niantic Labs gute Arbeit geleistet und seine Systeme ausfallsicher konzipiert. Bei Kapazitätsengpässen wurden freundliche Meldungen statt der üblichen HTTP-Statuscode-Seiten angezeigt, auf die ich häufig stoße. Sie waren humorvoll und für Kinder leicht zu lesen und zu verstehen (ich weiß das, weil mein achtjähriges Kind sie uns alle 20 Minuten vorgelesen hat). Womit das Unternehmen jedoch nicht gerechnet hatte, war der vielleicht unerwartete Erfolg. Das ist eine gute Erinnerung für uns alle, dass es genauso wichtig ist, Systeme skalierbar wie ausfallsicher zu konzipieren.

Denn wenn du es nicht tust, gewinnt Team Rocket.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie