skalerbare systemer

1

Skalerbare systemer –Modellering for skalerbarhet

Tormod Varhaugvik, SITS-IS-UTVJuni 2010

2

29.02.2012Skatteetaten – Skalerbare systemer 2

Bakgrunn

•Store systemer behandler store mengder data og logikk på de•Kompleksiteten er svært stor

•,og den har vokst seg inn i løsningene over tid•både funksjonelle krav •og ikke funksjonelle krav

•Hva er essensiell kompleksitet?•Skatteberegning / Avgiftsberegning / Renteberegning / Klassifisering

•Hva er inngrodd kompleksitet?•Beslutninger over tid / For store systemer / Mangel på struktur

•Tjenesteorientering er en del av basisen•Bevisst valg av arkitektur er med på å redusere kompleksitet•Arkitekturen er kompleks (for å redusere kompleksitet i det vi lager)

Beskrive hvordan man i samme logikk henter informasjon og sjekker ting underveis+++

Mangel på struktur er både del-systemer med data og prosesser

3


Bakgrunn

•Tjenesteorientering – splitt og hersk•Organisatorisk•Funksjonelt•Teknisk Vi skal se på denne!

Med oppetid menes at systemet skal kunne ha ”fail-over” i tilfelle feil, men også at systemet skal være tilgjengelig ved høy last

Alle disse kan sorteres ut ved å se på systemet faktisk skal levere for hvem.Ved å dele opp i forskjellige funksjoner vil man kunne se konturene av forskjellige komponenter i arkitekturenNoe nedetid val man self ha, men det går ann å minimere det.

4


Disposisjon

•Hvorfor – Krav og drivere•Hva – Egenskaper ved store systemer•Hvordan – Designe systemene for parallellitet•Med hva – Verktøy•Hva med oss?

5


Drivere - Krav

•”Gjøre mer med mindre”

•Fange data og behandle de når det skjer•Selvbetjening – slipp publikum inn•Automatisering

•Dele ressurser•Dele på den samme maskinvare•Virtualisering, men på hvilket nivå?

•Oppetid•Systemet skal være tilgjengelig

•Endringsevne•Endringer skal i stor grad gjøres uten å miste oppetid•La andre kunne komme seg inn i ”koden”

Selvbetjening innebærer også mye blottlegging

Med oppetid menes at systemet skal kunne ha ”fail-over” i tilfelle feil, men også at systemet skal være tilgjengelig ved høy last

Alle disse kan sorteres ut ved å se på systemet faktisk skal levere for hvem.Ved å dele opp i forskjellige funksjoner vil man kunne se konturene av forskjellige komponenter i arkitekturenNoe nedetid val man self ha, men det går ann å minimere det.

6


Drivere - Teknisk

•Flerkjerne CPU•Hastighet møter veggen•Vanskeligere å få det mindre•Flere kjerner i samme CPU presser på

•Mange små bokser små… (standardisering)•Lett tilgjengelig og mye billigere•Unix / linux ruler•Fleksibilitet – begynne i det små, skalere etter hvert•Facebook har 10.000 vis av servere•50 millioner transaksjoner i sekundet…•10’talls terrabyte med RAM

•Compute-grid•Billigere RAM•Mange servere kan dele felles minne

•De største framskritt i prosessering ligger på algoritmer og ikke i HW•Parellellitet: Generelle algoritmer i dag klarer kanskje 20%

7


Drivere - Teknisk

8


Hva består skyen av?

9


Drivere - arkitektur

•Arkitekturen gir nye muligheter•Lagdeling•Komponenter •Spesialisering•Standardisering

•Etablert praksis for god design•Presentasjonslag•Forretningslogikk•Data•-> Så kan man spørre seg: Men har vi ikke det da?•-> De skal være uavhengig fordi de skal behandles forskjellig

•Så da er det bare på plassere funksjonalitet i sine spesialiserte komponenter!

Standadisering og erfaringer har gitt arkitekturkomponenter som avlaste

10


Drivere - Space Based Arhitecture

What is a Processing Unit:• Bundle of services, data, messaging

• Collocation into single VM

• Unified Messaging & Data

• In-Memory

Cloud of Processing Units• Scale through

Partitioning

• Virtualized middleware

What is a Space:

• Elegant – 4 API

• Solves:

• Data sharing

• Messaging

• Workflow

• Parallel processing

Space-Based Architecture (SBA) is a software architecture pattern for achieving linear scalability of stateful, high-performance applications, based on Yale’sTuple-Space Model (Source Wikipedia)

Hvi det ikke paser inn i Yale’s modell så får man finne på noe annet.

11


Drivere - utfordring

•For å utnytte dette må vi dele opp problemet slik at det:•Passer med lagene i arkitekturen•Utnytter standarder•Finne datasett og funksjoner som kan håndteres hver for seg

•Kan håndteres i parallell•Funksjonelt er lettere å forstå

•Skattyterfamilien

•Mål:•Endringsfleksibilitet•Tilgjengelighet•Oppetid•Utnytter plattformen (HW/SW) mer effektivt

12


Disposisjon


13


Egenskaper for store systemer

•Masse data•Mange funksjoner og regler•Mange brukere•Mange interessenter•Mange perspektiv•Distribuert•Heterogent•----------------------•Alt passer ikke i den samme bøtta•Den guddommelige silo finnes ikke•Tjenesteorientering har mye av svaret•Tid er vanskelig

•Alt er egentlig i fortid, så hvordan skal vi håndtere det?•I mellomtiden kan du banne på at det har skjedd noe

14


En verden av tid og rom

• Nettbutikk

Eksempel på tidDet tar 3-5 sekunder fra lageret har sagt hvor mye som er det.ens brukeren bestemmer segså har noen andre kjøpt noe…Brukeren kan ikke holde på en lø helt inn i lageret

Dette må man rett og slett håndtere!

15


Verden av tid og rom

• Skatt; Vi er aldri konsistent med omverdenen

måneder og dager før dette er riktig

Vår prosessering

Si litt om Altinn også. Det kan ta inntil 2 døgn før vi har data i husVi kan hende å behandle data som allerede er feil (det er mer i pipeline på vei inn)

Forsinkelser mellom våre systemer også.

Vi forholder oss til ett snapshot av verden

16


ACID

•Kjære egenskaper ved databaseløsninger•Dette har med endring av tilstand og tid å gjøre, med samtidige hendelser (transaksjoner)

•Databaseteori kalles dette ”Serialiserbarhet”

Hvis noe feiler skal det forbli konsistentRobustDurability

En transaksjon skal gjennomføres som om ingenting annet skjer

IsolertIsolation

Resultatet er konsistentKonsistentConsistency

Transaksjonen er en enhet, alle eller ingenAtomærAtomicity

17


BASE

•BASE passer bedre for store systemer

•Splitt og hersk•Det handler om å ha kontroll (over det distribuerte systemet)•Global serialiserbarhet

Ha kontroll over systemene slik at vi kan garantere et det blir konsistent

Eventually-Consistent

Tilstand (på person) mellom to systemer er løsrevet. Innad riktig men til tider ikke i mellom

Soft State

Systemet skal i hovedsak være tilgjengelig, som følge av feil eller av oppgraderinger

Hovedsakelig tilgjengelig

BasicallyAvailable

BA – Det betyr at noen deler av systemer kan ha ekstrem oppetid, mens andre tar dette litt mer med ro. Hensikten er å dele opp slik at det blir håndterbartEC – i de systemene vi snakker om er det sekunder mellom at tilstand blir propagert inn i systemene. Vi bestemmer selv hvo fort sette skal gå.

18


CAP kompromiss

•Teoremet sier at det er umulig for et distribuert system å ha alle tre•Prinsippet er teknisk og går på at du maks kunne tilby 2

Funksjoner kan utføres selv om noder i systemet er nede. Distribuert robusthet

Partition-Tolerance

Funksjoner skal kunne utføres slik de er tiltenktTilgjengeligAvailability

Funksjoner skal legge fra seg en konsistent tilstandKonsistentConsistency

•Fra samtidighet til samhandling? (concurrent to concurring)•ACID sprekker i store sammenhenger•Enkeltsystemer eller komponenter må gjerne ha ACID

CAP - Det er faktisk bevist at det er slik (se wikipedia)

19


Disposisjon

•Hvorfor – Krav og drivere•Hva – Egenskaper ved store systemer•Hvordan – Designe systemene for skalerbarhet•Med hva – Verktøy•Hva med oss?

20


God design - lagdeling

•Lagdelt design har vært kjent lenge•Disse var til å begynne med drevet av å lage systemer som var lettere åforstå og å forvalte

•Har etter hvert også vist seg nyttig for skalerbarhet

•Lagene deler applikasjonen opp etter funksjoner

View

View model

Business

Data

21


God design - lagdeling

•Disse kan skaleres opp slik at•lasten kan fordeles•bedre oppetid•endringsfleksibilitet

•Horisontal skalering – flere maskiner

•Vertikal skalering – flere prosesser / tråder

•Fremskutte cache’r

•Dette tar kapasiteten ett stykke videre, men før eller siden møtes de i databasen

App

Web

AppApp

WebWebWeb

Proxy

22


Tilstand skalerer ikke

•Databasen holder tilstand og har sverget på ACID•Jo mer som puttes i en og samme database, jo tøffere jobb har den med å beholde tilstand

•Vi må dele opp dataene slik at de kan håndteres hver for seg•Uavhengige data kan prosesseres i parallell•Optimalt ønsker vi å dele

•funksjonene i lag•dataene i partisjoner eller komponenter

•Lineær skalering betyr at•doble cpu eller ekstra tråd -> behandle dobbelt så mye

•Målet er uavhengige systemer som samarbeider

Det må ikke missforstås med at det er en sentral database med partitionoing: Fremdeles en og samme databasemotor som skal håndtere det hele.

23


Hva er lineært?

•Vi ønsker lineær egenkaper•En gruppe problemer kalles ”NP-komplette”

•det er kjent at disse absolutt ikke skalerer•for eksempel: alle venners venner, korteste vei, hva passer best i sekken•Relasjons joinen…

•1000x1000 går bra, 1000000x1000000 vil aldri svare•Fantastisk fleksibel, men skummel ytelsesmessig

•Den funksjonalitet vi lager skal ha en lineær funksjon•Men da må dataene også modelleres slik at de passer formålet

•Alle med basis IT utdanning har hatt ”Algoritmer og datastrukturer”•så la oss bruke det!

NP - Non-Polynomial in Time Complete

24


Designe for ytelse / pallellitet

•Hva skal dataene brukes til?•Innkapsling og tjenesteorientering

•Det som ble gjennomgått ifbm. ”Hva er god tjenesteorientering?”•Skille primær produkt, mot mer sekundære produkter

•Beregn skatt•… ikke tilrettelegging for annen bruk

•Kø-modellering•I stedet for å tenke data, kan man tenke hva som skal behandles hver for seg

•Trinnvis tilrettelegging av data•Prosessering går ofte i en verdikjede, og da kan man legge opp passelige mellomprodukter (aka. likningsutkast)

•Spesialisering og masterdata

Køer gir tydelige grensesitt, løskobling, tydelige grenser mellom moduler. Letter også testbarhet

25


Eksempler: Facebook, yr.no

Cache

Tekst

Tilrettelegg

Sett sammen

Tilrettelegg

Tilrettelegg

Sett sammen

Sett sammen

Sett sammen

StrukturBilder x4

Løpende tilretteleggingAsynkront, bygger opp webside ”etter hvert”, ting joines først på”din side”.400 millioner brukereVenners venner er vanskelig…

26


Eksempel bwin.com

Poker

Roulette

Betting

?

Spill-logg == fasit

Viktigste egenskap er tilgjengelighet og

ytelse

Hver eneste transaksjon slik den

ble utført; og av hvem. Identifisering er viktig

OppgjørReskontro

Analyse og bedrageri

Regler (land, person)

Styreparametere(VIP, stopp)

Styreparametere Rapportering

Business Intelligence

Spillehistorikk

Person

Spillebord

Kan når som helst regenerere

akkumulerte data som følge av endringer i logikk eller feilretting

Forskjellige komponenter bearbeider og

tilrettelegger data

Viktigste egenskap er fleksibilitet og

korrekthet

Oppgjør

27


Eksempel - kømodellering

Transaksjon

Se hvordan du ligger an på tid. Hopp evt over.

28


Disposisjon

•Hvorfor – Krav og drivere•Hva – Egenskaper ved store systemer•Hvordan – Designe systemene for skalerbarhet•Med hva – Verktøy•Hva med oss?

29


Verktøy - prinsipper

•Endringskapasitet•Alle løsningers funksjonalitet skal være fleksible nok til å kunne følge forventede endringer i samfunnet og i etatens tjenester innen rimelig tid og prisramme.

•Gjenbruk•Gjenbruk skal prioriteres, både ved å velge allerede gjenbrukbar funksjonalitet ovenfor ny utvikling/anskaffelse og ved å investere i gjenbrukbarhet ved utvikling/anskaffelse av ny funksjonalitet.

•Livsløp•Ved utvikling og anskaffelser skal gevinst- og kostnadsbildet ta høyde for helheten i SKEs systemportefølje, hele livsløpsbildet for løsningen, samt de ikke-funksjonelle kravene.

30


Java så klart! – Sitat Oracle

•Java, including Java Platform, Enterprise Edition (Java EE), has become the platform of choice for mission-critical applications for a number of important reasons:

•Java is the premier platform for cutting-edge Web services, clustering, and grid technologies — all vital to today’s competitive landscape.

•Substantial standardized infrastructure is available for building, deploying, and managing Java-based applications.

•There is a large pool of professionals available to build and support Java-based systems.

•Almost every new component, library, and application has an API availablefor Java.

•Java provides an unprecedented number of flexible deployment options —more than any other software platform — including the ability to upgradeapplications and services without downtime; the flexibility to implementphased transitions, such as the transition from big iron and UNIX servers to scale-out, commodity hardware; and support on every major server hardware platform and operating system.

Objektorientering og standarddisering samt VM

31


Konteiner

•En konteiner er en standardisert arkitekturramme som inneholder forretningslogikk

•En konteiner tilbyr standard infrastruktur slik at forretningslogikken kan rendyrkes

•Infrastrukturtjenester:•Minne•Tråder•Sikkerhet •Feilhåndtering / Exceptions•Transaksjoner•Ressurser (filer, køer, databaser)

•Konteiner er rundt beskrevet, mye av mulighetene ligger også i bruk av standardiserte komponenter

•Arkitekturprinsippet Inversion of Control (IoC) er en premiss

32


Konteiner - kjøremiljø

•Det finner mange slags konteinere, spesialiserte for sine formål•En konteiner kan deployes i vidt forskjellige kjøremiljøer•En Applikasjons-tjener eller web-tjener gir kjøremiljø•En konteiner har kjøre parametere som kalles deployment-descriptor•Deployment-descriptoren tilpasses kjøremiljøet (utv, test prod)

•forretningslogikken er uforandret•Ved å strukturere forretningslogikken i det små, kan de deployes over i det virkelig store

•I det små på din PC i samme VM med lite testdata•I det mellomstore med tjenestene på bussen•I det store i ”skyen” hvor tjenestene og bussen kjører der

33


Dynamisk skalering / oppetid / lastbalansering

Krav og policys rundt svartid og type forespørsel.Nye tas opp eller stenges ned etter behovNye versjoner startes gradvis

App

App

App

App

Ta i mot, sorter og

route

Forespørsler

34


Eksempel - cache

Kan ta alle data i db og legge ut, men logikken er desverre sylta inn i databasen

35


Eksempel – Replikert cache

GSCGSC

Replication

Partition 1-BackupPartition 1-Primary

GSCGSC

Replication

GSCGSC

Replication



36


Eksempel – Replikert cache

• Routing basert på skattyter/familie• Spørring – ”Map – Reduce”

Writer

Reader

GSCGSC

Replication


GSCGSC

Replication

GSCGSC

Replication



37


Funksjoner

•Dette er basis-operasjonene for å hente, utveksle og å lagre informasjon

•Read/write er db•Take/Notify er kø

•Take 1:1•Notify 1:n

Write TakeTake

Write

Read

Take

Notify

38


XML – Dokumentsentrisk

•Ingen join!•1 til 1 med funksjonalitet•Tilrettelagte data•Master, komponenten eier sine data•Versjoner•Uavhengige data•Tydelige definisjon (xsd - XML Schema Definition)•Settes sammen lengre opp i lagene

•Ulemper:•Vanskelig med å se ting på tvers av hierarkisk struktur

Men her kommer dette med løpende tilrettelegging inn

39


Prosessflyt

•Skill •Utvalg •Behandling•Levere resultat

•Trinnvis berikelse•Forenklet totalprosess•Man går ikke i butikken for å handle mens man lager mat!

Skill: gir løs koblingbedrer testbarhet betraktelig

40


Design for de ikke-funksjonelle krav

•Vær edruelig mhp. krav•Ikke alle løsninger trenger kompleks arkitektur•Både funksjonelle og ikke-funksjonelle krav koster•Unødvendig funksjonalitet er dyrt•Unødvendig komplekse løsninger er dyrt

•Sentrale arkitekturbeslutninger bør analyseres nøye•… de setter spor•I ukjent terreng er en smidig tilnærming risikoreduserende•Kjør en Pilot

•Utfordre kravstillere med de ikke-funksjonelle kravene•Oppetid, svartid, volum, antall samtidige brukere•… og sikkerhet

Mye er overdesignet, og annet er ikke forberedt!(undersøkelser viser at mye av de vi lager ikke blir brukt…)

41


Eksempel: Ikke-funksjonelle krav

Meldings-motor

Butikk Utvalg

Ekstern

AuthorizationPris Saksbehandling

B3B2

B1

Innkjøp

AHA1

A2

N1

S1B1

B2B3

S1

AHA1

A2

AH

2-phase commit

2-phase commit

1 tråd, alt i

sekvens

42


Disposisjon


43


Tid og konsistens

•Våre viktigste egenskaper er korrekthet, kvalitet og integritet•Så kommer fleksibilitet•Så kommer tidsmessighet•Eksempel:

•En skattyter mottar lønn•Det rapporteres til oss•Vi beregner konsekvensene•Skattyter mottar disse

•Det er ikke mulig å lage ett system som skal serve alle og som skal beholde ACID.

•Det viktigste for oss er•1. Vi skal godta at tilstand på skattyter er forskjellig i forskjellige perspektiv•2. Vi skal ha kontroll slik at tilstanden ”snart blir riktig”•3. Asynkron oppførsel

44


Hva med oss?

•Det er noe BASE hos oss, men vi har ikke ”eventually consistent”•Vi må få kontroll på tilstand på skattyter•Forvaltningskostnadene vokser•Mye avstemming og manuell jobbing

•Vi har for mye ACID•Batchene vokser i tid•Forvaltningskost vokser•Oppetid synker

45


Våre data

•Eksempel: skattyter og skatteunderlag•Må ha inn periode – eks. inntektsår•Andre områder kan struktureres på lik måte

Part

111-A/200.000,-

Grunnlag Fastsatt Skatt

111-A/20,-

116-A3.192,-

3.1.1/3.192,-

3.1.1/2,-

2.1/203.212,-

4.2.5/126.000,-

3.3.1/34.569,-

3.2.10/25.000,-

4.2/126.000,-

3.3/34.596,-

3.2/25.000,-

3.1/3.194,-

Formue – Stat/0

Toppskatt/10.101,-

Inntekt – Kommune/23.098,-

Inntekt – Stat/50.001,-

Formue – Kommune/0

Trygd/33.094,-

46


Målbilde - Prosesseringsarkitektur

• Informasjon orienteres rundt en Part•Komponenter har eierskap til den informasjon den skaper

•Vi sender operasjoner med data•Køer mellom datalager og prosessering, og mellom prosessering og datalager

•1. Vi skal godta at tilstand påskattyter er forskjellig i forskjellige perspektiv

•2. Vi skal ha kontroll slik at tilstanden ”snart blir riktig”

•3. Asynkron oppførsel

Aut

omat

iser

tepr

oses

ser

Tren

ger

beha

ndlin

g

Lagre resultat

Man

uell

beha

ndlin

g

Processing Unit

Nevn eksepel med takseringssystem for strømforbruk på tog.Det sier seg selvat man ikke kan teste ved å kjøre tog rundt om kringTesting må kunne gjøres i en simulator

47


Missforståtte egenskaper ved distribuerte systemer

•Nettverket er pålitelig•Latens er null•Båndbredde er ubegrenset•Nettverk er sikre•Topologi endres ikke•Bare en administrator•Transport er null•Nettverk er homogene•Systemet er homogen•Systemet er ferdig

48


Oppsummering

•Beste grunnlag for skalering er å dele opp problemet•(som for Tjenesteorientering og distribuerte systemer)•Tenk uavhengige funksjoner•Tenk uavhengige data•Ha riktige ikke-funksjonelle krav

•Implementer riktig i det små, -> deploy inn i den arkitektur som kan bære den

49


Takk for meg

•Noen linker:• http://www.springsource.org/spring-integration• http://www.gigaspaces.com/• http://www.oracle.com/technology/products/coherence/index.html• http://wiki.tangosol.com/display/CSIG/Presentations

skalerbare systemer

Technology