Wat is canary deployment? Praktische gids voor devs

Wat is canary deployment? Het is een release waarbij de nieuwe versie van je app eerst een klein deel van het echte verkeer krijgt, zeg 1 tot 5 procent, terwijl de rest op de oude versie blijft. Je kijkt naar foutpercentages en latency op dat deel. Ziet het er gezond uit, dan verbreed je het. Ziet het er slecht uit, dan zet je het verkeer terug en heeft bijna niemand er iets van gemerkt. Dat is het hele idee. Alles hieronder gaat over hoe je dat in de praktijk laat werken.

Waarom heet het een canary?

Mijnwerkers namen vroeger kanaries mee de mijn in, omdat die vogels eerder reageerden op giftig gas dan mensen. Een kanarie die stopte met zingen was het signaal om weg te gaan. Bij een deployment werkt het net zo: een kleine groep gebruikers raakt de nieuwe code als eerste en fungeert als vroeg waarschuwingssysteem. De CNCF-glossary beschrijft het als twee omgevingen, één met live verkeer en één met de bijgewerkte code, waarbij het verkeer geleidelijk verschuift, te beginnen bij een klein aandeel zoals 1 procent.

Wat dit in de praktijk lastig maakt: de canary-gebruikers zijn echte gebruikers. Staging kan dat niet nabootsen. Productie heeft de rare browsers, de verouderde caches en die ene klant met een importbestand van 40 MB. Een canary is de manier om die dingen te ontmoeten voordat ze allemaal jouw bug ontmoeten.

Hoe werkt het, en hoe ziet de verkeersverdeling eruit?

Vier onderdelen, niets exotisch.

• Twee versies naast elkaar. De oude (stable) en de nieuwe (canary). Beide moeten tegelijk requests kunnen afhandelen.

• Een verkeersverdeler. Een load balancer, ingress controller, service mesh of CDN-regel die een instelbaar percentage naar de canary stuurt.

• Metrieken die je vertrouwt. Foutpercentage, latency en minstens één bedrijfssignaal, zoals geslaagde betalingen of aanmeldingen.

• Een regel om door te gaan of af te breken. Opgeschreven vóór de deploy, niet bedacht om 23.00 uur terwijl je naar grafieken staart.

Een typische opbouw is 1%, 5%, 25%, 50%, 100%, met een pauze bij elke stap. Google Cloud Deploy beschrijft hetzelfde patroon: je definieert een reeks percentages en de tool verdeelt het verkeer, met als voorbeeld fasen van 25%, 50% en 75% voor de laatste stabiele versie. In de Cloud Deploy-documentatie over canary staat ook dat elke fase een verify-job en een analysestap kan draaien om te beslissen of het mag doorgaan.

Het is geen perfecte opzet, wel een haalbare. Je hebt geen Kubernetes nodig. Een gewogen route in nginx, een Cloudflare worker die een cookie omzet, of twee Fly.io-machines achter één proxy tellen allemaal mee.

Hier is het kleinst bruikbare voorbeeld: een nginx-upstream met gewichten. Negen van de tien requests gaan naar stable, één naar de canary.

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

Er zit een zwakke plek in die je moet kennen: de verdeling gebeurt per request, dus één gebruiker kan bij opeenvolgende klikken tussen versies heen en weer springen. Als je nieuwe versie de vorm van een API-response of een databasekolom verandert, heeft die gebruiker het moeilijk. Sticky routing op basis van een cookie of user ID lost dat op, en dat is het eerste wat je toevoegt zodra de basisverdeling werkt.

Waar let je op terwijl de canary draait?

Vergelijk de canary met de stable versie op hetzelfde moment, niet met vorige week. Vorige week had ander verkeer. De vraag is altijd: is de canary slechter dan de versie die nu de andere 95% bedient?

• Foutpercentage. HTTP 5xx-fouten en onafgehandelde exceptions, gesplitst per versielabel.

• Latency. p95 en p99, niet het gemiddelde. Een gemiddelde verbergt de trage staart waar regressies zitten.

• Verzadiging. CPU, geheugen, databaseverbindingen. Een geheugenlek zie je als een helling, dus geef het tijd.

• Eén bedrijfsmetriek. Als het slagingspercentage van de checkout op de canary daalt terwijl de fouten gelijk blijven, heb je een stille bug uitgerold.

De fout die kleine teams het vaakst maken, is op een timer ophogen. Vijf minuten op 1%, dan 25%, wat de grafieken ook zeggen. Bij weinig verkeer zijn vijf minuten op 1% misschien zes requests. Dat zegt niets. Wacht op een minimaal aantal requests, niet op een minimaal aantal minuten.

Tools die dit minder handmatig maken, zijn de moeite waard zodra je echt verkeer hebt.

Canary of blue-green: wat kies je?

Blue-green houdt twee volledige omgevingen aan en schakelt in één keer al het verkeer om. Terugdraaien is dan gewoon terugschakelen, snel en schoon. De prijs: even staan 100% van de gebruikers op de nieuwe versie, en je betaalt dubbele infrastructuur tijdens de overgang.

Canary laat maar een deel de nieuwe versie zien, dus de schade bij een fout is kleiner. De prijs is complexiteit: je hebt verkeersweging nodig, metrieken per versie en een beslisregel. Terugdraaien betekent het canary-gewicht op nul zetten. Dat gaat snel, maar is niet letterlijk direct als verbindingen nog moeten uitlopen.

Drie redenen om voor canary te gaan, één reden om het niet te doen. Kies canary als een bug in productie duur is, als je genoeg verkeer hebt zodat een klein deel iets betekent, en als je metrieken per versie kunt vergelijken. Sla het over als je een paar tientallen gebruikers per dag hebt: het canary-deel is dan statistisch leeg en je gokt maar. Op die schaal is blue-green, of gewoon deployen met een snel rollback-script, het eerlijke antwoord.

Rolling updates zitten daartussenin. Ze vervangen instanties één voor één, wat zachter is, maar het is geen gecontroleerd experiment: je kiest niet wie de nieuwe versie ziet en je vergelijkt geen groepen.

Waar passen feature flags?

Een canary-deployment verdeelt het verkeer over versies van je code. Een feature flag verdeelt het gedrag binnen één versie. Mensen halen die twee vaak door elkaar, en dat is duur.

Deploy de nieuwe code naar iedereen, verborgen achter een flag die uit staat. Zet de flag daarna aan voor 1% van de gebruikers, dan 10%, dan iedereen. Dit wordt vaak een canary-release op featureniveau genoemd. Het voordeel: terugdraaien is een flag omzetten, zonder redeploy. Het nadeel: het ongebruikte codepad staat voor iedereen in productie, en flags die je laat staan worden technische schuld.

Voor een solo developer zijn flags meestal de goedkopere eerste stap. Een boolean in een configuratietabel en een hash van het user ID geven je al 80% van de waarde. Groei je daar overheen, dan neemt een managed service de targeting, auditlogs en geleidelijke percentage-uitrol over.

Wat gaat er mis met canaries in echte projecten?

Getest. Niet optimaal. Dit is waarom we het toch doen. Dit zijn de fouten die echt bijten.

Databasemigraties. Beide versies praten tegelijk met dezelfde database. Als de canary een kolom verwijdert of hernoemt, breekt de stable versie. De oplossing is het expand-and-contract-patroon: voeg eerst de nieuwe kolom toe, lever code die beide vormen aankan, en verwijder de oude kolom pas in een latere release. Sla je dit over, dan sloopt je canary de stable versie.

Stateful sessies. Als sessies in het geheugen van één instantie leven, wordt een gebruiker die tussen versies heen en weer springt uitgelogd. Zet sessiestatus eerst in een gedeelde store voordat je met canaries begint.

Cache-vervuiling. Een nieuwe versie die een ander cacheformaat schrijft, kan wat de oude versie leest corrumperen. Geef je cachesleutels een versie.

Achtergrondtaken. De canary consumeert ook queueberichten. Een bugged worker kan jobs met volle snelheid wegwerken, omdat het verkeerspercentage het queueverbruik niet begrenst. Geef de canary een eigen queue of een eigen consumentgewicht.

Alerts die niemand heeft ingesteld. De canary kan luid falen in een dashboard dat niemand opent. Automatisch afbreken bij een drempelwaarde is beter dan een mens die toekijkt, zeker om 2 uur 's nachts in Taipei of Bangkok, wanneer de enige die wakker is degene is die de deploy deed.

Hoe begin je met een canary bij een side project?

Begin kleiner dan je denkt. Je bent één developer, geen platformteam.

1. Label elke metriek met een versie. Zet de git-SHA in een header en in je logs. Zonder dit kun je canary en stable niet vergelijken.

2. Kies één afbreekregel. Bijvoorbeeld: het foutpercentage op de canary is vijf minuten lang meer dan twee keer dat van stable, dan terugdraaien. Eén regel, opgeschreven.

3. Voeg een gewogen route toe. Nginx-gewichten, een Cloudflare-regel of de verkeersverdeling van je hostingplatform. De meeste managed platforms bieden inmiddels percentage-routing zonder extra tooling.

4. Ship eerst iets saais. Een tekstwijziging, geen herschrijving van de prijspagina. Oefen de ophoging en de rollback terwijl er niets op het spel staat.

5. Meet de rollback. Draai hem een keer echt. Kost het tien minuten gepruts, dan is dat het punt om te verbeteren, niet de ophoging.

Als je project nog in de fase zit van uitzoeken wie ervoor betaalt, is dit waarschijnlijk voortijdig. Ship gewoon, houd een rollback-script bij de hand en kom op canaries terug zodra een storing je echte klanten zou kosten. Staat het er al wel, dan is de gewogen route plus één afbreekregel een weekend werk, en het verdient zich terug de eerste keer dat een slechte release sterft bij 1% in plaats van bij 100%.

Moet je alles via een canary uitrollen?

Nee. Configuratiewijzigingen, tekstcorrecties en een typefout in een footer hebben geen ophoging nodig. Gebruik canaries voor de wijzigingen waar een fout geld of vertrouwen kost: betalingen, authenticatie, datamodellen, alles op het hot path. Een pipeline die elke commit een uur lang ophoogt, wordt de eerste keer dat iemand haast heeft omzeild, en een omzeild proces is erger dan geen proces.

Dus wat is de riskantste wijziging in je volgende release, en wat zou het kosten om die eerst naar 1% van de gebruikers te sturen?