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)
Skatteetaten – Skalerbare systemer 29.02.2012 2
Beskrive hvordan man i samme logikk henter informasjon og
sjekker ting underveis+++
Mangel på struktur er både del-systemer med data og prosesser
2
3. Bakgrunn
• Tjenesteorientering – splitt og hersk
• Organisatorisk
• Funksjonelt
• Teknisk Vi skal se på denne!
Skatteetaten – Skalerbare systemer 29.02.2012 3
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 arkitekturen
Noe nedetid val man self ha, men det går ann å minimere det.
3
4. Disposisjon
• Hvorfor – Krav og drivere
• Hva – Egenskaper ved store systemer
• Hvordan – Designe systemene for parallellitet
• Med hva – Verktøy
• Hva med oss?
Skatteetaten – Skalerbare systemer 29.02.2012 4
4
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”
Skatteetaten – Skalerbare systemer 29.02.2012 5
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 arkitekturen
Noe nedetid val man self ha, men det går ann å minimere det.
5
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%
Skatteetaten – Skalerbare systemer 29.02.2012 6
6
8. Hva består skyen av?
Skatteetaten – Skalerbare systemer 29.02.2012 8
8
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!
Skatteetaten – Skalerbare systemer 29.02.2012 9
Standadisering og erfaringer har gitt arkitekturkomponenter som
avlaste
9
10. Drivere - Space Based Arhitecture
Space-Based Architecture (SBA) is a software architecture pattern for achieving
linear scalability of stateful, high-performance applications, based on Yale’s
Tuple-Space Model (Source Wikipedia)
What is a Space:
• Elegant – 4 API
What is a Processing Unit: Cloud of Processing Units
• Solves:
• Bundle of services, data, messaging • Scale through
• Data sharing
• Collocation into single VM Partitioning
• Messaging
• Unified Messaging & Data • Virtualized middleware
• Workflow
• In-Memory
• Parallel processing
Skatteetaten – Skalerbare systemer 29.02.2012 10
Hvi det ikke paser inn i Yale’s modell så får man finne på noe
annet.
10
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
Skatteetaten – Skalerbare systemer 29.02.2012 11
11
12. Disposisjon
• Hvorfor – Krav og drivere
• Hva – Egenskaper ved store systemer
• Hvordan – Designe systemene for parallellitet
• Med hva – Verktøy
• Hva med oss?
Skatteetaten – Skalerbare systemer 29.02.2012 12
12
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
Skatteetaten – Skalerbare systemer 29.02.2012 13
13
14. En verden av tid og rom
• Nettbutikk
Skatteetaten – Skalerbare systemer 29.02.2012 14
Eksempel på tid
Det tar 3-5 sekunder fra lageret har sagt hvor mye som er det.
ens brukeren bestemmer seg
så 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!
14
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
Skatteetaten – Skalerbare systemer 29.02.2012 15
Si litt om Altinn også. Det kan ta inntil 2 døgn før vi har data i hus
Vi 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
15
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”
Atomicity Atomær Transaksjonen er en enhet, alle eller ingen
Consistency Konsistent Resultatet er konsistent
Isolation Isolert En transaksjon skal gjennomføres som om
ingenting annet skjer
Durability Robust Hvis noe feiler skal det forbli konsistent
Skatteetaten – Skalerbare systemer 29.02.2012 16
16
17. BASE
• BASE passer bedre for store systemer
Basically Hovedsakelig Systemet skal i hovedsak være
Available tilgjengelig tilgjengelig, som følge av feil eller av
oppgraderinger
Soft State Tilstand (på person) mellom to
systemer er løsrevet.
Innad riktig men til tider ikke i
mellom
Eventually- Ha kontroll over systemene slik at vi
Consistent kan garantere et det blir konsistent
• Splitt og hersk
• Det handler om å ha kontroll (over det distribuerte systemet)
• Global serialiserbarhet
Skatteetaten – Skalerbare systemer 29.02.2012 17
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åndterbart
EC – 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å.
17
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
Consistency Konsistent Funksjoner skal legge fra seg en konsistent tilstand
Availability Tilgjengelig Funksjoner skal kunne utføres slik de er tiltenkt
Partition- Distribuert Funksjoner kan utføres selv om noder i systemet er nede.
robusthet
Tolerance
• Fra samtidighet til samhandling? (concurrent to concurring)
• ACID sprekker i store sammenhenger
• Enkeltsystemer eller komponenter må gjerne ha ACID
Skatteetaten – Skalerbare systemer 29.02.2012 18
CAP - Det er faktisk bevist at det er slik (se wikipedia)
18
19. Disposisjon
• Hvorfor – Krav og drivere
• Hva – Egenskaper ved store systemer
• Hvordan – Designe systemene for skalerbarhet
• Med hva – Verktøy
• Hva med oss?
Skatteetaten – Skalerbare systemer 29.02.2012 19
19
20. God design - lagdeling
• Lagdelt design har vært kjent lenge
• Disse var til å begynne med drevet av
View
å lage systemer som var lettere å
forstå og å forvalte
• Har etter hvert også vist seg nyttig for View model
skalerbarhet
• Lagene deler applikasjonen opp etter Business
funksjoner
Data
Skatteetaten – Skalerbare systemer 29.02.2012 20
20
21. God design - lagdeling
• Disse kan skaleres opp slik at
• lasten kan fordeles
• bedre oppetid
• endringsfleksibilitet
• Horisontal skalering
– flere maskiner Proxy
• Vertikal skalering
– flere prosesser / tråder
Web Web Web Web
• Fremskutte cache’r
App App App
• Dette tar kapasiteten ett stykke
videre, men før eller siden møtes
de i databasen
Skatteetaten – Skalerbare systemer 29.02.2012 21
21
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
Skatteetaten – Skalerbare systemer 29.02.2012 22
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.
22
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!
Skatteetaten – Skalerbare systemer 29.02.2012 23
NP - Non-Polynomial in Time Complete
23
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
Skatteetaten – Skalerbare systemer 29.02.2012 24
Køer gir tydelige grensesitt, løskobling, tydelige grenser mellom
moduler. Letter også testbarhet
24
25. Eksempler: Facebook, yr.no
Sett Sett Sett Sett
sammen sammen sammen sammen
Tilretteleg Tilretteleg Tilretteleg
g g g
Cache
Bilder x4 Tekst Struktur
Skatteetaten – Skalerbare systemer 29.02.2012 25
Løpende tilrettelegging
Asynkront, bygger opp webside ”etter hvert”, ting joines først på
”din side”.
400 millioner brukere
Venners venner er vanskelig…
25
26. Eksempel bwin.com
Viktigste egenskap er Hver eneste Kan når som helst
transaksjon slik den regenerere Viktigste egenskap er
tilgjengelighet og fleksibilitet og
ytelse ble utført; og av hvem. akkumulerte data som
Identifisering er viktig følge av endringer i korrekthet
logikk eller feilretting
Poker Regler
Spill-logg (land, person)
== fasit
Person
Betting Analyse og bedrageri
Spille Spille
Roulette historikk bord
Styreparametere Rapportering
Styreparametere
(VIP, stopp)
Oppgjør
? Reskontro
Forskjellige
komponenter
bearbeider og
tilrettelegger data
Business Intelligence
Oppgjør
Skatteetaten – Skalerbare systemer 29.02.2012 26
26
27. Eksempel - kømodellering
Transaksjon
Skatteetaten – Skalerbare systemer 29.02.2012 27
Se hvordan du ligger an på tid. Hopp evt over.
27
28. Disposisjon
• Hvorfor – Krav og drivere
• Hva – Egenskaper ved store systemer
• Hvordan – Designe systemene for skalerbarhet
• Med hva – Verktøy
• Hva med oss?
Skatteetaten – Skalerbare systemer 29.02.2012 28
28
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.
Skatteetaten – Skalerbare systemer 29.02.2012 29
29
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 available
for Java.
• Java provides an unprecedented number of flexible deployment options —
more than any other software platform — including the ability to upgrade
applications and services without downtime; the flexibility to implement
phased 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.
Skatteetaten – Skalerbare systemer 29.02.2012 30
Objektorientering og standarddisering samt VM
30
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
Skatteetaten – Skalerbare systemer 29.02.2012 31
31
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
Skatteetaten – Skalerbare systemer 29.02.2012 32
32
33. Dynamisk skalering / oppetid / lastbalansering
App
App
Ta i mot,
Forespørsler
sorter og
App
route
App
Krav og policys rundt svartid og
type forespørsel.
Nye tas opp eller stenges ned
etter behov
Nye versjoner startes gradvis
Skatteetaten – Skalerbare systemer 29.02.2012 33
33
34. Eksempel - cache
Skatteetaten – Skalerbare systemer 29.02.2012 34
Kan ta alle data i db og legge ut, men logikken er desverre sylta inn
i databasen
34
37. Funksjoner
• Dette er basis- Write
operasjonene for å hente, Read
utveksle og å lagre Take
informasjon
Notify
• Read/write er db
• Take/Notify er kø
• Take 1:1
• Notify 1:n
Write Take Take
Skatteetaten – Skalerbare systemer 29.02.2012 37
37
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
Skatteetaten – Skalerbare systemer 29.02.2012 38
Men her kommer dette med løpende tilrettelegging inn
38
39. Prosessflyt
• Skill
• Utvalg
• Behandling
• Levere resultat
• Trinnvis berikelse
• Forenklet totalprosess
• Man går ikke i butikken
for å handle mens man
lager mat!
Skatteetaten – Skalerbare systemer 29.02.2012 39
Skill: gir løs kobling
bedrer testbarhet betraktelig
39
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
Skatteetaten – Skalerbare systemer 29.02.2012 40
Mye er overdesignet, og annet er ikke forberedt!
(undersøkelser viser at mye av de vi lager ikke blir
brukt…)
40
42. Disposisjon
• Hvorfor – Krav og drivere
• Hva – Egenskaper ved store systemer
• Hvordan – Designe systemene for parallellitet
• Med hva – Verktøy
• Hva med oss?
Skatteetaten – Skalerbare systemer 29.02.2012 42
42
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
Skatteetaten – Skalerbare systemer 29.02.2012 43
43
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
Skatteetaten – Skalerbare systemer 29.02.2012 44
44
45. Våre data
• Eksempel: skattyter og skatteunderlag
• Må ha inn periode – eks. inntektsår
• Andre områder kan struktureres på lik
Part
måte
Grunnlag Fastsatt Skatt
111-A/200.000,- 2.1/203.212,- Formue – Stat/0
111-A/20,- 3.1/3.194,- Formue – Kommune/0
116-A3.192,- 3.2/25.000,- Inntekt – Stat/50.001,-
3.1.1/3.192,- 3.3/34.596,- Inntekt – Kommune/23.098,-
3.1.1/2,- 4.2/126.000,- Toppskatt/10.101,-
3.2.10/25.000,- Trygd/33.094,-
3.3.1/34.569,-
4.2.5/126.000,-
Skatteetaten – Skalerbare systemer 29.02.2012 45
45
46. Målbilde - Prosesseringsarkitektur
• Informasjon orienteres rundt en Part
• Komponenter har eierskap til den
Automatiserte
informasjon den skaper
prosesser
• Vi sender operasjoner med data
Lagre resultat
behandling
Trenger
• Køer mellom datalager og
prosessering, og mellom
prosessering og datalager
• 1. Vi skal godta at tilstand på
skattyter er forskjellig i forskjellige
behandling
perspektiv
Manuell
• 2. Vi skal ha kontroll slik at tilstanden
”snart blir riktig”
• 3. Asynkron oppførsel
Skatteetaten – Skalerbare systemer 29.02.2012 46
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
kring
Testing må kunne gjøres i en simulator
46
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
Skatteetaten – Skalerbare systemer 29.02.2012 47
47
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
Skatteetaten – Skalerbare systemer 29.02.2012 48
48
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
Skatteetaten – Skalerbare systemer 29.02.2012 49
49