Sicher in Richtung moderner Deployment-Strategien Monitoring in Microservice-Umgebungen

Von Stefan Marx *

Anbieter zum Thema

Dynamische Cloud-Umgebungen und agile DevOps-Praktiken erfordern neue Deployment-Strategien. Einen Überblick über die gängigsten Methoden und welche Auswirkungen sie auf die Software-Entwicklung haben, betrachtet dieser Gastbeitrag.

Tracking aller Requests und prozentuale Veränderungen von Service Errors im Canary Deployment.
Tracking aller Requests und prozentuale Veränderungen von Service Errors im Canary Deployment.
(Bild: Datadog)

In den Pre-Cloud-Zeiten monolithischer Umgebungen und der Wasserfall-Softwareentwicklung waren Code-Implementierungen isolierte, überschaubare Ereignisse. Code wurde in einem bestimmten Teil der Infrastruktur bereitgestellt und das Betriebsteam überwachte die Auswirkungen des Codes, sobald er in Produktion war.

In vielerlei Hinsicht war dieses Vorgehen einschränkend, aber es bedeutete, dass die Auswirkungen leicht zu verstehen waren – die Operations-Teams wussten, wo sie nachschauen mussten und was zu tun war, wenn ein neues Code-Deployment fehlschlug. Anstelle eines Monolithen können die Teams aber heutzutage auch einzelne, gut identifizierte Microservice einsetzen.

Ein solcher Microservice bedient möglicherweise Dutzende von Upstream-Diensten, die über eine automatisch skalierte Flotte von zehn oder Hunderten von Containern oder Hosts bereitgestellt werden. Dies ermöglicht zwar eine bessere Kontrolle über Funktionalität, Leistung und Betriebskosten, aber der Grad der Vernetzung und Komplexität erhöht das Gesamtrisiko, einen Fehler zu machen.

Diese Dynamik hat zu einer Welle moderner Deployment-Strategien geführt – und angesichts des Innovationstempos sind diese Strategien in den meisten modernen softwaregestützten Unternehmen von „nice-to-have“ zu „need-to-have“ geworden. Wie können also technische Teams diese neue Welt mit Zuversicht betreten und die Vorteile nutzen, gleichzeitig aber die Risiken unter Kontrolle halten?

Schnell und skalierbar

Zwischen diesen neuen Deployment-Strategien gibt es zwar wesentliche Unterschiede; aber sie alle spiegeln den verteilten, dynamischen und kollaborativen Charakter der Software-Entwicklung in der Cloud wider, der eine kontinuierliche Verbesserung der Anwendungen im Laufe der Zeit ermöglicht.

Die gängigsten modernen Deployment-Strategien sind:

  • Gradual Deployment: Hier wird der Code schrittweise, in teilweise Kleinstschritten in die Infrastruktur gespielt – zum Beispiel anfangs nur wenige Container – um sicherzustellen, dass nichts schief geht, bevor eine breitere Verteilung erfolgt.
  • Canary Deployment: In diesem Fall wird der Code auf bestimmte Instanzen verteilt. Diese funktionieren wie der Kanarienvogel (Canary) im Bergwerk. Das Team kann so überprüfen, was passieren könnte, wenn der Code auf eine größere Anzahl ähnlicher Instanzen verteilt wird.
  • Blue/Green Deployment: Hierbei wird der alte Code im Hintergrund ausgeführt, während gleichzeitig der neue Code verteilt wird. Der alte Code dient als Backup, falls etwas schief geht.
  • A/B-Deployment: Bei diesem Vorgehen werden zwei neue Verteilungen gleichzeitig ausgeführt, so dass sie hinsichtlich ihrer jeweiligen Performance verglichen werden können.

Tracking aller Requests und prozentuale Veränderungen von Service Errors im Canary Deployment.
Tracking aller Requests und prozentuale Veränderungen von Service Errors im Canary Deployment.
(Bild: Datadog)

Jede dieser Strategien ermöglicht eine schnellere Entwicklung neuer Anwendungen und Funktionen, da sie die Möglichkeit bieten, neue Deployments zu analysieren und gegebenenfalls zurückzunehmen und zu überarbeiten. Wenn Teams ihren Code schnell auf einer bestimmten Infrastruktur ausliefern können, können sie die Auswirkungen unsichtbarer Probleme auf ein Minimum reduzieren, diese Probleme identifizieren und beheben und dann schnell erneut deployen, um ihren Code weiter zu verfeinern.

Das klingt in der Praxis einfach, birgt in der Realität aber Herausforderungen. Tatsächlich können mehrere Teams oder sogar einzelne Mitarbeiter entscheiden, verschiedene Services parallel zu implementieren. Das macht es schwierig, den Überblick zu behalten. Schauen wir uns also ein konkretes Beispiel an, um zu sehen, wie dies in der Praxis funktioniert.

Blue/Green-Deployment in Aktion

Stellen wir uns ein Blue/Green-Deployment eines kritischen Updates für eine Anwendung vor. Der neue Code wird in getrennten Containern bereitgestellt, während der vorhandene Code ununterbrochen läuft. Dann wird der Traffic auf den neuen Code umgeschaltet.

Die zuständigen DevOps- oder SRE-Teams (Site Reliability Engineering) beobachten was passiert, testen die Performance des Codes unter realen Bedingungen und greifen bei Bedarf auf den vorhandenen alten Code als Backup zurück. Wenn der neue Code vollständig validiert (auf Performance, Fehler und Funktionalität geprüft) ist, kann der alte Code entfernt oder für einen zukünftigen Einsatz liegengelassen werden.

Deployment Tracking im Blue/Green-Deployment.
Deployment Tracking im Blue/Green-Deployment.
(Bild: Datadog)

Bei einer traditionellen Deployment-Strategie müssen die Teams nur Daten aus einem einzelnen Einsatz über einen begrenzten Zeitraum konsultieren. Bei der oben beschriebenen Blue/Green-Strategie ist die Überwachung jedoch komplexer. Um mit dieser Komplexität umgehen zu können, benötigen die Teams ein robustes Monitoring, so dass alle relevanten Daten – über alle Deployments hinweg, solange sie laufen – sowohl für Echtzeit- als auch für Post-Mortem-Untersuchungen gesammelt und organisiert werden.

Es beginnt mit den Daten

Die meisten Teams verfügen bereits über Monitoring-Lösungen und -Prozesse, um Daten zu sammeln, zu organisieren und zu visualisieren. Um die Sichtbarkeit moderner Deployment-Strategien zu verbessern, müssen die einzelnen Deployments mit Tags versehen werden, die Vergleiche zwischen ihnen ermöglichen.

Kein Deployment darf ohne Monitoring bleiben, um Troubleshooting inmitten mehrerer Deployments und unterschiedlicher Code-Versionen anzustoßen. Die gesammelten Daten sollten außerdem maximal granular sein. Vergleichsdaten aus der Vergangenheit müssen zudem unverändert und insbesondere nicht aggregiert vorliegen.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Softwareentwicklung und DevOps

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Um den Kern eines Problems zu identifizieren, muss die Tiefe die Breite ergänzen. Metriken, Logs und Traces sollten von einzelnen Endpunkten und Anfragen gesammelt werden, so dass auf bestimmte Probleme gezoomt werden kann und diese im Zusammenhang mit der gesamten Umgebung und den unterschiedlichen Deployments betrachten können.

Sobald Daten auf granularer Ebene gesammelt werden und das Monitoring für jedes Deployment implementiert ist, ist eine detaillierte Fehlersuche und -behebung möglich, unabhängig von der Summe der Deployments.

Überwachung moderner Deployment-Strategien in der Praxis

Neue Fehler während eines Blue/Green-Deployments.
Neue Fehler während eines Blue/Green-Deployments.
(Bild: Datadog)

Reichhaltige Daten in der Breite für alle Deployments zu haben, ist aber erst der Anfang. Die Art und Weise, wie diese Daten zur Fehlerbehebung genutzt werden, ist auch für die Verwaltung moderner Deployment-Strategien wichtig.

Zunächst muss eine Reihe von „goldenen Signalen“ identifiziert werden – gesammelte Daten, die den stärksten Hinweis auf die Performance eines Deployments liefern. Requests, Latenzzeiten und Fehlerraten sind hierbei am gängigsten, während Infrastrukturmetriken und Performance-Anforderungen auf Code-Ebene aus Anwendungs-Traces ebenfalls wichtig sind.

Als Nächstes muss die Monitoring-Praxis darauf ausgerichtet werden, mehrere gleichzeitig laufende Deployment-Versionen zu beobachten. Dieser Monitoring-Ansatz sollte sich nicht auf bestimmte zeitliche Ereignisse konzentrieren, sondern vielmehr auf die laufende Beobachtung der unterschiedlichen Deployments.

Bei der Fehlerbehebung von Problemen, die sich aus neuen oder parallelen laufenden Deployments ergeben, sollte schnell zwischen Informationen aus verschiedenen Quellen gewechselt werden können, um Unterschiede zwischen allen Microservice-Diensten erkennen zu können. Auf diese Weise können Protokolle, Traces und Codeprofile zur Behebung eines Problems im laufenden Betrieb verglichen und gegenübergestellt werden.

Und schließlich benötigen Unternehmen ein robustes Set von vordefinierten Warnmeldungen und Dashboards, damit Teams über die wichtigsten Probleme benachrichtigt werden und in Echtzeit visualisieren können, was geschieht.

Neue Zuversicht

Code-Implementierungen sind nicht länger diskrete Ereignisse mit begrenzten Auswirkungen – der Prozess des Code-Deployments und der Überwachung seiner Auswirkungen ist kontinuierlich. Um diese neuen Strategien mit Zuversicht anwenden zu können, benötigen Unternehmen einen gut strukturierten Monitoring-Ansatz.

Stefan Marx, DataDog
Stefan Marx, DataDog
(Bild: Erika Martins (http://erikamartins.de))

Ein solcher ermöglicht schnelle Vergleiche der goldenen Signale in jeder einzelnen Service-Version und bietet reichhaltige Untersuchungsdaten, wenn etwas nicht in Ordnung zu sein scheint. Mit der richtigen Grundlagenarbeit werden die Vorteile des modernen Code-Deployments allmählich zum Tragen kommen – Funktionen werden schneller ausgeliefert, Fehler werden vermieden und die Kunden bleiben zufrieden.

* Stefan Marx ist Director Product Management für die EMEA-Region beim Cloud-Monitoring-Anbieter Datadog. Marx ist seit über 20 Jahren in der IT-Entwicklung und -Beratung tätig. In den vergangenen Jahren arbeitete er mit verschiedenen Architekturen und Techniken wie Java Enterprise Systemen und spezialisierten Webanwendungen. Seine Tätigkeitsschwerpunkte liegen in der Planung, dem Aufbau und dem Betrieb der Anwendungen mit Blick auf die Anforderungen und Problemstellungen hinter den konkreten IT-Projekten.

(ID:47028334)