Hvorfor trenger et selskap som MegaFon Tarantool i fakturering? Fra utsiden ser det ut til at selgeren vanligvis kommer, tar med en slags stor boks, setter støpselet inn i stikkontakten - og det er fakturering! Dette var en gang tilfelle, men nå er det arkaisk, og slike dinosaurer har allerede blitt utryddet eller holder på å bli utryddet. I utgangspunktet er fakturering et system for utstedelse av fakturaer - en tellemaskin eller kalkulator. I moderne telekom er dette automatiseringssystem for hele livssyklusen av interaksjon med en abonnent fra inngåelse av en kontrakt til oppsigelse, inkludert sanntidsfakturering, betalingsmottak og mye mer. Fakturering i telekomselskaper er som en kamprobot – stor, kraftig og lastet med våpen.
Hva har Tarantool med det å gjøre? De vil snakke om det Oleg Ivlev и Andrey Knyazev. Oleg er sjefsarkitekten for selskapet med lang erfaring fra utenlandske selskaper, er Andrey direktør for forretningssystemer. Fra utskriften av rapporten deres på du vil lære hvorfor FoU er nødvendig i selskaper, hva Tarantool er, hvordan blindgate av vertikal skalering og globalisering ble forutsetningene for utseendet til denne databasen i selskapet, om teknologiske utfordringer, arkitektonisk transformasjon og hvordan MegaFons technostack ligner på Netflix , Google og Amazon.
Prosjekt "Unified Billing"
Det aktuelle prosjektet kalles "Unified Billing". Det var her Tarantool viste sine beste egenskaper.
Veksten i produktiviteten til Hi-End-utstyr holdt ikke tritt med veksten i abonnentbasen og veksten i antall tjenester; ytterligere vekst i antall abonnenter og tjenester var forventet på grunn av M2M, IoT og bransjefunksjoner førte til en forverring av time-to-market. Selskapet bestemte seg for å lage et enhetlig forretningssystem med en unik modulær arkitektur i verdensklasse, i stedet for 8 nåværende forskjellige faktureringssystemer.
MegaFon er åtte selskaper i ett. I 2009 ble omorganiseringen fullført: filialer over hele Russland slo seg sammen til et enkelt selskap, MegaFon OJSC (nå PJSC). Dermed har selskapet 8 faktureringssystemer med egne "tilpassede" løsninger, filialfunksjoner og ulike organisasjonsstrukturer, IT og markedsføring.
Alt var bra helt til vi måtte lansere ett felles føderalt produkt. Her oppsto mange vanskeligheter: for noen rundes tariffer opp, for andre rundes ned, og for andre - basert på det aritmetiske gjennomsnittet. Det er tusenvis av slike øyeblikk.
Til tross for at det kun fantes én versjon av faktureringssystemet, én leverandør, skilte innstillingene seg så mye at det tok lang tid å sette sammen. Vi prøvde å redusere antallet, og kom over et annet problem som er kjent for mange selskaper.
Vertikal skalering. Selv den kuleste maskinvaren på den tiden dekket ikke behovene. Vi brukte Hewlett-Packard-utstyr fra Superdome Hi-End-linjen, men det dekket ikke behovene til to grener. Jeg ønsket horisontal skalering uten store driftskostnader og kapitalinvesteringer.
Forventning om vekst i antall abonnenter og tjenester. Konsulenter har lenge brakt historier om IoT og M2M til telekomverdenen: Tiden kommer da hver telefon og strykejern vil ha et SIM-kort, og to i kjøleskapet. I dag har vi like mange abonnenter, men i nær fremtid vil det bli mange flere.
Teknologiske utfordringer
Disse fire grunnene motiverte oss til å gjøre alvorlige endringer. Det var et valg mellom å oppgradere systemet og designe fra bunnen av. Vi tenkte lenge, tok seriøse avgjørelser, spilte anbud. Som et resultat bestemte vi oss for å designe helt fra begynnelsen, og tok på oss interessante utfordringer – teknologiske utfordringer.
Skalerbarhet
Hvis det var før, la oss si, la oss si 8 faktureringer for 15 millioner abonnenter, og nå burde det ha fungert 100 millioner abonnenter og mer - belastningen er en størrelsesorden høyere.
Vi har blitt sammenlignbare i skala med store Internett-aktører som Mail.ru eller Netflix.
Men den videre bevegelsen for å øke belastningen og abonnentbasen har satt store utfordringer for oss.
Geografi av vårt enorme land
Mellom Kaliningrad og Vladivostok 7500 km og 10 tidssoner. Lysets hastighet er begrenset og på slike avstander er forsinkelsene allerede betydelige. 150 ms på de kuleste moderne optiske kanalene er for mye for sanntidsfakturering, spesielt ettersom det nå er i telekom i Russland. I tillegg må du oppdatere på én virkedag, og med ulike tidssoner er dette et problem.
Vi tilbyr ikke bare tjenester mot et abonnementsgebyr, vi har komplekse tariffer, pakker og ulike modifikatorer. Vi må ikke bare tillate eller nekte abonnenten å snakke, men gi ham en viss kvote - beregne samtaler og handlinger i sanntid slik at han ikke legger merke til det.
feiltoleranse
Dette er den andre siden av sentralisering.
Hvis vi samler alle abonnenter i ett system, er eventuelle nødhendelser og katastrofer katastrofale for virksomheten. Derfor designer vi systemet på en slik måte at det eliminerer virkningen av ulykker på hele abonnentbasen.
Dette er igjen en konsekvens av nektet å skalere vertikalt. Når vi skalert horisontalt, økte vi antallet servere fra hundrevis til tusenvis. De må administreres og utskiftbare, automatisk sikkerhetskopiere IT-infrastrukturen og gjenopprette det distribuerte systemet.
Vi møtte slike interessante utfordringer. Vi designet systemet, og i det øyeblikket prøvde vi å finne globale beste praksiser for å sjekke hvor i trenden vi er, hvor mye vi følger avanserte teknologier.
Verdensopplevelse
Overraskende nok fant vi ikke en eneste referanse i global telekom.
Europa har falt bort når det gjelder antall abonnenter og omfang, USA - når det gjelder flatheten i tariffer. Vi så på noen i Kina, og fant noen i India og leide inn spesialister fra Vodafone India.
For å analysere arkitekturen, satt vi sammen et Dream Team ledet av IBM - arkitekter fra forskjellige felt. Disse menneskene kunne tilstrekkelig vurdere hva vi gjorde og bringe viss kunnskap til arkitekturen vår.
Skala
Noen tall for illustrasjon.
Vi designer systemet for 80 millioner abonnenter med en reserve på én milliard. Slik fjerner vi fremtidige terskler. Dette er ikke fordi vi skal ta over Kina, men på grunn av angrepet av IoT og M2M.
300 millioner dokumenter behandlet i sanntid. Selv om vi har 80 millioner abonnenter, jobber vi med både potensielle kunder og de som har forlatt oss dersom vi trenger å samle inn fordringer. Derfor er de faktiske volumene merkbart større.
2 milliarder transaksjoner Saldoen endres daglig - dette er betalinger, gebyrer, samtaler og andre hendelser. 200 TB med data endres aktivt, endre litt saktere 8 PB med data, og dette er ikke et arkiv, men live data i en enkelt fakturering. Skaler etter datasenter - 5 tusen servere på 14 nettsteder.
Teknologistabel
Da vi planla arkitekturen og begynte å sette sammen systemet, importerte vi de mest interessante og avanserte teknologiene. Resultatet er en teknologistabel som er kjent for alle Internett-spillere og selskaper som lager høybelastningssystemer.
Stabelen ligner stablene til andre store aktører: Netflix, Twitter, Viber. Den består av 6 komponenter, men vi ønsker å forkorte og forene den.
Fleksibilitet er bra, men i et stort konsern er det ingen vei uten forening.
Vi kommer ikke til å endre det samme Oracle til Tarantool. I realitetene til store selskaper er dette en utopi, eller et korstog i 5-10 år med et uklart utfall. Men Cassandra og Couchbase kan enkelt erstattes med Tarantool, og det er det vi streber etter.
Hvorfor Tarantool?
Det er 4 enkle kriterier for hvorfor vi valgte denne databasen.
Fart. Vi utførte belastningstester på MegaFon industrisystemer. Tarantool vant - den viste den beste ytelsen.
Det er ikke dermed sagt at andre systemer ikke oppfyller MegaFons behov. Dagens minneløsninger er så produktive at selskapets reserver er mer enn nok. Men vi er interessert i å forholde oss til en leder, og ikke med noen som henger etter, også i belastningstesten.
Tarantool dekker selskapets behov også på lang sikt.
TCO kostnad. Støtte for Couchbase på MegaFon-volumer koster astronomiske summer, men med Tarantool er situasjonen mye mer behagelig, og de er like i funksjonalitet.
En annen fin funksjon som påvirket vårt valg litt er at Tarantool fungerer bedre med minne enn andre databaser. Han viser maksimal effektivitet.
Pålitelighet. MegaFon investerer i pålitelighet, sannsynligvis mer enn noen andre. Så da vi så på Tarantool, innså vi at vi måtte få det til å oppfylle kravene våre.
Vi investerte tid og økonomi, og sammen med Mail.ru laget vi en bedriftsversjon, som nå brukes i flere andre selskaper.
Tarantool-enterprise tilfredsstilte oss helt når det gjelder sikkerhet, pålitelighet og logging.
partnerskap
Det viktigste for meg er direkte kontakt med utbygger. Det er akkurat dette gutta fra Tarantool bestukket med.
Hvis du kommer til en spiller, spesielt en som jobber med en ankerklient, og sier at du trenger databasen for å kunne gjøre dette, dette og dette, svarer han vanligvis:
– Ok, legg kravene nederst i den bunken – en dag kommer vi nok til dem.
Mange har et veikart for de neste 2-3 årene, og det er nesten umulig å integrere der, men Tarantool-utviklere fengsler med sin åpenhet, og ikke bare fra MegaFon, og tilpasser systemet sitt til kunden. Det er kult og vi liker det veldig godt.
Der vi brukte Tarantool
Vi bruker Tarantool i flere elementer. Den første er i piloten, som vi laget på adressekatalogsystemet. En gang ønsket jeg at det skulle være et system som lignet Yandex.Maps og Google Maps, men det ble litt annerledes.
For eksempel adressekatalogen i salgsgrensesnittet. På Oracle tar det 12-13 sekunder å søke etter ønsket adresse. - ubehagelige tall. Når vi bytter til Tarantool, erstatter Oracle med en annen database i konsollen og utfører det samme søket, får vi en 200x speedup! Byen dukker opp etter den tredje bokstaven. Nå tilpasser vi grensesnittet slik at dette skjer etter det første. Responshastigheten er imidlertid en helt annen – millisekunder i stedet for sekunder.
Den andre applikasjonen er et trendy tema kalt to-hastighets IT. Dette er fordi konsulenter fra hvert hjørne sier at selskaper bør gå dit.
Det er et infrastrukturlag, over det er det domener, for eksempel et faktureringssystem som telekom, bedriftssystemer, bedriftsrapportering. Dette er kjernen som ikke trenger å berøres. Det er, selvfølgelig, det er mulig, men paranoidt å sikre kvalitet, fordi det gir penger til selskapet.
Deretter kommer laget av mikrotjenester – det som skiller operatøren eller annen aktør. Mikrotjenester kan raskt opprettes basert på bestemte cacher, og bringe data fra forskjellige domener dit. Her felt for eksperimenter – Hvis noe ikke fungerte, lukket jeg en mikrotjeneste og åpnet en annen. Dette gir virkelig økt time-to-market og øker påliteligheten og hastigheten til selskapet.
Mikrotjenester er kanskje hovedrollen til Tarantool hos MegaFon.
Hvor vi planlegger å bruke Tarantool
Hvis vi sammenligner vårt vellykkede faktureringsprosjekt med transformasjonsprogrammene hos Deutsche Telekom, Svyazcom, Vodafone India, er det overraskende dynamisk og kreativt. I prosessen med å implementere dette prosjektet ble ikke bare MegaFon og dets struktur transformert, men også Tarantool-enterprise dukket opp på Mail.ru, og vår leverandør Nexign (tidligere Peter-Service) - BSS Box (en eske faktureringsløsning).
Dette er på en måte et historisk prosjekt for det russiske markedet. Det kan sammenlignes med det som er beskrevet i boken «The Mythical Man-Month» av Frederick Brooks. Så, på 60-tallet, ansatte IBM 360 personer for å utvikle det nye OS/5-operativsystemet for stormaskiner. Vi har færre – 000, men våre er i vest, og tatt i betraktning bruk av åpen kildekode og nye tilnærminger, jobber vi mer produktivt.
Nedenfor er domenene til fakturering eller, mer generelt sett, forretningssystemer. Folk fra bedrifter kjenner CRM veldig godt. Alle burde allerede ha andre systemer: Open API, API Gateway.
Åpne API
La oss se på tallene igjen og hvordan Open API fungerer for øyeblikket. Lasten er 10 000 transaksjoner per sekund. Siden vi planlegger å aktivt utvikle mikrotjenester-laget og bygge den offentlige MegaFon API, forventer vi større vekst i fremtiden i denne delen. Det vil definitivt være 100 000 transaksjoner.
Jeg vet ikke om vi kan sammenligne med Mail.ru i SSO - gutta ser ut til å ha 1 000 0000 transaksjoner per sekund. Løsningen deres er ekstremt interessant for oss, og vi planlegger å ta i bruk deres erfaring - for eksempel å lage en funksjonell SSO-sikkerhetskopi ved hjelp av Tarantool. Nå gjør utviklerne fra Mail.ru dette for oss.
CRM
CRM er de samme 80 millioner abonnentene som vi ønsker å øke til en milliard, fordi det allerede er 300 millioner dokumenter som inkluderer en treårig historie. Vi gleder oss veldig til nye tjenester og her vekstpunktet er tilkoblede tjenester. Dette er en ball som vil vokse, for det blir flere og flere tjenester. Følgelig vil vi trenge en historie; vi ønsker ikke å snuble over dette.
Fakturerer seg selv i form av utstedelse av fakturaer, arbeider med kundereskontro omdannet til et eget domene. For å forbedre ytelsen, anvendt domenearkitektur arkitektonisk mønster.
Systemet er delt inn i domener, lasten fordeles og feiltoleranse er sikret. I tillegg jobbet vi med distribuert arkitektur.
Alt annet er løsninger på bedriftsnivå. I samtalelageret - 2 milliarder per dag60 milliarder kroner per måned. Noen ganger må du telle dem om en måned, og det blir raskt bedre. Økonomisk overvåking – dette er nøyaktig de samme 300 millionene som stadig vokser og vokser: Abonnenter løper ofte mellom operatører, og øker denne delen.
Den mest telekomkomponenten i mobilkommunikasjon er nettfakturering. Dette er systemene som lar deg ringe eller ikke ringe, ta avgjørelser i sanntid. Her er belastningen 30 000 transaksjoner per sekund, men tatt i betraktning veksten i dataoverføring planlegger vi 250 000 transaksjoner, og derfor er vi veldig interessert i Tarantool.
Det forrige bildet er domenene der vi skal bruke Tarantool. CRM i seg selv er selvfølgelig bredere, og vi kommer til å bruke det i selve kjernen.
Vårt estimerte TTX-tall på 100 millioner abonnenter forvirrer meg som arkitekt - hva om 101 millioner? Må du gjøre om alt på nytt? For å forhindre at dette skjer bruker vi cacher, samtidig som vi øker tilgjengeligheten.
Generelt er det to måter å bruke Tarantool på. Først - bygge alle cacher på mikroservicenivå. Så vidt jeg forstår, følger VimpelCom denne veien, og lager en cache av klienter.
Vi er mindre avhengige av leverandører, vi endrer BSS-kjernen, så vi har én enkelt klientfil ut av esken. Men vi ønsker å utvide den. Derfor tar vi en litt annen tilnærming - lage cacher inne i systemer.
På denne måten er det mindre synkronisering - ett system er ansvarlig for både hurtigbufferen og hovedkilden.
Metoden passer godt med Tarantool-tilnærmingen med et transaksjonsskjelett, når kun deler som relaterer seg til oppdateringer, det vil si dataendringer, oppdateres. Alt annet kan lagres et annet sted. Det er ingen stor datainnsjø, uadministrert global cache. Cacher er designet for systemet, eller for produkter, eller for klienter, eller for å gjøre livet enklere for vedlikehold. Når en abonnent ringer og er opprørt over kvaliteten på tjenesten din, ønsker du å tilby kvalitetsservice.
RTO og RPO
Det er to begreper i IT - RTO и RPO.
Mål for gjenopprettingstid er tiden det tar å gjenopprette tjenesten etter en feil. RTO = 0 betyr at selv om noe feiler, fortsetter tjenesten å fungere.
Gjenopprettingspunktmål - dette er datagjenopprettingstiden, hvor mye data vi kan miste over en viss tidsperiode. RPO = 0 betyr at vi ikke mister data.
Tarantool oppgave
La oss prøve å løse et problem for Tarantool.
Gitt: en kurv med applikasjoner som alle forstår, for eksempel i Amazon eller et annet sted. nødvendig slik at handlekurven fungerer 24 timer 7 dager i uken, eller 99,99 % av tiden. Bestillingene som kommer til oss må forbli i orden, fordi vi ikke tilfeldig kan slå på eller slå av abonnentens tilkobling - alt må være strengt konsistent. Det forrige abonnementet påvirker det neste, så dataene er viktige - ingenting bør gå glipp av.
beslutning. Du kan prøve å løse det direkte og spørre databaseutviklerne, men problemet kan ikke løses matematisk. Du kan huske teoremer, bevaringslover, kvantefysikk, men hvorfor - det kan ikke løses på DB-nivå.
Den gode gamle arkitektoniske tilnærmingen fungerer her - du må kjenne fagområdet godt og bruke det til å løse dette puslespillet.
Vår løsning: opprette et distribuert register over applikasjoner på Tarantool - en geo-distribuert klynge. I diagrammet er dette tre forskjellige databehandlingssentre - to før Ural, ett utenfor Ural, og vi fordeler alle forespørsler mellom disse sentrene.
Netflix, som nå regnes som en av lederne innen IT, hadde bare ett datasenter frem til 2012. På tampen av katolsk jul, 24. desember, gikk dette datasenteret ned. Brukere i Canada og USA ble stående uten favorittfilmene sine, var veldig opprørt og skrev om det på sosiale nettverk. Netflix har nå tre datasentre på vest-østkysten og ett i Vest-Europa.
Vi bygger i første omgang en geodistribuert løsning – feiltoleranse er viktig for oss.
Så vi har en klynge, men hva med RPO = 0 og RTO = 0? Løsningen er enkel, avhengig av emnet.
Hva er viktig i søknader? To deler: Kurvkasting TIL ta en kjøpsbeslutning, og ETTER. DO-delen i telekom kalles vanligvis ordrefangst eller ordreforhandling. I telekom kan dette være mye vanskeligere enn i en nettbutikk, fordi der må klienten betjenes, tilbys 5 alternativer, og alt dette skjer en stund, men kurven er fylt. I dette øyeblikket er en feil mulig, men det er ikke skummelt, fordi det skjer interaktivt under menneskelig tilsyn.
Hvis Moskva-datasenteret plutselig mislykkes, vil vi fortsette å jobbe ved automatisk å bytte til et annet datasenter. Teoretisk sett kan ett produkt gå tapt i handlekurven, men du ser det, legg til i handlekurven igjen og fortsett å jobbe. I dette tilfellet er RTO = 0.
I samme øyeblikk er det et annet alternativ: når vi klikket "send", vil vi at dataene ikke skal gå tapt. Fra dette øyeblikket begynner automatiseringen å fungere - dette er RPO = 0. Ved å bruke disse to forskjellige mønstrene, kan det i ett tilfelle ganske enkelt være en geo-distribuert klynge med en skiftbar master, i et annet tilfelle en slags quorum-record. Mønstrene kan variere, men vi løser problemet.
Videre, med et distribuert register over applikasjoner, kan vi også skalere det hele - har mange ekspeditører og eksekutorer som får tilgang til dette registeret.
Cassandra og Tarantool sammen
Det er et annet tilfelle - "utstillingsvindu for balanser". Her er et interessant tilfelle av felles bruk av Cassandra og Tarantool.
Vi bruker Cassandra fordi 2 milliarder samtaler per dag ikke er grensen, og det vil bli flere. Markedsførere elsker å fargelegge trafikk etter kilde; flere og flere detaljer vises på sosiale nettverk, for eksempel. Alt bidrar til historien.
Cassandra lar deg skalere horisontalt til alle størrelser.
Vi føler oss komfortable med Cassandra, men den har ett problem - den er ikke god til å lese. Alt er OK på opptaket, 30 000 per sekund er ikke noe problem - leseproblem.
Derfor dukket det opp et emne med en cache, og samtidig løste vi følgende problem: det er en gammel tradisjonell sak når utstyr fra en bytte fra nettfakturering kommer inn i filene som vi laster inn i Cassandra. Vi slet med problemet med pålitelig nedlasting av disse filene, til og med ved å bruke råd fra IBM-lederfiloverføring - det finnes løsninger som håndterer filoverføring effektivt, for eksempel ved å bruke UDP-protokollen i stedet for TCP. Dette er bra, men det er fortsatt minutter, og vi har ikke lastet alt ennå, operatøren i kundesenteret kan ikke svare klienten hva som skjedde med saldoen hans - vi må vente.
For å forhindre at dette skjer, har vi vi bruker parallell funksjonell reserve. Når vi sender en hendelse via Kafka til Tarantool, omberegning av aggregater i sanntid, for eksempel for i dag, får vi kontantbeholdning, som kan overføre saldoer i hvilken som helst hastighet, for eksempel 100 tusen transaksjoner per sekund og de samme 2 sekundene.
Målet er at etter å ha ringt, vil det innen 2 sekunder på din personlige konto ikke bare være den endrede saldoen, men informasjon om hvorfor den endret seg.
Konklusjon
Dette var eksempler på bruk av Tarantool. Vi likte virkelig åpenheten til Mail.ru og deres vilje til å vurdere forskjellige saker.
Det er allerede vanskelig for konsulenter fra BCG eller McKinsey, Accenture eller IBM å overraske oss med noe nytt – mye av det de tilbyr, enten gjør vi allerede, har gjort eller planlegger å gjøre. Jeg tror at Tarantool vil ta sin rettmessige plass i teknologistabelen vår og erstatte mange eksisterende teknologier. Vi er i den aktive utviklingsfasen av dette prosjektet.
Rapporten til Oleg og Andrey er en av de beste på Tarantool-konferansen i fjor, og 17. juni taler Oleg Ivlev kl. med en rapport . Alexander Deulin vil også holde en presentasjon fra MegaFon . La oss finne ut hva som har endret seg, hvilke planer som er gjennomført. Bli med – konferansen er gratis, alt du trenger å gjøre er ... Alt og konferanseprogrammet har blitt dannet: nye saker, ny erfaring med å bruke Tarantool, arkitektur, bedrift, opplæringsprogrammer og mikrotjenester.
Kilde: www.habr.com