Zero-Downtime Deployment: Aktualisierungen ohne Ausfallzeiten

Zero-Downtime Deployment, Rolling Deployment

Jede Sekunde, die ein digitaler Service nicht online ist, kostet das Unternehmen bares Geld und Vertrauen bei der Kundschaft. Durch Zero-Downtime Deployment (auch Rolling Deployment genannt) soll verhindert werden, dass ein Service bei Aktualisierung offline gehen muss. Wie das funktioniert und warum es nicht immer leicht umsetzbar ist, erklärt unser DevOps-Experte Markus Uckelmann.

Was ist Zero-Downtime Deployment?

Zero-Downtime Deployment bedeutet im Grunde, dass ein Deployment einer Applikation gemacht wird, ohne dass der Nutzer etwas davon merkt. Bei einem Zero-Downtime Deployment sind mindestens zwei Dienste beteiligt:

  • Der eine ist ein Loadbalancer (LB), der wie eine Weiche die HTTP-Requests der Clients (Browser) zu unterschiedlichen Zielen leiten kann.
  • Der zweite Dienst ist eine Applikation (App). In diesem Fall ein Webserver, der eine Webseite ausliefert. Der Loadbalancer leitet alle Requests an die App weiter.

Nun soll eine neue Version der App veröffentlicht werden. Damit die Versionen der App unterscheidbar sind, wird die alte Version “V1” genannt und die neue Version “V2” genannt.

Zero-Downtime Deployment vor dem Switch

Vor der Veröffentlichung der neuen Version verweist der Loadbalancer auf die alte Version. Anschließend wird ein neuer Dienst mit der App “V2” gestartet. Im Moment steht “V2” isoliert da und erhält keine Anfragen.

Zero-Downtime Deployment nach dem Switch

Nachdem durch Testen sichergestellt ist, dass die neue Version einwandfrei funktioniert, wird dem Loadbalancer mitgeteilt, dass alle neuen Requests auf die neue Version weiterzuleiten sind.

Zero-Downtime Deployment für “stateless” Apps

Diese Art des Deployments wird auch Rolling Deployment genannt. Es funktioniert wie in diesem Beispiel angegeben für “stateless” Apps. Das bedeutet:

  • Stateless ist eine Applikation, wenn sie unabhängig von jeglicher Art von Zustand ist. Das bedeutet, dass die Applikation keine Daten speichern muss, wie z.B. Sessions, oder Daten liest und schreibt, wie z.B. Bilder.
  • Stateful ist das genaue Gegenteil. Die Applikation muss und wird also Daten speichern: Nutzer können sich einloggen, Content wird in einer Datenbank gespeichert, o.Ä.

Sobald man eine Applikation hat, die “stateful” ist, funktioniert Zero-Downtime Deployment nicht mehr. Ein Benutzer der in der alten Version eingeloggt ist, wird in der neuen Version ausgeloggt. Hätte man in “V1” einen Warenkorb mit Produkten gehabt oder Bilder hochgeladen, wären diese in “V2” verschwunden.

Rolling Deployment auch für “stateful” Apps?

Die meisten Web-Apps setzen auf Nutzer-Interaktion. Daher wäre es wünschenswert, ein Zero-Downtime Deployment oder Rolling Deployment auch für “stateful” Apps umsetzen zu können. Wie könnte das funktionieren?

Möglichkeit 1: Den “state” der App entfernen

Man kann die Informationen und Daten aus der Applikation in einem anderen Service speichern, wie z.B. Redis als Session-Speicher oder einem NFS-Laufwerk für Bilder. Dabei muss man jedoch sicherstellen, dass es zu keinen konkurrierenden Zugriffen kommen kann.

Sollten zum Beispiel in “V1” und “V2” im obigen Beispiel zur gleichen Zeit ein Bild verändert werden, wäre unklar, welcher App der Vorrang zu geben wäre. Im schlimmsten Fall würde die Änderung ganz verloren gehen.

Möglichkeit 2: Kompatible Datenbanken nutzen

Es gibt Datenbanken, die mit konkurrierenden Zugriffen (die gleichen Daten werden von Zugriffen zur gleichen Zeit verändert) umgehen können. Diese führen Operationen (wie Schreiben und Lesen) als Transaktion aus.

Dabei ist jede Datenbank-Operation atomar gekapselt. Dadurch kann es nicht passieren, dass zur gleichen Zeit auf dieselben Daten zugegriffen wird. Nutzt eine App eine solche Datenbank, erwartet sie, die Daten in einer fest definierten Form vorzufinden. Diese dürfte bei einem neuen Deployment also nicht geändert werden:

Nehmen wir an “V1” würde die Benutzer in einer Datenbanktabelle verwalten, welche die Felder “ID”, “Name” und “Eintrittsdatum” hätte. In “V2” wäre das Feld “Eintrittsdatum” aber in eine andere Tabelle verschoben worden.

Da die Applikationen bei einem Deployment für eine gewisse Zeit parallel auf die Datenbank zugreifen, würde “V1” dann nicht mehr funktionieren. Diese Art der Änderung passiert z.B. in CMS-Systemen bei fast jedem Release. Und hier hilft dann auch die Transaktionalität nicht mehr.

Fazit

Grundsätzlich gilt, dass ein Zero-Downtime Deployment oder Rolling Deployment nur mit “stateless” Applikationen gemacht werden kann. “Stateful” Applikationen dagegen ermöglichen dies nicht.

Selbst für “stateful” Applikationen gibt es aber Möglichkeiten, sie für Zero-Downtime Deployments vorzubereiten. Das ist aber kompliziert und aufwendig. Wichtig sind hier genaue Kenntnisse der Applikation und der eingesetzten Services, detaillierte Planung, ein hoher Grad an Automatisierung und eine gute Testabdeckung.

Zero-Downtime Deployment mit Docker-Containern lässt sich übrigens mit der Docker-Hosting-Plattform sloppy.io umsetzen.

Photo by Sean Lim on Unsplash

Zur Blog-Startseite