Hvorfor har en virksomhed som MegaFon brug for Tarantool til fakturering? Udefra ser det ud til, at sælgeren normalt kommer, medbringer en form for stor boks, sætter stikket i stikkontakten - og det er fakturering! Sådan var det engang, men nu er det arkaisk, og sådanne dinosaurer er allerede uddøde eller er ved at blive udryddet. I første omgang er fakturering et system til at udstede fakturaer - en tællemaskine eller lommeregner. I moderne telekommunikation er dette automatiseringssystem for hele livscyklussen af interaktion med en abonnent fra indgåelse af en kontrakt til opsigelse, herunder fakturering i realtid, betalingsaccept og meget mere. Fakturering i teleselskaber er som en kamprobot – stor, kraftfuld og fyldt med våben.
Hvad har Tarantool med det at gøre? De vil tale om det Oleg Ivlev и Andrey Knyazev. Oleg er virksomhedens chefarkitekt med stor erfaring med at arbejde i udenlandske virksomheder er Andrey direktør for forretningssystemer. Fra udskriften af deres rapport vedr du vil lære, hvorfor der er behov for forskning og udvikling i virksomheder, hvad Tarantool er, hvordan blindgyde af vertikal skalering og globalisering blev forudsætningerne for denne databases fremkomst i virksomheden, om teknologiske udfordringer, arkitektonisk transformation, og hvordan MegaFons technostack ligner Netflix , Google og Amazon.
Projekt "Unified Billing"
Det pågældende projekt kaldes "Unified Billing". Det var her, Tarantool viste sine bedste kvaliteter.
Væksten i produktiviteten af Hi-End-udstyr holdt ikke trit med væksten i abonnentbasen og væksten i antallet af tjenester; yderligere vækst i antallet af abonnenter og tjenester var forventet på grund af M2M, IoT og branchefunktioner førte til en forringelse af time-to-market. Virksomheden besluttede at skabe et samlet forretningssystem med en unik modulær arkitektur i verdensklasse i stedet for 8 nuværende forskellige faktureringssystemer.
MegaFon er otte virksomheder i én. I 2009 blev omorganiseringen afsluttet: filialer i hele Rusland fusionerede til et enkelt selskab, MegaFon OJSC (nu PJSC). Virksomheden har således 8 afregningssystemer med egne "custom" løsninger, branchefunktioner og forskellige organisationsstrukturer, IT og marketing.
Alt var fint, indtil vi skulle lancere et fælles føderalt produkt. Her opstod der mange vanskeligheder: for nogle rundes taksterne op, for andre rundes ned, og for andre - baseret på det aritmetiske gennemsnit. Der er tusindvis af sådanne øjeblikke.
På trods af at der kun var én version af faktureringssystemet, én leverandør, var indstillingerne så forskellige, at det tog lang tid at sammensætte. Vi forsøgte at reducere deres antal og stødte på et andet problem, som mange virksomheder kender.
Lodret skalering. Selv den fedeste hardware på det tidspunkt opfyldte ikke behovene. Vi brugte Hewlett-Packard-udstyr fra Superdome Hi-End-linjen, men det opfyldte ikke engang behovene hos to filialer. Jeg ønskede horisontal skalering uden store driftsomkostninger og kapitalinvesteringer.
Forventning om vækst i antallet af abonnenter og tjenester. Konsulenter har længe bragt historier om IoT og M2M til telekommunikationsverdenen: Tiden kommer, hvor hver telefon og strygejern vil have et SIM-kort og to i køleskabet. I dag har vi ét antal abonnenter, men i den nærmeste fremtid kommer der mange flere.
Teknologiske udfordringer
Disse fire grunde motiverede os til at foretage seriøse ændringer. Der var et valg mellem at opgradere systemet og designe fra bunden. Vi tænkte længe, tog seriøse beslutninger, spillede udbud. Som et resultat besluttede vi os for at designe helt fra begyndelsen og tog interessante udfordringer - teknologiske udfordringer.
Skalerbarhed
Hvis det var før, lad os sige, lad os sige 8 faktureringer for 15 millioner abonnenter, og nu skulle det have virket 100 millioner abonnenter og mere - belastningen er en størrelsesorden højere.
Vi er blevet sammenlignelige i skala med store internetspillere som Mail.ru eller Netflix.
Men den yderligere bevægelse for at øge belastningen og abonnentbasen har givet os alvorlige udfordringer.
Geografi af vores store land
Mellem Kaliningrad og Vladivostok 7500 km og 10 tidszoner. Lysets hastighed er begrænset, og på sådanne afstande er forsinkelserne allerede betydelige. 150 ms på de sejeste moderne optiske kanaler er for meget til realtidsfakturering, især som det nu er i telekommunikation i Rusland. Derudover skal du opdatere på én hverdag, og med forskellige tidszoner er dette et problem.
Vi leverer ikke kun tjenester mod et abonnementsgebyr, vi har komplekse takster, pakker og forskellige modifikatorer. Vi skal ikke kun tillade eller nægte abonnenten at tale, men give ham en vis kvote - beregne opkald og handlinger i realtid, så han ikke lægger mærke til det.
fejltolerance
Dette er den anden side af centralisering.
Hvis vi samler alle abonnenter i ét system, er alle nødbegivenheder og katastrofer katastrofale for erhvervslivet. Derfor designer vi systemet på en sådan måde, at det eliminerer virkningen af ulykker på hele abonnentbasen.
Dette er igen en konsekvens af afslaget på at skalere vertikalt. Når vi skalerede vandret, øgede vi antallet af servere fra hundreder til tusinder. De skal administreres og udskiftes, automatisk sikkerhedskopieres it-infrastrukturen og genskabe det distribuerede system.
Vi stod over for så interessante udfordringer. Vi designede systemet, og i det øjeblik forsøgte vi at finde globale bedste praksisser for at kontrollere, hvor trendy vi er, hvor meget vi følger avancerede teknologier.
Verdensoplevelse
Overraskende nok fandt vi ikke en eneste reference i global telekommunikation.
Europa er faldet væk med hensyn til antallet af abonnenter og omfang, USA - med hensyn til fladheden af sine tariffer. Vi kiggede på nogle i Kina, og fandt nogle i Indien og hyrede specialister fra Vodafone Indien.
For at analysere arkitekturen sammensatte vi et Dream Team ledet af IBM - arkitekter fra forskellige felter. Disse mennesker kunne tilstrækkeligt vurdere, hvad vi lavede og bringe vis viden til vores arkitektur.
skala
Et par tal til illustration.
Vi designer systemet til 80 millioner abonnenter med en reserve på en mia. Sådan fjerner vi fremtidige tærskler. Det er ikke fordi vi skal overtage Kina, men på grund af angrebet fra IoT og M2M.
300 millioner dokumenter behandlet i realtid. Selvom vi har 80 millioner abonnenter, arbejder vi med både potentielle kunder og dem, der har forladt os, hvis vi skal inddrive tilgodehavender. Derfor er de faktiske mængder mærkbart større.
2 milliarder transaktioner Saldoen ændres dagligt - det er betalinger, gebyrer, opkald og andre begivenheder. 200 TB data ændres aktivt, skift lidt langsommere 8 PB data, og dette er ikke et arkiv, men live data i en enkelt fakturering. Skaler efter datacenter - 5 tusinde servere på 14 websteder.
Teknologi stak
Da vi planlagde arkitekturen og begyndte at samle systemet, importerede vi de mest interessante og avancerede teknologier. Resultatet er en teknologistabel, som enhver internetspiller og virksomheder, der laver højbelastningssystemer, kender.
Stakken ligner stakkene fra 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 forening.
Vi vil ikke ændre det samme Oracle til Tarantool. I de store virksomheders realiteter er dette en utopi eller et korstog i 5-10 år med et uklart resultat. Men Cassandra og Couchbase kan sagtens udskiftes med Tarantool, og det er det, vi stræber efter.
Hvorfor Tarantool?
Der er 4 enkle kriterier, hvorfor vi valgte denne database.
hastighed. Vi udførte belastningstest på MegaFon industrisystemer. Tarantool vandt - det viste den bedste præstation.
Dermed ikke sagt, at andre systemer ikke opfylder MegaFons behov. Nuværende hukommelsesløsninger er så produktive, at virksomhedens reserver er mere end nok. Men vi er interesserede i at have med en leder at gøre, og ikke med en, der er bagud, også i belastningstesten.
Tarantool dækker virksomhedens behov også på længere sigt.
TCO omkostninger. Support til Couchbase på MegaFon-volumener koster astronomiske summer, men med Tarantool er situationen meget mere behagelig, og de ligner hinanden i funktionalitet.
En anden fin funktion, der lidt påvirkede vores valg, er, at Tarantool fungerer bedre med hukommelse end andre databaser. Han viser maksimal effektivitet.
Pålidelighed. MegaFon investerer i pålidelighed, sandsynligvis mere end nogen anden. Så da vi så på Tarantool, indså vi, at vi var nødt til at få det til at opfylde vores krav.
Vi investerede vores tid og økonomi, og sammen med Mail.ru lavede vi en enterprise-version, som nu bruges i flere andre virksomheder.
Tarantool-enterprise tilfredsstillede os fuldstændigt med hensyn til sikkerhed, pålidelighed og logning.
Партнерство
Det vigtigste for mig er direkte kontakt med bygherren. Det er præcis, hvad fyrene fra Tarantool bestikkede med.
Hvis du kommer til en spiller, især en, der arbejder med en ankerklient, og siger, at du har brug for databasen for at kunne gøre dette, dette og dette, svarer han normalt:
- Okay, sæt kravene i bunden af den bunke - en dag skal vi nok komme til dem.
Mange har en køreplan for de næste 2-3 år, og det er næsten umuligt at integrere der, men Tarantool-udviklere fanger med deres åbenhed, og ikke kun fra MegaFon, og tilpasser deres system til kunden. Det er fedt, og vi kan rigtig godt lide det.
Hvor vi brugte Tarantool
Vi bruger Tarantool i flere elementer. Den første er i piloten, som vi lavede på adressekartoteket. På et tidspunkt ønskede jeg, at det skulle være et system, der lignede Yandex.Maps og Google Maps, men det viste sig lidt anderledes.
For eksempel adressekataloget i salgsgrænsefladen. På Oracle tager det 12-13 sekunder at søge efter den ønskede adresse. - ubehagelige tal. Når vi skifter til Tarantool, erstatter Oracle med en anden database i konsollen og udfører den samme søgning, får vi en speedup på 200x! Byen dukker op efter det tredje bogstav. Nu tilpasser vi grænsefladen, så det sker efter den første. Responshastigheden er dog en helt anden – millisekunder i stedet for sekunder.
Den anden applikation er et trendy tema kaldet to-hastigheds IT. Dette skyldes, at konsulenter fra alle hjørner siger, at virksomheder bør tage dertil.
Der er et infrastrukturlag, over det er der domæner, for eksempel et faktureringssystem som telekommunikation, virksomhedssystemer, virksomhedsrapportering. Dette er kernen, der ikke skal røres. Det er selvfølgelig muligt, men paranoidt at sikre kvalitet, fordi det bringer penge til selskabet.
Dernæst kommer laget af mikrotjenester - hvad der adskiller operatøren eller anden spiller. Mikrotjenester kan hurtigt oprettes baseret på bestemte caches, der bringer data fra forskellige domæner dertil. Her felt til forsøg - hvis noget ikke fungerede, lukkede jeg en mikroservice og åbnede en anden. Dette giver virkelig øget time-to-market og øger virksomhedens pålidelighed og hastighed.
Mikrotjenester er måske Tarantools hovedrolle hos MegaFon.
Hvor vi planlægger at bruge Tarantool
Hvis vi sammenligner vores succesfulde faktureringsprojekt med transformationsprogrammerne hos Deutsche Telekom, Svyazcom, Vodafone Indien, er det overraskende dynamisk og kreativt. I processen med at implementere dette projekt blev ikke kun MegaFon og dets struktur transformeret, men også Tarantool-enterprise dukkede op på Mail.ru og vores leverandør Nexign (tidligere Peter-Service) - BSS Box (en boxed faktureringsløsning).
Dette er på en måde et historisk projekt for det russiske marked. Det kan sammenlignes med det, der er beskrevet i bogen "The Mythical Man-Month" af Frederick Brooks. Så, i 60'erne, hyrede IBM 360 mennesker til at udvikle det nye OS/5-operativsystem til mainframes. Vi har færre - 000, men vores er i veste, og taget i betragtning brugen af open source og nye tilgange, arbejder vi mere produktivt.
Nedenfor er domænerne for fakturering eller mere generelt forretningssystemer. Folk fra virksomheder kender CRM meget godt. Alle burde allerede have andre systemer: Open API, API Gateway.
Åbn API
Lad os se på tallene igen, og hvordan Open API fungerer i øjeblikket. Dens belastning er 10 transaktioner i sekundet. Da vi planlægger aktivt at udvikle mikroservicelaget og bygge den offentlige MegaFon API, forventer vi større vækst i fremtiden i denne del. Der vil helt sikkert være 100 transaktioner.
Jeg ved ikke, om vi kan sammenligne med Mail.ru i SSO - fyrene ser ud til at have 1 transaktioner i sekundet. Deres løsning er ekstremt interessant for os, og vi planlægger at tage deres erfaring til sig - for eksempel ved at lave en funktionel SSO backup ved hjælp af Tarantool. Nu gør udviklerne fra Mail.ru dette for os.
CRM
CRM er de samme 80 millioner abonnenter, som vi ønsker at øge til en milliard, fordi der allerede er 300 millioner dokumenter, der inkluderer en tre-årig historie. Vi ser virkelig frem til nye tjenester og her vækstpunkt er forbundne tjenester. Dette er en bold, der vil vokse, for der kommer flere og flere tjenester. Derfor har vi brug for en historie; vi ønsker ikke at snuble over dette.
Fakturerer sig selv mht. udstedelse af fakturaer, arbejder med debitorer omdannet til et separat domæne. For at forbedre ydeevnen, anvendt domænearkitektur arkitektonisk mønster.
Systemet er opdelt i domæner, belastningen fordeles og fejltolerance er sikret. Derudover arbejdede vi med distribueret arkitektur.
Alt andet er løsninger på virksomhedsniveau. I opkaldslageret - 2 milliarder om dagen60 milliarder om måneden. Nogle gange skal du tælle dem om en måned, og det er hurtigt bedre. Økonomisk overvågning - det er præcis de samme 300 millioner, som konstant vokser og vokser: Abonnenter løber ofte mellem operatører, hvilket øger denne del.
Den mest telecom-komponent i mobilkommunikation er online fakturering. Det er de systemer, der giver dig mulighed for at ringe eller lade være, træffe beslutninger i realtid. Her er belastningen 30 transaktioner i sekundet, men under hensyntagen til væksten i dataoverførsel, planlægger vi 250 transaktioner, og derfor er vi meget interesserede i Tarantool.
Det forrige billede er de domæner, hvor vi skal bruge Tarantool. CRM i sig selv er selvfølgelig bredere, og vi kommer til at bruge det i selve kernen.
Vores estimerede TTX-tal på 100 millioner abonnenter forvirrer mig som arkitekt - hvad nu hvis 101 millioner? Skal du lave alt om igen? For at forhindre dette i at ske, bruger vi caches, og øger samtidig tilgængeligheden.
Generelt er der to tilgange til at bruge Tarantool. Først - opbygge alle caches på mikroserviceniveau. Så vidt jeg forstår, følger VimpelCom denne vej og skaber en cache af klienter.
Vi er mindre afhængige af leverandører, vi ændrer BSS-kernen, så vi har en enkelt klientfil ud af kassen. Men vi vil gerne udvide det. Derfor tager vi en lidt anden tilgang - lave caches inde i systemer.
På denne måde er der mindre synkronisering - ét system er ansvarligt for både cachen og hovedkilden.
Metoden passer godt til Tarantool-tilgangen med et transaktionsskelet, hvor kun dele, der vedrører opdateringer, altså dataændringer, opdateres. Alt andet kan opbevares et andet sted. Der er ingen stor datasø, uadministreret global cache. Caches er designet til systemet eller til produkter eller til kunder eller for at gøre livet lettere for vedligeholdelse. Når en abonnent ringer og er ked af kvaliteten af tjenesten, vil du gerne levere kvalitetsservice.
RTO og RPO
Der er to termer inden for IT - RTO и RPO.
Mål for restitutionstid er den tid, det tager at gendanne tjenesten efter en fejl. RTO = 0 betyder, at selvom noget fejler, fortsætter tjenesten med at fungere.
Genoprettelsespunktsmål - dette er datagendannelsestiden, hvor meget data vi kan miste over en vis periode. RPO = 0 betyder, at vi ikke mister data.
Tarantool opgave
Lad os prøve at løse et problem for Tarantool.
Givet: en kurv af applikationer, som alle forstår, for eksempel i Amazon eller et andet sted. påkrævet så indkøbskurven fungerer 24 timer 7 dage om ugen, eller 99,99 % af tiden. De ordrer, der kommer til os, skal forblive i orden, fordi vi ikke tilfældigt kan tænde eller slukke for abonnentens forbindelse - alt skal være strengt konsistent. Det forrige abonnement påvirker det næste, så dataene er vigtige - intet bør mangle.
beslutning. Du kan prøve at løse det direkte og spørge databaseudviklerne, men problemet kan ikke løses matematisk. Du kan huske sætninger, bevarelseslove, kvantefysik, men hvorfor – det kan ikke løses på DB-niveau.
Den gode gamle arkitektoniske tilgang virker her - du skal kende fagområdet godt og bruge det til at løse dette puslespil.
Vores løsning: oprettelse af et distribueret register over applikationer på Tarantool - en geo-distribueret klynge. I diagrammet er disse tre forskellige databehandlingscentre - to før Ural, et ud over Ural, og vi fordeler alle anmodninger blandt disse centre.
Netflix, som nu betragtes som en af de førende inden for IT, havde indtil 2012 kun ét datacenter. På tærsklen til katolsk jul, den 24. december, gik dette datacenter ned. Brugere i Canada og USA blev efterladt uden deres yndlingsfilm, var meget kede af det og skrev om det på sociale netværk. Netflix har nu tre datacentre på vest-østkysten og et i Vesteuropa.
Vi bygger i første omgang en geo-distribueret løsning – fejltolerance er vigtig for os.
Så vi har en klynge, men hvad med RPO = 0 og RTO = 0? Løsningen er enkel, afhængig af emnet.
Hvad er vigtigt i applikationer? To dele: Kurvekastning FØR træffe en købsbeslutning, og EFTER. DO-delen i telekom kaldes normalt ordrefangst eller ordreforhandling. Inden for telekommunikation kan dette være meget sværere end i en netbutik, fordi der skal kunden betjenes, tilbydes 5 muligheder, og det hele sker i nogen tid, men kurven er fyldt. I dette øjeblik er en fiasko mulig, men det er ikke skræmmende, fordi det sker interaktivt under menneskelig opsyn.
Hvis Moskva-datacentret pludselig svigter, vil vi fortsætte med at arbejde ved automatisk at skifte til et andet datacenter. Teoretisk set kan et produkt gå tabt i indkøbskurven, men du ser det, læg det i indkøbskurven igen og fortsætter med at arbejde. I dette tilfælde er RTO = 0.
I samme øjeblik er der en anden mulighed: Når vi klikkede på "send", vil vi have, at dataene ikke går tabt. Fra dette øjeblik begynder automatiseringen at virke - dette er RPO = 0. Ved at bruge disse to forskellige mønstre, kunne det i et tilfælde simpelthen være en geo-distribueret klynge med én omskiftelig master, i et andet tilfælde en form for kvorum-record. Mønstrene kan variere, men vi løser problemet.
Yderligere, med et distribueret register af applikationer, kan vi også skalere det hele - har mange dispatchere og eksekvere, der får adgang til dette register.
Cassandra og Tarantool sammen
Der er en anden sag - "udstilling af balancer". Her er et interessant tilfælde af fælles brug af Cassandra og Tarantool.
Vi bruger Cassandra, fordi 2 milliarder opkald om dagen ikke er grænsen, og der vil være flere. Marketingfolk elsker at farvelægge trafik efter kilde; flere og flere detaljer vises for eksempel på sociale netværk. Det hele føjer til historien.
Cassandra giver dig mulighed for at skalere vandret til enhver størrelse.
Vi føler os godt tilpas med Cassandra, men den har et problem – den er ikke god til at læse. Alt er OK på optagelsen, 30 i sekundet er ikke et problem - læseproblem.
Derfor dukkede et emne op med en cache, og samtidig løste vi følgende problem: der er en gammel traditionel sag, hvor udstyr fra et skifte fra online fakturering kommer ind i de filer, som vi indlæser i Cassandra. Vi kæmpede med problemet med pålidelig download af disse filer, selv ved at bruge råd fra IBM-administratorens filoverførsel - der er løsninger, der styrer filoverførsel effektivt, for eksempel ved at bruge UDP-protokollen i stedet for TCP. Det er godt, men det er stadig minutter, og vi har ikke indlæst det hele endnu, operatøren i callcenteret kan ikke svare klienten, hvad der skete med hans saldo - vi må vente.
For at forhindre, at dette sker, har vi vi bruger parallel funktionel reserve. Når vi sender en begivenhed via Kafka til Tarantool, genberegning af aggregater i realtid, for eksempel for i dag, får vi kassebeholdninger, som kan overføre saldi ved enhver hastighed, for eksempel 100 tusinde transaktioner i sekundet og de samme 2 sekunder.
Målet er, at der efter et opkald inden for 2 sekunder på din personlige konto ikke kun vil være den ændrede saldo, men information om, hvorfor den ændrede sig.
Konklusion
Disse var eksempler på brug af Tarantool. Vi kunne virkelig godt lide åbenheden i Mail.ru og deres vilje til at overveje forskellige sager.
Det er allerede svært for konsulenter fra BCG eller McKinsey, Accenture eller IBM at overraske os med noget nyt - meget af det, de tilbyder, gør vi enten allerede, har gjort eller planlægger at gøre. Jeg tror, at Tarantool vil tage sin retmæssige plads i vores teknologistabel og vil erstatte mange eksisterende teknologier. Vi er i den aktive fase af udviklingen af dette projekt.
Rapporten af Oleg og Andrey er en af de bedste på Tarantool-konferencen sidste år, og den 17. juni taler Oleg Ivlev kl. med en rapport . Alexander Deulin vil også holde et oplæg fra MegaFon . Lad os finde ud af, hvad der har ændret sig, hvilke planer der er blevet implementeret. Deltag - konferencen er gratis, det eneste du skal gøre er . Alle og konferenceprogrammet er blevet dannet: nye cases, ny erfaring med at bruge Tarantool, arkitektur, enterprise, tutorials og mikrotjenester.
Kilde: www.habr.com