Blue-Green-Deployments und DNS-Cutover

Ein Blue-Green-Deployment hält zwei vollständige Produktionsumgebungen vor – eine live („Blue“), eine ungenutzt, aber vollständig ausgerollt und bereit („Green“) – und schaltet den Traffic zwischen beiden in einem einzigen, schnellen Wechsel um, statt per Rolling Update. Eine verbreitete Möglichkeit, diesen Wechsel umzusetzen, insbesondere über getrennte Infrastrukturen oder Anbieter hinweg, ist eine DNS-Änderung: Der Record der Domain wird auf die Adresse der Green-Umgebung umgestellt, sobald diese als gesund verifiziert ist.

Wo die einfache Variante an ihre Grenzen stößt

Ein DNS-basierter Cutover erfolgt nicht augenblicklich, wie es das Umlegen der Target Group eines Load Balancers meist tut. Jeder Resolver, der die alte (Blue-)Antwort gecacht hat, liefert sie weiter aus, bis die TTL dieses Records abgelaufen ist – das heißt, über einen Zeitraum proportional zur TTL landet ein Teil des Traffics weiterhin auf der Umgebung, von der Sie gerade wegschalten wollten. Bei einer TTL von einer Stunde kann das bis zu eine Stunde geteilten Traffic über beide Umgebungen bedeuten, bevor der Cutover überall vollständig abgeschlossen ist.

• Senken Sie die TTL deutlich vor dem geplanten Cutover – idealerweise mindestens einen vollen Zyklus der alten TTL im Voraus, damit bis zum Cutover alle Resolver bereits mit der neuen, kürzeren TTL neu gecacht haben.
• Halten Sie die alte (Blue-)Umgebung nach dem Cutover mindestens für die Dauer der TTL voll lauffähig und gesund und fahren Sie sie nicht sofort herunter – sie erhält in diesem Zeitraum weiterhin echten Traffic.
• Verifizieren Sie den Cutover durch eine direkte DNS-Abfrage statt nur über Anwendungslogs – so bestätigen Sie, dass sich der Record selbst geändert hat, unabhängig davon, wie viel Traffic ihm bereits gefolgt ist.
• Setzen Sie die TTL erst auf ihren normalen Wert zurück, wenn Sie sicher sind, dass der Cutover abgeschlossen und stabil ist.

Die schrittweise Alternative: gewichtetes DNS

Statt alle Resolver auf einmal umzuschalten und zu hoffen, dass die Green-Umgebung sofort der vollen Produktionslast standhält, unterstützen mehrere DNS-Anbieter gewichtetes (oder prozentbasiertes) Routing: 95 % der Antworten zeigen auf Blue, 5 % auf Green, und diese Verteilung verschiebt sich mit wachsendem Vertrauen in die neue Umgebung schrittweise (80/20, 50/50 und so weiter).

Man tauscht einen sauberen, einfachen Wechsel gegen die Möglichkeit ein, ein Problem zu erkennen, solange es nur einen kleinen Teil des Traffics betrifft, und in Sekunden wieder auf 100 % Blue zurückzuschalten, falls Green nicht bereit ist – statt unter Druck einen vollständigen Cutover rückgängig machen zu müssen.

Beide Ansätze auf dieselbe Weise verifizieren

Welche Strategie auch verwendet wird, der Verifizierungsschritt ist identisch: Lösen Sie die Domain wiederholt von mehr als einem Standort aus auf und bestätigen Sie, dass die tatsächlich beobachtete Verteilung der konfigurierten entspricht. Eine gewichtete Richtlinie, die 10 % des Traffics an Green senden sollte, tatsächlich aber 40 % sendet – wegen eines falsch konfigurierten Gewichts oder weil manche Resolver cachen und die Verteilung nicht so oft neu auswürfeln wie erwartet –, ist genau die Art von Abweichung, die sich nur zeigt, wenn man die tatsächlich aufgelösten Antworten prüft, statt darauf zu vertrauen, dass das Dashboard des DNS-Anbieters die Realität perfekt abbildet.