Gunnar Brataas er seniorforsker ved SINTEF IKT.
Av Gunnar Brataas, seniorforsker, SINTEF
En vond drøm har de felles, både programvare-leverandører og alle foretak som er avhengige av at datasystemer fungerer. Marerittet er at et program krasjer fordi det ikke tåler mange nok brukere. Eller fordi brukerne gir systemet for tunge oppgaver. «Programmet har skaleringsproblemer», er fagtermen for dette.
Om litt blir det forebyggende hjelp å få mot slike datakrasj.
To grøfter å gå i
På skaleringsområdet er det i dag to grøfter å gå i for systemutviklere. Den ene fella er å droppe all forhåndsvurdering av programmets skalerbarhet – det vil si dets evne til å håndtere økende arbeidsmengder.
Dette er som med brannforsikring. Så lenge huset står, er det billig å droppe premien. Men det er en dyr strategi om huset brenner. Hvis sentrale offentlige tjenester går ned grunnet skaleringsvansker, har samfunnet et stort problem.
Den andre fella er ukritisk bruk av tilgjengelige analyseverktøy på området. Slike verktøy er ikke enkle å bruke. I tillegg krever de informasjon som er vanskelig å finne. Verktøyene kan derfor gjøre utviklingsprosjekter tidkrevende – og gi resultater som er for usikre til å ha verdi.
Trygg vei mellom fellene
Med Forskningsrådet og norske systemeiere i ryggen, er vi i SINTEF i gang med å utvikle en metode som ligger trygt mellom de to grøftene.
Første trinn i metoden er at de som skal bruke programmet, lager skalerbarhetskrav: På passende detaljeringsnivå må de beskrive hvor mange som maksimalt skal bruke programmet samtidig, og hvilke datamengder de bruker.
Ved å teste biter av det kommende programmet underveis i utviklingsprosjektet og sammenlikne testresultatene med kravet, får utviklerne vite hvordan de ligger an. I dag lages slike krav sjelden. Da er det vanskelig å sjekke fremdriften.
Som å bære tunge flygel
Metoden vil også vise utviklerne hvordan de får grovbilder av en sammenheng som programmers suksess står og faller med: Forholdet mellom maskinvareressurser og programmets skalerbarhet. Maskinvareressurser innbefatter antall og størrelse på prosessorer (CPUer), samt antall og størrelse på disker og nettverk. For enkelhets skyld kan vi snakke om antall prosessorer.
Det hele likner dilemmaet en nybakt huseier står overfor på flyttedagen, idet et tungt flygel skal bæres inn. Hvor mange venner er det optimalt å hyre inn til bæringen? Eller mer presist: Hvor går grensen før de ikke klarer å samarbeide? Passeres denne grensen, blir effekten av en ekstra bærer liten, og etter hvert null. Til slutt kan virkningen bli negativ.
Slik er det også med forholdet mellom antall prosessorer og dataprogrammers kapasitet. Når antall prosessorer øker, får de etterhvert problemer med å dele på arbeidsoppgavene. Da flater kapasiteten ut, for så å synke.
Håp om færre mareritt
Oppstår det tvil om bruken av et program vil kreve et antall prosessorer som får kurven til å flate ut, må utviklerne spørre seg: Bør vi konstruere programmet slik at det yter mer med færre prosessorer?
Et slikt alternativt system kan bli dyrere. Men det å unngå skaleringsproblemer er kanskje verdt den ekstra investeringen? At slike spørsmål tidlig kommer på bordet og så gjennomdrøftes, er avgjørende for å forebygge fremtidige skaleringsproblemer.
Vi skal arbeide i snaut tre år med å utvikle og teste ut metoden. Alt nå har vi godt håp om at resultatene vil spare programutviklere og kundene deres for noen av marerittene som lurer på skaleringsfeltet.
