Varför behöver ett företag som MegaFon Tarantool för fakturering? Från utsidan verkar det som att säljaren vanligtvis kommer, tar med sig någon form av stor låda, sätter in kontakten i uttaget - och det är fakturering! Detta var en gång fallet, men nu är det arkaiskt, och sådana dinosaurier har redan dött ut eller håller på att dö ut. Till en början är fakturering ett system för att utfärda fakturor - en räknemaskin eller kalkylator. I modern telekom är detta automationssystem för hela livscykeln av interaktion med en abonnent från ingående av ett avtal till uppsägning, inklusive realtidsfakturering, betalningsacceptans och mycket mer. Fakturering i telekombolag är som en stridsrobot – stor, kraftfull och laddad med vapen.
Vad har Tarantool med det att göra? De kommer att prata om det Oleg Ivlev и Andrey Knyazev. Oleg är företagets chefsarkitekt med lång erfarenhet av att arbeta i utländska företag är Andrey chef för affärssystem. Från utskriften av deras rapport på du kommer att lära dig varför FoU behövs i företag, vad Tarantool är, hur återvändsgränden av vertikal skalning och globalisering blev förutsättningarna för denna databas uppkomst i företaget, om tekniska utmaningar, arkitektonisk transformation och hur MegaFons technostack liknar Netflix , Google och Amazon.
Projektet "Unified Billing"
Projektet i fråga kallas "Unified Billing". Det var här som Tarantool visade sina bästa egenskaper.
Tillväxten i produktiviteten för Hi-End-utrustning höll inte jämna steg med tillväxten av abonnentbasen och ökningen av antalet tjänster; ytterligare tillväxt i antalet abonnenter och tjänster förväntades på grund av M2M, IoT och branschfunktioner ledde till en försämring av time-to-market. Företaget bestämde sig för att skapa ett enhetligt affärssystem med en unik modulär arkitektur i världsklass, istället för 8 nuvarande olika faktureringssystem.
MegaFon är åtta företag i ett. 2009 slutfördes omorganisationen: filialer i hela Ryssland slogs samman till ett enda företag, MegaFon OJSC (nu PJSC). Därmed har företaget 8 faktureringssystem med egna ”anpassade” lösningar, branschfunktioner och olika organisationsstrukturer, IT och marknadsföring.
Allt var bra tills vi var tvungna att lansera en gemensam federal produkt. Här uppstod många svårigheter: för vissa avrundas tarifferna uppåt, för andra avrundas nedåt och för andra - baserat på det aritmetiska medelvärdet. Det finns tusentals sådana ögonblick.
Trots att det bara fanns en version av faktureringssystemet, en leverantör, skilde sig inställningarna så mycket att det tog lång tid att sätta ihop. Vi försökte minska deras antal och stötte på ett andra problem som är bekant för många företag.
Vertikal skalning. Inte ens den häftigaste hårdvaran på den tiden uppfyllde behoven. Vi använde Hewlett-Packard-utrustning från Superdome Hi-End-serien, men den uppfyllde inte ens behoven hos två grenar. Jag ville ha horisontell skalning utan stora driftskostnader och kapitalinvesteringar.
Förväntningar på tillväxt i antalet abonnenter och tjänster. Konsulter har länge fört berättelser om IoT och M2M till telekomvärlden: tiden kommer när varje telefon och strykjärn kommer att ha ett SIM-kort och två i kylskåpet. Idag har vi ett antal prenumeranter, men inom en snar framtid kommer det att bli många fler.
Tekniska utmaningar
Dessa fyra skäl motiverade oss att göra allvarliga förändringar. Det fanns ett val mellan att uppgradera systemet och att designa från grunden. Vi funderade länge, tog seriösa beslut, spelade anbud. Som ett resultat bestämde vi oss för att designa från första början och tog oss an intressanta utmaningar - tekniska utmaningar.
Skalbarhet
Om det var tidigare, låt oss säga, låt oss säga 8 fakturor för 15 miljoner abonnenter, och nu borde det ha fungerat 100 miljoner prenumeranter och mer - belastningen är en storleksordning högre.
Vi har blivit jämförbara i skala med stora internetspelare som Mail.ru eller Netflix.
Men den ytterligare rörelsen för att öka belastningen och abonnentbasen har skapat allvarliga utmaningar för oss.
Geografi av vårt vidsträckta land
Mellan Kaliningrad och Vladivostok 7500 km och 10 tidszoner. Ljusets hastighet är begränsad och på sådana avstånd är förseningarna redan betydande. 150 ms på de coolaste moderna optiska kanalerna är för mycket för realtidsfakturering, särskilt som det nu är inom telekom i Ryssland. Dessutom måste du uppdatera på en arbetsdag, och med olika tidszoner är detta ett problem.
Vi tillhandahåller inte bara tjänster mot en prenumerationsavgift, vi har komplexa tariffer, paket och olika modifierare. Vi behöver inte bara tillåta eller neka abonnenten att prata, utan ge honom en viss kvot - beräkna samtal och åtgärder i realtid så att han inte märker det.
feltolerans
Detta är den andra sidan av centralisering.
Om vi samlar alla abonnenter i ett system är alla nödhändelser och katastrofer katastrofala för företagen. Därför utformar vi systemet på ett sådant sätt att det eliminerar påverkan av olyckor på hela abonnentbasen.
Detta är återigen en följd av vägran att skala vertikalt. När vi skalade horisontellt ökade vi antalet servrar från hundratals till tusentals. De måste hanteras och utbytbara, automatiskt säkerhetskopiera IT-infrastrukturen och återställa det distribuerade systemet.
Vi stod inför sådana intressanta utmaningar. Vi designade systemet och i det ögonblicket försökte vi hitta globala bästa praxis för att kontrollera hur trendiga vi är, hur mycket vi följer avancerad teknologi.
Världsupplevelse
Överraskande nog hittade vi inte en enda referens inom global telekom.
Europa har fallit bort när det gäller antalet abonnenter och skala, USA - när det gäller flatheten i sina tariffer. Vi tittade på några i Kina och hittade några i Indien och anlitade specialister från Vodafone Indien.
För att analysera arkitekturen satte vi ihop ett Dream Team ledd av IBM - arkitekter från olika områden. Dessa människor kunde adekvat bedöma vad vi gjorde och tillföra viss kunskap till vår arkitektur.
skala
Några siffror för illustration.
Vi designar systemet för 80 miljoner abonnenter med en reserv på en miljard. Så tar vi bort framtida trösklar. Detta beror inte på att vi ska ta över Kina, utan på grund av anstormningen av IoT och M2M.
300 miljoner dokument behandlas i realtid. Trots att vi har 80 miljoner prenumeranter arbetar vi med både potentiella kunder och de som lämnat oss om vi behöver driva in fordringar. Därför är de faktiska volymerna märkbart större.
2 miljarder transaktioner Saldot ändras dagligen - det är betalningar, avgifter, samtal och andra händelser. 200 TB data förändras aktivt, ändra lite långsammare 8 PB data, och detta är inte ett arkiv, utan livedata i en enda fakturering. Skala efter datacenter - 5 tusen servrar på 14 sajter.
Teknikstapel
När vi planerade arkitekturen och började montera systemet importerade vi de mest intressanta och avancerade teknologierna. Resultatet är en teknikstack som är bekant för alla internetspelare och företag som tillverkar högbelastningssystem.
Stacken liknar högarna hos andra stora aktörer: Netflix, Twitter, Viber. Den består av 6 komponenter, men vi vill förkorta och förena den.
Flexibilitet är bra, men i ett stort företag går det inte utan enighet.
Vi kommer inte att ändra samma Oracle till Tarantool. I de stora företagens verklighet är detta en utopi, eller ett korståg i 5-10 år med en oklar utgång. Men Cassandra och Couchbase kan enkelt ersättas med Tarantool, och det är vad vi strävar efter.
Varför Tarantool?
Det finns fyra enkla kriterier för att vi valde denna databas.
Скорость. Vi genomförde belastningstester på MegaFons industrisystem. Tarantool vann - det visade den bästa prestandan.
Därmed inte sagt att andra system inte uppfyller MegaFons behov. Nuvarande minneslösningar är så produktiva att företagets reserver är mer än tillräckligt. Men vi är intresserade av att ha att göra med en ledare, och inte med någon som ligger efter, bland annat i belastningstestet.
Tarantool täcker företagets behov även på lång sikt.
TCO kostnad. Stöd för Couchbase på MegaFon-volymer kostar astronomiska summor pengar, men med Tarantool är situationen mycket trevligare, och de liknar funktionaliteten.
En annan trevlig funktion som lite påverkat vårt val är att Tarantool fungerar bättre med minne än andra databaser. Han visar maximal effektivitet.
Надежность. MegaFon investerar i tillförlitlighet, förmodligen mer än någon annan. Så när vi tittade på Tarantool insåg vi att vi måste få det att uppfylla våra krav.
Vi investerade vår tid och ekonomi, och tillsammans med Mail.ru skapade vi en företagsversion, som nu används i flera andra företag.
Tarantool-enterprise nöjde oss helt när det gäller säkerhet, tillförlitlighet och loggning.
partnerskap
Det viktigaste för mig är direktkontakt med utvecklaren. Detta är precis vad killarna från Tarantool mutade med.
Om du kommer till en spelare, speciellt en som jobbar med en ankarklient, och säger att du behöver databasen för att kunna göra det här, det här och det här, brukar han svara:
– Okej, lägg kraven längst ner i den högen – någon gång kommer vi nog till dem.
Många har en färdplan för de kommande 2-3 åren, och det är nästan omöjligt att integrera där, men Tarantool-utvecklare fängslar med sin öppenhet, och inte bara från MegaFon, och anpassar sitt system till kunden. Det är coolt och vi gillar det verkligen.
Där vi använde Tarantool
Vi använder Tarantool i flera element. Den första är i piloten, som vi gjorde på adresskatalogsystemet. En gång ville jag att det skulle vara ett system som liknade Yandex.Maps och Google Maps, men det blev lite annorlunda.
Till exempel adresskatalogen i försäljningsgränssnittet. På Oracle tar det 12-13 sekunder att söka efter den önskade adressen. - obekväma siffror. När vi byter till Tarantool, ersätter Oracle med en annan databas i konsolen och utför samma sökning får vi en 200x snabbare! Staden dyker upp efter den tredje bokstaven. Nu anpassar vi gränssnittet så att detta sker efter det första. Svarshastigheten är dock en helt annan – millisekunder istället för sekunder.
Den andra applikationen är ett trendigt tema som kallas tvåhastighets IT. Detta beror på att konsulter från alla hörn säger att företag borde gå dit.
Det finns ett infrastrukturlager, ovanför det finns domäner, till exempel ett faktureringssystem som telekom, företagssystem, företagsrapportering. Detta är kärnan som inte behöver röras. Det är, naturligtvis, det är möjligt, men paranoidly att säkerställa kvalitet, eftersom det ger pengar till företaget.
Därefter kommer lagret av mikrotjänster – det som skiljer operatören eller annan aktör. Mikrotjänster kan snabbt skapas baserat på vissa cachar, vilket tar data från olika domäner dit. Här fält för experiment — om något inte fungerade stängde jag en mikrotjänst och öppnade en annan. Detta ger verkligt ökad time-to-market och ökar företagets tillförlitlighet och snabbhet.
Mikrotjänster är kanske Tarantools huvudroll på MegaFon.
Där vi planerar att använda Tarantool
Om vi jämför vårt framgångsrika faktureringsprojekt med transformationsprogrammen på Deutsche Telekom, Svyazcom, Vodafone India, är det förvånansvärt dynamiskt och kreativt. I processen att implementera detta projekt förvandlades inte bara MegaFon och dess struktur, utan även Tarantool-enterprise dök upp på Mail.ru och vår leverantör Nexign (tidigare Peter-Service) - BSS Box (en boxed faktureringslösning).
Detta är på sätt och vis ett historiskt projekt för den ryska marknaden. Det kan jämföras med det som beskrivs i boken "The Mythical Man-Month" av Frederick Brooks. Sedan, på 60-talet, anställde IBM 360 5 personer för att utveckla det nya operativsystemet OS/000 för stordatorer. Vi har färre - 1 800, men våra är i västar, och med hänsyn till användningen av öppen källkod och nya tillvägagångssätt arbetar vi mer produktivt.
Nedan finns domänerna för fakturering eller, mer allmänt, affärssystem. Människor från företag känner till CRM mycket väl. Alla borde redan ha andra system: Open API, API Gateway.
Öppna API
Låt oss titta på siffrorna igen och hur Open API för närvarande fungerar. Dess belastning är 10 000 transaktioner per sekund. Eftersom vi planerar att aktivt utveckla mikroservicelagret och bygga MegaFons publika API förväntar vi oss större tillväxt i framtiden i denna del. Det kommer definitivt att bli 100 000 transaktioner.
Jag vet inte om vi kan jämföra med Mail.ru i SSO - killarna verkar ha 1 000 0000 transaktioner per sekund. Deras lösning är extremt intressant för oss och vi planerar att ta till oss deras erfarenhet - till exempel att göra en funktionell SSO-säkerhetskopiering med Tarantool. Nu gör utvecklarna från Mail.ru detta åt oss.
CRM
CRM är samma 80 miljoner prenumeranter som vi vill öka till en miljard, eftersom det redan finns 300 miljoner dokument som inkluderar en treårig historia. Vi ser verkligen fram emot nya tjänster och här tillväxtpunkt är anslutna tjänster. Det här är en boll som kommer att växa, för det kommer fler och fler tjänster. Följaktligen kommer vi att behöva en historia, vi vill inte snubbla över detta.
Fakturerar själv vad gäller utfärdande av fakturor, arbetar med kundreskontra omvandlas till en separat domän. För att förbättra prestanda, tillämpad domänarkitektur arkitektoniskt mönster.
Systemet är uppdelat i domäner, belastningen fördelas och feltolerans säkerställs. Dessutom arbetade vi med distribuerad arkitektur.
Allt annat är lösningar på företagsnivå. I samtalsförrådet - 2 miljarder per dag60 miljarder per månad. Ibland måste du räkna dem på en månad, och det går snabbt bättre. Finansiell övervakning - det här är exakt samma 300 miljoner som ständigt växer och växer: abonnenter springer ofta mellan operatörer, vilket ökar denna del.
Den mest telekomkomponenten i mobil kommunikation är onlinefakturering. Det här är de system som låter dig ringa eller inte ringa, fatta beslut i realtid. Här är belastningen 30 000 transaktioner per sekund, men med hänsyn till tillväxten i dataöverföring planerar vi 250 000 transaktioner, och därför är vi mycket intresserade av Tarantool.
Den föregående bilden är de domäner där vi ska använda Tarantool. CRM i sig är naturligtvis bredare och vi kommer att använda det i själva kärnan.
Vår uppskattade TTX-siffra på 100 miljoner prenumeranter förvirrar mig som arkitekt - tänk om 101 miljoner? Måste du göra om allt igen? För att förhindra att detta händer använder vi cacher, samtidigt som vi ökar tillgängligheten.
I allmänhet finns det två sätt att använda Tarantool. Först - bygga alla cachar på mikroservicenivå. Såvitt jag förstår följer VimpelCom denna väg och skapar en cache med klienter.
Vi är mindre beroende av leverantörer, vi ändrar BSS-kärnan, så vi har en enda klientfil ur lådan. Men vi vill utöka den. Därför tar vi ett lite annorlunda tillvägagångssätt - skapa cacher i system.
På så sätt blir det mindre synkronisering - ett system är ansvarigt för både cachen och huvudkällan.
Metoden passar bra ihop med Tarantools upplägg med ett transaktionsskelett, då endast delar som relaterar till uppdateringar, det vill säga dataändringar, uppdateras. Allt annat kan förvaras någon annanstans. Det finns ingen enorm datasjö, ohanterad global cache. Cachar är designade för systemet, eller för produkter, eller för kunder, eller för att göra livet lättare för underhåll. När en abonnent ringer och är upprörd över kvaliteten på din tjänst vill du ge kvalitetsservice.
RTO och RPO
Det finns två termer inom IT - RTO и RPO.
Mål för återhämtningstid är den tid det tar att återställa tjänsten efter ett fel. RTO = 0 betyder att även om något misslyckas så fortsätter tjänsten att fungera.
Mål för återhämtningspunkt - det här är dataåterställningstiden, hur mycket data vi kan förlora under en viss tidsperiod. RPO = 0 betyder att vi inte förlorar data.
Tarantool uppgift
Låt oss försöka lösa ett problem för Tarantool.
Given: en korg med applikationer som alla förstår, till exempel i Amazon eller någon annanstans. Krävs så att kundvagnen fungerar 24 timmar 7 dagar i veckan, eller 99,99 % av tiden. Beställningarna som kommer till oss måste förbli i ordning, eftersom vi inte kan slumpmässigt slå på eller stänga av abonnentens anslutning - allt måste vara strikt konsekvent. Den tidigare prenumerationen påverkar nästa, så uppgifterna är viktiga - inget bör försvinna.
beslutet. Du kan försöka lösa det direkt och fråga databasutvecklarna, men problemet kan inte lösas matematiskt. Du kan komma ihåg satser, bevarandelagar, kvantfysik, men varför - det går inte att lösa på DB-nivå.
Det gamla goda arkitektoniska tillvägagångssättet fungerar här - du måste känna till ämnesområdet väl och använda det för att lösa detta pussel.
Vår lösning: skapa ett distribuerat register över applikationer på Tarantool - ett geodistribuerat kluster. I diagrammet är dessa tre olika databehandlingscentra - två före Ural, ett bortom Ural, och vi fördelar alla förfrågningar mellan dessa centra.
Netflix, som nu anses vara en av de ledande inom IT, hade bara ett datacenter fram till 2012. På tröskeln till den katolska julen, den 24 december, gick detta datacenter ner. Användare i Kanada och USA lämnades utan sina favoritfilmer, var mycket upprörda och skrev om det på sociala nätverk. Netflix har nu tre datacenter på västkusten och ett i västra Europa.
Vi bygger initialt en geodistribuerad lösning – feltolerans är viktigt för oss.
Så vi har ett kluster, men hur är det med RPO = 0 och RTO = 0? Lösningen är enkel, beroende på ämne.
Vad är viktigt i applikationer? Två delar: Korgkastning tO fatta ett köpbeslut, och EFTER. DO-delen inom telekom brukar kallas orderfångst eller orderförhandling. Inom telekom kan detta vara mycket svårare än i en onlinebutik, för där måste kunden betjänas, erbjudas 5 alternativ, och allt detta händer under en tid, men korgen är fylld. I detta ögonblick är ett misslyckande möjligt, men det är inte skrämmande, eftersom det sker interaktivt under mänsklig övervakning.
Om Moskvas datacenter plötsligt misslyckas, kommer vi att fortsätta att arbeta genom att automatiskt byta till ett annat datacenter. Teoretiskt kan en produkt gå förlorad i varukorgen, men du ser den, lägg till i varukorgen igen och fortsätt arbeta. I detta fall RTO = 0.
Samtidigt finns det ett andra alternativ: när vi klickade på "skicka" vill vi att data inte ska gå förlorade. Från och med detta ögonblick börjar automatiseringen fungera - det här är RPO = 0. Med dessa två olika mönster kan det i ett fall helt enkelt vara ett geodistribuerat kluster med en omkopplingsbar master, i ett annat fall någon form av kvorumpost. Mönstren kan variera, men vi löser problemet.
Dessutom, med ett distribuerat register av applikationer, kan vi också skala det hela - har många avsändare och exekutörer som kommer åt detta register.
Cassandra och Tarantool tillsammans
Det finns ett annat fall - "uppvisning av balanser". Här är ett intressant fall av gemensam användning av Cassandra och Tarantool.
Vi använder Cassandra eftersom 2 miljarder samtal per dag inte är gränsen, och det kommer att bli fler. Marknadsförare älskar att färglägga trafik efter källa; fler och fler detaljer dyker upp på sociala nätverk, till exempel. Allt bidrar till historien.
Cassandra låter dig skala horisontellt till valfri storlek.
Vi känner oss bekväma med Cassandra, men den har ett problem - den är inte bra på att läsa. Allt är OK på inspelningen, 30 000 per sekund är inget problem - läsproblem.
Därför dök ett ämne upp med en cache, och samtidigt löste vi följande problem: det finns ett gammalt traditionellt fall när utrustning från en switch från onlinefakturering kommer in i filerna som vi laddar in i Cassandra. Vi kämpade med problemet med tillförlitlig nedladdning av dessa filer, även med hjälp av råd från IBM-chefens filöverföring - det finns lösningar som hanterar filöverföringen effektivt, med till exempel UDP-protokollet snarare än TCP. Det här är bra, men det är fortfarande minuter, och vi har inte laddat allt ännu, operatören i callcentret kan inte svara kunden vad som hände med hans saldo - vi måste vänta.
För att förhindra att detta händer har vi vi använder parallell funktionsreserv. När vi skickar en händelse via Kafka till Tarantool, omräkning av aggregat i realtid, till exempel för idag, får vi kassatillgodohavanden, som kan överföra saldon med vilken hastighet som helst, till exempel 100 tusen transaktioner per sekund och samma 2 sekunder.
Målet är att efter att ha ringt ett samtal, inom 2 sekunder på ditt personliga konto kommer det inte bara att finnas det ändrade saldot, utan information om varför det ändrades.
Slutsats
Dessa var exempel på att använda Tarantool. Vi gillade verkligen öppenheten hos Mail.ru och deras vilja att överväga olika fall.
Det är redan svårt för konsulter från BCG eller McKinsey, Accenture eller IBM att överraska oss med något nytt - mycket av det de erbjuder, antingen gör vi redan, har gjort eller planerar att göra. Jag tror att Tarantool kommer att ta sin rättmätiga plats i vår teknikstack och kommer att ersätta många befintliga teknologier. Vi är i den aktiva fasen av utvecklingen av detta projekt.
Rapporten av Oleg och Andrey är en av de bästa på Tarantool-konferensen förra året, och den 17 juni talar Oleg Ivlev kl. med en rapport . Alexander Deulin kommer också att hålla en presentation från MegaFon . Låt oss ta reda på vad som har förändrats, vilka planer som har genomförts. Gå med – konferensen är gratis, allt du behöver göra är . allt och konferensprogrammet har skapats: nya fall, ny erfarenhet av att använda Tarantool, arkitektur, företag, tutorials och mikrotjänster.
Källa: will.com