Blue Green Deployment
Zwischen zwei vollständigen Umgebungen umschalten
Die Idee und ihr Nutzen
Das Kundenportal einer Versicherung läuft in Version 5.1 und soll auf Version 5.2 aktualisiert werden, ohne dass Kunden währenddessen vor einer Wartungsseite stehen. Das zuständige Team hält dafür zwei gleich aufgebaute Umgebungen bereit, also zwei vollständige Sätze von Servern mit dem Kundenportal. In der Umgebung Blau bedient Version 5.1 die Kunden, in der Umgebung Grün installiert und prüft das Team Version 5.2. Jede Anfrage der Kunden geht zuerst an einen Lastverteiler, ein Programm, das die Anfrage an eine der beiden Umgebungen weiterleitet. Erst wenn Version 5.2 geprüft ist, stellt das Team den Lastverteiler auf die Umgebung Grün um. Zeigt sich danach ein Fehler, schaltet das Team in Sekunden auf die Umgebung Blau zurück, die noch vollständig läuft. Nach den Namen der beiden Umgebungen heißt das Verfahren Blue Green Deployment. Deployment ist das englische Wort für das Ausliefern einer neuen Version.
Wie funktioniert es?
Am Dienstag um 10 Uhr bedient die Umgebung Blau mit Version 5.1 alle Kunden: Die Kunden schicken ihre Anfragen an den Lastverteiler, und der Lastverteiler schickt alle Anfragen an die Umgebung Blau. Währenddessen installiert das Team Version 5.2 in der Umgebung Grün. Die automatischen Tests laufen 30 Minuten ohne Fehler. Kunden merken davon nichts, weil der Lastverteiler noch keine Anfragen an die Umgebung Grün schickt. Um 10:40 Uhr stellt das Team den Lastverteiler so um, dass neue Anfragen an die Umgebung Grün gehen. Anfragen, die gerade noch in der Umgebung Blau laufen, dürfen dort zu Ende laufen. Von da an bedient die Umgebung Grün mit Version 5.2 alle neuen Anfragen. Die „Überwachung“ ist ein Programm, das Fehler im Betrieb meldet. Um 10:55 Uhr meldet die „Überwachung“ dem Team, dass viele Foto-Uploads scheitern: Kunden versuchen vergeblich, Fotos ihrer Schäden hochzuladen. Diesen Fall hatten die automatischen Tests nicht abgedeckt. Das Team stellt den Lastverteiler zurück auf die Umgebung Blau, und nach etwa 20 Sekunden bedient wieder Version 5.1 alle Kunden. Das gelingt, weil Version 5.2 die gemeinsame Datenbank der beiden Umgebungen nur um eine Spalte ergänzt hat, die Version 5.1 nicht beachtet. Version 5.2 bleibt in der Umgebung Grün installiert. Das Team behebt den Fehler dort in Ruhe und schaltet am Mittwoch erneut um.
Welche Umgebung gerade die Kunden bedient, legt allein die Einstellung des Lastverteilers fest, und diese Einstellung ändert das Team. Wie schnell nach dem Umschalten alle Kunden bei der neuen Version ankommen, hängt davon ab, wie lange bestehende Netzverbindungen zur Umgebung Blau offen bleiben. Bei der nächsten Aktualisierung tauschen die Umgebungen ihre Rollen: Die neue Version kommt dann in die Umgebung Blau.
Beide Umgebungen teilen sich eine Datenbank, damit die Kundendaten nicht in zwei Kopien voneinander abweichen. Deshalb muss jede Änderung am Aufbau der Datenbank, dem Schema, so gestaltet sein, dass alte und neue Version gleichzeitig mit der Datenbank arbeiten können. Braucht Version 5.2 eine neue Spalte, wird die Spalte zunächst nur hinzugefügt. Eine Spalte, die nur Version 5.1 nutzt, entfernt das Team erst mit einer späteren Version, wenn niemand mehr zu Version 5.1 zurückschalten will. Das Zurückschalten bringt nur das Programm zurück, nicht die Daten: Was Version 5.2 zwischen 10:40 und 10:55 Uhr in die Datenbank geschrieben hat, bleibt dort. Beim Umschalten dürfen angemeldete Kunden nicht abgemeldet werden. Das gelingt nur, wenn die Anmeldedaten nicht allein im Speicher einer Umgebung liegen, sondern in der gemeinsamen Datenbank oder im Browser des Kunden.
Blue/Green: Portalversion 5.2 testen und zurückschalten
Wann ist es sinnvoll und wann nicht?
Ein Blue Green Deployment lohnt sich
- Das Kundenportal soll rund um die Uhr erreichbar sein und erhält regelmäßig neue Versionen. Ohne zweite Umgebung hält das Team die alte Version an, installiert die neue und startet sie. In dieser Zeit ist das Kundenportal nicht erreichbar.
- Das Team will bei einem Fehler innerhalb von Sekunden zur alten Version zurück. Ohne die laufende Umgebung Blau müsste das Team Version 5.1 erneut installieren, und das dauert ähnlich lange wie die Aktualisierung.
- Das Team will häufiger ausliefern. Ohne zweite Umgebung verlegen viele Unternehmen Aktualisierungen in die Nacht oder aufs Wochenende und machen sie deshalb selten. Seltene Aktualisierungen enthalten viele Änderungen auf einmal. Tritt dann ein Fehler auf, ist schwer zu erkennen, welche Änderung ihn verursacht hat. Mit zwei Umgebungen lässt sich eine fehlerhafte Aktualisierung in Sekunden zurücknehmen, und jede Auslieferung kann weniger Änderungen enthalten.
- Version 5.2 soll unter denselben Bedingungen wie im Betrieb geprüft werden, bevor ein Kunde sie erreicht. Die Umgebung Grün ist genauso aufgebaut wie die Umgebung Blau. Ohne zweite Umgebung prüft das Team Version 5.2 meist in einer kleineren Testumgebung, die sich in Einstellungen und Zugängen vom Betrieb unterscheiden kann.
- Eine vollständige zweite Umgebung lässt sich automatisch aufbauen. Das gelingt mit Skripten, also kleinen Programmen, die alle Server gleich einrichten.
- Datenbankänderungen lassen sich so gestalten, dass alte und neue Version eine Zeit lang gleichzeitig mit derselben Datenbank arbeiten können.
Ein Blue Green Deployment ist nicht das Richtige
- Eine zweite Umgebung ist sehr teuer. Ein Beispiel sind große Rechner mit hohen Lizenzkosten. Dann aktualisiert das Team mit einem Rolling Deployment die Server einer einzigen Umgebung nacheinander. Während ein Server die neue Version erhält, bedienen die übrigen Server die Kunden. Die Versicherung bezahlt so keine zweite Umgebung mit Servern und Lizenzen. Das Zurückschalten dauert dann allerdings so lange wie eine erneute Aktualisierung.
- Datenbankänderungen lassen sich nicht so gestalten, dass die alte Version weiter mit der Datenbank arbeiten kann. Nach dem Zurückschalten würde Version 5.1 an der geänderten Datenbank scheitern. Dann sichert das Team die Datenbank und aktualisiert Programm und Datenbank gemeinsam in einer angekündigten Wartungszeit. Bei einem Fehler spielt das Team die Sicherung und Version 5.1 wieder ein. Eine zweite Umgebung, deren Zurückschalten hier nicht hilft, bezahlt die Versicherung dann nicht.
- Ein Fehler in der neuen Version darf nicht alle Kunden gleichzeitig treffen. Beim Blue Green Deployment geht nach dem Umschalten jede neue Anfrage an Version 5.2. Stattdessen macht das Team ein Canary Release: Das Team stellt den Lastverteiler so ein, dass zuerst nur ein kleiner Teil der Kunden Version 5.2 erreicht. Ein Fehler wie die scheiternden Foto-Uploads trifft dann nur diesen kleinen Teil der Kunden.
- Die Neuerung betrifft nur eine einzelne Funktion. Dann baut das Team die Funktion mit Feature Toggles ein, also mit einem Schalter, mit dem das Team die Funktion im laufenden Programm ein- und wieder ausschaltet. Bei einem Fehler schaltet das Team nur diese eine Funktion aus und muss nicht die ganze Version zurücknehmen.
Nachteile und typische Fehler
Während einer Aktualisierung laufen zwei vollständige Umgebungen, also doppelt so viele Server wie im Normalbetrieb. Beide Umgebungen müssen gleich aufgebaut bleiben, was ohne Skripte für die Einrichtung kaum gelingt. Jede Datenbankänderung verteilt sich auf zwei Auslieferungen, weil eine alte Spalte erst mit einer späteren Version entfernt werden darf. Das Team muss das Umschalten im Lastverteiler regelmäßig üben, und die „Überwachung“ muss nach jedem Umschalten zeigen, ob gescheiterte Anfragen zunehmen.
Typische Fehler und woran man sie erkennt:
- Nicht rückwärtsverträgliche Daten: Version 5.2 speichert Daten in einer Form, die Version 5.1 nicht lesen kann. Nach dem Zurückschalten läuft Version 5.1 zwar wieder, scheitert aber an diesen Daten. Erkennbar ist das an Fehlern in der Umgebung Blau unmittelbar nach dem Zurückschalten, obwohl die Umgebung Blau vorher fehlerfrei lief.
- Abmeldung beim Umschalten: Die Anmeldedaten liegen nur im Speicher der Umgebung Blau. Nach dem Umschalten schickt der Lastverteiler die Anfragen der angemeldeten Kunden an die Umgebung Grün, die diese Anmeldedaten nicht kennt. Die Kunden sind dann abgemeldet und verlieren halb ausgefüllte Schadenmeldungen. Erkennbar ist das an einem Anstieg der Anmeldungen und der abgebrochenen Formulare genau zum Zeitpunkt des Umschaltens.
- Ungleiche Umgebungen: Die Umgebung Grün wurde von Hand eingerichtet und unterscheidet sich in Einstellungen oder Zugängen von der Umgebung Blau. Die Tests in der Umgebung Grün bestehen, im Betrieb scheitert aber ein Aufruf, den die Umgebung Blau problemlos ausführt. Erkennbar ist das an Fehlern, die nur in einer der beiden Umgebungen auftreten.
- Fehler trifft alle Kunden: Nach dem Umschalten nutzen alle Kunden auf einmal die neue Version. Ein Fehler, den die Tests nicht abdecken, trifft sofort alle, bis das Team zurückschaltet. Erkennbar ist das an einem sprunghaften Anstieg gescheiterter Anfragen in der „Überwachung“ direkt nach dem Umschalten.
- Alte Umgebung zu früh abgebaut: Das Team baut die Umgebung Blau unmittelbar nach dem Umschalten ab, um Kosten für die Server zu sparen. Zeigt sich der Fehler erst danach, gibt es keine laufende Version 5.1 mehr, auf die der Lastverteiler zurückschalten kann. Erkennbar ist das daran, dass ein Zurückschalten eine neue Installation erfordert.
Weiterführend
Verwandte Ansätze
- Immutable Infrastructure: baut Server bei jeder Änderung neu auf, statt sie zu verändern. So lässt sich die zweite Umgebung jedes Mal frisch und gleichartig erstellen.
Werkzeuge und Umsetzungen
- Argo Rollouts: steuert in Kubernetes, einer verbreiteten Plattform zum Betrieb von Anwendungen auf vielen Servern, das Umschalten zwischen zwei Versionen einschließlich Prüfung und Zurückschalten.
- Flagger: schaltet in Kubernetes automatisch zwischen zwei Versionen um und wertet dabei Messwerte wie die Fehlerrate aus.
- Spinnaker: Plattform für Auslieferungen mit fertigen Abläufen für dieses Umschalten.
- HAProxy und NGINX: Lastverteiler, in denen das Umschalten als Änderung des Weiterleitungsziels eingestellt wird.
Quellen
- Martin Fowler: BlueGreenDeployment: beschreibt das Verfahren mit zwei vollständigen Umgebungen für den echten Betrieb, das Umschalten der Anfragen zwischen beiden, das Zurückschalten und das Trennen von Schemaänderungen und Programmaktualisierung.
- Amazon Web Services: Blue/Green Deployments on AWS, Introduction: erklärt, warum die unberührte alte Umgebung ein schnelles Zurückschalten erlaubt und wie der Schaden auf die Zeit bis zum Zurückschalten begrenzt bleibt.