Was ist Canary Deployment? Ein Leitfaden für Entwickler

Was ist Canary Deployment? Dabei bekommt die neue Version deiner App zuerst einen kleinen Anteil des echten Traffics, etwa 1% bis 5%, während alle anderen auf der alten Version bleiben. Du beobachtest Fehlerraten und Latenz genau auf diesem Anteil. Sieht alles gesund aus, erhöhst du den Anteil. Sieht es schlecht aus, leitest du den Traffic zurück, und fast niemand hat etwas bemerkt. Das ist die ganze Idee. Alles Weitere in diesem Artikel dreht sich darum, sie im Alltag zum Laufen zu bringen.

Warum heißt es Canary?

Bergleute nahmen früher Kanarienvögel mit unter Tage, weil die Vögel auf giftiges Gas reagierten, bevor es die Menschen merkten. Ein Vogel, der aufhörte zu singen, war das Signal, schnell herauszukommen. Bei einem Deployment funktioniert es genauso: Eine kleine Gruppe von Nutzern trifft zuerst auf den neuen Code und dient als Frühwarnsystem. Das CNCF-Glossar beschreibt es als zwei Umgebungen, von denen eine den Live-Traffic bedient und die andere den aktualisierten Code ausführt. Der Traffic wird schrittweise umgeleitet, zu Beginn etwa auf 1%.

In der Praxis kommt etwas dazwischen: Die Canary-Nutzer sind echte Nutzer, und Staging kann dir das nicht bieten. Produktion hat die seltsamen Browser, die veralteten Caches und den einen Kunden mit der 40-MB-Importdatei. Ein Canary ist die Methode, diese Bedingungen kennenzulernen, bevor sie alle auf deinen Fehler treffen.

Wie funktioniert ein Canary Deployment genau?

Vier bewegliche Teile, nichts Exotisches.

• Zwei Versionen laufen nebeneinander. Die alte (stabil) und die neue (Canary). Beide müssen gleichzeitig Anfragen beantworten können.

• Ein Traffic-Splitter. Ein Load Balancer, Ingress-Controller, Service Mesh oder eine CDN-Regel, die einen einstellbaren Prozentsatz an den Canary schickt.

• Metriken, denen du vertraust. Fehlerrate, Latenz und mindestens ein Geschäftssignal wie erfolgreiche Checkouts oder Registrierungen.

• Eine Regel zum Weitermachen oder Abbrechen. Vor dem Deploy aufgeschrieben, nicht um 23 Uhr beim Blick auf die Graphen erfunden.

Ein typischer Ablauf sieht so aus: 1%, 5%, 25%, 50%, 100%, mit einer Pause bei jedem Schritt. Google Cloud Deploy dokumentiert dasselbe Muster. Du legst eine Reihe von Prozentsätzen fest, und das Tool verteilt den Traffic entsprechend. Das Beispiel dort arbeitet mit Phasen bei 25%, 50% und 75%, bevor die finale stabile Version kommt. Die Cloud-Deploy-Dokumentation zu Canary zeigt außerdem, dass jede Phase einen Verify-Job und einen Analyse-Schritt haben kann, der entscheidet, ob es weitergeht.

Das Setup ist nicht perfekt, aber machbar. Du brauchst dafür kein Kubernetes. Eine gewichtete Route in nginx, eine Cloudflare-Worker-Regel, die ein Cookie setzt, oder zwei Fly.io-Maschinen hinter einem gemeinsamen Proxy zählen alle.

Wie sieht die Traffic-Aufteilung in der Konfiguration aus?

Hier ist das kleinste sinnvolle Beispiel: ein nginx-Upstream mit Gewichtungen. Neun von zehn Anfragen gehen an die stabile Version, eine an den Canary.

upstream app {
    server 10.0.0.10:3000 weight=9;   # stabil
    server 10.0.0.11:3000 weight=1;   # canary
}

Die Konfiguration hat eine Schwäche, die du kennen solltest: Die Aufteilung erfolgt pro Anfrage. Ein Nutzer kann also bei aufeinanderfolgenden Klicks zwischen den Versionen wechseln. Ändert deine neue Version die Form einer API-Antwort oder eine Datenbankspalte, hat dieser Nutzer ein schlechtes Erlebnis. Sticky Routing per Cookie oder Nutzer-ID behebt das. Es ist das Erste, was du nachrüsten solltest, sobald die einfache Aufteilung läuft.

Was solltest du beobachten, während der Canary läuft?

Vergleiche den Canary mit der stabilen Version im selben Moment, nicht mit der letzten Woche. Letzte Woche war der Traffic ein anderer. Die Frage lautet immer: Ist der Canary schlechter als die Version, die gerade die übrigen 95% bedient?

• Fehlerrate. HTTP-5xx-Antworten und unbehandelte Exceptions, getrennt nach Versions-Label.

• Latenz. p95 und p99, nicht der Durchschnitt. Der Durchschnitt verdeckt den langsamen Ausreißer, in dem sich Regressionen verstecken.

• Sättigung. CPU, Speicher, Datenbankverbindungen. Ein Speicherleck zeigt sich als Steigung, also gib ihm Zeit.

• Eine Geschäftsmetrik. Sinkt die Checkout-Erfolgsquote auf dem Canary, während die Fehler konstant bleiben, hast du einen stillen Bug ausgeliefert.

Der Fehler, den wir bei kleinen Teams am häufigsten sehen, ist das Hochfahren nach Timer: fünf Minuten bei 1%, dann 25%, egal was die Graphen zeigen. Bei wenig Traffic können fünf Minuten bei 1% sechs Anfragen sein, und daraus liest man nichts ab. Warte auf eine Mindestanzahl an Anfragen, nicht auf eine Mindestanzahl an Minuten.

Tools, die das weniger manuell machen, lohnen einen Blick, sobald du echten Traffic hast.

Canary oder Blue-Green: was solltest du wählen?

Blue-Green hält zwei vollständige Umgebungen bereit und schaltet den gesamten Traffic auf einmal um. Zurückrollen heißt, zurückzuschalten, das ist schnell und sauber. Der Preis: Für einen Moment sind 100% der Nutzer auf der neuen Version, und während der Umschaltung bezahlst du die doppelte Infrastruktur.

Ein Canary setzt nur einen Teil der Nutzer dem Risiko aus, der Wirkungsradius ist also kleiner. Der Preis ist die Komplexität. Du brauchst Traffic-Gewichtung, Metriken pro Version und eine Entscheidungsregel. Zurückrollen bedeutet, das Canary-Gewicht auf null zu setzen. Das geht schnell, ist aber nicht wörtlich sofort, wenn Verbindungen erst abfließen müssen.

Drei Gründe für einen Canary, ein Grund dagegen. Nimm den Canary, wenn ein Fehler in der Produktion teuer wäre, wenn du genug Traffic hast, damit ein kleiner Anteil aussagekräftig ist, und wenn du Metriken pro Version vergleichen kannst. Verzichte darauf, wenn du ein paar Dutzend Nutzer am Tag hast. Der Canary-Anteil bleibt dann statistisch leer, und du rätst nur. In dieser Größenordnung sind Blue-Green oder ein einfacher Deploy mit einem schnellen Rollback-Skript die ehrliche Antwort.

Rolling Updates liegen dazwischen. Sie ersetzen Instanzen nach und nach, das ist schonend. Es ist aber kein kontrolliertes Experiment: Du entscheidest nicht, wer die neue Version sieht, und du vergleichst keine Gruppen von Nutzern miteinander.

Wo passen Feature Flags hinein?

Ein Canary Deployment verteilt den Traffic zwischen Versionen deines Codes. Ein Feature Flag verteilt das Verhalten innerhalb einer Version. Die beiden werden oft verwechselt, und die Verwechslung kann teuer werden.

Du deployst den neuen Code für alle, versteckt hinter einem Flag, das ausgeschaltet ist. Dann schaltest du das Flag für 1% der Nutzer ein, danach für 10%, dann für alle. Das nennt man oft Canary Release auf Feature-Ebene. Der Vorteil: Zurückrollen heißt, ein Flag umzulegen, ohne neuen Deploy. Der Nachteil: Der tote Codepfad liegt für alle in der Produktion, und vergessene Flags werden zu technischer Schuld.

Für Solo-Entwickler sind Flags meist der günstigere erste Schritt. Ein Boolean in einer Konfigurationstabelle und ein Hash der Nutzer-ID bringen dir etwa 80% des Nutzens. Wenn du darüber hinauswächst, übernimmt ein Managed Service das Targeting, die Audit-Logs und die schrittweisen Prozent-Rollouts.

Was geht bei Canaries in echten Projekten schief?

Getestet. Nicht optimal. Hier erklärt sich, warum wir es trotzdem tun. Das sind die Fehler, die tatsächlich wehtun.

Datenbankmigrationen. Beide Versionen greifen gleichzeitig auf dieselbe Datenbank zu. Entfernt oder benennt der Canary eine Spalte um, bricht die stabile Version. Die Lösung ist das Expand-and-Contract-Muster: Zuerst die neue Spalte hinzufügen, Code ausliefern, der beide Formen versteht, und die alte Spalte erst in einem späteren Release entfernen. Lässt du diesen Schritt weg, reißt der Canary die stabile Version mit.

Zustandsbehaftete Sessions. Liegen Sessions im Speicher einer einzelnen Instanz, wird ein Nutzer, der zwischen den Versionen wechselt, ausgeloggt. Verschiebe den Session-Zustand in einen gemeinsamen Speicher, bevor du Canaries versuchst.

Cache-Vergiftung. Eine neue Version, die ein anderes Cache-Format schreibt, kann beschädigen, was die alte Version liest. Versioniere deine Cache-Keys.

Hintergrundjobs. Der Canary verarbeitet auch Queue-Nachrichten. Ein fehlerhafter Worker kann Jobs mit voller Geschwindigkeit abarbeiten, weil der Traffic-Prozentsatz den Queue-Konsum nicht begrenzt. Gib dem Canary eine eigene Queue oder ein eigenes Consumer-Gewicht.

Alarme, die niemand angeschlossen hat. Der Canary kann im Dashboard laut scheitern, das niemand öffnet. Ein automatischer Abbruch bei einem Schwellenwert schlägt einen Menschen, der zuschaut, besonders um 2 Uhr nachts in Taipeh oder Bangkok, wenn die einzige wache Person diejenige ist, die gerade deployt hat.

Wie startest du mit einem Canary bei einem Side Project?

Fang kleiner an, als du denkst. Du bist ein Entwickler, kein Plattform-Team.

1. Versieh jede Metrik mit einer Version. Schreib den Git-SHA in einen Header und in deine Logs. Ohne das kannst du Canary und stabile Version gar nicht vergleichen.

2. Wähle eine Abbruchregel. Zum Beispiel: Liegt die Fehlerrate des Canarys fünf Minuten lang über dem Doppelten der stabilen Version, wird zurückgerollt. Eine Regel, aufgeschrieben.

3. Richte eine gewichtete Route ein. nginx-Gewichte, eine Cloudflare-Regel oder die Traffic-Splitting-Funktion deines Hosters. Die meisten Managed-Plattformen bieten inzwischen prozentbasiertes Routing ohne zusätzliche Werkzeuge.

4. Liefere zuerst etwas Unspektakuläres aus. Eine Textänderung, keinen Umbau der Preisseite. Übe das Hochfahren und das Zurückrollen, wenn noch nichts auf dem Spiel steht.

5. Miss die Zeit für den Rollback. Führ ihn einmal wirklich aus. Braucht er zehn Minuten Gefummel, ist das die Stelle, die du beheben solltest, nicht die Rampe.

Wenn dein Projekt noch an der Frage hängt, wer dafür bezahlt, ist das wahrscheinlich verfrüht. Liefere schlicht aus, behalte ein Rollback-Skript und komm zu Canaries zurück, sobald ein Ausfall echte Kunden kosten würde. Ist dein Projekt schon so weit, ist die gewichtete Route plus eine Abbruchregel ein Wochenende Arbeit. Sie zahlt sich beim ersten schlechten Release aus, das bei 1% stirbt statt bei 100%.

Sollte man wirklich alles per Canary ausrollen?

Nein. Konfigurationsänderungen, Textkorrekturen und ein Tippfehler im Footer brauchen keine Rampe. Nutze Canaries für Änderungen, bei denen ein Fehler Geld oder Vertrauen kostet: Zahlungen, Authentifizierung, Datenmodelle und alles, was den Hot Path berührt. Eine Pipeline, die jeden Commit eine Stunde lang hochfährt, wird beim ersten Mal umgangen, wenn es jemand eilig hat. Ein umgangener Prozess ist schlechter als gar keiner.

Also: Was ist die riskanteste Änderung in deinem nächsten Release, und was bräuchte es, um sie zuerst an 1% der Nutzer zu schicken?