In het midden van een migratie van een traditionele omgeving naar Kubernetes verwijderden Spotify-ingenieurs per ongeluk een operationele cluster. In een daaropvolgende poging zich te wapenen tegen dergelijke vergissingen, smeten ze er nog twee de vuilbak in. Toch bleef de muziek spelen.
Spotify migreerde recent van een traditionele omgeving met virtuele machines naar een container-ecosysteem, georchestreerd door Kubernetes. Die migratie verliep niet van een leien dakje. Dat komt David Xia, Infrastructure Engineer bij Spotify, zelf vertellen op het podium van KubeCon in Barcelona.
Spotify maakt gebruik van de Google Cloud en wilde zijn diensten overzetten naar een cloud-native omgeving met microservices en containers, beheerd via Kubernetes. Daarvoor koos de muziekstreamingdienst voor de Google Kubernetes Engine (GKE), Googles beheerde Kubernetes-dienst. “Het is erg eenvoudig om Kubernetes-clusters te maken en te configureren met GKE”, weet Xia. “Helaas kan je ze ook heel eenvoudig verwijderen.”
Oeps
De ingenieur zelf was op een bepaald moment tests aan het uitvoeren op een daartoe bestemde test-cluster, die hij in een tabblad naast het operationele cluster voor de VS open had. Na de tests klikte hij netjes op verwijderen, en je kan al raden wat er gebeurde. “Zodra je bevestigt, is er geen manier om het verwijderproces te stoppen”, herinnert Xia zich levendig. Op dat moment had Spotify drie clusters operationeel: één in de VS, één in Azië en één in Europa. Na het verwijderen bleven er nog twee over.
Na de tests klikte hij netjes op verwijderen, en je kan al raden wat er gebeurde.
Xia en zijn team waren vastbeloten om een dergelijk fiasco nooit meer te laten gebeuren. Deel van dat plan hield in om de hele infrastructuur te codificeren. Voor dat plan deden ze beroep op de Terraform-tool, waar ze geen ervaring mee hadden. Bij de implementatie liep er iets mis, waarna Terraform het Azië-cluster de vuilbak in smeet. Het team schakelde snel, paste enkele configuratie-instellingen aan en het nog maar pas herstelde VS-cluster verdween plots mee.
Geen voelbare impact
Hoewel het hier telkens om clusters in een operationele productie-omgeving ging, merkten eindgebruikers niets van het drama dat zich achter de schermen afspeelde. Sterker nog: terwijl Xia en zijn infrastructuur-team hun best deden om het probleem te verhelpen, ondervonden zelfs ontwikkelaars binnen het feature-departement, dat gebruik maakt van Xia’s infrastructuur, geen hinder. Op die manier is de dubbele mislukking eigenlijk een succesverhaal: hoe kon Spotify tot tweemaal toe falen zonder enige impact?
Niet toevallig, vertelt Xia, en daar zit de interessante les van zijn keynote. Spotify bleef draaien omdat het infrastructuur-team de nodige voorzorgen had genomen en niet over één nacht ijs is gegaan voor de migratie.
Voorzie het ergste
“Vanaf dag één planden we voor een ramp”, legt Xia uit. Zijn team besefte dat het voor de monumentale uitdaging stond om een enorme kritieke infrastructuur te migreren en besloot dat het een slecht idee was om alles in één keer te doen. Een graduele migratie maakte ruimte voor redundancy, en dat heeft de muziekdienst gered.
“Toen ik het cluster verwijderde, was de migratie nog niet rond. Een groot deel van de infrastructuur draaide nog op klassieke machines. Vooraf bouwden we een failover-systeem in, waarbij het uitvallen van een Kubernetes-cluster voor een automatische opstart van virtuele machines in de oude infrastructuur zou zorgen. Services werden daar naadloos heropgestart, met geen enkel merkbaar gevolg voor eindgebruiker of zelfs feature-ontwikkelaar.
Back-ups en tests
Vervolgens rolden Xia en zijn team een back-upstrategie uit voor de Kubernetes-migratie, van in het begin. Tijdens de uitrol werden de clusters al ieder uur geback-upt, zodat Xia een recente back-up had om naar terug te grijpen voor herstel. Dat herstel verliep bovendien vlot, omdat de back-ups al getest waren. “Zolang je een back-up niet probeerde te herstellen, heb je eigenlijk geen echte back-up”, vindt Xia.
“Zolang je een back-up niet probeerde te herstellen, heb je eigenlijk geen echte back-up.”
Terwijl de failover essentiële diensten draaiende hield op de oude infrastructuur, hadden de ontwikkelaars tijd om de clusters vanuit de back-up opnieuw te configureren. Dat ging aanvankelijk niet zo vlot. In eerste instantie hadden ze meer dan drie uur nodig om alles te herstellen. Xia: “Dankzij de best practices die we in de marge van dat herstel opdeden, kunnen we het intussen op een uur.”
Geen schuldgevoel maar een leerkans
Tot slot ziet Xia de leercultuur van Spotify als een troef. “We nemen mensen hun fouten niet kwalijk, maar maken van de gelegenheid gebruik om te leren zodat we ze later niet meer maken.” Xia’s team was volgens hem erg steunend in het hele proces. “Ze zagen het positieve ervan in, en haalden aan hoe het goed was dat zoiets nu gebeurde, voor de volledige migratie was afgerond”, weet hij nog. “Al stopte het positivisme net voor ‘dankjewel om ons deze les te leren op een vrijdag’.”
Wat jij kan opsteken van het verhaal vat David Xia samen in drie eenvoudige principes: “Migreer een grote omgeving in fases, plan voor mislukkingen en voorzie een terugvalmogelijkheid. Voorzie en test back-ups vanaf het eerste moment en grijp tegenslag aan om bij te leren.”