Rolling Update: Wie du ausrollst, ohne alles auf einmal runterzunehmen

Stell dir vor: Deine Anwendung läuft auf fünf Servern, alle bedienen Nutzer. Du musst eine neue Version mit einem kritischen Bugfix ausrollen. Der alte Weg wäre: alle Server stoppen, die neue Version deployen und alles neu starten. Das bedeutet aber Ausfallzeit. Jeder Nutzer sieht eine Fehlerseite oder einen Lade-Spinner, der nie endet.

Dieser Ansatz mag für interne Tools funktionieren, die um 3 Uhr morgens von ein paar Leuten genutzt werden. Aber für eine Live-Anwendung mit echten Nutzern ist es ein No-Go, alles auf einmal zu stoppen. Du brauchst eine Möglichkeit, die Software zu aktualisieren, ohne dass alle gleichzeitig die Auswirkungen spüren.

Das Problem: Alles-oder-Nichts-Deployments

Wenn du alle laufenden Instanzen deiner Anwendung gleichzeitig ersetzt, entsteht ein Zeitfenster, in dem nichts traffic bedient. Selbst wenn das Deployment nur Sekunden dauert, können diese Sekunden Umsatzverlust, frustrierte Nutzer oder fehlgeschlagene Transaktionen bedeuten. Für Anwendungen, die Hochverfügbarkeit benötigen, ist dieses Fenster inakzeptabel.

Das Kernproblem ist, dass du alle deine Server als eine Einheit behandelst. Du stoppst sie gemeinsam, aktualisierst sie gemeinsam und startest sie gemeinsam. Jedes Problem mit der neuen Version trifft alle Nutzer gleichzeitig. Wenn das Deployment fehlschlägt, musst du hektisch die alte Version zurückholen, während die Nutzer bereits Fehler sehen.

Die Lösung: Eine Instanz nach der anderen ersetzen

Statt alles auf einmal zu aktualisieren, kannst du deine Server nacheinander updaten. So funktioniert es:

Das folgende Sequenzdiagramm zeigt, wie ein Load Balancer das Update über die Instanzen koordiniert:

sequenceDiagram participant LB as Load Balancer participant I1 as Instanz 1 participant I2 as Instanz 2 participant I3 as Instanz 3 LB->>I1: Traffic abziehen I1-->>LB: Bestätigt I1->>I1: v2.0 deployen I1->>I1: Health Check /ready I1-->>LB: Bereit LB->>I1: Traffic fortsetzen LB->>I2: Traffic abziehen I2-->>LB: Bestätigt I2->>I2: v2.0 deployen I2->>I2: Health Check /ready I2-->>LB: Bereit LB->>I2: Traffic fortsetzen LB->>I3: Traffic abziehen I3-->>LB: Bestätigt I3->>I3: v2.0 deployen I3->>I3: Health Check /ready I3-->>LB: Bereit LB->>I3: Traffic fortsetzen
  1. Du hast fünf Server, die Version 1.0 deiner Anwendung ausführen.
  2. Du nimmst einen Server außer Betrieb.
  3. Du deployst Version 2.0 auf diesen Server.
  4. Du überprüfst, ob die neue Version korrekt funktioniert.
  5. Du nimmst den Server wieder in Betrieb.
  6. Du gehst zum nächsten Server und wiederholst den Vorgang.

Zu jedem Zeitpunkt laufen noch vier Server mit der alten Version und einer mit der neuen. Nutzer, die auf den aktualisierten Server treffen, bekommen die neue Version. Nutzer auf den anderen Servern sehen die alte. Niemand bekommt einen Fehler, weil kein Server jemals vollständig gestoppt wird.

Dieser Ansatz heißt Rolling Update. Der Name kommt daher, dass das Update wie eine Welle nacheinander über deine Instanzen hinwegrollt. Eine Instanz ist jede Einheit, auf der deine Anwendung läuft: ein physischer Server, eine virtuelle Maschine oder ein Container.

Warum Health Checks entscheidend sind

Ein Rolling Update funktioniert nur, wenn du feststellen kannst, ob die neue Version tatsächlich korrekt läuft, bevor du die nächste Instanz aktualisierst. Hier kommen Health Checks ins Spiel.

Ein Health Check ist ein einfacher Mechanismus, der testet, ob eine Instanz bereit ist, Traffic zu empfangen. Typischerweise ist es ein Endpunkt wie /health oder /ready, der eine Erfolgsmeldung zurückgibt, wenn die Anwendung normal arbeitet. Dein Orchestrierungssystem – ob Kubernetes, ein Load Balancer oder ein benutzerdefiniertes Deployment-Tool – prüft diesen Endpunkt, bevor es Traffic an die Instanz sendet.

Schlägt der Health Check nach dem Deployment der neuen Version fehl, stoppt das Rolling Update. Die problematische Instanz kann auf die alte Version zurückgesetzt werden, und der Rest deiner Server bleibt unberührt. Du hast den Schaden auf eine einzelne Instanz und eine kleine Teilmenge der Nutzer begrenzt.

Ohne Health Checks fliegst du blind. Du könntest alle fünf Server aktualisieren, bevor du merkst, dass die neue Version beim Start abstürzt. Dann sind alle Nutzer betroffen.

Wann Rolling Updates gut funktionieren

Rolling Updates sind ideal für Änderungen, die abwärtskompatibel sind. Das sind Änderungen, bei denen alte und neue Versionen problemlos nebeneinander laufen können. Beispiele:

  • Neue Log-Anweisungen hinzufügen
  • Einen kleinen Bug fixen, der keine Datenformate ändert
  • UI-Farben oder Texte ändern
  • Einen neuen API-Endpunkt hinzufügen, den noch niemand nutzt
  • Eine Abhängigkeit aktualisieren, die das Verhalten nicht ändert

Da während des Updates alte und neue Instanzen gleichzeitig laufen, ist Abwärtskompatibilität essenziell. Wenn die neue Version Daten in einem anderen Format erwartet oder mit anderen Diensten über ein anderes Protokoll kommuniziert, treten Fehler auf, wenn alte und neue Instanzen zusammenarbeiten.

Die Abwägungen

Rolling Updates sind einfach und benötigen keine zusätzliche Infrastruktur. Du nutzt dieselben Server, die du bereits hast. Es ist nicht nötig, eine parallele Umgebung aufzuziehen oder zusätzliche Kapazitäten bereitzustellen. Deine Infrastrukturkosten bleiben während des Updates gleich.

Der Nachteil ist die Geschwindigkeit. Rolling Updates dauern, weil du warten musst, bis jede Instanz aktualisiert und verifiziert ist. Wenn du fünfzig Server hast und jeder eine Minute zum Deployen und Prüfen braucht, dauert dein Update fast eine Stunde. Für dringende Sicherheitspatches kann das zu langsam sein.

Eine weitere Einschränkung ist die Sichtbarkeit. Wenn ein Rolling Update ein Problem einführt, breitet sich die Auswirkung allmählich aus. Manche Nutzer sehen das Problem, andere nicht. Das erschwert die Ursachenanalyse im Vergleich zu Strategien, bei denen betroffene und nicht betroffene Nutzer klar getrennt werden können.

Eine praktische Checkliste

Bevor du ein Rolling Update implementierst, stelle sicher, dass diese Grundlagen vorhanden sind:

  • Health-Check-Endpunkt: Deine Anwendung muss einen zuverlässigen Weg bieten, um zu prüfen, ob sie funktioniert.
  • Abwärtskompatibilität: Die neue Version muss während der Übergangsphase neben der alten Version laufen können.
  • Rollback-Plan: Wisse, wie du eine einzelne Instanz zurücksetzen kannst, wenn der Health Check fehlschlägt.
  • Monitoring: Beobachte Fehlerraten und Antwortzeiten während des Updates, um Probleme früh zu erkennen.
  • Ausreichend Instanzen: Rolling Updates funktionieren am besten mit mindestens drei Instanzen. Bei nur zwei verlierst du die Hälfte deiner Kapazität während des Updates.

Das Fazit

Rolling Updates sind die Standard-Deployment-Strategie für die meisten modernen Anwendungen, weil sie das grundlegende Problem lösen, Software ohne Ausfallzeit zu aktualisieren. Die Idee ist einfach: Ersetze nicht alles auf einmal. Ersetze eine Instanz, prüfe, ob sie funktioniert, und gehe dann zur nächsten über. Dieser Ansatz hält deine Anwendung während des gesamten Updates verfügbar und begrenzt die Auswirkungen, falls etwas schiefgeht.

Für kleine, abwärtskompatible Änderungen sind Rolling Updates oft alles, was du brauchst. Sie sind unkompliziert, kosteneffizient und werden von Container-Orchestrierungsplattformen wie Kubernetes und Cloud-Deployment-Tools weitgehend unterstützt. Aber für riskantere Änderungen – Datenbankmigrationen, Protokolländerungen oder große Feature-Überholungen – brauchst du vielleicht mehr Kontrolle. Hier kommen Strategien wie Blue-Green-Deployments oder Canary-Releases ins Spiel. Aber das ist ein Thema für einen anderen Beitrag.