Begriff
Canary Deployment
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Früher nahmen Bergleute einen Kanarienvogel mit in die Grube. Wenn der Vogel umfiel (sauerstoffarm, giftiges Gas), rannten die Menschen raus. Der Vogel war das Frühwarnsystem. Ein Canary Deployment macht das Gleiche mit Software. Du installierst das Update (Version 2) nicht sofort auf allen Servern. Du gibst es erst einer kleinen Gruppe von Nutzern (z. B. 5%). Das sind die "Kanarienvögel". Wenn bei denen alles glatt läuft (keine Fehler), rollst du es für alle aus (100%). Wenn es Fehler gibt, stoppst du sofort. Nur 5% der Nutzer waren betroffen.
Merksatz: Eine Deployment-Strategie, bei der eine neue Software-Version schrittweise an eine kleine Untermenge der Nutzer ausgerollt wird, um Risiken zu minimieren und Fehler frühzeitig zu erkennen.
Du brauchst einen Load Balancer oder Ingress Controller (z. B. Nginx, Istio).
- Start: 100% Traffic geht an v1.
- Canary: Du startest v2. Du konfigurierst den Load Balancer: "Leite 5% Traffic an v2".
Monitor: Du schaust auf die Logs. Gibt es "500 Errors"? Sind die Kunden zufrieden?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du brauchst einen Load Balancer oder Ingress Controller (z. B. Nginx, Istio). 1. Start: 100% Traffic geht an v1. 2. Canary: Du startest v2. Du konfigurierst den Load Balancer: "Leite 5% Traffic an v2". 3. Monitor: Du schaust auf die Logs. Gibt es "500 Errors"? Sind die Kunden zufrieden? 4. Rollout: Erhöhe auf 20%, 50%, 100%. 5. Finish: Lösche die alten v1 Instanzen.- Rollout: Erhöhe auf 20%, 50%, 100%.
- Finish: Lösche die alten v1 Instanzen.
1. Traffic Splitting (Header-based)
Statt Zufall (5% random user) kann man gezielt splitten.
User-Agent: iPhone-> Canary (weil man Mobile zuerst testen will).Cookie: beta-tester=true-> Canary (für interne Mitarbeiter). Das nennt man Targeted Canary. Kubernetes Tools wie Istio oder Argo Rollouts machen das per YAML-Config (weight: 5).
2. Automated Canary Analysis (ACA)
Manuell "auf Logs schauen" skaliert nicht bei Netflix (1000 Deploys am Tag). Tools (Spinnaker, Kayenta) machen ACA. Sie vergleichen Metriken (CPU, Memory, Error Rate) von v1 (Baseline) und v2 (Canary) statistisch. "Ist die Error Rate in v2 signifikant höher (p-value < 0.05)?" Wenn ja -> Automatischer Rollback. Kein Mensch muss wach sein.
3. Database Schema Changes
Der Endgegner. Was, wenn v2 eine Datenbank-Spalte umbenennt, aber v1 noch läuft? v1 würde abstürzen ("Column not found"). Regel für Canary: Datenbank-Änderungen müssen abwärtskompatibel sein. Schritt 1: DB-Spalte hinzufügen (Add Column). Schritt 2: Code deployen (Canary), der beide Spalten nutzen kann. Schritt 3: Alte Spalte löschen (Drop Column) erst, wenn v1 komplett weg ist. Das macht Canaries komplex ("Parallel Change Pattern").
1. Sticky Sessions & Session Affinity im Routing
Ein massives Problem bei Canary-Releases sind Stateful-Anwendungen. Landet ein Benutzer beim ersten Login-Request auf dem Canary-Server (v2), bekommt er sein Session-Cookie basierend auf dem v2-Crypto-Salt.
Klickt er danach auf "Warenkorb" und der Ingress-Controller wirft ihn aufgrund des stochastischen 5%-Random-Routings zurück auf den Stable-Server (v1), crasht v1, weil die Sitzung nicht entschlüsselbar ist.
Load-Balancer müssen daher Session Affinity (Sticky Sessions) implementieren: Man injiziert beim ersten Routing-Entscheid einen Set-Cookie: canary=true. Alle Folge-Requests desselben Browsers evaluieren dieses Cookie pre-Routing in der TCP-Schicht (z.B. in HAProxy) und leiten konstant nach v2 durch, bis der Test-Run endet.
2. Kayenta und der Mann-Whitney U-Test
Wenn Netflix ein Canary beurteilt, reicht kein simples "Ist Error > 0?". Die Automated Canary Analysis Plattform Kayenta (Open Source) unterzieht die Metriken statistischer Hypothesentests. Metriken von v1 (Baseline) und v2 (Canary) werden über Zeitreihen interpoliert und durch den Mann-Whitney U-Test (oder Kolmogorov-Smirnov) gezogen. Dieser prüft, ob die Wahrscheinlichkeitsverteilungen der v2-Latenzzeiten signifikant schlechter ausfallen als bei v1. Das System vergibt einen Score. Fällt der Score unter einen Grenzwert (z.B. 75/100), greift der Circuit für einen gnadenlosen, autonomen Release-Abbruch (Automated Rollback).
3. Canary vs. Percentage-Based Feature Flags
Oft wird das orchestrierte Server-Deployment mit Feature Flags (im Code) verwechselt.
Beim Canary-Deployment rotiert man physisch Pods & Images in einem Kubernetes-Cluster. Die Last teilt sich über das Netzwerk (Hardware-Ebene).
Ein Feature-Flag installiert den v2-Code sofort bei 100% der Instanzen, aber verbirgt ihn hinter einem if (flag_enabled). Der Traffic-Split erfolgt applikativ. Wenn ein Feature-Flag verrücktspielt, schaltet man es via API in 5 Millisekunden aus – ohne Docker-Container hoch- oder herunterfahren zu müssen. Canarys testet Infrastruktur, Feature Flags testen reine Logik.
Quick-Check
Unterschied zu Blue/Green?
Blue/Green schaltet sofort von 0 auf 100% um (Switch). Es braucht doppelte Hardware (Blue Cluster + Green Cluster). Canary schleicht sich langsam rein (Phased), spart Hardware, ist aber komplexer zu routen.Was sind "Dark Canaries"?
Traffic wird an v2 gesendet, aber die Antwort wird verworfen. Der User bekommt immer die Antwort von v1. Man testet nur, ob v2 crashen würde ("Shadow Traffic").Sticky Sessions?
Wichtig! Wenn User A einmal auf dem Canary (v2) gelandet ist, sollte er dort bleiben. Sonst springt er zwischen v1 (Warenkorb leer) und v2 (Warenkorb voll) hin und her. -> Session Affinity.