Throttling - En strategi för att göra ditt IT-system mer driftsäkert

Jag är ute i sista stund, som vanligt. Väntar in till det sista att skicka in ansökan. Väl inloggad fyller jag in mina uppgifter. Det är mycket som skall väljas, kontrolleras och fyllas i. Äntligen framme på sista sidan med den sköna gröna knappen ”SKICKA IN”. En känsla av välbehag infinner sig då man känner sig klar med alla sina uppgifter. Som när man gjort klart läxan eller rabattrensningen.

KLICK låter det från musen då jag trycker på den gröna knappen. Plötsligt står tiden stilla! Det enda som rör sig är markörens snurrande animering, sekundvisaren i mitt armbandsur och min puls som plötsligt rusar…snurr snurr, dunk dunk. Men nu så! Äntligen händer något på skärmen...

HTTP 500, Internal server error!?

Du har säkert upplevt samma sak som jag beskrev i texten ovan. Någon del av systemet slutade svara på anrop. Vi var i detta fall för många som försökte skicka in ansökan samtidigt. I och med att systemet blev överbelastat och således slut på resurser så gick systemet ner för alla användare, även de som redan kommit in tidigare

Har vi testat för vad som kan hända i verkligheten?

Dessvärre är detta inte ovanligt trots att vi har levt med problem som dessa i över 20 år nu. Vi kan läsa i pressen om det ena och det andra viktiga systemet som inte klarar anstormningen. Det verkar finnas en differens på vad systemen är testat för och hur många anrop som KAN inträffa under en period. Tidsbestämda kampanjer och deadlines är kanske bra av marknadsmässiga skäl men mindre bra för en driftorganisation.  

Kapaciteten ökar stadigt på nätverk och processorkraft men också komplexiteten och datamängder i dagens IT-system. Genom att förutsättningarna för stora/komplexa operationer ökar i och med kapacitetsutvecklingen så eskaleras också dessa avancerade operationer. 

” - Vi förväntade oss inte sådan tillströmning!” 

Hur kan man göra systemet mer driftsäkert? 

Hur kan man göra systemet mer driftsäkert då? Börja med att använda timeouter. En timeout är en tidsgräns på hur lång tid ett anrop får ta innan den avbryts med automatik. Man använder timeouter för att undvika blockerade trådar. Trådar (threads) i ett system används när flera operationer skall nyttja processorkraften utan att störa varandra.  

När antalet upptagna trådar är lika med antalet möjliga är problemet ett faktum. Inga nya anrop kan då längre utföras. Man bör införa timeouter för varje tjänsteanrop för att skydda den anropande tjänsten. Använd gärna aggressiva timeouter (korta), det är ju bättre att man får ett fel snabbt än ett efter att ha väntat i många sekunder, det gäller både dig som användare och för systemet. Timeouter är ett sätt att göra systemet feltolerant. 

För att skydda systemet ytterligare och göra det än mer feltolerant kan man införa skydd som Bulkheads och Circuit Brakers. 

Bulkheads (vattentäta skott) - Delar upp tjänsteinstanser i olika grupper, baserat på konsumentbelastning och tillgänglighetskrav. Denna design hjälper till att isolera fel och gör att du kan upprätthålla tjänstefunktionalitet för vissa konsumenter, även under ett fel. 

Circuit Breakers (strömbrytare) - Kan förhindra en tjänst från att upprepade gånger försöka utföra en operation som sannolikt kommer att misslyckas. Circuit Breaker gör det också möjligt för en applikation att upptäcka om felet har åtgärdats. Om problemet verkar ha fixats kan tjänsten försöka startas igen. 

” - Vi måste utveckla systemen för fel!” 

Vad kan man göra för att undvika timeouter?

Trots ett väl optimerat system kan en oväntad belastning (burst) orsaka problem och få resurserna att ta slut. I en molnbaserad arkitektur som är vanligt idag låter ”autoskalning” som en bra lösning. MEN denna automatiska utökning av resurser sker inte omedelbart och problemen kan dessvärre öka under en tid. Dessutom är det inte troligt att alla tjänster i anropskedjan kan utökas, som exempelvis sambanden (integrationer).  

Ett alternativ till autoskala är att tillåta resurser upp till en viss nivå och att strypa (throttle) nya anrop när den nivån är uppnådd. På detta sätt skyddar man användare som redan arbetar i systemet från att påverkas negativt av nya besökare. 

Redan 2007 då jag testade prestandan på den digitala skattedeklarationen åt Skatteverket, infördes begränsningar i antalet möjliga samtidiga sessioner (användare) i produktion. Det var då jag började intressera mig för denna ”pseudo”-lösning som inte alltid låter så bra hos marknadsavdelningen, men innebär ett bra skydd mot panikbrandsläckning, ledsna användare och trista rubriker.  

Vad skall man tänka på om man vill använda Throttling? Först och främst behöver man välja en strategi som man vill att Throttlingen skall åstadkomma för just det systemet. Här följer några exempel på strategier man kan införa. 

Throttling-strategier 

• Undvika anrop från en användare som utför fler anrop per sekund under en given tidsperiod.  

• Inaktivera icke-nödvändiga tjänster för att frigöra resurser. 

• Sänk kvalitet på ex. bilder och video eller byta hela sidan mot en enklare variant. 

• Införa olika typer om kösystem för att ta hand om anropen och skapa en jämnare last. 

• Skjuta upp operationer som är lägre prioriterade. Meddela kund att detta kan göras senare.

• Förhindra nya användare när man nått ett visst antal samtidiga sessioner. Meddela att det går bra att försöka senare.

   

Fördelar 

• En väl implementerad throttling kan också motverka DDoS-attacker (överbelastningsattack), vilka inte är ovanliga idag. Attackerna är ofta avsiktliga men kan också ske av misstag. 

• Man kan styra användandet av systemet och således få kontroll på kostnaderna om de är kopplade till antal anrop. 

• Du kan klara dina uppsatta SLA krav. 

Nackdelar 

• Det kan bli oönskade effekter vid införandet. 

• Kräver en hel del testning. 

Tips och överväganden 

• Vissa av throttle-åtgärderna bör införas tidigt i arkitekturen då den kan påverka många delar i systemet.  

• Det måste ske omedelbart. Systemet måste kunna agera direkt på problem.

• Använd tydliga felmeddelanden, man har förståelse för om det är många samtidigt. 

• Prestandatester måste vara en självklar del vid införande av throttling. 

• Kommunikation med ex. Marknadsavdelningen om ev. kommande kampanjer. 

• Kommunikation med PO om ev. ökning av kunder eller ett förändrat beteende. 

• Prestandatester utförs som påvisar vad vi maximalt kan klara av. Förmedla detta till PO. 

• Tag reda på vad som händer då vi når maxtaket? Vilken komponent drabbas först? Vad för meddelande erhålls? Är det acceptabelt?

• Monitorering i produktion, kan tala om hur ligger vi till idag. Hur mycket luft har vi kvar? Behöver vi göra något inför nästa år?

Testa din strategi för att veta att det fungerar

Systemen idag består ofta av många komponenter där de skall samexistera tillsammans som ett väloljat maskineri. Det är inte lätt att förutspå vad som händer att; när komponent X får problem kommer i sin tur påverka komponenterna Y och Z. Inte heller är det lätt att förutspå vad som händer om man förändrar inställningarna som exempelvis timeout-tider.  

Vi behöver således testa av vald trottling-strategi, trimma in våra timeouter, Bulkheads och Circiut breakers. Detta görs bäst i en miljö som är designmässigt produktionslik och utföra prestandatester. Det vill säga med realistiska testfall som körs med multipla sessioner. Där de tillsammans skapar en tillräcklig hög belastning mot systemet för att bevisa att strategin fungerar som planerat. Vi identifierar också om blir det följdeffekter som vi inte förutsåg och att spjällen automatiskt öppnas igen efter att anstormningen har bedarrat. 

Sammanfattning

I takt med att kapaciteten, komplexitet och datamängder ökar på nätverk och IT-system så behöver vi göra våra system mer driftsäkra för att undvika lappande och lagande, missnöjda användare och dålig publicitet. En metod är att använda Throttling som stryper nya anrop och inför begränsningar i antalet samtidiga sessioner för att undvika överbelastning. En av fördelarna är att man kan styra användandet av systemet och således få kontroll på kostnaderna om de är kopplade till antal anrop.

Vill du veta mer om Throttling eller har frågor kring prestanda så tar jag gärna en kaffe och pratar mer. Hör av dig på mejlen, slå en pling (+46 705 171709) eller connecta på

Linkedin.