Seit über einem Jahr sorgt die Coronapandemie für tägliche Berichterstattung und vielerlei Einschränkungen. Kontakte werden auf ein Minimum begrenzt, Gastronomien und Großteile des Einzelhandels geschlossen und Freizeit- sowie Kulturveranstaltungen abgesagt. Mehr Zeit als je zuvor verbringen die Menschen in ihren eigenen vier Wänden und nutzen IT-Systeme, um im Home-Office zu arbeiten, über Lernplattformen zu lernen oder durch Videokonferenzsysteme soziale Kontakte herzustellen. Auch die dafür benötigten, cloudbasierten IT-Systeme erfahren dadurch Auslastungen, die zuvor nur schwer vorstellbar waren. Dieser Mehraufwand und die dafür erforderliche Skalierung der Systeme, sorgte im vergangenen Jahr 2020 für Ausfälle (Outages), von welchen auch die “Big-Player” des Cloud-Computings nicht verschont blieben. Einer Microsoft Azure Einschränkung im März folgte im November der Ausfall einiger AWS-Dienste des Cloud-Marktführers Amazon, ehe im Dezember zahlreiche Google-Dienste wie YouTube oder GoogleDrive für einige Stunden unerreichbar waren. Mögliche Ursachen solcher Ausfälle wurden bereits 2018 in Laura Nolans USENIX-Konferenzbeitrag “What Breaks Our Systems: A Taxonomy of Black Swans” thematisiert und in sechs Muster kategorisiert [2]. Der folgende Blogbeitrag stellt diese Kategorien, die Ursachen schwarzer Schwäne in IT Systemen dar (Seite 1), ordnet einige Ausfälle aus dem vergangenen Jahr in diese ein (Seite 2) und zeigt mögliche Präventionsmaßnahmen auf (Seite 3).
Black Swans in IT-Systemen
Black-Swan-Ereignisse wurden bereits 2007 von Nassim Nicholas Taleb im Buch “The Black Swan: The Impact of the Highly Improbable” [4] beschrieben und sind unvorhersehbare Ereignisse mit potenziell schwerwiegenden Folgen. Außerdem zeichnen sich diese durch ihre extreme Seltenheit und die weit verbreitete Denke aus, dass sie im Nachhinein offensichtlich waren. Bekannte Beispiele für Black-Swan-Ereignisse außerhalb der Informationstechnologie sind 9/11, die Bankenkrise 2008 oder, als aktuellstes Beispiel, auch die Coronapandemie. All diese Ereignisse waren so nicht vorhersehbar, hatten bzw. haben schwerwiegende Folgen und sind im Nachhinein – trotz der Seltenheit des einzelnen Ereignisses – eigentlich offensichtlich. Mit diesen Zusammenhängen und Mustern im Kontext großer, verteilter IT-Systeme, beschäftigt sich Laura Nolan und definierte an der USENIX-Konferenz 2018 folgende Muster für schwerwiegende Ausfälle:
Hitting Limit
Hitting Limit umschreibt Fehler, die durch Erreichen einer bestimmten Kapazität dazuführen, dass die Systeme ausfallen. Limits in Ultra-Large-Scale (ULS) Systemen können System-Ressourcen (z.B. RAM, Speicher etc.), logische Ressourcen (z.B. Puffergrößen) oder auch von Dateisystemen oder Providern definierte Limits sein (siehe Beispiel Instapaper 2017 [5]). Diese Limits gibt es an allen möglichen Stellen und es handelt sich dabei sehr oft um harte Limits, die oft nur schwer zu erweitern und manchmal auch unbekannt sind, weshalb diese Art der Ursache immer wieder zu Ausfällen der komplexen Systeme führt.
Spreading Slowness
Spreading Slowness (dt. Ausbreitungsverzögerung) beschreibt einen Ausfall des Systems durch verlangsamtes Verarbeiten von Aufrufen einer Ressource, die dann in der Masse dazuführen, dass das System kollabiert. Spreading Slowness kann demnach auch als ungeplante Slowloris-Attacke – z.B. 2009 bei den Präsidentschaftswahlen im Iran durchgeführt [6] – bezeichnet werden. Bei dieser DoS-Attacke (Denial of Service) werden Webserver durch kontinuierliche und parallele HTTP-Anfragen, die niemals abgeschlossen werden, lahmgelegt. Häufig treten Spreading-Slowness Probleme in Verbindung mit Microservices auf, wodurch Ausfälle von einzelnen Microservices, Spreading Slownes anderer Dienste herbeiführen (z.B. Spotify 2013 [7]). Spreading-Slowness ist dabei nicht auf die Anfragen eines Dienstes beschränkt und kann auch zwischen den verschiedenen Diensten eines Systems auftreten.
Thundering Herds
Thundering Herds (dt. Donnernde Herde) drückt den Zustand aus der entsteht, wenn in kurzer Zeit eine zu hohe Anzahl an Anfragen auf eine Ressource treffen und diese dadurch überlasten. Diese Art des Fehlers kann nahezu jeden Internetdienst betreffen, da es nie vorherzusehen ist, welche Anzahl an Anfragen zeitgleich auf einem System eintreffen. Bekannte Thundering Herds Beispiele sind Web-Shops, die eine große Anzahl an Besuchern zeitgleich aufrufen und dadurch überlasten (z.B. Black-Friday oder Neuerscheinungen im Shop). Oft kommen Thundering Herds jedoch nicht nur durch die große Anzahl der Benutzer oder Besucher eines Systems zu Stande, sondern auch durch die Systeme selbst. Beispiele hierfür sind große Batch-Jobs, die automatisiert ablaufen (z.B. MapReduce) oder Abhängigkeiten andere Dienste die – wie im Beispiel CircleCI 2015 [8] – dazuführen, dass Thundering Herds nach Zurückkehren eines zuvor ausgefallenen Dienstes auftreten.
Automation Interactions
Automatisierung ist ein zentraler Bestandteil aller Ultra Large Scale (ULS) Systeme und findet in vielerlei Bereichen der komplexen, verteilten System – oft im Zusammenspiel mit künstlichen Intelligenzen und Machine Learning – Verwendung. Automatisierte Skalierung der Serverressourcen in einer Cloud ist dabei genauso üblich, wie Netzwerk-Automatisierungen oder automatisierte Wartungsereignisse in Rechenzentren. Führen solche Automatisierungen zu einem Ausfall des Systems, fällt dies in die Unterkategorie der Automation Interactions. Diese Kategorie ist aufgrund der häufigen Automatisierung in ULS-Systemen auch im Zusammenspiel anderer Kategorien häufig Mitauslöser eines Black-Swans. So z.B. auch bei einem Reddit Outage 2016 [9], wodurch ein automatisierter Start des AutoScalers bei einer Zookeeper Migration zu einem 90-minütigen Ausfall führen sollte.
Cyberattacks
Sorgen Hacker oder andere Angreifer von außerhalb dafür, dass ein gesamtes System ausfällt, ist von Cyberattacks die Rede. Diese nutzen Schwachstellen der Informationssicherheit (Sicherheit der Systeme gegen externe Bedrohungen), um sich Zugriff zu einem System zu verschaffen, weiten diesen Zugriff aus und gefährden so das gesamte System. Gängige Attacke sind Denial of Service (DoS) Attacken, die gesamte Infrastrukturen lahmlegen oder Schadsoftware die – wie am Beispiel Emotet [10] – Zugriffe über ein gesamtes System erlangt, dieses verschlüsselt und die Opfer anschließend mit der Entschlüsselung erpresst.
Dependency Problems
Wachsen Systeme über einen langen Zeitraum, sind Abhängigkeiten zwischen einzelnen Teilsystemen kaum zu vermeiden. Führen solche Abhängigkeiten, beispielsweise bei einem “Reboot from Scratch” zu Problemen und einem Ausfall des Systems, ist dies in die Kategorie Dependency Problems einzuordnen. Beispiele hierfür sind Abhängigkeiten zwischen Speicher und Monitoring oder – wie im Beispiel GitHub 2016 [11] – Abhängigkeiten zwischen Redis-Clustern (Remote Dictionary Server Cluster für Caching, Sitzungen etc.) und dem Data Center. Ein, durch einen Stromausfall notwendiger, Neustart führte aufgrund der vorhandenen Abhängigkeit zu einem 2-stündigen Ausfall GitHubs, da das Data Center durch die vorhandene Abhängigkeit zu den ebenfalls heruntergefahrenen Redis-Clustern nicht mehr korrekt hochgefahren werden konnte.
Wie weitreichende IT-Systemausfälle aus dem vergangenen Jahr zu Stande kamen und wie diese in die beschriebenen Muster eingeordnet werden können, wird auf Seite 2 des Blogeintrags beschrieben.
Leave a Reply
You must be logged in to post a comment.