Uitleg storing 26-02-2020

Waarom NLZIET gisteravond niet werkte

 

Beste lezer (en hopelijk gebruiker van NLZIET),

 

Gisteravond, 26 februari 2020, heeft ons platform er vanaf 20.30 uur bijna volledig uit gelegen. Dit had het vervelende gevolg dat onze gebruikers vanaf die tijd tot ver in de nacht niet of nauwelijks gebruik konden maken van NLZIET.

 

Met dit artikel wil ik een kijkje achter de schermen geven van wat er gisteravond is gebeurd. Bij NLZIET vinden we transparantie belangrijk. Naast het delen van successen willen we daarom ook dat onze gebruikers een goede uitleg krijgen wanneer dingen niet gaan zoals ze zouden mogen verwachten.

 

De korte versie is, door technische redenen kon vrijwel geen enkele app meer contact maken met de NLZIET-servers waardoor het kijken van programma’s onmogelijk was.

 

In de rest van deze blog leg ik uit welke redenen dit dan precies waren. Waarschuwing vooraf: deze blog is vrij technisch van aard.

 

Architectuur

Om te kunnen begrijpen wat er mis is gegaan, zal ik eerst heel globaal een introductie geven hoe NLZIET er qua IT-architectuur uitziet, voor wat betreft de onderdelen die er voor deze uitleg toe doen.

 

Om als gebruiker programma’s op NLZIET te kunnen kijken, zijn er twee dingen belangrijk: de streams en onze api.

 

Voor de streams hebben wij vier verschillende locaties (één voor de Live en Replay streams en de Video-On-Demand streams van de NPO, RTL en Talpa komen elk van een aparte locatie).

 

Daarnaast hebben we de api, dit is een REST-achtige webservice. Deze api zorgt voor alle communicatie met de apps, behalve het uitspelen van de daadwerkelijke videostreams. Dit zijn bijvoorbeeld lijsten van welke programma’s er beschikbaar zijn, de tv-gids en de zoekresultaten. Ook controleert de api of een gebruiker nog een geldig abonnement heeft voordat we een video laten afspelen. Juist deze api zorgde voor de problemen.

 

Attack of the smart tv’s

De problemen begonnen vorige week na de uitrol van de 4.1 versie van onze smart tv app. Binnen deze app zit op sommige platformen de zogenoemde ‘Preview’-functie. Deze functie haalt bij onze api een rijtje programmatitels (json) op en toont deze als suggestie. Deze preview toont al voordat je de smart tv-app opent, welke programma’s je kunt kijken bij NLZIET. Het probleem is dat deze call (het ophalen van het rijtje programmatitels) erg veel gebeurde. Met erg veel bedoel ik dat dit op momenten ruimschoots het merendeel van alle requests veroorzaakte.

 

Hier is natuurlijk een aantal oplossingen voor te bedenken. De gemakkelijkste is het uitschakelen van deze functionaliteit in de app. Helaas is het zo dat dit alleen kan door een nieuwe app in te dienen bij de fabrikant. Door strenge kwaliteitseisen en een uitgebreid testtraject per app duurt dit erg lang (soms zelfs weken). We hebben inmiddels een nieuwe app ingediend, maar dit bood dus op korte termijn geen oplossing.

 

Daarnaast hebben we nog een aantal oplossingen ingezet door bijvoorbeeld simpelweg dit endpoint uit te schakelen op de api en meer van soortgelijke tactieken. Helaas bleek dit soms even te werken, maar kwamen de requests hierna toch weer in grote getalen terug met helaas soms downtime tot gevolg.

 

Gisteren bereikte deze lawine aan requests een maximum waardoor, ondanks de extra cloud resources die we hadden ingezet, de servers het niet meer hielden en de api niet meer volledig reageerde. Vanaf dat moment was het niet of nauwelijks mogelijk om NLZIET te gebruiken.

 

Ter illustratie:

Storingsuitleg NLZIET

De eerste blauwe pijl geeft het verloop van een normale avondspits op NLZIET aan (deze is zelfs al iets hoger dan normaal vanwege de genoemde preview requests). De tweede blauwe pijl geeft aan hoe groot de piek was toen om 20.30 uur de servers er massaal de brui aan gaven.

 

Misfortune never comes alone

NLZIET wordt gehost op een cloud platform. Dat betekent dat wij vrij eenvoudig extra servers kunnen toevoegen om te anticiperen op extra drukte. Op het moment dat de servers het ondanks de extra capaciteit leken te begeven, hebben we twee dingen gedaan om de problemen te verhelpen.

 

De eerste stap was het inschakelen van Cloudflare. Cloudflare is een extra laag om de api heen die bescherming kan bieden tegen DDOS aanvallen en waar je daarbij ook extra firewall regels kunt instellen. Hier hebben we het endpoint van de preview functie in geblokkeerd.

 

Daarnaast hebben we een extra uitrol gedaan met daarin een nieuwe json die ervoor moest zorgen dat ook zonder Cloudflare de hoeveelheid requests vanuit de televisies enigszins beheersbaar zou worden. Helaas, zoals de Engelsen al zeggen “Misfortune never comes alone”.

 

Een uitrol op ons cloudplatform werkt als volgt. Er worden nieuwe servers aangemaakt, hier wordt de nieuwe code naartoe gedeployed. Wanneer dit volledig is afgerond wordt het IP van de huidige servers (of eigenlijk de loadbalancer) omgewisseld met dat van de nieuwe servers. Dit heet swappen.

 

Na deze uitrol bleken de servers helaas onbereikbaar, wat we verder ook probeerden met terugswappen, schalen naar nog krachtigere of nog meer servers, het probleem bleef en de api bleef niet of heel traag werken.

 

Op dit moment zat hier al een volledig team aan te werken. Met man en macht werd geprobeerd om de api weer aan de praat te krijgen.

 

Rond 24.00 uur kwam er uitsluitsel vanuit de cloud provider dat er onderhoud aan de infrastructuur werd gepleegd en dat daardoor bij het swappen telkens enkele servers ‘verdwaald’ raakten en hierdoor niet bereikbaar. Rond 3.00 uur ’s nachts was dit onderhoud voorbij en na nog een laatste keer opschalen (voor de zekerheid nog maar weer naar een niveau hoger), reageerden de servers weer naar behoren.

 

Huidige situatie en conclusie

De problemen met de grote hoeveelheid requests hebben we nu opgelost door deze te blokkeren in Cloudflare. Als back-up hierachter hebben we onze servers maximaal opgeschaald staan. Dit laten we voorlopig zo. Daarnaast doen we er natuurlijk alles aan om de app zo snel mogelijk te laten updaten zodat de json requests naar een aparte server kunnen. Op deze manier kan onze core api niet meer naar beneden gehaald worden.

 

Wat betreft het onderhoud, we zijn in gesprek met onze leverancier over hoe we beter op de hoogte kunnen zijn van wanneer dit onderhoud is. Daarnaast nemen we ook stappen zodat we onze servers bij gepland onderhoud tijdelijk naar een ander datacenter (van dezelfde cloud provider) kunnen verplaatsen.

 

Al met al begrijp ik dat bovenstaande uitleg een schrale troost is voor een NLZIET-abonnee die woensdagvond klaar zat om tv te kijken. Met dit blogartikel hoop ik in ieder geval zo transparant mogelijk te delen wat er precies is gebeurd en welke stappen wij continu zetten om te zorgen dat onze gebruikers optimaal van ons aanbod kunnen blijven genieten.

 

Voor wie tot hier gekomen is, bedankt voor het lezen en veel kijkplezier!

 

Sander Kouwenhoven
Director of IT
[email protected]