Hvorfor har en virksomhed som MegaFon brug for Tarantool i faktureringen? Udefra ser det ud til, at en leverandør normalt kommer, bringer en stor kasse, sætter stikket i stikkontakten - og så er faktureringen klar! Det var engang sådan, men nu er det forældet, og sådanne dinosaurer er allerede uddødt eller er på vej til at uddø. Oprindeligt var fakturering et system til at udstede regninger - en regnemaskine eller kalkulator. I den moderne telekomverden er det et system til automatisering af hele livscyklussen for interaktion med abonnenten fra indgåelse af kontrakt til opsigelse, inklusiv real-time taksering, modtagelse af betalinger og meget mere. Fakturering i telekomfirmaer ligner en kamprobot - stor, stærk og udstyret med våben.
Hvad har Tarantool at gøre med dette? Det vil Oleg Ivlev og Andrey Knyazev. Oleg er hovedarkitekten for virksomheden med stor erfaring fra udenlandske virksomheder, Andrey er direktør for forretningssystemer. Fra deres foredrag på vil du finde ud af, hvorfor R&D er nødvendigt i virksomheder, hvad Tarantool er, hvordan begrænsningerne ved vertikal skalerbarhed og globalisering blev forudsætningerne for denne database i virksomheden, om teknologiske udfordringer, transformation af arkitektur, og hvordan MegaFons teknologistak ligner Netflix, Google og Amazon.
Projektet 'Unified Billing'
Projektet, som vil blive omtalt, hedder 'Unified Billing'. Det var netop her, at Tarantool viste sine bedste egenskaber.
Væksten i ydeevnen for Hi-End udstyr kunne ikke følge med væksten i abonnentbasen og antallet af tjenester; der forventedes en yderligere stigning i antallet af abonnenter og tjenester på grund af M2M, IoT, og filialernes særegenheder førte til en forværring af time-to-market. Virksomheden besluttede at skabe et enkelt forretningssystem med en unik modulær arkitektur af verdensklasse, i stedet for de 8 nuværende forskellige faktureringssystemer.
MegaFon er otte selskaber i ét. I 2009 blev reorganiseringen afsluttet: filialer over hele Rusland blev samlet i et enkelt selskab, OAO 'MegaFon' (nu PAO). Dermed opstod der 8 faktureringssystemer i virksomheden med deres egne 'custom' løsninger, filial-specifikke træk og forskellige organisatoriske strukturer, IT og marketing.
Alt var godt, indtil vi skulle lancere et fælles nationalt produkt. Her opstod der en lang række udfordringer: Nogen har taksering med afrunding opad, andre nedad, og nogle efter det aritmetiske gennemsnit. Der er tusinder af sådanne situationer.
På trods af at versionen af faktureringssystemet er den samme, er der kun én leverandør, men indstillingerne var så forskellige, at det tog lang tid at limme dem sammen. Vi forsøgte at reducere antallet af dem og stødte på et andet problem, som mange virksomheder kender.
Vertikal skalering. Selv det mest avancerede udstyr på det tidspunkt kunne ikke imødekomme behovene. I arbejdet brugte vi Hewlett-Packard-udstyr fra linjen Superdome Hi-End, men det kunne ikke opfylde behovene selv for to filialer. Vi ønskede horisontal skalering uden store driftsomkostninger og kapitalinvesteringer.
Forventning om vækst i antallet af abonnenter og tjenester. Konsulenterne har længe bragt fortællinger om IoT og M2M ind i telekomverdenen: Der kommer en tid, hvor der vil være et SIM-kort i hver telefon og strygejern, og to i køleskabet. I dag har vi et antal abonnenter, men i den nærmeste fremtid vil der være mange gange flere.
Teknologiske udfordringer
Disse fire grunde drev os til alvorlige forandringer. Der var et valg mellem at opgradere systemet og designe det fra bunden. Vi tænkte længe, traf alvorlige beslutninger og deltog i udbud. I sidste ende besluttede vi at designe fra bunden og tage fat på spændende udfordringer - teknologiske udfordringer.
Skalering
Hvis det tidligere var, lad os sige 8 faktureringssystemer med 15 millioner abonnenter, så skulle det nu blive 100 millioner abonnenter eller flere — belastningen er meget højere.
Vi blev sammenlignelige i størrelse med store internetaktører som Mail.ru eller Netflix.
Men den videre bevægelse mod øget belastning og abonnentbase stiller alvorlige krav til os.
Geografien i vores enorme land
Mellem Kaliningrad og Vladivostok 7500 km og 10 tidszoner. Lysets hastighed er endelig, og på sådanne afstande er forsinkelsen allerede betydningsfuld. 150 ms på de mest avancerede optiske kanaler er for meget til real-time taksering, især som den er i telekom i Rusland nu. Desuden er det nødvendigt at opdatere inden for en arbejdsdag, og med forskellige tidszoner er det et problem.
Vi tilbyder ikke bare abonnementsbaserede tjenester, vi har komplekse tariffer, pakker og forskellige modifikatorer. Vi skal ikke bare give abonnenten lov til at tale eller ikke tale, men vi skal give ham en bestemt kvote – vi skal tælle opkald og handlinger i realtid, så han ikke bemærker det.
Fejltolerance
Det er bagsiden af centralisering.
Hvis vi samler alle abonnenter i ét system, vil enhver nødsituation og katastrofe være katastrofal for forretningen. Derfor designer vi systemet, så det udelukker indflydelsen fra afbrydelser på hele abonnentbasen.
Dette er igen et resultat af at opgive vertikal skalerbarhed. Da vi gik over til horisontal skalerbarhed, øgede vi antallet af servere fra hundrede til tusinder. De skal styres, og der skal bygges udskiftelighed, automatisk reservedele IT-infrastruktur og genoprettes distribuerede systemer.
Der var interessante udfordringer foran os. Vi designede systemet og forsøgte i det øjeblik at finde global best practice for at se, hvorvidt vi var på rette spor, og i hvor høj grad vi fulgte med i teknologierne.
Global erfaring
Overraskende nok fandt vi ikke en eneste reference i den globale telekommunikationsindustri.
Europa var ikke relevant i forhold til antal abonnenter og omfang, USA – på grund af fladen af deres takster. Vi kiggede lidt i Kina og fandt noget i Indien og tog specialister fra Vodafone India.
Til at analysere arkitekturen samlede vi Dream Team ledet af IBM – arkitekter fra forskellige områder. Disse personer kunne vurdere, hvad vi gjorde, og bringe bestemte viden ind i vores arkitektur.
Skala
Nogle tal til illustration.
Vi designer systemet til 80 mio. abonnenter med plads til en milliard. Sådan fjerner vi fremtidige grænser. Det er ikke fordi vi planlægger at erobre Kina, men på grund af presset fra IoT og M2M.
300 mio. dokumenter behandles i realtid. Selvom vi har 80 mio. abonnenter, arbejder vi også med potentielle kunder og dem, der er forladt os, hvis der er behov for at inddrive fordringer. Derfor er de reelle volumen betydeligt større.
2 mia. transaktioner ændrer saldo dagligt – det er betalinger, opkrævninger, opkald og andre begivenheder. 200 TB data ændres aktivt, lidt langsommere ændres 8 PB data, og dette er ikke en arkiv, men levende data i ét billing-system. Skalaen på datacentre er 5.000 servere på 14 lokationer.
Teknologisk stak
Da vi planlagde arkitekturen og begyndte at opbygge systemet, importerede vi de mest interessante og avancerede teknologier. Resultatet blev en teknologistak, som er kendt af enhver spiller på internettet og af virksomheder, der skaber højtydende systemer.
Stakken ligner stakkene hos andre store spillere: Netflix, Twitter, Viber. Den består af 6 komponenter, men vi ønsker at forkorte og forene den.
Fleksibilitet er godt, men i en stor virksomhed er der ingen vej uden ensretning.
Vi har ikke tænkt os at erstatte Oracle med Tarantool. I store virksomheders realiteter ville det være en utopi, eller en korsfarertur på 5-10 år med et uforudsigeligt resultat. Men Cassandra og Couchbase kan sagtens erstattes med Tarantool, og det er vi i gang med.
Hvorfor Tarantool?
Der er 4 enkle kriterier for, hvorfor vi valgte denne database.
Hastighed. Vi har gennemført belastningstests på MegaFons industrielle systemer. Tarantool vandt – det viste den bedste ydeevne.
Det kan ikke siges, at andre systemer ikke imødekommer MegaFons behov. De nuværende memory-løsninger er så effektive, at denne kapacitet er mere end tilstrækkelig for virksomheden. Men vi er interesseret i at arbejde med en leder, og ikke med dem, der halter bagefter, også hvad angår belastningstest.
Tarantool imødekommer virksomhedens behov, selv på lang sigt.
TCO-omkostninger. Support af Couchbase i MegaFons omfang koster astronomiske beløb, mens situationen med Tarantool er langt mere behagelig, og de er tæt på hinanden hvad funktionalitet angår.
En anden behagelig egenskab, som lidt påvirkede vores valg – Tarantool fungerer bedre end de andre databaser med hukommelsen. Den viser maksimal effektivitet.
Pålidelighed. MegaFon investerer i pålidelighed, måske som ingen andre. Så da vi kiggede på Tarantool, indså vi, at vi måtte sørge for, at det kunne opfylde vores krav.
Vi har investeret vores tid og penge, og sammen med Mail.ru har vi skabt en enterprise-version, som nu bruges i flere andre virksomheder.
Tarantool-enterprise tilfredsstillede os fuldt ud på sikkerhed, pålidelighed og loggning.
Partnerskab
Det vigtigste for mig er den direkte kontakt med udvikleren. Det er præcis det, som folkene fra Tarantool har vundet os over med.
Når du henvender dig til en spiller, især en der arbejder med en ankerkunde, og siger, at du har brug for, at databasen skal kunne gøre dette, dette og dette, svarer de som regel:
— Godt, læg kravene nederst i den bunke — på et tidspunkt, måske, når vi kommer til dem.
Mange har en roadmap for de næste 2-3 år, og det er næsten umuligt at få plads der, men udviklerne af Tarantool tiltrækker med deres åbenhed, ikke kun med MegaFon, og tilpasser deres system til kunden. Det er fantastisk, og vi kan virkelig lide det.
Hvor vi anvendte Tarantool
Vi bruger Tarantool i flere elementer. Det første er i piloten, som vi lavede på adressen katalogsystemet. I sin tid ønskede vi, at det skulle være et system, der ligner Yandex.Kort og Google Maps, men det endte med at blive lidt anderledes.
For eksempel, adressekataloget i salgsgrænsefladen. På Oracle tager det 12-13 sekunder at finde den ønskede adresse — ikke komfortable tal. Når vi skifter til Tarantool, erstatter vi Oracle med en anden database i konsollen, og udfører den samme søgning, så får vi en acceleration på 200 gange! Byen dukker op efter det tredje bogstav. Vi tilpasser nu grænsefladen, så det sker efter det første. Alligevel er responstiden helt anderledes — nu millisekunder i stedet for sekunder.
Det andet anvendelsesområde er et populært emne, der kaldes to-hastigheds IT. Alt fordi konsulenter fra hvert hjørne siger, at virksomheder bør gå den vej.
Her er der et lag af infrastruktur, over det er domæner, for eksempel billing systemer, som i telekommunikation, virksomhedssystemer, virksomhedsrapportering. Dette er kernen, som ikke bør røres. Det vil sige, at man naturligvis kan, men på en paranoid måde sikrer kvalitet, fordi det bringer penge til virksomheden.
Dernæst er lag af mikrotjenester — det, der differentierer operatøren eller en anden spiller. Mikrotjenester kan hurtigt skabes baseret på visse caches, der henter data fra forskellige domæner. Her er der plads til eksperimenter — hvis noget mislykkes, lukker man en mikrotjeneste, åbner en anden. Dette sikrer virkelig en øget time-to-market og øger pålideligheden og hastigheden i virksomheden.
Mikrotjenester er uden tvivl den primære rolle for Tarantool i MegaFon.
Hvor vi planlægger at anvende Tarantool
Sammenlignet med vores succesfulde billing-projekt og transformationsprogrammerne hos Deutsche Telekom, Связьком, Vodafone India, er det bemærkelsesværdigt dynamisk og kreativt. I implementeringen af dette projekt er ikke kun MegaFon og dens struktur blevet transformeret, men der er også opstået Tarantool-enterprise hos Mail.ru, mens vores leverandør Nexign (tidligere „Петер-Сервис“) har udviklet BSS Box (et box-baseret billing-løsning).
Dette er, på en måde, et historisk projekt for det russiske marked. Det kan sammenlignes med det, der er beskrevet i Frederic Brooks' bog „The Mythical Man-Month“. Dengang, i 60'erne, anmodede IBM 5.000 mennesker om at udvikle et nyt operativsystem, OS/360, til mainframes. Vi har færre, 1.800, men vores folk er dedikerede, og med brugen af open source og nye tilgange arbejder vi mere effektivt.
Nedenfor vises domænerne for billing eller, mere bredt, for forretningssystemer. Folk fra enterprise kender godt CRM. Andre systemer skal allerede være tilgængelige for alle: Open API, API Gateway.
Open API
Lad os igen se på tallene og hvordan Open API fungerer nu. Dets belastning er 10.000 transaktioner per sekund. Da vi planlægger aktivt at udvikle lagene af mikrotjenester og bygge MegaFons offentlige API, forventer vi en større vækst i fremtiden, især på dette område. 100.000 transaktioner vil helt sikkert være.
Jeg ved ikke, om vi kan sammenligne os med Mail.ru i SSO – de har tilsyneladende 1.000.000 transaktioner per sekund. Deres løsning er yderst interessant for os, og vi planlægger at lære af deres erfaring - for eksempel ved at skabe funktionel redundans i SSO ved hjælp af Tarantool. Lige nu arbejder udviklerne fra Mail.ru med dette hos os.
CRM
CRM er de samme 80 millioner abonnenter, som vi ønsker at bringe op på en milliard, fordi der allerede er 300 millioner dokumenter, der omfatter tre års historie. Vi venter virkelig på nye tjenester, og her vækstpunktet er de tilkoblede tjenester. Det er et område, der vil vokse, fordi der vil komme flere og flere tjenester. Derfor vil der være behov for en historie, vi ønsker ikke at snuble over dette.
Selve billing i forhold til fakturering, arbejde med kundernes debitorer er blevet transformeret til et særskilt domæne. For at forbedre produktiviteten, er den domænearkitekturmæssige skabelon blevet anvendt..
Systemet er opdelt i domæner, belastningen er fordelt, og der er sikret fejltolerance. Derudover er der arbejdet med den distribuerede arkitektur.
Alt andet er enterprise-løsninger. I opkaldslageret - 2 milliarder om dagen, 60 milliarder om måneden. Nogle gange skal de tælles op igen for måneden, og det er bedre hurtigt. Finansiel overvågning – det er lige nøjagtigt de 300 millioner, som konstant vokser og vokser: abonnenter bevæger sig ofte mellem operatører, hvilket øger denne del.
Den mest telekommunikationsmæssige komponent fra mobiltelefonien er onlinetaksering. Det er de systemer, der tillader dig at ringe eller ikke ringe, og træffer beslutninger i realtid. Her er belastningen 30.000 transaktioner i sekundet, men med hensyn til den voksende datatransmission planlægger vi 250.000 transaktioner, og derfor er vi meget interesserede i Tarantool.
Det tidligere billede viser de domæner, hvor vi planlægger at anvende Tarantool. Selve CRM-systemet er selvfølgelig bredere, og vi har til hensigt at anvende det i selve kernen.
Mit beregnede tal for TTH på 100 millioner abonnenter bekymrer mig som arkitekt – hvad hvis der er 101 millioner? Skal alt laves om igen? For at undgå dette anvender vi caches og samtidig øger tilgængeligheden.
Generelt er der to tilgange til anvendelsen af Tarantool. Den første er at bygge alle caches på mikroserviceniveau.Hvad jeg forstår, er det den vej, VimpelCom går, når de opretter en kundecache.
Vi er derimod mindre afhængige af leverandører og ændrer BSS-kernen, så vi allerede har en ensartet kundekatalog fra kassen. Men vi ønsker at udvide det. Derfor anvender vi en lidt anden tilgang – vi laver caches inde i systemerne..
Så er der mindre desynkronisering – ét system står for både cache og den primære masterkilde.
Metoden passer godt ind i Tarantools tilgang med en transaktionel skelet, hvor der kun opdateres de dele, der vedrører opdateringer, det vil sige dataændringer. Alt andet kan opbevares et andet sted. Der er ikke et enorme data lake, et ukontrolleret globalt cache. Caches designes til systemet, enten til produkter, eller til kunder, eller for at lette livet for service.
RTO og RPO
Der findes to termer i IT - RTO og RPO.
Recovery time objective — det er den tid, det tager at gendanne tjenesten efter en fejl. RTO = 0 betyder, at selvom noget falder ud, fortsætter tjenesten med at arbejde.
gendannelsespunktmål — det er den tid, det tager at gendanne data, hvor mange data vi kan miste over en given tidsperiode. RPO = 0 betyder, at vi ikke mister data.
Opgave for Tarantool
Lad os prøve at løse opgaven for Tarantool.
Givet: en velkendt indkøbskurv, for eksempel på Amazon eller et andet sted. Krav at kurven skal fungere 24 timer i døgnet, 7 dage om ugen, eller 99,99% af tiden. Bestillinger, der kommer til os, skal bevare rækkefølgen, fordi vi ikke kan tænde eller slukke for abonnentens forbindelse kaotisk – alt skal være strengt sekventielt. Den tidligere abonnementsstatus påvirker den næste, så data er vigtige – intet må gå tabt.
Løsning. Man kan forsøge at løse det direkte og spørge databaseudviklerne, men opgaven kan ikke løses matematisk. Man kan huske teoremerne, bevarelseslovene, kvantefysikken, men hvorfor – det er umuligt at løse på databaseniveau.
Her fungerer den gode gamle arkitekturmæssige tilgang – man skal kende emnet godt og dermed løse denne gåde.
Vores løsning: vi opretter et distribueret register for anmodninger på Tarantool – et geo-distribueret kluster. På diagrammet er det tre forskellige datacentre – to før Ural, et efter Ural, og vi fordeler alle anmodninger mellem disse centre.
Hos Netflix, som nu betragtes som en af lederne inden for IT, havde de indtil 2012 kun et datacenter. Dagen før den katolske juleaften, den 24. december, faldt dette datacenter. Brugere i Canada og USA blev frataget deres yndlingsfilm, blev meget kede af det og skrev om det på sociale medier. Nu har Netflix tre datacentre på den vest-østlige kyst og et i Vesteuropa.
Vi bygger oprindeligt en geo-distribueret løsning – vi værdsætter fejltolerance.
Så vi har et kluster, men hvordan håndterer vi RPO = 0 og RTO = 0? Løsningen er enkel og afhænger af emnet.
Hvad er vigtigt i anmodningerne? To dele: skabelsen af kurven FØR beslutningen om køb, og EFTER. Delen FØR kaldes i telekommunikation normalt order capturing eller order negotiation. I telekombranchen kan det være betydeligt mere komplekst end i en internetbutik, fordi man skal betjene kunden, tilbyde 5 muligheder, og det hele tager lidt tid, men kurven fyldes. I dette øjeblik kan der ske en fejl, men det er ikke farligt, fordi det foregår interaktivt under opsyn af en person.
Hvis det Moskva Data Center pludselig går ned, vil vi automatisk skifte til et andet Data Center og fortsætte driften. Teoretisk kan et produkt gå tabt i kurven, men du kan se det, genopfylde kurven og fortsætte arbejdet. I dette tilfælde er RTO = 0.
Samtidig er der et andet scenarie: når vi trykker på 'submit', ønsker vi, at dataene ikke går tabt. Fra dette punkt begynder automatiseringen at fungere - det er allerede RPO = 0. Anvendelsen af disse to forskellige mønstre i et tilfælde kan være et geo-distribueret cluster med en skiftbar master, mens det i et andet tilfælde kan være en form for quorum-optegnelse. Mønstrene kan variere, men vi løser problemet.
Derudover, med en distribueret register af anmodninger, kan vi også skalere det hele - have mange dispatcher og udførere, der henvender sig til dette register.
Cassandra og Tarantool sammen
Der er endnu et tilfælde - "balancespejlet". Her har vi netop en interessant anvendelse af Cassandra og Tarantool.
Vi anvender Cassandra, fordi 2 milliarder opkald om dagen ikke er grænsen, og det vil blive mere. Marketers elsker at visualisere trafik efter kilder, og der kommer flere og flere detaljer fra sociale medier, for eksempel. Dette øger historikken.
Cassandra tillader horisontal skalerbarhed på enhver volumen.
Vi føler os godt tilpas med Cassandra, men den har et problem - den er ikke god til læsning. Ved skrivning er alt fint, 30.000 i sekundet er ikke et problem - problemet ligger i læsningen..
Derfor opstod temaet med cache, og vi besluttede samtidig at løse det næste problem: Der er et gammelt traditionelt tilfælde, hvor udstyret fra switchen fra online-efterretning kommer ind i filer, som vi uploader til Cassandra. Vi kæmpede med problemet med pålidelig upload af disse filer, og vi brugte endda, efter råd fra IBM manager file transfer - der findes sådanne løsninger, der effektivt styrer filoverførsel ved hjælp af UDP-protokollen, for eksempel, og ikke TCP. Det er godt, men det tager stadig minutter, og indtil vi har indlæst alt dette, kan operatøren i callcentret ikke svare kunden på, hvad der er sket med hans balance - man må vente.
For at undgå dette bruger vi parallelt funktionelt reserve. Når vi sender en hændelse gennem Kafka til Tarantool, mens vi gensender aggregater i realtid, for eksempel for i dag, får vi cache af saldi, som kan returnere saldi med enhver hastighed, for eksempel 100.000 transaktioner per sekund og de samme 2 sekunder.
Målet er, at efter et opkald skal den ændrede balance ikke kun være tilgængelig i brugerens personlige konto efter 2 sekunder, men også information om, hvorfor den er ændret.
Konklusion
Dette var eksempler på brug af Tarantool. Vi har været meget tilfredse med åbenheden hos Mail.ru og deres vilje til at overveje forskellige tilfælde.
Det er allerede svært at overraske konsulenter fra BCG eller McKinsey, Accenture eller IBM med noget nyt - meget af det, de tilbyder, laver vi allerede, har gjort eller planlægger at gøre. Jeg tror, at Tarantool vil få en værdig plads i vores teknologiske stak og erstatte mange eksisterende teknologier. Vi er i den aktive fase af udviklingen af dette projekt.
Oleg og Andrey's præsentation var en af de bedste ved Tarantool Conference sidste år, og allerede den 17. juni vil Oleg Ivlev tale ved med en præsentation . Alexander Deulin fra MegaFon vil også deltage med en præsentation . Vi vil finde ud af, hvad der er ændret, hvilke planer der er blevet realiseret. Deltag - konferencen er gratis, man skal bare . Alle og konferencens program er blevet dannet: nye cases, ny erfaring med at bruge Tarantool, arkitektur, enterprise, tutorials og mikrotjenester.
Kilde: habr.com
