Virksomhedspræsentation for IDA

Transkript

1 Netcompany Virksomhedspræsentation for IDA Version: 1.0 Status: Endelig Forfatter: Thomas Koefoed Principal Copyright 2015 Netcompany A/S. Alle rettigheder forbeholdes. Elektronisk, mekanisk, fotografisk eller anden gengivelse, oversættelse eller kopiering af dette dokument eller dele deraf er, uanset formål, ikke tilladt uden forudgående skriftlig tilladelse fra Netcompany A/S. Side 1

2 Indhold Virksomhedspræsentation Introduktion til Netcompany og oplægsholder Case: Sagsoverblik til danske kommuner Case opgaver Opsamling Side 2

3 Opgaver I opgaverne (udleveres) beskrives et antal arkitekturopgaver, som er relevante for systemets rette udformning og skalering. Gå sammen i grupper á 2-4 personer i Amalienborg, Østervold eller Bredgade (mødelokaler). Hvis I behøver afklaringer ifm. løsningen af opgaverne, så er I meget velkomne til at stille spørgsmål Opgaverne skal løses af hele gruppen i fortløbende rækkefølge. Vi mødes igen i Amalienborg (dette mødelokale). NB. Præmisserne for og tallene i - opgaverne er fiktive og ikke taget fra projektet. Side 3

4 Situationen Jeres gruppe udgør projektets arkitekturteam. Projektet er godt i gang med implementeringsforløbet, som består af 7 planlagte iterationer. I nuværende iteration 3 er det arkitekturteamets ansvar at produktionsmiljøet skaleres til kundens krav om svartider og skalerbarhed. I står derfor foran at skulle skalere systemet, og lave andre nødvendige performancetunings af løsningen. Side 4

5 Beregning af fysisk skalering Kunden stiller i udbudsmaterialet krav om at alle sider skal kunne svare på 1 sekund. Servicemål er fraregnet tid brugt på I/O operationer til eksterne systemer (i dette tilfælde webservice kald). På de to følgende slides, ses den forventede belastning af systemet over de næste 10 år. For hvert partsopslag, forventes det at brugeren i sin arbejdsgang, i gennemsnit udfører i alt 5 http GET eller POST requests til løsningen. Hvert request forårsager 3-5 I/O operationer til eksterne systemer. Kunden ønsker systemet skaleret, så det kan håndtere de første 4 års anvendelse. Systemets logiske arkitektur består af N webservere, der kommunikerer direkte med de eksterne systemer (dvs. ingen applikationsservere). Opgaver: 1. Hvor mange webservere skal der til, for at leve op til kundens krav til svartider? Hint: Husk at I/O operationer ikke medregnes - og at tid forbrugt i I/O operationer ikke anvender lokal CPU. 2. Hvad kan man gøre for at minimere antallet af nødvendige webservere? 3. Hvor mange webservere forventer I at kunne fjerne ved ovenstående optimering? 4. Hvilke antagelser har I gjort i opgave 1-3? Side 5

6 Belastningsprofil - Antal brugere over tid Side 6

7 Belastningsprofil Partsopslag per sekund 300 SAPA forventet udvikling i antal transaktioner pr. sekund Maks transaktioner Forventet øget forbrug Sikkerhedsfaktor SUM 0 År 1 År 2 År 3 År 4 År 5 År 6 År 7 År 8 År 9 År 10 Blå = Forventede partsopslag pr. sekund Rød = Anslået vækst ved udvidet brug af Systemet Grøn = Sikkerhedsmargin Lilla = Summen af de tre andre kurver Side 7

8 Tråd-flaskehalsen På trods af jeres retmæssige sizing af produktionsmiljøet, viser der sig fejl ved performancetesten i præproduktion. Systemet kan kun håndtere cirka halvdelen af de forventede requests, før klienten modtager HTTP code 500 (internal server error). Et kig i en af systemets tekniske logs, afslører mange forekomster af fejlmeddelelsen Error: No threads available to handle incoming request. Et kig i servicemål loggen afslører, at der internt i systemet ikke anvendes længere tid per request end forventet. Opgave: 1. Hvor i systemet er det mest sandsynligt at problemet ligger? 2. Foreslå et softwaredesign, som optimerer systemet ift. denne flaskehals. Hint: En I/O operation til backenden tager betydeligt længere tid end serverens håndtering af indkommende requests (uden brug af cache). Hint: Tråden returneres som standard først til applikationens thread-pool, når response er sendt til klienten. Side 8

9 Langsomme sider på trods af korrekt efterlevelse af servicemål. Det viser sig, at den foreslåede designændring løste problemet med flaskehalsen. Kunden oplever dog i systemtesten, at siderne nogen gange er meget langsomme (30-40 sekunder per side). En gennemgang af servicemål loggen afslører, at vores system i 100% af tilfældene lever op til de krævede servicemål. Ofte, men ikke hver gang, vises der fejl til brugeren på de langsomme sider. Fejlbeskederne er tekniske og brugerne forstår dem ikke. Opgaver 1. Hvad kan årsagen til ovenstående problem være? 2. Hvordan kan man udvide designet fra forrige slide, til at forbedre brugeroplevelsen ift. svartid og brugervenlige beskeder? 3. Er der problemer/uhensigtsmæssigheder ved den foreslåede løsning? Side 9

10 Sikkerhed Det viser sig nu, at systemet svarer til kundens tilfredshed og med 100% overholdelse af servicemål. Ved fortsættelse af systemtesten viser det sig nu, at brugerne kan se data, som de jf. persondataloven ikke må se. Brugerens rettigheder til at se data, er beskrevet i det SAML-token, som er udstedt af systemets secure token service: Eksempelvis indeholder SAML token et claim om hvilke sagstyper, som brugeren på se, når der hentes sager fra eksterne systemer. Eksempel (metakode) på token med claims til to tilladte sagstyper: Claim:AllowedSagstype= ;Claim:AllowedSagstype= Det er et arkitekturkrav at sikkerhed håndteres centralt ved alle kald til eksterne systemer. Det er et arkitekturkrav at tilføjelse af nye services, ikke må medføre at der skal udføres ny sikkerhedstrimning. Kun ændring af datamodel eller sikkerhedskrav, må medføre nyudvikling af sikkerhed. Løsningen skal altså være generisk ift. at frafiltrere data modtaget fra eksterne systemer. Opgave: Foreslå et softwaredesign, der løser ovenstående krav. Hint: Stil gerne spørgsmål Side 10

11 Indhold Virksomhedspræsentation Introduktion til Netcompany og oplægsholder Case: Sagsoverblik til danske kommuner Case opgaver Opsamling Side 11

12 Løsningsforslag: Fysisk skalering Antagelse: Anvender lilla kurve for at give et sikkert/konservativt estimat. Antagelse: Hvert request tager 40 millisekunder at eksekvere (fraregnet tid brugt på I/O kald). Antagelse: Tråde er ikke en knap ressource (men det er de i virkeligheden ) 210 partsopslag per sekund * 5 requests per partsoplsag = 1050 requests per sekund. Hver kerne kan servicere 1000 ms per sekund/40 ms per request = 25 requests per sekund. Antal nødvendige kerner = 1050 request per sekund / 25 requests per kerne per sekund = 42 kerner. Ved 6 kerner per server, er der derfor brug for 7 servere. Side 12

13 Løsningsforslag: Minimering af antal webservere ved brug af cache Ved brug af lokal cache, f.eks. Redis Cache, reduceres kompleksiteten af gentagne kald betydeligt. Antagelse: 1 ud af 3 webrequests kan trækkes fra cachen Antagelse: Gennemsnitligt webrequest for cachet data tager 2 ms. Ny gennemsnitlig tid per request = 2/3 * 40 ms + 1/3 * 2 ms = 27,33 ms. Hver kerne kan nu håndtere 1000/27,33 = 37 requests/sekund Nyt antal kerner = 1050 request per sekund / 37 requests per kerne per sekund = 28 kerner. Ved 6 kerner per server, svarer dette til 5 webservere (dvs. 2 færre end uden cache). Sags- og partsoverblik Behov for mere RAM per server. Frontend Load Balancer Administration ASP.NET MVC 5 ASP.NET MVC 5 ASP.NET MVC 5 ASP.NET MVC 5 ASP.NET MVC 5 Hent konfigurationsdata Sharepoint 2013 Webfarm Redis Cache Hent adviser Services Services Advismodul Støttesystemer Serviceplatformen Side 13

14 Løsningsforslag: Eliminering af tråd-flaskehals og sikring af timeout Tråd slippes ved I/O operation kæmpe forbedring af trådflaskehalsen Async service-timeout på 5 sekunder (sider tager max 6 sekunder at vise ofte meget hurtigere men af og til vises der ved denne løsning fejl, der ved længere timeout ikke ville forekomme) Fejl i servicekald håndteres igennem Exception håndtering. Fejl og timeouts håndteres, og brugervenlige fejlbeskeder sendes til brugergrænsefladen. Side 14

15 Framework kode (async pattern) Side 15

16 Løsningsforslag: Generisk filtrering af data med reflection Liste af tilladte sagstyper trukket ud fra SAML token Side 16