Wieder einmal haben Amazon Web Services (AWS) das Internet kaputt gemacht oder besser „ein Tippfehler“. Am 28. Februar 2017 hat ein Ausfall von Amazon S3 in AWS’ ältester Cloud-Region US-EAST-1 zahlreiche bekannte Webseiten und Services vom Internet getrennt, darunter Slack, Trello, Quora, Business Insider, Coursera und Time Inc. Andere Nutzer berichteten zudem, dass sie nicht in der Lage waren, Endgeräte zu steuern, die mit dem Internet of Things verbunden waren, da das IFTTT ebenfalls von dem Ausfall betroffen war. Wie man sieht, werden diese Art von Ausfällen zu einer zunehmenden Bedrohung für unsere digitale Ökonomie. Um solchen Situationen vorzubeugen, sollten Cloud-Nutzer ständig das Shared-Responsibility Modell der Public Cloud berücksichtigen. Allerdings existieren ebenfalls Mittel und Wege, wie eine Artificial Intelligence (AI) dabei helfen kann. Dieser Artikel beschreibt, wie eine AI-defined Infrastructure bzw. eine AI-powered IT-Managementlösung dabei helfen kann, Ausfälle von Public Cloud-Anbietern zu vermeiden.

Der Amazon S3 Ausfall – Was war passiert?

Nach einem Ausfall veröffentlicht AWS immer eine Zusammenfassung der entstandenen Probleme, damit nachvollzogen werden kann, was passiert ist. Der nachfolgende Abschnitt beschreibt im Original die Ereignisse am Morgen des 28. Februar.

Weitere Informationen finden sich unter “Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region”.

“The Amazon Simple Storage Service (S3) team was debugging an issue causing the S3 billing system to progress more slowly than expected. At 9:37AM PST, an authorized S3 team member using an established playbook executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process. Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended. The servers that were inadvertently removed supported two other S3 subsystems.  One of these subsystems, the index subsystem, manages the metadata and location information of all S3 objects in the region. This subsystem is necessary to serve all GET, LIST, PUT, and DELETE requests. The second subsystem, the placement subsystem, manages allocation of new storage and requires the index subsystem to be functioning properly to correctly operate. The placement subsystem is used during PUT requests to allocate storage for new objects. Removing a significant portion of the capacity caused each of these systems to require a full restart. While these subsystems were being restarted, S3 was unable to service requests. Other AWS services in the US-EAST-1 Region that rely on S3 for storage, including the S3 console, Amazon Elastic Compute Cloud (EC2) new instance launches, Amazon Elastic Block Store (EBS) volumes (when data was needed from a S3 snapshot), and AWS Lambda were also impacted while the S3 APIs were unavailable.”

Unterm Strich lässt sich also sagen, dass ein „Tippfehler“ das AWS-angetriebene Internet in die Knie gezwungen hat. AWS-Ausfälle haben eine lange Geschichte und je mehr AWS-Kunden ihre Web-Infrastrukturen auf dem Cloud-Giganten betreiben, desto mehr Probleme werden Endkunden in der Zukunft erleben. Laut SimilarTech wird alleine nur Amazon S3 bereits schon von 152,123 Webseiten und 124,577 und Domains eingesetzt.

Folgt man allerdings der “Everything fails all the time“ Philosophie von Amazon.com CTO Werner Vogels, muss jeder AWS-Kunde das Konzept des “Design for Failure” berücksichtigen. Etwas, welches Cloud-Pionier und –Vorbild Netflix in Perfektion beherrscht. Als Teil davon hat Netflix beispielsweise seine Simian Army entwickelt. Eine Open-Source Toolbox, die jeder nutzen kann, um seine Cloud-Infrastruktur auf AWS hochverfügbar zu betreiben.

Netflix setzt hierzu „ganz simpel“ auf die beiden Redundanz-Ebenen die AWS bietet: Multiple Regions und Multiple Availability Zones (AZ). Multiple Regions sind die Meisterklasse, wenn man AWS einsetzt. Sehr kompliziert und anspruchsvoll, da hierbei autarke Infrastrukturumgebungen innerhalb der weltweit verteilten AWS Cloud-Infrastruktur voneinander isoliert aufgebaut und betrieben werden und im Ausnahmefall gegenseitig den Betrieb übernehmen. Multiple AZs sind der bevorzugte und „einfachste“ Weg, um Hochverfügbarkeit (HA) auf AWS zu erreichen. In diesem Fall wird die Infrastruktur in mehr als einem AWS-Rechenzentrum (AZ) aufgebaut. Hierzu wird eine einzige HA-Architektur in mindestens zwei – am besten mehr – AZs bereitgestellt. Ein Load-Balancer sorgt anschließend für die Steuerung des Datenverkehrs.

Auch wenn „Tippfehler“ nicht passieren sollten, zeigt der letzte Ausfall erneut, dass menschliche Fehler weiterhin zu den größten Problemen während des Betriebs von IT-Systemen gehören. Hinzu kommt, dass man AWS nur bis zu einem gewissen Grad die Schuld geben kann. Schließlich existiert in der Public Cloud die Shared-Responsibility.

Shared Responsibility in der Public Cloud

Ein entscheidendes Detail der Public Cloud ist das Self-Service-Modell. Die Anbieter zeigen sich, je nach ihrer DNA, nur für bestimmte Bereiche verantwortlich. Für den Rest ist der Kunde selbst zuständig.

In der Public Cloud geht es also um die Aufteilung von Verantwortlichkeiten – auch als Shared-Responsibility – bezeichnet. Anbieter und Kunde teilen sich die Aufgabenbereiche untereinander auf. Die Eigenverantwortung des Kunden spielt dabei eine zentrale Rolle. Im Rahmen der IaaS-Nutzung ist der Anbieter für den Betrieb und die Sicherheit der physikalischen Umgebung zuständig, hierbei kümmert er sich um:

• den Aufbau der Rechenzentrumsinfrastruktur,
• die Bereitstellung von Rechenleistung, Speicherplatz, Netzwerk und einige Managed Services wie Datenbanken und gegebenenfalls andere Microservices,
• die Bereitstellung der Virtualisierungsschicht, über die der Kunde zu jeder Zeit virtuelle Ressourcen anfordern kann,
• das Bereitstellen von Services und Tools, mit denen der Kunde seine Aufgabenbereiche erledigen kann.

Der Kunde ist für den Betrieb und die Sicherheit der logischen Umgebung verantwortlich. Hierzu gehören:

• der Aufbau der virtuellen Infrastruktur,
• die Installation der Betriebssysteme,
• die Konfiguration des Netzwerks und der Firewall-Einstellungen,
• der Betrieb der eigenen Applikationen und selbstentwickelter (Micro)-Services.

Der Kunde ist somit für den Betrieb und die Sicherheit der eigenen Infrastrukturumgebung und den darauf betriebenen Systemen, Applikationen und Services sowie den gespeicherten Daten verantwortlich. Anbieter wie Amazon Web Services oder Microsoft Azure stellen dem Kunden jedoch umfangreiche Tools und Services zur Verfügung mit denen sich zum Beispiel die Verschlüsselung der Daten als auch die Identitäts- und Zugriffskontrollen sicherstellen lassen. Darüber hinaus existieren zum Teil weitere Enablement-Services (Microservices) mit denen der Kunde schneller und einfacher eigene Applikationen entwickeln kann.

Der Cloud-Nutzer ist in diesen Bereichen also vollständig auf sich alleine gestellt und muss selbst Verantwortung übernehmen. Allerdings lassen sich diese Verantwortungsbereiche auch von einem AI-defined IT-Managementsystem bzw. einer AI-defined Infrastructure übernehmen.

Eine AI-defined Infrastructure kann helfen Ausfälle zu vermeiden

Eine AI-defined Infrastructure kann dabei helfen, Ausfälle in der Public Cloud zu vermeiden. Die Basis für diese Art von Infrastruktur liegt eine General AI zu Grunde, welche drei typische menschliche Eigenschaften vereint, mit denen Unternehmen in die Lage versetzt werden, ihre IT- und Geschäftsprozesse zu steuern.

• Verstehen (Understanding): Mit dem Erstellen einer semantischen Landkarte (bestehend aus Daten) versteht die General AI die Welt, in welcher sich das Unternehmen mit seiner IT und dem Geschäftszweck befindet.
• Lernen (Learning): Anhand von Lerneinheiten erhält die General AI die Best Practices und Gedankengänge von Experten. Hierzu wird das Wissen in granularen Stücken (Knowledge Items) vermittelt, welche einen separaten Teil eines Prozesses beinhalten.
• Lösen (Solving): Mit dem Konzept des “Machine Reasoning” lassen sich Probleme in unklaren und insbesondere sich ständig verändernden Umgebungen lösen. Die General AI ist damit in der Lage, dynamisch auf den sich fortwährend wechselnden Kontext zu reagieren und den besten Handlungsablauf zu wählen. Anhand von Machine Learning werden die Ergebnisse basierend auf Experimenten optimiert.

Im Kontext eines AWS-Ausfalls würde dies dann in etwa so ausschauen:

• Verstehen (Understanding): Die General AI erstellt eine semantische Landkarte der AWS-Umgebung als Teil der Welt in welcher sich das Unternehmen befindet.
• Lernen (Learning): IT-Experten erstellen Knowledge Items während sie die AWS-Umgebung aufbauen und damit arbeiten und lernen der General AI damit Best Practices. Damit bringen die Experten der General AI kontextbezogenes Wissen bei, welches das „Was“, „Wann“, „Wo“ und „Warum“ beinhaltet – z.B., wenn ein bestimmter AWS-Service nicht antwortet.
• Lösen (Solving): Basierend auf dem angelernten Wissen reagiert die General AI dynamisch auf Vorfälle. Damit ist die AI (möglicherweise) in der Lage zu wissen, was sie in einem bestimmten Moment zu tun hat – auch dann, wenn eine Hochverfügbarkeitsumgebung nicht von Beginn an berücksichtigt wurde.

Natürlich ist alles, was oben beschrieben wird, keine Magie. Wie jeder neu geborene Organismus bzw. jedes neu entstandene System muss auch eine AI-defined Infrastructure angelernt werden, um anschließend autonom arbeiten zu können und Anomalien als auch Ausfälle in der Public Cloud eigenständig zu entdecken und lösen zu können. Hierfür ist das Wissen von Experten erforderlich, die über ein tiefgreifendes Verständnis von AWS und wie die Cloud im Allgemeinen funktioniert, verfügen. Diese Experten bringen der General AI dann ihr kontextbezogenes Wissen bei. Sie lernen die AI mit kleinen Wissensstücken (Knowledge Items, KI) an, die sich von der AI indizieren und priorisieren lassen. Der Kontext und das Indizieren erlauben es der General AI die KIs zu kombinieren und damit unterschiedliche Lösungsansätze – Domain-übergreifend – zu finden.

KIs die von unterschiedlichen Experten erstellt werden, führen zu einem Wissenspool, aus welchem anhand des „Machine Reasoning“ die bestmöglichen Wissenskombinationen zusammengeführt werden, um Lösungen zu finden. Je mehr Aufgaben über die Zeit durchgeführt werden, führt diese Art des kollaborativen Lernens zu einer besseren Bearbeitungszeit. Weiterhin steigt die Anzahl möglicher Permutationen exponentiell mit der Menge an hinzugefügten Wissens an. Verbunden mit einem Knowledge Core, optimiert die General AI kontinuierlich ihre Leistung, indem sie nicht notwendige Schritte beseitigt und anhand des kontextbasierten Lernens zudem Lösungswege verändert. Je größer der semantische Graph und der Knowledge Core werden, desto besser und dynamischer kann die Infrastruktur im Kontext von Ausfällen agieren.

Zu guter Letzt sollte niemals der Community-Gedanke unterschätzt werden! Unser Research bei Arago zeigt, dass sich Basiswissen in 33 Prozent überschneidet. Dieses kann und wird außerhalb von bestimmten Organisationsumgebungen eingesetzt – z.B. über unterschiedliche Kundenumgebungen hinweg. Die Wiederverwendung von Wissen innerhalb einer Kundenumgebung beträgt 80 Prozent. Somit ist der Austausch von Basiswissen innerhalb einer Community ein wichtiger Bestandteil, um die Effizienz zu steigern und die Fähigkeiten einer General AI zu verbessern.