10 grunde til at din applikation crasher i skyen

Oppetid er ikke kun driftsfolkenes ansvar, og udviklerne kan afhjælpe en række af de årsager, som oftest fører til problemer med applikationer i skyen.

SAN FRANCISCO: Selvom man lægger sin applikation i skyen, så slipper man ikke af med alle driftsproblemer. Men når skyen har næsten ubegrænset kapacitet, så bliver det vigtigt, at udviklerne hjælper driftsfolkene med at løse flaskehalsene, som ikke altid bare løser sig med flere kerner eller mere hukommelse.

»Det handler om som app-udvikler at designe sine applikationer på en måde, hvorpå der er indbygget funktioner, som hjælper med at sikre mod nedbrud automatisk,« sagde Luke Stone fra supportafdelingen hos Google Cloud på Google Cloud Next-konferencen i San Francisco.

Googles supportafdeling har fundet frem til 10 scenarier, som er hyppige årsager til, at an applikation går ned. Og der er måder, hvorpå applikationen går ned mere elegant end det totale crash.

Overload

Overbelastning på grund af flere brugere, end en kritisk komponent i din applikation kan håndtere, er et almindeligt problem, hvor skyen gør det ekstra svært, fordi trafikken som regel kan nå helt ind til selve applikationen i stedet for at blive afvist af en firewall eller load balancer.

»Hvis du eksempelvis lige har lanceret et nyt spil, og du får 50 gange så mange brugere, som du havde forventet - og det sker hele tiden på skyen, fordi vi har et virkelig godt netværk og alt omkring din applikation kan skalere. Load balanceren vil med glæde smide millioner af forespørgsler i din retning, og firewallen er distribueret over hele datacentret,« siger Luke Stone.

I stedet for blot hovedkulds at bede driftsfolkene om flere servere, så bør man sørge for at indbygge mekanismer, der kan holde applikationen nogenlunde kørende, indtil infrastrukturen er skaleret til en passende størrelse. Det kan eksempelvis ske ved at smide brugere af, når kapaciteten når maksimum.

Tanken er, at det er bedre, at nogle brugere får den normale oplevelse, og så må resten få en fejlmeddelelse i første omgang.

Noisy neighbor

En ting er en overbelastning af legitime brugere, noget andet er, hvis belastningen kommer fra spambots eller endda dit eget backup-script, som optager ressourcer på det forkerte tidspunkt.

»Lige så snart du har brugere, så får du også spam-brugere, og det kan være 10 gange så stort,« siger Luke Stone.

Ved en simpel overbelastning er det ok, at man afviser eksempelvis hver anden bruger, men hvis man har problemer med spam, så skal man tænke sig lidt mere om, og eksempelvis sætte begrænsninger på, hvor mange forespørgsler hvert bruger-id kan generere inden for et vist tidsrum.

Her er det en god idé at lave mekanismen til afvisning på en måde, så det er nemt at ændre uden at skulle udrulle en opdateret version af koden.

Retry spikes

Brugere - eller din mobilapplikation - som bliver afvist af serveren, vil forsøge igen. Det skaber mere trafik, som også skal håndteres.

»Med micro-services bliver det lidt mere tricky, fordi de enkelte dele kan eskalere retry-forsøgene,« siger Luke Stone.

Som regel vil man med en mobilapp kunne sørge for, at den ikke laver for mange forsøg - en almindelig metode er eksponentiel backoff, hvor man først venter 1, 2, 4 sekunder og så videre.

Eventuelt kan man også lade klienten fortælle serveren, hvilket forsøg der er tale om, så serveren kan prioritere. Som sidste udvej kan man bruge tar-pitting, hvor serveren udnytter sin maksimale svartid for at forsinke de næste forsøg.

Bad dependency

En ting er at have beregnet sin kapacitet og sat applikationen op til at smide alt over en vis grænse væk. Men hvis en enkelt komponent eller service begynder at køre langsommere end forventet, så skal applikationen også kunne håndtere det.

Man bør gøre sin applikation bevidst om, at grænsen kan være fleksibel. Eksempelvis ved at indbygge en mekanisme, som gør de bagvedliggende services i stand til at fortælle de foranliggende, hvornår svartider eller kapaciteten er ved at være overskredet, så de kan regulere mængden af forespørgsler, som sendes videre.

Man er nødt til at forvente, at der opstår udsving i kapaciteten i forhold til det normale. Det kan også gælde for cloud-services, man benytter, hvor man for eksempel kan have en storage-service, som har hurtige svartider, men i forbindelse med opdateringer måske falder til dårligere svartider. Det vil som regel stadig være inden for cloud-udbyderens SLA-værdier, men hvis man har testet og skaleret efter et normalt scenarie, hvor ydelsen er bedre end i SLA'en, så kan man stå med et problem.

Her bør man teste for at se, hvordan applikationen håndterer både gradvise og spontane udsving i belastningen, og så implementere en form for dynamisk load-shedding, som kan justere til den aktuelle kapacitet.

Scaling boundries

En større virtuel maskine er ikke altid et godt svar på skalering. I stedet kan det være bedre at skalere til flere virtuelle maskiner.

»Mange af os er nok mærket af, hvor besværligt det før kunne være at bede om en ekstra server. Det er man nødt til at komme ud over, for du kan få en ny virtuel maskine i løbet af få sekunder,« siger Luke Stone.

Man kan sætte applikationen til selv at bede om at skalere, når der er behov for, og så sætte begrænsninger for, hvor mange nye instanser der kan åbnes.

Det kræver, at man er i stand til at opbygge sin applikation i dele, som kan splittes op på nye instanser, eksempelvis ved hjælp af sharding. Det er ikke nødvendigvis nemt, og derfor er det en god idé at begynde på at gøre sin applikation klar til det tidligt i processen.

Uneven sharding

Problemet med sharding er, at du vil få shards, som belastes forskelligt. Derfor kan der være enkelte shards, som oplever ekstremt større belastning end andre.

I så fald er det en god strategi at kunne opsplitte en shard. Fordelen er, at det kun påvirker en enkelt shard, men det hjælper ikke, hvis det er en enkelt del, som ikke kan opdeles, der er skyld i belastningen, for så vil den nye shard, hvor den havner, også blive overbelastet.

Pets

Det er en klassisk tankegang fra stordrift af datacentre, at man ikke må tænke på sine servere, fysiske såvel som virtuelle, som sine kæledyr (pets), men skal tænke på dem som kvæg (cattle).

Den måske lidt brutale sammenligning er, at ingen græder over en død ko på en kvægfarm, men man græder over det døde kæledyr. Tilsvarende er en død server blot en omkostning, ikke noget man skal forsøge at reparere.

»Pets har som regel én person, der er ansvarlig for maskinen, og hvis du har en maskine, ingen tør pille ved, så er det nok et kæledyr,« siger Luke Stone.

Hvis man skriver det ned, hvilke maskiner der opfattes som kritiske, så kan man blive mere bevidst om, at man har gjort en maskine til et kæledyr og gøre noget ved det.

Bad deployment

På et eller andet tidspunkt kommer man til at udrulle en opdatering, som får noget til ikke at virke. Det kan både være opdateringer af koden og af konfigurationen.

»Hos Google håndterer vi konfiguration på samme måde som kode, så vi ruller kode og konfiguration ud på samme måde,« siger Luke Stone.

Selv med unit testing og andre metoder til at undgå en skidt udrulning, så kan det gå galt, så derfor bør man sørge for at have procedurer og mekanismer på plads til hurtigt at redde systemerne fra den dårlige udrulning.

Det er bedre at rulle tilbage end at forsøge at rette fejlen med det samme med risiko for at introducere flere problemer. Det kan også være en god idé at sørge for, at man kan rulle ud på nogle få maskiner til at begynde med, hvis man har et meget distribueret system.

Monitoring gap

Det kan være svært at finde ud af, om softwareopdateringen fungerer korrekt. Det kræver, at man indsamler de rigtige målinger. Selvom man ser på cpu og RAM, så er det ikke sikkert, at det afspejler oplevelsen for brugeren.

»Hvis du ruller en ny funktion ud, så ser du måske et stort spring i I/O, fordi der er en masse nye tabeller, som skal fyldes ud. Det kan se skræmmende ud for driftsfolkene

Mål eksempelvis på antal fejlmeddelelser til brugerne eller svartider. Det bør man bygge direkte ind i de biblioteker, man bruger i sine micro-services.

Failure domains

Hvilke store klumper af din infrastruktur kan fejle på samme tid? Hvis du kender dem, så kan du lettere opbygge en backup, fordi du så ved, hvilket punkt du skal gendanne fra og hvortil.

»Du bør ikke prøve at træffe sådanne beslutninger, når det hele er gået ned,« siger Luke Stone.

I skyen bør du have styr på, hvilke zoner der er problemer med snarere end blot de enkelte noder. Tilsvarende kan det være en god idé at opdele sin applikation i forskellige zoner, der kan gå ned. Det kunne eksempelvis være forskellige typer brugere, så de ikke alle går ned på samme tid, og du har mulighed for at genskabe tjenesten for forskellige grupper i den rækkefølge, du ønsker.

Se hele oplægget fra Luke Stone i videoen:

Version2 er inviteret til Google Cloud Next af Google.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Følg forløbet

Kommentarer (0)

Log ind eller opret en konto for at skrive kommentarer

Pressemeddelelser

Big Data Lake Summit: Fast and Trusted Insights

If you want to outpace, outsmart and outperform your competition in a digital world, you need trusted data that can be turned into actionable business insights at speed.
24. apr 2017

Welcome to Free course to learn about the combined power of Alteryx and Qlik!

Affecto invites to a free course, where we want to share our knowledge of this self-service analysis platform together with the power of Qlik.
20. apr 2017

Robotics Process Automation (RPA) changes the way organizations think about and perform work at a reduced cost, higher efficiency and greater productivity

Join us for this exiting seminar, which Affecto hosts with our business partner SmartRPA May 3rd, 2017 at 13.00 in Copenhagen.
30. mar 2017