massivt skalerbar skatteberegning

1

Massivt skalerbar skatteberegning

Software 2012

Tormod Varhaugvik, SKD SITS, Jan 2012

2

29.02.2012Skatteetaten 2

Bakgrunn

• Skatteberegning i løsningsarkitekturen• Egen informasjon, logikk og prosess• Avlaster standardløsninger• Finansarkitektur har likhetstrekk• Satt sammen; Domain Driven Design, Tuple Space, CQRS,

BASE, SOA, ODS, XML-dokumenter og god gammel Java

• Skape felles forståelse rundt arkitekturdiskusjoner og valg• Å redusere risiko i planlegging og estimering• 1000 ganger ytelse?• Hardware < 10%?• Kodeforvaltning < 30%?

Fastsetting

Skal presentere noe som ingen i verden har fått til innenfor Offentlig sektor (i hvert fall skatte administrasjoner) har fått til. Og hvis du vet om noen ”SI I FRA”Mange offentlige instanser ville kalle Fastsetting for: ”Vedtak”Minne er allerede 10-100 ganger raskereWe did it!

Command Query Responsibility Segregation

Basicaly Available Eventuatly Consistent

Operational Data Store

3


Drivere og Krav

• Hendelsesdrevet• Selvbetjening• Automatisering• Endringsevne• Livsløp – åpne standarder

• Flerkjerne CPU & Mange bokser små• Vi må designe for parallellitet• Skalere ”ut av boksen”, ”Skriv for skyen i dag”• Vår egen sky i dag, forberedt på det som kommer • Ytelse, volumer, økonomi• Ikke alle problemer passer

Selvbetjening innebærer også mye blottlegging, man må ha kontroll på bakrommetMed oppetid menes at systemet skal kunne ha ”fail-over” i tilfelle feil, men også at systemet skal være tilgjengelig ved høy last

En clustret løsning er mer robust i seg selv, og applikasjonen må bygges for det. (Når virket sist failover siten)?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 vil man selvfølgelig ha, men det går an å minimere det.

Facebook har 10.000 vis av servere,50 millioner transaksjoner i sekundet…,10’talls terrabyte med RAMDe største framskritt i prosessering ligger på algoritmer og ikke i HWParallellitet: Generelle algoritmer i dag klarer kanskje 20%

4


DDD i Space Based Arhitecture

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)

Aggregate

Aggregate slik definert i Domain Driven DesignRett og slett en gigantisk HasMap

5


Kontinuerlig utveksling av Aggregater

Fast-satte

verdier

Ilagt skatt / avgift

Verdier

Innsamling

Egen

dekla

rasjo

n

FastsettingAvgifts- og

Skatteberegning

Forsk

udd

SkatteInfo

For-skudd

Prog-nose

Forskjellige aggregater side-om-

side for skattyter

Kontinuerlig tilrettelegging

Tuple er et xml-dokument som

inneholder aggregat

XML for lang holdbarhet

Processing uniter en module

Unik produsent av aggregat

Module har en bounded context

Last et sett aggregater og

produserer et nyttUavhengige

contexts

Massiv spørring Alle aggregaterpå samme sted

Tilstand påaggregatet styrer

prosessen

Skiller produksjon

fra bruk

Alle aggregaterinnkapsles i et

super-dokument

Modulene avgir tjenestekomponenter

til SkatteInfo

SkatteInfo er en super-repository

Løs kobling mellom aggregater(Skattyter, contextog årsversjoner)

http://tormodv.blogspot.com/2010/11/concept-for-datastore-and-processing.html

Continual Aggregate Hub.Viktig å poengtere at dette er design for å la mange Moduler samarbeide om de samme informasjonsobjektene. Grid / skalering er det kun for ytelse.

Tenk også på SkatteInfo som et lager over alt som er produsert av systemene. All spørring foregår hit.Slikt sett likt med Operational data store, men det er dette med arkitekturen rundt som gjør den spesiell

Tid er løs kobling. Har bedre tid når man utarbeider noe enn når man spør etter det.Høy spørre til beregn ratioSkatteinfo er til enhver tid fasiten.

Soft stateBedrer muligheten for gode metadata, enhetlig masterAggregater: utfordringen er å finne riktig granularitet.

6


Tekniske egenskaper

• Parallelliserbar• Skill utvalg…• … fra behandling• … fra lagring av resultat

• Prosessfokus• Automatisk saksbehandling• Manuell saksbehandling• Kontinuerlig tilrettelegging

• Åpne standarder • Kapsle inn forretningslogikk• xml, java, kontainer, web• Leverandør / plattformuavhengig• Plattform i utvikling

• Objektorientert• Rik semantikk, DSL• xml 1:1 med java (aggregatet)

• Test og drift• Automatisk / avgrenset test• Omkjøring ifbm feilretting• Enkel simulering

http://tormodv.blogspot.com/2010/12/continual-data-hub-architecture-and.html

Åpne standarder gir handlingsrom. Beste valget man kan gjøre i dagLisens uavhengighet, flytt prosesseringsbehov ut til noe gratisVarighet!Skille utvalg, fra prosessering, fra lagringTenk en og en når man utvikler.Snakk om container og komponenterPresenter en case!Tilrettelegge, man går ikke i butikken mens man lager matDramatisk forenkling av concurrencyFantastisk mulighet til å planlegge cache-pre-load…

7


Lagringsarkitektur - Aggregater

• Tenke Aggregater (info+use) • Forretningslogikk styrende• Part i fokus, ikke datatype• Robusthet og skalerbarhet• Redusert I/O og mindre låsing• Endringsevne og testbarhet• Serialisering er lik • Søkemotor• Alle dokumenter har skjema• Vilkårlige data fra 3. part• Kan ha ustrukturert info også• Hva med funksjoner på tvers av

aggregater/dokumenter?

<hode><nøkler> <prosess><aggregat><beslutning><avvik><logg>

http://tormodv.blogspot.com/2011/02/document-store-for-enterprise.html

Dramatisk forenkling av concurrency mekanismer

8


Proof of Concpt mål

• Enkel; ved at regler, informasjon og prosess er tettest opp mot forretningsbegrep

• Logisk gruppering, ikke teknisk oppstykking• Helhet i skatteprosessen gir forenkling totalt sett (gjenbruk)

• Testbar; ved at moduler lar seg teste hver for seg i en tydelig verdikjede

• Faser i saksbehandlingen• Steg i prosesseringen• Uavhengige informasjonselementer• 400+70+25+20 er mindre enn 400*70*25*20

• Skalerbar; ved at volum og svartider lar seg løse ved kjøp av mer hardware, og ikke igjennom å skrive om regler, informasjon eller prosess.

• Lavere kostnad• Mindre risiko

http://tormodv.blogspot.com/2011/09/tax-norways-proof-of-concept.html

Kinderegg!Kan ikke abstrahere seg bort fra forretningslogikk

9


Hva gjør vi?

• Valgt noe vanskelig; selvangivelse og skatt• Selvangivelsen har ca. 800 felter / 300 poster• Settes sammen av 28 grunnlagsdata, samt 47 underskjema• Bare Lønn og trekkoppgaven har ca. 250 mappinger

• Essensiell kompleksitet skal håndteres• Vise at helhet i skatteprosessen gir forenkling totalt sett

• Konvertert del-mengde fra produksjon (60 millioner dokumenter)• Det skal kjøres for ca. 1 million skattytere• Dobbelt så mange maskiner skal gi dobbel ytelse

I dag ca 4000 beregningsregler og 3000 kontroller. Dette er en teknisk oppdeling og gir ikke forretningsnivå regler.

Infrastruktur

Etablert servermiljø hos EDB og Installert grid-løsning (utvidelse av AURORA)

Funksjonalitet

Lastet grunnlagsdata, produsert selvangivelse og beregnet skatt Bygget et eksempel på 360° brukergrensesnittVurdert konsepter for automatisk og manuell saksflytHelhetlig ramme på plass med fasene; skal utvide med SkattekortFull dekning innenfor ansettelser til Skatt. (50 – 60 summeringer)Skatt ca 70% av befolkningen. 30-40% av logikken?Saksbehandling på SA er godt dekket (hvem gjorde hva når)Løsning for årsversjoner; både små og store endringer

Data

Full saldo/rente og LTO for 2009 og 2010 60% volum av GLD 2 av 17 oppgavetyper

10


Lagring av Aggregater i super-dokument

id, gjelder, rapportert av, skjematype, gyldighetsperiode [inntektsår, datoperiode],

Hode tidspunkt, tilstand [privat, åpen, fjernet, erstattet] erstatter

avvikbeskrivelsegjelderPoster

Avvik

brukernavntidspunkthendelsebegrunnelseendredePoster

Logg

fase [prognose, PSA, levert, fastsatt, klage]versjontilstand [ny, behandles, ferdig ]

Sak

post2.1.1textverdiref Id

post3.1.12.7…post5

Selv-angivelse

Lik for alle i SkatteInfo

Lik for alle i SkatteInfo

Spesifikk pr skjematype

Selvangivelseaggregat

Tilstand påaggregatet

Tilstand pådokumentet

Analogi med bøker Header er ISBN, Forfatter, tittel etc. Boka kan inneholde hva den vil.

11


KildeRepo”Data til bruk i selvangivelsen”-LTO, S&R, (GLD - 17)-RF-1088 (etc)

SelvangivelseRepo-Fase og versjon-Prosess og sakstilstand-RF-1030-Avvik-Logg og audit

PartRepo-Navn-Organisasjon-Familie-Kommune

Bus

ines

sIn

frast

ruct

ure

/ S

katte

Info

App

licat

ion

Vie

w

Modul: Selvangivelse

SelvangivelseService-Opprett-Lagre i kontekst (fase)-Endre / Fastsett-Valider / Diff-Fase-Lås

Factory-Nå situasjon

Familie-Utgjevn-Endre-Fastsett-Valider-Diff-Fase

EndreService-”Services for å endre på Selvangivelse”-Lag-Endre etc…-listner- (selvangivelse, familie)

EndreView-”GUI for Saksbehandler”-Lag ny-Se på familie-Se endring over tid-Fastsett- (verdi, type og part)-Fastsett (-fase)

BrukView-”GUI for innsyn”-Se på familie-Se på selvangivelse

BrukService-”Sevices for bruk av Selvangivelse”-Søk-List-Se på (versjoner)-Subscribe / event handler

LookupService-søk-list-se på

VPL VPLBPM BPM

Reell forretningslogikk ligger i Selvangivelse Service:La deg ikke villede til å tro at datamodellen er i stand til å ha full

konsistens. det er forretningslogikken som har den.

12


Kjøremiljø

29.02.2012 12

Maskin (server) Maskin (server) Maskin (server)

Grid-node (JVM)

Skattefamilie

Lønns- og trekkoppgaver

Saldo- og rentemeldinger

PSA

Grid-node (JVM)

Skattefamilie



PSA

Grid-node (JVM)

Skattefamilie



PSA

• Alle noder er funksjonelt like• Noder har forskjellig datasett

• Skattefamilie samlokalisert

• Grid håndterer partisjonering, søk, jobber, redundans, overflow, lagring, failover, indekser, med mer.

• Transparent for logikken

• Plass tar mer tid enn beregning• Flytte data mellom servere tar tid

som forventet• Redundans tar tid• Lasting av data er ikke fult så

parallell

Mao. dyrere å flytte data enn å regne på dem (samme erfaring for hovedfaget fra IFI: Distribuertedatabaser og design mhp ytelse.fra1992)Eneste stor HashMap

12

13


Estimert fullskala produksjon

• 28.000 Selvangivelser i sekundet (ca 3 minutter)• 56.000 Skatteberegninger i sekunder (ca 90 sekunder)

• 5.100.000 Selvangivelse & Skatt og Skattekort• 80.000.000 Grunnlagsdata & Underskjemaer• 120 Gb RAM netto• 370 Gb RAM brutto med 1x redundans og indekser• 12 Servere (Intel i7) a 32 Gb• Last av XML fra fil: 6000tps => 5 timer

• Ekstrem ytelse ikke så viktig i seg selv, men gir handlingsrom• Kost ca 400.000 i servere og 1 million i lisens• Alt behøver ikke være i minne

http://tormodv.blogspot.com/2012/01/tax-norways-poc-results.html

ca 3kb pr selvangivelseHW og lisenser

PoC: 3 std. servere á 25.000 krGemFire lisenser: 1 mill

Server 25.000, 1Tb RAM 200.000, $12.000 pr 6core-CPU(vi har 13.000 på 3 servere). Selv disse i sekvens er raskere enn dagens

14


Erfaring

• Konseptet innfrir!• Forretningsnær og vedlikeholdbar kode kan yte sykt bra• Funksjonelle tester som regneark• Kode som fagperson kan lese (DSL)

• Informasjonsmodellen er også viktig • Åpne standarder gir verktøy, komponenter og markedsstøtte• Handlingsrom for valg av kjøreplattform, skalere ved behov• Omskriving er høyst oppnåelig• La POJO utvikling være styrende, ikke xml-definisjoner• Passer også for andre applikasjonstyper

• Lagre aggregatet når det passer

putSumPost("3.4", sum(post("3.1.14"), minus(post("3.3.13"))))

putSumPost("3.5.1",hvis(post("3.3.7.3")).er(kr(0)).brukDa(hvis(post("3.5.1.1")).ikkeEr(kr(0)).brukDa(post("3.5.1.1"))))

Svært fleksible deployment modellerSpeilet Grid for Operasjonelt Datavarehus Enda enklere failoverRimelig HW fordi den kan feileBruk failover ved høy last

Regelmotor vil aldre helt ta av. DSL ruler!

massivt skalerbar skatteberegning

Technology