Begriff
Canary Release
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.
Bergleute nahmen früher einen Kanarienvogel mit in die Mine. Wenn der Vogel umfiel (Gas!), wussten sie: "Wir müssen raus!", bevor es die Menschen traf. Canary Release macht das mit Usern. Du installierst das Update nicht für alle 100% sofort. Du gibst es erst mal nur 1% der User (die Kanarienvögel). Dann schaust du auf die Golden Signals (Errors? Latency?). Wenn alles gut ist -> 10% -> 50% -> 100%. Wenn es knallt, haben nur 1% geflucht. Die anderen 99% haben nichts gemerkt.
Merksatz: Eine Deployment-Strategie, bei der eine neue Version einer Software schrittweise einer kleinen Benutzergruppe zur Verfügung gestellt wird, um Probleme zu erkennen, bevor sie alle Nutzer betreffen.
Tools: Istio, Linkerd, Argo Rollouts. Der Load Balancer entscheidet: "User ID endet auf 0-9? -> Ab zu Canary." "Alle anderen -> Ab zu Stable." Oft nimmt man für den Canary auch interne Mitarbeiter ("Dogfooding") oder User in einem unwichtigen Land (z. B. nachts in Neuseeland testen, bevor USA aufwacht).
1. Automatisches Rollback
Das Ziel ist Zero Touch. Das Deployment-Tool (Argo) beobachtet Prometheus. "Error Rate bei Canary > 1%?" -> Sofort Abbruch und Rollback. Kein Mensch muss nachts wach sein.
2. Sticky Sessions
Wichtig! Wenn ich einmal im Canary bin (neues Design), will ich beim nächsten Klick nicht wieder im alten Design landen. Das verwirrt. Der Load Balancer muss sich merken (Cookie), wer Canary ist.
1. Kayenta und statistische Signifikanz
Um zu entscheiden, ob der Canary erfolgreich ist oder nicht, messen IT-Giganten keine absoluten Fehlerzahlen, sondern nutzen robuste Statistik-Plattformen wie Kayenta (von Netflix entwickelt). Kayenta zieht Baseline-Metriken (Server v1) und Canary-Metriken (Server v2). Statt nur "Ist der Durchschnitt höher?" zu fragen, wendet das System z. B. den Mann-Whitney U-Test oder Kolmogorov-Smirnov Test an. Man berechnet P-Values, um zu beweisen, dass die Abweichung z. B. bei Speicherlecks keine zufällige Rauschabweichung ist, sondern statistisch signifikant an der neuen V2-Version hängt. Fällt der Canary Threshold Score unter 75, bricht das CD-System stumm und unerbittlich den Rollout ab.
2. Backward & Forward Schema Evolution
Während Traffic-Weichen in Kubernetes nur Sekundenbruchteile dauern, bleibt die relationale Datenbank das Nadelöhr des Canary Release.
Der Kanarienvogel läuft in Version V2 und braucht eine neue Spalte user_hash_id. Die Baseline V1 läuft weiterhin auf 99% Last und kennt diese Spalte nicht.
Der Entwickler ist gezwungen, das Expand and Contract Pattern zu orchestrieren. Schritt 1 (Wochen vor dem Canary): Tabelle bekommt die Spalte (Expand). Schritt 2: Code von V2 (Canary) schreibt in beide Spalten synchron. V1 ignoriert die Spalte weiter. Schritt 3: Erst wenn V2 hundertprozentig in Produktion ist und wochenlang nicht gecrasht hat, zieht man einen Migration-Job durch, der alte Alt-Daten in den neuen Status kopiert (Contract) und die alte Spalte droppt.
3. Shadow Traffic und Dark Launches
Eine Hardcore-Stufe vor dem echten "User facing" Canary ist der Shadow Canary (Dark Launching). Dabei wird dem Kanarienvogel niemals echter Last-Traffic zur Beantwortung freigegeben. Der Envoy Proxy / Ingress klont jeden HTTP-Request live im Netzwerk. Er schickt das Original zur stabilen Version (die es direkt zum Kunden beantwortet). Der Klon geht "stumm" an den Canary Pod. Der Canary verarbeitet die Last komplett, seine Antwort wird im Proxy aber weggeworfen. Man prüft im Backend nur: Ist er gecrasht? Lief er in einen OOM (Out Of Memory)? Echte User bemerken selbst bei einem Totalausfall des Canarys exakt gar nichts.
Quick-Check
Unterschied zu A/B Testing?
Technisch ähnlich (Traffic Split). Ziel ist anders. Canary prüft: "Ist es kaputt?" (Technik). A/B Test prüft: "Gefällt es euch?" (Business, Conversion Rate).Warum nicht immer Canary?
Komplexität. Du hast zwei Versionen gleichzeitig live. Das Datenbank-Schema muss beide unterstützen. Debugging ist schwerer ("Welche Version hatte der User?").Wer sind die Opfer?
Oft die "Free User". Zahlende Enterprise-Kunden kriegen Updates erst, wenn sie "abgehangen" (stable) sind.