Waarom heeft een bedrijf als MegaFon Tarantool nodig in de billing? Van de buitenkant lijkt het wel alsof een leverancier gewoon een grote doos meebrengt, erin steekt en voilà, daar is de billing! Vroeger was dat zo, maar dat is nu verouderd, en zulke dinosaurussen zijn ofwel verdwenen of sterven uit. Oorspronkelijk was billing een systeem voor het opstellen van rekeningen - een rekenmachine of calculator. In de moderne telecom is het een systeem voor de automatisering van de volledige levenscyclus van de interactie met de abonnee, van het sluiten van een contract tot het beëindigen ervan, inclusief real-time tarificatie, betalingsacceptatie en nog veel meer. Billing in telecombedrijven lijkt op een strijdrobot - groot, krachtig en vol wapens.
Wat is hier nu de rol van Tarantool? Dit zullen ze uitleggen Oleg Ivlev en Andrey Knyazev. Oleg is de hoofdar Architekt van het bedrijf met enorme ervaring in buitenlandse bedrijven, Andrey is directeur van zakelijke systemen. Uit hun presentatie tijdens zult u ontdekken waarom R&D nodig is in bedrijven, wat Tarantool is, hoe de impasse van verticale schaalvergroting en globalisering de redenen waren voor het ontstaan van deze database in het bedrijf, de technologische uitdagingen, de transformatie van de architectuur, en hoe de techstack van MegaFon lijkt op die van Netflix, Google en Amazon.
Project 'Unified Billing'
Het project waar het hier om gaat, heet 'Unified Billing'. Juist hierin toonde Tarantool zijn beste kwaliteiten.
De groei van de prestaties van Hi-End apparatuur kon de groei van het aantal abonnees en het aantal diensten niet bijbenen, terwijl verder groei in abonnees en diensten door M2M, IoT, en regionale bijzonderheden leidde tot een verslechtering van de time-to-market. Het bedrijf besloot een uniek business systeem met modulaire wereldwijde architectuur te creëren, ter vervanging van 8 verschillende huidige billing systemen.
MegaFon is acht bedrijven in één. In 2009 werd de reorganisatie afgerond: filiale bedrijven in heel Rusland werden samengevoegd tot één bedrijf, OAO 'MegaFon' (nu PAO). Zo ontstonden er binnen het bedrijf 8 billing systemen met hun eigen 'custom' oplossingen, regionale bijzonderheden en verschillende organisatorische structuren, IT en marketing.
Alles was goed, totdat we een gezamenlijk federaal product moesten lanceren. Toen verschenen er talloze complicaties: sommigen hanteerden afrondingen naar boven, anderen naar beneden, en weer anderen volgens het rekenkundige gemiddelde. Dergelijke momenten zijn er duizenden.
Ondanks dat er één versie van het facturatiesysteem is en één leverancier, verschilden de instellingen zozeer dat het lange tijd kostte. We probeerden hun aantal te reduceren en stuitten op een tweede probleem dat veel bedrijven bekend voorkomt.
Verticale schaling. Zelfs de beste hardware van die tijd voldeed niet aan de behoeften. We gebruikten Hewlett-Packard-apparatuur, uit de Superdome Hi-End-lijn, maar dat voldeed niet aan de eisen van zelfs twee filialen. We wilden horizontale schaalbaarheid zonder hoge operationele kosten en kapitaalinvesteringen.
De verwachting van groei in het aantal abonnees en diensten. Consultants hebben al lang verhalen over IoT en M2M in de telecomwereld geïntroduceerd: er komt een tijd waarin er in elke telefoon en elk strijkijzer een simkaart zal zitten, en in de koelkast twee. Vandaag hebben we een bepaald aantal abonnees, en in de nabije toekomst zal dat veel meer zijn.
Technologische uitdagingen
Deze vier redenen hebben ons aangezet tot serieuze veranderingen. Er was de keuze tussen het moderniseren van het systeem of het ontwerpen vanaf nul. We hebben lang nagedacht, serieuze besluiten genomen en aanbestedingen gespeeld. Uiteindelijk hebben we besloten om vanaf het begin te ontwerpen en hebben we ons geworpen op interessante uitdagingen - technologische uitdagingen.
Schaalbaarheid
Als het vroeger, laten we zeggen, 8 factureringssystemen met 15 miljoen abonnees, moest het nu worden 100 miljoen abonnees of meer — de belasting is daardoor veel hoger.
We zijn op schaal vergelijkbaar geworden met grote internetspelers zoals Mail.ru of Netflix.
Maar verdere groei in het aantal abonnees en belasting heeft ons voor serieuze uitdagingen geplaatst.
De geografische uitgestrektheid van ons immense land
Tussen Kaliningrad en Vladivostok 7500 km en 10 tijdzones. De snelheid van het licht is eindig en op zulke afstanden zijn de vertragingen al significatief. 150 ms op de meest geavanceerde moderne optische kanalen is al te veel voor real-time facturering, zeker zoals het nu in de telecom in Rusland is. Bovendien is het noodzakelijk om binnen één werkdag te vernieuwen, en met verschillende tijdzones is dat een probleem.
Wij bieden niet alleen abonnementsdiensten aan, maar hebben complexe tarieven, pakketten en verschillende modifiers. We moeten niet alleen toestaan of verbieden dat een abonnee belt, maar hem ook een bepaalde quotum geven — oproepen en acties in real-time berekenen zodat hij het niet opmerkt.
Resilience
Dit is de keerzijde van centralisatie.
Als we alle abonnees in één systeem verzamelen, zijn eventuele noodsituaties en rampen rampzalig voor de bedrijfsvoering. Daarom ontwerpen we het systeem zo dat het effect van storingen op de gehele klantenbasis wordt uitgesloten.
Dit is opnieuw het gevolg van de afslag van verticale schaalvergroting. Toen we overstapten naar horizontale schaalvergroting, verhoogden we het aantal servers van honderden naar duizenden. We moeten deze beheren, interoperabiliteit opbouwen, IT-infrastructuur automatisch reserveren en een gedistribueerd systeem herstellen.
We stonden voor interessante uitdagingen. We hebben het systeem ontworpen en op dat moment geprobeerd de wereldwijde best practices te vinden om te controleren of we 'in de pas lopen' met geavanceerde technologieën.
Wereldwijde ervaring
Verbluffend, maar in de wereldwijde telecom hebben we geen enkele referentie gevonden.
Europa viel af vanwege het aantal abonnees en de schaal, de VS vanwege de breedte van hun tarieven. We hebben iets in China bekeken, maar ook iets gevonden in India en experts van Vodafone India ingeschakeld.
Voor de architectuuranalyse hebben we een Dream Team samengesteld onder leiding van IBM - architecten uit verschillende disciplines. Deze mensen konden adequaat beoordelen wat we doen en bepaalde kennis in onze architectuur brengen.
Schaal
Enkele cijfers ter illustratie.
We ontwerpen het systeem voor 80 miljoen abonnees met een reserve voor een miljard. Zo verwijderen we toekomstige drempels. Dit komt niet omdat we China willen veroveren, maar vanwege de druk van IoT en M2M.
300 miljoen documenten worden in real-time verwerkt. Hoewel we 80 miljoen abonnees hebben, werken we ook met potentiële klanten en met degenen die ons hebben verlaten, als het nodig is om vorderingen in te vorderen. Daarom zijn de werkelijke volumes beduidend groter.
2 miljard transacties veranderen dagelijks het saldo — dit zijn betalingen, toekenningen, oproepen en andere gebeurtenissen. 200 TB data verandert actief, iets langzamer verandert 8 PB data, en dit zijn geen archieven, maar live gegevens in één facturering. Schaal naar datacenters - 5.000 servers op 14 locaties.
Technologische stack
Toen we de architectuur planden en aan het bouwen van het systeem begonnen, hebben we de meest interessante en geavanceerde technologieën geïmporteerd. Het resultaat is een technologische stack die bekend is bij elke internetspeler en bedrijven die hoge belasting systemen maken.
De stack is vergelijkbaar met die van andere grote spelers: Netflix, Twitter, Viber. Hij bestaat uit 6 componenten, maar we willen deze verkorten en uniformeren.
Flexibiliteit is goed, maar in een groot bedrijf kan je niet zonder uniformiteit.
We zijn niet van plan om Oracle te vervangen door Tarantool. In de realiteit van grote bedrijven is dat een utopie, of een kruistocht van 5-10 jaar met een onzekere uitkomst. Maar Cassandra en Couchbase kunnen we prima vervangen door Tarantool, en daar streven we naar.
Waarom Tarantool?
Er zijn 4 eenvoudige criteria waarom we deze database hebben gekozen.
Snelheid. We hebben belastingtests uitgevoerd op de industriële systemen van MegaFon. Tarantool won - het toonde de beste prestaties.
Je kunt niet zeggen dat andere systemen niet voldoen aan de behoeften van MegaFon. De huidige memory-oplossingen zijn zo performant dat die capaciteit voor het bedrijf meer dan genoeg is. Maar we zijn geïnteresseerd in het werken met een leider en niet met degene die achteraan loopt, ook in termen van belastingtests.
Tarantool voldoet aan de behoeften van het bedrijf zelfs op de lange termijn.
Kosten TCO. Ondersteuning voor Couchbase op de volumes van MegaFon kost een fortuin, terwijl de situatie met Tarantool veel prettiger is, en qua functionaliteit zijn ze vergelijkbaar.
Een ander aangenaam kenmerk dat een beetje invloed heeft gehad op onze keuze - Tarantool werkt beter met geheugen dan andere databases. Het toont maximale efficiëntie.
Betrouwbaarheid. MegaFon investeert in betrouwbaarheid, waarschijnlijk als geen ander. Dus toen we naar Tarantool keken, begrepen we dat we het zo moesten maken dat het aan onze eisen voldeed.
We hebben onze tijd en financiën geïnvesteerd en samen met Mail.ru een enterprise-versie gecreëerd die nu al door verschillende andere bedrijven wordt gebruikt.
Tarantool-enterprise voldeed volledig aan onze eisen voor veiligheid, betrouwbaarheid en logging.
Partnerschap
Het belangrijkste voor mij is rechtstreeks contact met de ontwikkelaar. Dat is precies wat de jongens van Tarantool overtuigde.
Wanneer je met een speler praat, vooral iemand die met een verankerde klant werkt, en je zegt dat je wilt dat de database dit, dit en dit kan, antwoordt hij meestal:
— Goed, leg de vereisten onderaan die stapel — misschien komen we er ooit aan toe.
Velen hebben een roadmap voor de komende 2-3 jaar, en het is praktisch onmogelijk om daar in te passen, en de ontwikkelaars van Tarantool winnen door hun openheid, niet alleen met MegaFon, en passen hun systeem aan voor de klant. Dat is geweldig, en we houden er echt van.
Waar we Tarantool hebben toegepast
We gebruiken Tarantool in verschillende elementen. De eerste — in de pilot, die we hebben gemaakt op het systeem van het adrescatalogus. Destijds wilden we dat het een systeem zou zijn dat lijkt op Yandex Maps en Google Maps, maar het is iets anders geworden.
Bijvoorbeeld, het adrescatalogus in de verkoopinterface. Op Oracle kost het zoeken naar het juiste adres 12-13 seconden — oncomfortabele cijfers. Wanneer we overschakelen naar Tarantool, vervangen we Oracle door een andere database in de console, en als we dezelfde zoekopdracht uitvoeren, krijgen we een versnelling van 200 keer! De stad verschijnt na de derde letter. Momenteel passen we de interface aan zodat dit na de eerste letter gebeurt. Desondanks is de responstijd totaal anders — nu zijn het milliseconden in plaats van seconden.
De tweede toepassing — de populaire trend die twee snelheden IT wordt genoemd. Dit komt omdat consultants uit elke hoek zeggen dat bedrijven daarheen moeten gaan.
Hier is er een laag infrastructuur, daarboven domeinen, zoals een factureringssysteem, zoals in de telecom, bedrijfsystemen, bedrijfsrapportage. Dit is de kern die je niet moet aanraken. Natuurlijk is het mogelijk, maar dat vereist obsessieve kwaliteitsborging, omdat dit geld voor het bedrijf oplevert.
Daarboven komt de laag van microservices — datgene wat de operator of een andere speler differentieert. Microservices kunnen snel worden gecreëerd op basis van bepaalde caches, waarbij gegevens uit verschillende domeinen worden opgehaald. Hier is ruimte voor experimenten — als iets niet werkt, sluit je de ene microservice en open je een andere. Dit zorgt voor een werkelijk verhoogde time-to-market en verhoogt de betrouwbaarheid en snelheid van het bedrijf.
Microservices zijn waarschijnlijk de belangrijkste rol van Tarantool in MegaFon.
Waar we van plan zijn Tarantool toe te passen
Als we ons succesvolle billingproject vergelijken met de transformatieprogramma's bij Deutsche Telekom, Svaztome, Vodafone India, dan is het verrassend dynamisch en creatief. Tijdens de uitvoering van dit project is niet alleen MegaFon en zijn structuur getransformeerd, maar is ook Tarantool-enterprise bij Mail.ru ontstaan, en heeft onze leverancier Nexign (voorheen 'Peter-Service') BSS Box (een kant-en-klare billingoplossing) ontwikkeld.
Dit is, op een bepaalde manier, een historisch project voor de Russische markt. Het kan worden vergeleken met wat is beschreven in het boek van Frederick Brooks 'The Mythical Man-Month'. Toen, in de jaren 60, heeft IBM 5.000 mensen ingezet voor de ontwikkeling van het nieuwe besturingssysteem OS/360 voor mainframes. Wij hebben minder - 1.800, maar vanwege onze inzet voor open source en nieuwe benaderingen, werken we productiever.
Hieronder zijn de billingdomeinen weergegeven, of breder gezegd - de businesssystemen. Mensen uit het enterprise-segment zijn goed bekend met CRM. Andere systemen moeten eigenlijk overal aanwezig zijn: Open API, API Gateway.
Open API
Laten we opnieuw naar de cijfers kijken en hoe Open API momenteel functioneert. De belasting ervan is 10.000 transacties per seconde. Aangezien we van plan zijn om de laag van microservices actief te ontwikkelen en een openbaar API voor MegaFon op te bouwen, verwachten we in de toekomst een verdere groei in dit segment. 100.000 transacties zal het zeker worden..
Ik weet niet of we qua SSO kunnen concurreren met Mail.ru - zij hebben blijkbaar 1.000.000 transacties per seconde. Hun oplossing is voor ons erg interessant en we zijn van plan om hun ervaring over te nemen - bijvoorbeeld door functionele SSO-reserves te maken met behulp van Tarantool. Momenteel zijn de ontwikkelaars van Mail.ru hiermee bij ons bezig.
CRM
CRM zijn die 80 miljoen abonnees die we willen verhogen tot een miljard, omdat er al 300 miljoen documenten zijn die een geschiedenis van drie jaar omvatten. We wachten echt op nieuwe diensten, en hier is de groeipunt de aangesloten diensten. Dit is een sfeer die zal groeien, omdat er steeds meer diensten zullen komen. Dienovereenkomstig is er een geschiedenis nodig, we willen daar niet over struikelen.
De billing zelf in termen van facturering, werken met debiteuren is getransformeerd in een afzonderlijk domein. Om de prestaties te verhogen, is het architecturale sjabloon van domeinarchitectuur toegepast..
Het systeem is opgedeeld in domeinen, de belasting is verdeeld en er is redundantie gegarandeerd. Bovendien is er gewerkt aan de gedistribueerde architectuur.
Alles wat overblijft zijn enterprise-niveau oplossingen. In de belafdeling zijn er 2 miljard per dag, 60 miljard per maand. Soms moet je ze per maand herberekenen, en het is beter om dat snel te doen. Financiële monitoring is precies die 300 miljoen die constant groeit: abonnees wisselen vaak van provider, wat dit gedeelte vergroot.
Het meest telecomcomponent van mobiele communicatie is online tarificatie. Dit zijn de systemen die je laten bellen of niet laten bellen, beslissingen nemen in realtime. Hier is de belasting 30.000 transacties per seconde, maar gezien de groei van gegevensoverdracht plannen we 250.000 transacties, en daarom zijn we erg geïnteresseerd in Tarantool.
De vorige afbeelding toont de domeinen waar we van plan zijn Tarantool toe te passen. Het CRM zelf is natuurlijk breder en we zijn van plan het in de kern toe te passen.
Mijn berekende cijfer van 100 miljoen abonnees verontrust me als architect – wat als het 101 miljoen is? Moeten we dan alles opnieuw doen? Om dit te voorkomen, gebruiken we caches, wat ook de beschikbaarheid verhoogt.
In totaal zijn er twee benaderingen voor het toepassen van Tarantool. De eerste is alle caches op het niveau van microservices te bouwen.Voor zover ik begrijp, gaat VimpelCom deze route, door een klanten cache te creëren.
Wij zijn minder afhankelijk van leveranciers, we veranderen de BSS-kern, daarom hebben we al een uniforme klantendatabase uit de doos. Maar we willen dit uitbreiden. Daarom passen we een iets andere benadering toe – we maken caches binnen systemen..
Dat vermindert de desynchronisatie – één systeem is verantwoordelijk voor zowel de cache als de hoofd masterbron.
Deze methode sluit goed aan bij de Tarantool-aanpak met een transactionele skelet, waarbij alleen de delen worden bijgewerkt die betrekking hebben op updates, dat wil zeggen gegevenswijzigingen. Alles andere kan ergens anders worden opgeslagen. Er is geen enorme data lake, geen onbeheerd globaal cache. Caches worden ontworpen voor het systeem, of voor producten, of voor klanten, of om het onderhoud te vergemakkelijken. Wanneer een abonnee die ontevreden is over de kwaliteit belt, wil je hem goed van dienst zijn.
RTO en RPO
In IT zijn er twee termen – RTO en RPO.
Recovery time objective — is the service recovery time after a failure. RTO = 0 means that even if something goes down, the service continues to operate.
Recovery Point Objective — is the data recovery time, how much data we can lose over a certain period. RPO = 0 means we do not lose any data.
Task for Tarantool
Let's try to solve the task for Tarantool.
Given: a well-known shopping cart, for example, on Amazon or elsewhere. It is required that the cart operates 24 hours a day, 7 days a week, or 99.99% of the time. Orders that come to us must maintain order because we cannot chaotically turn a subscriber's connection on or off—everything must be strictly sequential. The previous subscription affects the next one, so the data is important—nothing should be lost.
Oplossing. You can try solving it directly and ask the DB developers, but the problem cannot be solved mathematically. You can recall theorems, laws of conservation, quantum physics, but why—it's impossible to solve at the database level.
Here we use the old tried-and-true architectural approach—you need to know the subject area well and solve this puzzle based on it.
Our solution: we create a distributed request registry on Tarantool—a geo-distributed cluster. In the diagram, this is three different data centers—two before the Ural Mountains, one after, and we distribute all requests across these centers.
Netflix, which is now considered a leader in IT, had only one data center until 2012. On the eve of Christmas, December 24, this data center went down. Users in Canada and the USA were left without their favorite movies, were very upset, and wrote about it on social media. Now Netflix has three data centers on the east-west coast and one in Western Europe.
We are initially building a geo-distributed solution—fault tolerance is important to us.
So we have a cluster, but what about RPO = 0 and RTO = 0? The solution is simple, depending on the subject matter.
What is important in requests? Two parts: preparing the cart BEFORE making a purchasing decision, and AFTER. The BEFORE part in telecommunications is usually called order capturing of order negotiationIn telecom, this can be much more complicated than in an online store, because the customer needs to be served, offered 5 options, and this takes some time, but the cart gets filled. At this moment, a failure is possible, but it's not critical, as this occurs interactively under human supervision.
If the Moscow data center suddenly fails, we will continue to operate by automatically switching to another data center. Theoretically, one product in the cart might be lost, but you will see this, re-add to the cart, and continue working. In this case, RTO = 0.
At the same moment, there is a second option: when we press 'submit', we want to ensure that the data is not lost. From this moment on, automation starts working — this is RPO = 0. The application of these two different patterns in one case can simply be a geo-distributed cluster with one failover master, and in another case, some quorum-based record. The templates can vary, but we solve the problem.
Furthermore, having a distributed application registry, we can also scale it all — having many dispatchers and executors who refer to this registry.
Cassandra and Tarantool together
There is one more case - ‘balance showcase’. Here is an interesting case of the joint application of Cassandra and Tarantool.
We use Cassandra because 2 billion calls a day is not the limit, and it will only increase. Marketers love to color traffic by sources; more and more details arise from social networks, for instance. This all enriches history.
Cassandra allows for horizontal scaling to any volumes.
We feel comfortable with Cassandra, but it does have one problem — it is not great for reading. Writing is fine, 30,000 per second is not an issue — the problem lies in reading..
Daarom is het onderwerp caching ontstaan, en hebben we tegelijkertijd een volgend probleem opgelost: er is een oude traditionele case waarin apparatuur van de switch voor online facturering binnenkomt in bestanden die wij in Cassandra uploaden. We hebben het probleem van betrouwbare bestandsoverdracht aangepakt en zelfs op advies van IBM file transfer gebruikt — er zijn dergelijke oplossingen die de overdracht van bestanden efficiënt beheren, bijvoorbeeld met het UDP-protocol, in plaats van met TCP. Dat is goed, maar het duurt nog steeds minuten, en zolang we dit allemaal niet hebben geladen, kan de operator in het callcenter de klant niet vertellen wat er met zijn saldo is gebeurd — we moeten wachten.
Om dit te voorkomen, toepassen we een parallel functioneel reservaat. Wanneer we een gebeurtenis via Kafka naar Tarantool verzenden, en de aggregaten in real-time herberekenen, bijvoorbeeld voor vandaag, dan ontvangen we de saldo-cache, die saldi kan geven met elke snelheid, bijvoorbeeld 100.000 transacties per seconde en dezelfde 2 seconden.
Het doel is dat na het maken van een oproep, al binnen 2 seconden het gewijzigde saldo in het persoonlijke account te zien is, alsook de informatie over waarom het is veranderd.
Conclusie
Dit waren voorbeelden van het gebruik van Tarantool. We zijn erg onder de indruk van de openheid van Mail.ru en hun bereidheid om verschillende cases te overwegen.
Het is voor consultants van BCG, McKinsey, Accenture of IBM al moeilijk om ons met iets nieuws te verrassen — veel van wat zij voorstellen, doen we al, hebben we gedaan of zijn we van plan te doen. Ik denk dat Tarantool een waardige plek in onze technologische stack zal innemen en veel bestaande technologieën zal vervangen. We zijn actief bezig met de ontwikkeling van dit project.
De presentatie van Oleg en Andrey was een van de beste op de Tarantool-conferentie van vorig jaar, en op 17 juni zal Oleg Ivlev optreden op de met een presentatie . Ook Alexander Deulin van MegaFon zal een presentatie geven . We zullen ontdekken wat er is veranderd, welke plannen zijn gerealiseerd. Sluit je aan — de conferentie is gratis, je hoeft alleen maar . Alle en het programma van de conferentie is opgesteld: nieuwe cases, nieuwe ervaringen met het gebruik van Tarantool, architectuur, enterprise, tutorials en microservices.
Bron: habr.com
