Kolumne

DevOps Stories: Cloud bedeutet nicht NoOps

Konstantin Diener

© Software & Support

Das MusicStore-Team hat vor einigen Wochen ein paar neue Funktionen am Recommender live geschaltet. Durch diese Änderung sollen die Kunden bessere Vorschläge erhalten, welche Musik für sie interessant sein könnte. Manuela, die sich um den Support für MusicStore kümmert, wendet sich an die Kollegen im Raum.

Manuela: „Das ist seltsam. Es haben sich jetzt einige Kunden beschwert, dass der Recommender total langsam ist. Ich habe ihn gerade selbst mal aufgerufen. Ich finde auch, dass es sich viel langsamer anfühlt als vor zwei Wochen!“

Christian: „Was meinst du mit ‚fühlt sich viel langsamer an’?“

Manuela: „Ich rufe die Seite im Browser auf und es dauert deutlich über zehn Sekunden bis überhaupt eine Antwort kommt …“

Julia: „Ich habe gerade mal nachgesehen … am JavaScript-Frontend liegt es nicht. Der REST-Service antwortet einfach sehr langsam.“

Lukas: „Wir schauen mal rein …“

Lukas und Christian analysieren, warum der Service so langsam antwortet. Nach einer längeren Suche stellen sie fest, dass die Laufzeit einiger Datenbankabfragen offenbar der Grund für die schlechte Performance ist. Erik, der Product Owner, ist hinzugekommen und klinkt sich in das Gespräch ein.

Abb. 1: Das Produktteam diskutiert das aktuelle Problem

Lukas: „Die Datenbank für die Benutzeraktionen läuft am Anschlag.“

Erik: „Also die Datenbank, aus der die Vorschläge berechnet werden?“

Lukas: „Ja, die. Die Benutzer haben das Produkt fleißig verwendet, dadurch sind viele Daten entstanden, und die Datenbank verträgt das nicht mehr. Wir haben damals eine Instanz in der Cloud gestartet und die ist mittlerweile einfach deutlich zu klein. Noch dazu wird der Service von den Apps bombardiert und die Connections Pools sind rasend schnell leer.“

Erik: „Warum ist die so klein? Und warum fällt uns das erst auf, wenn die Benutzer sich beschweren – mit den langsamen Abfragen und den Connection Pools?“

Christian: „Die Instanz hat Martin in der AWS Console angelegt. Damals, als wir mit dem Recommender angefangen haben …“

Lukas: „… und wir haben bislang keine Performancekennzahlen oder Warnungen, wenn die Connection Pools leer laufen.“

Erik: „Lasst mich raten: Die Antwortzeiten der Services messen wir auch nicht?“

Lukas: „Nein.“

Erik: „Na, dann sollten wir das aber schleunigst nachholen …“

Keine Ops-Mitarbeiter heißt nicht, dass es keine Ops-Themen gibt

Durch moderne Cloud-Services wie Amazon Web Services, Google Cloud Platform oder Microsoft Azure ist der Umgang mit Infrastruktur wie Datenbanken, Servern und Storage in den letzten Jahren geradezu spielend leicht geworden. Wenige Mausklicks genügen, um z. B. eine neue Datenbankinstanz zu starten. Gleichzeitig beschäftigen sich immer mehr Firmen damit, ob sie ihre Applikation auf ein Cloud Hosting umstellen und ihre internen Betriebsteams einsparen sollten. Statt dieser internen Ops-Teams gibt es dann Ops-as-a-Service (Abb. 2, [1]).

Abb. 2: Modell „Ops as a Service“

Der einfacher gewordene Umgang mit der Infrastruktur und Ops-as-a-Service führt immer wieder dazu, dass Teams vergessen, dass damit nicht alle Ops-Aufgaben verschwunden sind. Natürlich erhalten sie Infrastrukturkomponenten, bei denen sie sich nicht mehr um kaputte Hardware und oft auch nicht mehr um ein entsprechendes Patch-Level bemühen müssen. Auf der anderen Seite gibt es eine Reihe von Aufgaben, die früher z. B. ein internes Betriebsteam übernommen oder von den Entwicklern eingefordert hat.

Der Betrieb fängt schon mit dem Deployment an

Das beste Beispiel ist die Datenbankinstanz, die Lukas und seinen Kollegen jetzt Kopfzerbrechen bereitet. Vor der Umstellung auf Ops as a Service mussten Datenbankinstanzen beim Betriebsteam immer „beantragt“ werden. Die Kollegen wollten ganz genau wissen, welche Parameter die neue Instanz haben solle. Mittlerweile ist der Prozess viel einfacher, hat aber auch dazu geführt, dass Martin die Instanz einfach von Hand über die Webkonsole angelegt hat. Es gibt keinerlei Dokumentation. Wenn das Team z. B. eine weitere Testumgebung braucht, müssen Lukas und seine Kollegen außerdem alle erforderlichen Komponenten ermitteln und wiederum von Hand anlegen.

Es ist gut vorstellbar, dass das Ausfüllen von Anträgen dem Team auf die Nerven gegangen ist und sie froh waren, als dieser lästige Schritt wegfiel. In ihrer Freude haben sie übersehen, dass die strukturierte Beschreibung von Infrastruktur eigentlich eine sinnvolle Sache ist (u. a. zu Dokumentationszwecken) und nur die manuelle Umsetzung dieser Beschreibung zeitraubend und nervig ist. Sinnvoller wäre es gewesen, statt der Anträge an das Betriebsteam nach der Umstellung einfach Beschreibungen in Form von Infrastructure-as-Code zu erstellen.

Gleichzeitig ist mit dem Betriebsteam eine Kontrollinstanz weggefallen. Niemand hat mehr die Aufgabe, zu überprüfen, ob zu allen Infrastrukturkomponenten entsprechende Beschreibungen existieren. Der Wegfall dieser Kontrolle erfordert eine größere Disziplin bei den Mitgliedern des Dev-(Ops-)Teams.

Das DevOps-Team muss der Anwendung regelmäßig „den Puls fühlen“

Der CTO von Amazon, Werner Vogels, hat den Satz „You build it, you run it“ geprägt. Er zeigt, dass automatisierte Deployments in Produktion und der konsequente Einsatz von Infrastructure-as-Code nur der Anfang sind. „You run it“ endet nicht damit, dass eine Änderung auf dem Produktivsystem deployt wird, sondern fängt dann erst an.

Im ehemaligen Betriebsteam gab es Datenbankadministratoren, die regelmäßig Performancekennzahlen gemessen haben. Diesen Kollegen wäre sehr viel früher aufgefallen, dass die Datenbank mit der gestiegenen Last nicht mehr zurechtkommt. Genauso hätte das Betriebsteam vermutlich früher gesehen, dass die Connection Pools ständig ausgeschöpft sind. Durch den Wegfall dieses Teams verschwinden die beschriebenen Tätigkeiten aber nicht. Das MusicStore-Produktteam muss sich nun selbst um ein Monitoring seiner Anwendung kümmern, um etwaige Schwachstellen frühzeitig zu erkennen.

Hierbei können Application-Performance-Monitoring-Tools helfen. Diese Tools sammeln kontinuierlich Performanceinformationen in der laufenden Anwendung. Die gesammelten Informationen lassen sich einerseits einsetzen, um Alarme festzulegen. Dauert z. B. ein Serviceaufruf länger als der definierte Schwellwert, wird ein Alarm ausgelöst und per E-Mail, Group-Chat-Tool oder SMS an die Entwickler geschickt. Da ein APM-Tool kontinuierlich Performanceinformationen über die Anwendung sammelt, kann ein solches Tool andererseits auch die Fehlersuche unterstützen. Lukas und Christian haben sich in diesem Fall vermutlich stundenlang durch Logdateien gewühlt und Timestamps miteinander verglichen, oder versucht, das Problem auf einer Testumgebung nachzustellen. Mit den Informationen aus einem APM-Tool hätten sie wahrscheinlich nur wenige Klicks gebraucht, um die Datenbank als Engpass zu identifizieren.

DevOpsCon Dossier 2018

Free: 40+ pages DevOps knowledge by experts

Learn about Docker, Kubernetes, Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Kai Tödter (Siemens), Nicki Watt (OpenCredo), Tobias Gesellchen (Europace AG) and many more.

Infrastrukturprobleme nicht nur frühzeitig identifizieren, sondern verhindern

Ein geeignetes Monitoring hilft dem Team also, schneller Probleme mit der Infrastruktur zu erkennen, beispielsweise, dass die Datenbank an ihrer Belastungsgrenze arbeitet. Genaugenommen ist es zu diesem Zeitpunkt aber schon zu spät: Es existiert bereits ein Problem. Die Datenbank ist überlastet, weil die Menge der darin gespeicherten Daten rasant gewachsen ist. Bis Manuela sie auf die schlechte Performance des Recommenders hingewiesen hat, wussten sie von diesem Wachstum nichts, und dass die Mobile-Apps den Service mit Anfragen bombardieren, wurde ihnen auch erst durch die Fehlersuche klar.

Neben dem reinen Monitoring der Infrastruktur ist es also sinnvoll, Metriken zur Anwendung zu sammeln und auszuwerten:

  • Wie viele Benutzer kommen täglich dazu?
  • Wie viele sind es insgesamt?
  • Wie viele Aktionen haben die Benutzer an diesem bzw. am letzten Tag durchgeführt?
  • Wie viele Aktionen wurden bislang insgesamt durchgeführt?
  • Wie viele Benutzer verwenden die Apps im Moment?
  • Wie viele Zugriffe der Apps gab es in der letzten Stunde?
  • Gibt es Endgeräte, von denen besonders viele Zugriffe kommen?

Diese Metriken erlauben es dem Team, Engpässe zu erkennen, bevor daraus konkrete Probleme entstehen („Wenn die Datenmenge weiter so wächst wie in den letzten zwei Wochen, müssen wir spätestens in drei Wochen die Datenbankinstanz vergrößern.“). Darüber hinaus können die Metriken dem Team aber auch noch an anderen Stellen helfen. Die Mitglieder des Teams sehen unmittelbar, welche Auswirkungen ihre Änderungen auf das Nutzerverhalten haben („Haben wir die Nutzeraktionen durch die neuen Funktionen wie gewünscht gesteigert?“). Außerdem helfen sie z. B., Angriffe zu erkennen („Gibt es vermehrt (unzulässige) Requests von einzelnen Clients?“).

Auch mit Serverless sind wir nicht alle Ops-Themen los

Serverless stellt einen Extremfall von Cloud-Infrastrukturen dar: Da die Ressourcen nach tatsächlichem Verbrauch abgerechnet werden, muss ich mir keine bzw. kaum noch Gedanken über das Sizing meiner Infrastrukturkomponenten machen. Aber auch in diesem Fall ist es aus den oben beschriebenen Gründen wichtig, Metriken zu erfassen und auszuwerten („Wie viel werden wir grob für die Infrastruktur zahlen müssen?“, „Wie wirken sich unsere Änderungen aus?“, „Gibt es Securityprobleme?“).

Lukas und seine Kollegen haben sich entschieden, konsequent Infrastructure-as-Code einzusetzen, Alerts über ein APM-Tool abzubilden und regelmäßig wichtige Metriken in ihrem Group-Chat-Tool zu veröffentlichen.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.