Hantera svanslatens
- 13 minuter
Vi har redan diskuterat flera optimeringstekniker som används i molnet för att minska svarstiden. Några av de åtgärder som vi har studerat är att skala resurser vågrätt eller lodrätt och använda en lastbalanserare för att dirigera begäranden till närmaste tillgängliga resurser. Den här sidan går djupare in på varför det i ett stort datacenter eller molnprogram är viktigt att minimera svarstiden för alla begäranden och inte bara optimera för det allmänna fallet. Vi kommer att studera hur även några extremvärden med hög latens avsevärt kan försämra den observerade prestandan för ett stort system. Den här sidan beskriver också olika tekniker för att skapa tjänster som ger förutsägbara svar med låg svarstid, även om de enskilda komponenterna inte garanterar detta. Det här är ett problem som är särskilt viktigt för interaktiva program där den önskade svarstiden för en interaktion är under 100 ms.
Vad är svanslatens?
De flesta molnprogram är stora, distribuerade system som ofta förlitar sig på parallellisering för att minska svarstiden. En vanlig teknik är att skicka vidare en begäran som tas emot på en rotnod (till exempel en frontend-webbserver) till många lövnoder (backend-servrar). Prestandaförbättringen drivs av parallelliteten i den distribuerade beräkningen, och även av det faktum att extremt dyra kostnader för dataflytt undviks. Vi flyttar helt enkelt beräkningen till den plats där data lagras. Naturligtvis hanterar varje lövnod samtidigt hundratals eller till och med tusentals parallella förfrågningar.
Bild 7: Svarstid på grund av utskalning
Överväg exemplet med att söka efter en film på Netflix. När en användare börjar skriva i sökrutan genereras flera parallella händelser från rotwebbservern. Dessa händelser innehåller minst följande begäranden:
- Till autocomplete-motorn, för att faktiskt förutsäga sökningen som görs baserat på tidigare trender och användarens profil.
- Till korrigeringsmotorn, som hittar fel i den typerade frågan baserat på en ständigt anpassningsbar språkmodell.
- Enskilda sökresultat för var och en av komponentorden i en fråga med flera ord, som måste kombineras baserat på filmernas rangordning och relevans.
- Ytterligare efterbearbetning och filtrering av resultat för att uppfylla användarens inställningar för "säker sökning".
Sådana exempel är mycket vanliga. En enda Facebook-begäran är känd för att kontakta tusentals memcached-servrar, medan en enda Bing-sökning ofta kontaktar över tio tusen indexservrar.
Det är uppenbart att behovet av skalbarhet har lett till en stor fan-out i backend-delen för varje enskild begäran som hanteras av frontend-delen. För tjänster som förväntas vara "dynamiska" för att behålla sin användarbas visar heuristik att svar förväntas inom 100 ms. När antalet servrar som krävs för att lösa en fråga ökar beror den totala tiden ofta på det sämst presterande svaret från en lövnod till en rotnod. Förutsatt att alla lövnoder måste slutföra körningen innan ett resultat kan returneras måste den övergripande svarstiden alltid vara större än svarstiden för den enskilt långsammaste komponenten.
Precis som de flesta stokastiska processer kan svarstiden för en enskild lövnod uttryckas som en distribution. Årtionden av erfarenhet har visat att i det allmänna fallet kommer de flesta (>99%) begäranden från ett väl konfigurerat molnsystem att köras extremt snabbt. Men ofta finns det mycket få extremvärden i ett system som körs extremt långsamt.
Bild 8: Exempel på tail latens5
Tänk dig ett system där alla lövnoder har en genomsnittlig svarstid på 1 ms, men det finns en sannolikhet på 1% att svarstiden är större än 1 000 ms (en sekund). Om varje fråga endast hanteras av en enskild lövnod är sannolikheten för att frågan tar längre tid än en sekund också 1%. Men när vi ökar antalet noder till 100 sjunker sannolikheten att sökfrågan kommer till avslut inom en sekund till 36,6%, vilket innebär att det finns en 63,4% chans att sökfrågans varaktighet bestäms av den nedre svansen (lägst 1%) för latensfördelningen.
$(.99^{100})$
Om vi simulerar detta för en mängd olika fall ser vi att när antalet servrar ökar är effekten av en enskild långsam fråga mer uttalad (observera att diagrammet nedan ökar monotont). Eftersom sannolikheten för dessa avvikande värden minskar från 1% till 0,01%är systemet betydligt lägre.
Bild 9: Nyligen genomförd studie av sannolikhet för svarstid som visar den 50:e, 95:e och 99:e percentilen för svarstid för begäranden4
Precis som vi har utformat våra program för att vara feltoleranta för att hantera problem med resurstillförlitlighet bör det nu vara tydligt varför det är viktigt att program är "tail toleranta". För att kunna göra detta måste vi förstå källorna till dessa långa prestandaavvikelser och identifiera åtgärder där det är möjligt och lösningar där inte.
Variabilitet i molnet: Källor och åtgärder
För att lösa svarstidens variabilitet som leder till det här problemet med svarstid måste vi förstå källorna till prestandavariationer. 1
- Användning av delade resurser: Många olika virtuella datorer (och program inom dessa virtuella datorer) kämpar för en delad pool med beräkningsresurser. I sällsynta fall är det möjligt att den här konkurrensen leder till låg svarstid för vissa begäranden. För kritiska uppgifter kan det vara klokt att använda dedikerade instanser och regelbundet köra benchmarks när de är inaktiva för att säkerställa att de fungerar korrekt.
- Bakgrundsdaemoner och underhåll: Vi har redan talat om behovet av bakgrundsprocesser för att skapa kontrollpunkter, skapa säkerhetskopior, uppdatera loggar, samla in skräp och hantera resursrensning. Dessa kan dock försämra systemets prestanda vid körning. För att minimera detta är det viktigt att synkronisera störningar på grund av underhållstrådar för att minimera påverkan på trafikflödet. Detta gör att alla varianter sker i ett kort, välkänt fönster i stället för slumpmässigt under programmets livslängd.
- Köbildning: En annan vanlig källa till variabilitet är trafikens ankomstvariation. 1 Denna variabilitet förvärras om operativsystemet använder en annan schemaläggningsalgoritm än FIFO. Linux-system schemalägger ofta trådar i fel ordning för att optimera det övergripande dataflödet och maximera användningen av servern. Studier har funnit att användning av FIFO-schemaläggning i operativsystemet minskar svarstiden på bekostnad av att sänka systemets totala dataflöde.
- Allt-till-alla-incast: Mönstret som visas i bild 8 ovan kallas för allt-till-alla-kommunikation. Eftersom den mesta nätverkskommunikationen sker via TCP leder detta till tusentals samtidiga begäranden och svar mellan klientwebbservern och alla serverdelsbearbetningsnoder. Detta är ett extremt späckat kommunikationsmönster och leder ofta till en speciell typ av överbelastningsfel som kallas TCP-incastkollaps. 1, 2 Det intensiva plötsliga svaret från tusentals servrar leder till många borttagna och återsända paket, vilket så småningom orsakar en nätverks lavin av trafik för datapaket som är mycket små. Stora datacenter och molnprogram behöver ofta använda anpassade nätverksdrivrutiner för att dynamiskt justera TCP-mottagningsfönstret och timern för återöverföring. Routrar kan också konfigureras för att släppa trafik som överskrider en viss hastighet och minska storleken på sändningen.
- Energi- och temperaturhantering: Slutligen är variabilitet en biprodukt av andra tekniker för kostnadsminskning som att använda inaktiva tillstånd eller nedskalning av CPU-frekvens. En processor kan ofta ägna en icke-trivial tid åt att skala upp från ett inaktivt tillstånd. Att stänga av sådana kostnadsoptimeringar leder till högre energianvändning och kostnader, men lägre variabilitet. Detta är mindre av ett problem i det offentliga molnet, eftersom prismodeller sällan tar hänsyn till interna användningsmått för kundens resurser.
Vissa experiment har funnit att variabiliteten hos sådana system är mycket sämre på det offentliga molnet, 3 vanligtvis på grund av ofullkomlig prestandaisolering av virtuella resurser och den delade processorn. Detta förvärras om många svarstidskänsliga jobb körs på samma fysiska nod som processorintensiva jobb.
Leva med variabilitet: Tekniska lösningar
Många av källorna till variabilitet ovan har ingen idiotsäker lösning. I stället för att försöka lösa alla källor som blåser upp svarstidssvansen måste molnprogram därför utformas för att kunna hantera sådana variationer i svarstider. Detta liknar naturligtvis det sätt som vi utformar program så att de är feltoleranta eftersom vi omöjligt kan hoppas på att åtgärda alla möjliga fel. Några av de vanliga teknikerna för att hantera den här variabiliteten är:
- "Tillräckligt bra"-resultat: Ofta, när systemet väntar på att få resultat från tusentals noder, kan vikten av ett enskilt resultat antas vara ganska låg. Därför kan många program välja att helt enkelt svara användarna med resultat som kommer inom ett visst kort svarstidsfönster och ta bort resten.
- Kanariefåglar: Ett annat alternativ som ofta används för sällsynta kodsökvägar är att prova en förfrågan på en liten delmängd av bladnoder för att se om det orsakar en krasch eller ett fel som påverkar hela systemet. Den fullständiga utloggningsfrågan genereras endast om kanariefågeln inte orsakar ett fel. Detta liknar att skicka en kanariefågel (fågel) till en kolgruva för att testa om den är säker för människor.
- Svarstidsinducerad skyddstillsyn och hälsokontroller: Naturligtvis är en stor del av förfrågningarna till ett system för vanliga för att testa med hjälp av en kanariefågel. Sådana begäranden är mer benägna att sträcka ut sig över tid om en av bladnoderna presterar dåligt. För att motverka detta måste systemet regelbundet övervaka hälsotillståndet och svarstiden för varje lövnod och inte dirigera begäranden till noder som uppvisar låga prestanda (på grund av underhåll eller fel).
- Differentiell QoS: Separata tjänstklasser kan skapas för interaktiva begäranden så att de kan prioriteras i valfri kö. Svarstidsokänsliga program kan tolerera längre väntetider för sina åtgärder.
- Säkring av begäran: Det här är en enkel lösning för att minska variabilitetens inverkan genom att vidarebefordra samma begäran till flera repliker och använda svaret som kommer först. Naturligtvis kan detta fördubbla eller tredubbla mängden resurser som krävs. För att minska antalet begäranden med skydd kan den andra begäran endast skickas om det första svaret har varit i vänteläge längre än över den 95:e percentilen av den förväntade svarstiden för den begäran. Detta gör att den extra belastningen bara är cirka 5%, men minskar svarstiden avsevärt (i det typiska fallet som visas i bild 9, där svarstiden för den 95:e percentilen är mycket lägre än svarstiden för den 99:e percentilen).
- Spekulativ körning och selektiv replikering: Uppgifter på noder som är särskilt upptagna kan startas spekulativt på andra underutnytttagna lövnoder. Detta är särskilt effektivt om ett fel i en viss nod gör att den överbelastas.
- UX-baserade lösningar: Slutligen kan fördröjningen vara intelligent dold för användaren via ett väldesignat användargränssnitt som minskar den fördröjning som en mänsklig användare upplever. Tekniker för att göra detta kan omfatta användning av animeringar, visa tidiga resultat eller engagera användaren genom att skicka relevanta meddelanden.
Med hjälp av dessa tekniker är det möjligt att avsevärt förbättra upplevelsen för slutanvändarna av ett molnprogram för att lösa det märkliga problemet med en lång svans.
Referenser
- Li, J., Sharma, N. K., Ports, D. R., & Gribble, S. D. (2014). Berättelser om svansen: Hårdvara, operativsystem och Application-Level källor till svanslatens från Proceedings of the ACM Symposium on Cloud Computing, ACM
- Wu, Haitao och Feng, Zhenqian och Guo, Chuanxiong och Zhang, Yongguang (2013). ICTCP: Incast Congestion Control for TCP i Datacenter-nätverk, IEEE/ACM Transactions on Networking (TON), IEEE Press
- Xu, Yunjing och Musgrave, Zachary och Noble, Brian och Bailey, Michael (2013). Bobtail: Undvika långa svansar i molnet, 10:e USENIX-konferensen om design och implementering av nätverkssystem, USENIX Association
- Dean, Jeffrey och Barroso, Luiz André (2013). Svansen i stor skala, Kommunikationer från ACM, ACM
- Tene, Gil (2014). [Förstå svarstid – vissa viktiga lektioner och verktyg](https://www.infoq.com/presentations/latency-lessons-tools/, QCon London