Skalerbare systemer
•
0 gostou•735 visualizações
Presentasjonen inneholder en oppsummering av egenskaper ved store skalerbare systemer, og deres egnethet i målarkitekturen til Skatteetaten.
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (8)
Semelhante a Skalerbare systemer
Semelhante a Skalerbare systemer (20)
Skalerbare systemer
- 1. Skalerbare systemer – Modellering for skalerbarhet Tormod Varhaugvik, SITS-IS-UTV Juni 2010 1
- 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
- 7. Drivere - Teknisk Skatteetaten – Skalerbare systemer 29.02.2012 7 7
- 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
- 35. Eksempel – Replikert cache Replication Partition 1-Primary Partition 1-Backup GSC GSC Replication Partition 2-Primary Partition 2-Backup GSC GSC Replication Partition 3-Primary Partition 3-Backup GSC GSC Skatteetaten – Skalerbare systemer 29.02.2012 35 35
- 36. Eksempel – Replikert cache • Routing basert på skattyter/familie • Spørring – ”Map – Reduce” Replication Partition 1-Primary Partition 1-Backup GSC GSC Replication Partition 2-Primary Partition 2-Backup GSC GSC Reader Writer Replication Partition 3-Primary Partition 3-Backup GSC GSC Skatteetaten – Skalerbare systemer 29.02.2012 36 36
- 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
- 41. Eksempel: Ikke-funksjonelle krav Innkjøp Butikk Utvalg B1 S1 B2 2-phase B3 B3 A2 B2 commit A1 B1 AH Ekstern Meldings- 1 tråd, alt i motor sekvens S1 A2 2-phase A1 N1 commit AH AH Pris Authorization Saksbehandlin g Skatteetaten – Skalerbare systemer 29.02.2012 41 41
- 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