Framstruktur för nästa generations fakturering: transformation med övergång till Tarantool

Varför behöver en sådan korporation som MegaFon Tarantool i faktureringen? Det verkar som om en leverantör vanligtvis kommer in, tar med sig en stor låda, kopplar in den i uttaget – och där har vi faktureringen! Så var det en gång, men nu är det en arkaisk metod, och sådana dinosaurier har antingen dött ut eller håller på att försvinna. Ursprungligen var fakturering ett system för att skapa fakturor – en räknesnurra eller kalkylator. Inom modern telekommunikation är det ett system för automatisering av hela livscykeln av interaktionerna med abonnenten, från avtalets ingående till uppsägning, inklusive realtidsprissättning, betalningsmottagning och mycket mer. Fakturering i telekomföretag liknar en stridsrobot – stor, kraftfull och beväpnad.

Vad har då Tarantool med detta att göra? Det kommer Oleg Ivlev och Andrey Knyazev. Oleg är huvudarkitekten för företaget MegaFon med lång erfarenhet från utländska företag, och Andrey är direktör för affärssystem. Från deras föredrag på Tarantool Conference 2018 kommer du att få veta varför R&D är viktigt i företag, vad Tarantool är, hur den vertikala skalningens väg är en dead-end och globaliseringen blev en förutsättning för att denna databas kom till företaget, samt de teknologiska utmaningar, transformeringen av arkitekturen, och hur MegaFons teknologistack liknar Netflix, Google och Amazon.

Projektet "Enhetlig fakturering"

Projektet vi kommer att diskutera kallas "Enhetlig fakturering". Det är här Tarantool visade sina bästa egenskaper.

Tillväxten av prestanda hos Hi-End utrustning kunde inte hålla jämna steg med tillväxten av abonnentbasen och antalet tjänster, och en fortsatt ökning av abonnenter och tjänster förväntades genom M2M, IoT, samt filialernas specifika behov ledde till en försämring av time-to-market. Företaget beslutade att skapa ett enhetligt affärssystem med en unik modulär arkitektur av världsklass, som en ersättning för 8 nuvarande olika faktureringssystem.

MegaFon är åtta företag i ett. År 2009 avslutades omorganisationen: filialer över hela Ryssland slogs samman till ett enda företag, OAO "MegaFon" (nu PAO). På så sätt fick företaget 8 faktureringssystem med egna "anpassade" lösningar, filialspecifika behov och olika organisationstrukturer, IT och marknadsföring.

Allt gick bra tills vi var tvungna att lansera en gemensam federal produkt. Här dök det upp en massa svårigheter: vissa hade avrundning uppåt, andra neråt, och vissa hade det utifrån medelvärdet. Det finns tusentals sådana situationer.

Trots att versionen av faktureringssystemet är densamma och det är en leverantör, varierade inställningarna så mycket att det tog lång tid att stämma ihop dem. Vi försökte minska antalet, och stötte på det andra problemet som många företag känner till.

Vertikal skalning. Även den mest avancerade hårdvaran vid den tiden motsvarade inte behoven. Under arbetet använde vi Hewlett-Packard-utrustning från Superdome Hi-End-serien, men den klarade inte ens behovet från två filialer. Vi önskade horisontell skalning utan stora driftskostnader och kapitalinvesteringar.

Förväntan på tillväxt av antalet abonnenter och tjänster. Konsulter har länge fört berättelser om IoT och M2M in i telekomvärlden: det kommer en tid då varje telefon och strykjärn har ett SIM-kort, och kylskåp kommer ha två. Idag har vi ett visst antal abonnenter, men inom en snar framtid kommer det att bli betydligt fler.

Teknologiska utmaningar

Dessa fyra orsaker drev oss till omfattande förändringar. Det fanns ett val mellan att uppgradera systemet eller bygga från grunden. Vi funderade länge, fattade svåra beslut, gick på upphandlingar. I slutändan beslutade vi oss för att konstruera från grunden och ta oss an intressanta utmaningar – teknologiska utmaningar.

Skalbarhet

Om det tidigare var, låt oss säga, 8 faktureringssystem för 15 miljoner abonnenter, så skulle det nu bli 100 miljoner abonnenter eller fler – belastningen är betydligt högre.

Vi blev jämförbara i skala med stora internetaktörer som Mail.ru eller Netflix.

Men det fortsatta arbetet med att öka belastningen och abonnentbasen ställde allvarliga frågor för oss.

Geografin i vårt stora land

Mellan Kaliningrad och Vladivostok 7500 km och 10 tidszoner. Ljusets hastighet är ändlig och på sådana avstånd är fördröjningar redan betydande. 150 ms på de mest avancerade moderna optiska kanalerna är ganska mycket för realtidsfakturering, särskilt som den är just nu inom telekom i Ryssland. Dessutom måste uppdateringar göras inom en arbetsdag, vilket är ett problem med olika tidszoner.

Vi tillhandahåller inte bara abonnemangstjänster, vi har komplexa prismodeller, paket och olika modifierare. Vi måste inte bara ge abonnenten tillstånd eller nekad att kommunicera, utan ge dem en specifik kvot – beräkna samtal och åtgärder i realtid så att de inte märker något.

Fel-tolerans

Detta är baksidan av centralisering.

Om vi samlar alla abonnenter i ett system, så blir eventuella nödsituationer och katastrofer förödande för affärerna. Därför designar vi systemet så att det utesluter påverkan av olyckor på hela kundbasen.

Detta är återigen en konsekvens av att avstå från vertikal skalning. När vi gick mot horisontell skalning ökade vi antalet servrar från hundratals till tusentals. Dessa måste hanteras och skapa utbytbarhet, automatiskt säkerhetskopiera IT-infrastrukturen och återhämta det distribuerade systemet.

Det har funnits intressanta utmaningar framför oss. Vi har designat systemet och i detta ögonblick försökte vi hitta världspraxis för att kontrollera hur mycket vi är i takt med, hur mycket vi följer den senaste teknologin.

Världserfarenhet

Förvånande nog hittade vi ingen referens i den globala telekomsektorn.

Europa uteslöts på grund av antalet abonnenter och skalan, USA på grund av prismodellerna. Vi tittade på något i Kina, och hittade något i Indien och tog experter från Vodafone Indien.

För att analysera arkitekturen samlade vi Dream Team under ledning av IBM – arkitekter från olika områden. Dessa personer kunde adekvat bedöma vad vi gör och tillföra specifik kunskap till vår arkitektur.

Skala

Några siffror för illustration.

Vi designar systemet för 80 miljoner abonnenter med reserv för en miljard. Så här tar vi bort framtida gränser. Det beror inte på att vi tänker erövra Kina, utan på grund av trycket från IoT och M2M.

300 miljoner dokument bearbetas i realtid. Även om vi har 80 miljoner abonnenter, arbetar vi också med potentiella kunder och de som har lämnat oss, om det behövs för att återkräva fordringar. Därför är de verkliga volymerna betydligt större.

2 miljarder transaktioner förändrar saldot dagligen – detta inkluderar betalningar, debiteringar, samtal och andra händelser. 200 TB data förändras aktivt, något långsammare förändras 8 PB data, och det är inte ett arkiv, utan levande data i en och samma fakturering. Skalan med datacenter är 5 000 servrar på 14 platser.

Teknologisk stack

När vi planerade arkitekturen och började bygga systemet importerade vi de mest intressanta och avancerade teknologierna. Resultatet blev en teknologisk stack som är bekant för alla internetanvändare och företag som bygger högbelastade system.

Stacken liknar stackarna hos andra stora aktörer: Netflix, Twitter, Viber. Den består av 6 komponenter, men vi vill förenkla och enhetliggöra den.

Flexibilitet är bra, men utan enhetlighet fungerar det inte i ett stort företag.

Vi tänker inte byta ut Oracle mot Tarantool. I stora företagsverkligheter är det en utopi, eller ett korståg som tar 5–10 år med ett oklart resultat. Men Cassandra och Couchbase kan gott ersättas med Tarantool, och vi strävar efter det.

Varför Tarantool?

Det finns 4 enkla kriterier för varför vi valde denna databasen.

Hastighet. Vi genomförde belastningstester på MegaFons industriella system. Tarantool vann – den visade bäst prestanda.

Man kan inte säga att andra system inte tillfredsställer MegaFons behov. De nuvarande minneslösningarna är så effektiva att det utrymmet företaget har är mer än tillräckligt. Men vi är intresserade av att jobba med en ledare, och inte med dem som halkar längst bak, även i belastningstestet.

Tarantool uppfyller företagets behov även på lång sikt.

TCO-kostnad. Stödet för Couchbase i MegaFons volymer kostar astronomiska summor, medan situationen med Tarantool är mycket trevligare, och funktionaliteten är nära.

En annan trevlig aspekt som påverkade vårt val – Tarantool arbetar bättre med minnet än andra databaser. Den visar maximal effektivitet.

Pålitlighet. MegaFon investerar i pålitlighet, kanske mer än någon annan. Därför när vi tittade på Tarantool insåg vi att vi måste se till att den uppfyller våra krav.

Vi har investerat vår tid och pengar, och tillsammans med Mail.ru skapade vi en företagsversion som nu används av flera andra företag.

Tarantool-enterprise uppfyllde helt våra krav när det kommer till säkerhet, tillförlitlighet och loggning.

Partnerskap

Det viktigaste för mig är den direkta kontakten med utvecklaren. Det är precis det som killarna från Tarantool har gjort intryck på oss.

Om du kommer till en spelare, särskilt en som arbetar med en strategisk kund, och säger att du behöver att databasen kan göra det här, det här och det här, brukar han svara:

— Okej, lägg kraven längst ner i den där högen – kanske kommer vi till dem en dag.

Många har en roadmap för de kommande 2-3 åren, och det är nästan omöjligt att få in något där, men utvecklarna av Tarantool imponerar med sin öppenhet, inte bara gentemot MegaFon, och anpassar sitt system efter kunden. Det är fantastiskt och vi gillar det verkligen.

Där vi tillämpar Tarantool

Vi använder Tarantool i flera komponenter. Första är i piloten, som vi gjorde med det adresserade katalogsystemet. I sin tid ville vi att det skulle vara ett system som liknar Yandex.Kartor och Google Maps, men resultatet blev något annat.

Som exempel, katalogen av adresser i försäljningsgränssnittet. På Oracle tar det 12-13 sekunder att söka efter en adress – obekväma siffror. När vi byter till Tarantool, ersätter Oracle med en annan databas i konsolen, och gör samma sökning, får vi en acceleration på 200 gånger! Staden dyker upp efter tredje bokstaven. Just nu anpassar vi gränssnittet så att det sker efter den första. Trots det är svaret helt annorlunda – redan i millisekunder istället för sekunder.

Den andra tillämpningen är en het trend som kallas dual-speed IT. Allt för att konsulter från varje hörn säger att företag bör gå dit.

Här finns en infrastruktur som ligger ovanför den, exempelvis faktureringssystem, som i telekom, företagssystem, företagsrapportering. Det är kärnan som man inte bör röra. Det går naturligtvis, men man måste paranoidt säkerställa kvaliteten, för det ger företagen intäkter.

Därefter kommer lagret med mikrotjänster – något som särskiljer operatören eller en annan aktör. Mikrotjänster kan snabbt skapas baserat på vissa cache och genom att hämta data från olika domäner. Här finns utrymme för experiment – om något inte fungerar, stänger man en mikrotjänst och öppnar en annan. Det garanterar verkligen en ökad time-to-market och ökar företagets pålitlighet och hastighet.

Mikrotjänster är förmodligen den huvudsakliga rollen för Tarantool i MegaFon.

Där planerar vi att tillämpa Tarantool

Om man jämför vårt framgångsrika faktureringsprojekt med transformationsprogrammen hos Deutsche Telekom, Svjaztkom, Vodafone India, är det fantastiskt dynamiskt och kreativt. I genomförandet av detta projekt har inte bara MegaFon och dess struktur transformerats, utan även Tarantool-enterprise hos Mail.ru, och vår leverantör Nexign (tidigare "Peter-Service") har BSS Box (en paketlösning för fakturering).

Detta är, på något sätt, ett historiskt projekt för den ryska marknaden. Det kan jämföras med vad som beskrivs i Frederick Brooks bok "The Mythical Man-Month". Då, på 60-talet, använde IBM 5 000 personer för att utveckla det nya operativsystemet OS/360 för deras mainframes. Vi har färre – 1 800, men med våra tröjor och med hänsyn till användningen av öppen källkod och nya tillvägagångssätt arbetar vi mer effektivt.

Nedan visas domäner för fakturering eller, om vi pratar bredare, affärssystem. Folk inom enterprise känner till CRM. Andra system borde alla redan ha: Open API, API Gateway.

Open API

Låt oss återigen titta på siffrorna och hur Open API fungerar nu. Dess belastning är 10 000 transaktioner per sekund. Eftersom vi planerar att aktivt utveckla lager av mikrotjänster och bygga en offentlig API för MegaFon, förväntar vi oss en större tillväxt i framtiden, särskilt inom detta område. 100 000 transaktioner kommer definitivt att bli verklighet.

Jag vet inte om vi kommer att kunna jämföra oss med Mail.ru i SSO – de har, verkar det som, 1 000 000 transaktioner per sekund. Deras lösning är extremt intressant för oss och vi planerar att ta del av deras erfarenhet – till exempel att skapa en funktionell reserv för SSO med hjälp av Tarantool. Just nu arbetar utvecklarna från Mail.ru på detta hos oss.

CRM

CRM är de där 80 miljoner abonnenter som vi vill föra till en miljard, eftersom vi redan har 300 miljoner dokument som inkluderar tre års historia. Vi väntar verkligen på nya tjänster, och här ligger tillväxtpunkten – det är de anslutna tjänsterna. Det är en sfär som kommer att växa, för det kommer att finnas fler och fler tjänster. Därmed kommer det att behövas en historia, vi vill inte snubbla över detta.

Själva faktureringen när det gäller att utfärda fakturor, hantera kunders fordringar har transformerats till en separat domän. För att öka prestandan, har en arkitekturmodell med domänarkitektur tillämpats.

Systemet är indelat i domäner, belastningen är fördelad och redundans är säkerställd. Dessutom har vi arbetat med distribuerad arkitektur.

Allt annat är företagslösningar. I samtalslagringen — 2 miljarder per dag, 60 miljarder per månad. Ibland måste vi räkna om dem per månad, och det är bättre att göra det snabbt. Finansiell övervakning — det handlar just om de 300 miljoner som ständigt växer och växer: abonnenter springer ofta mellan operatörerna, vilket ökar denna del.

Den mest telekomkomponenten från mobilkommunikation är online-tarifiering. Det är de system som låter dig ringa eller inte ringa, som fattar beslut i realtid. Här är belastningen 30 000 transaktioner per sekund, men med hänsyn till den växande datatrafiken planerar vi 250 000 transaktioner, och därför är vi starkt intresserade av Tarantool.

Den föregående bilden visar de domäner där vi planerar att tillämpa Tarantool. Själva CRM:et är bredare och vi planerar att använda det i kärnan.

Min uppskattade siffra för TTF i 100 miljoner abonnenter bekymrar mig som arkitekt — vad händer om det blir 101 miljoner? Måste vi göra om allt? För att undvika detta använder vi cacheminnen, vilket i sin tur ökar tillgängligheten.

Det finns i stort sett två angreppssätt för att tillämpa Tarantool. Det första är att bygga alla cacher på mikrotjänstnivå.Såvitt jag vet följer VimpelCom denna väg och skapar kundcache.

Vi är mindre beroende av leverantörer, ändrar kärnan i BSS, så vi har enhetlig kundregister redan från början. Men vi vill utöka det. Därför tillämpar vi en något annan metod — vi gör cacher internt i systemen..

På så sätt minskar synkroniseringsproblemen — ett system ansvarar både för cachen och för huvudmasterkällan.

Metoden passar väl in i Tarantools angreppssätt med transaktionell skelett, när endast de delar som är relaterade till uppdateringar uppdateras, det vill säga ändringar av data. Allt annat kan lagras någon annanstans. Det finns ingen enorm data lake, ingen okontrollerad global cache. Cacher designas för systemet, antingen för produkter eller för kunder, eller för att underlätta livet för supporten. När en missnöjd abonnent ringer vill man ge dem ett kvalitativt bemötande.

RTO och RPO

Inom IT finns det två termer — RTO och RPO.

Recovery time objective — detta är tiden för återställning av tjänsten efter ett fel. RTO = 0 betyder att även om något går ner, fortsätter tjänsten att fungera.

återställningspunktsmål — detta är tiden för dataåterställning, hur mycket data vi kan förlora under en viss tidsperiod. RPO = 0 innebär att vi inte förlorar data.

Uppgift för Tarantool

Låt oss försöka lösa uppgiften för Tarantool.

Givet: en allmänt känd varukorg, till exempel i Amazon eller någon annanstans. Krav att varukorgen ska fungera 24 timmar om dygnet, 7 dagar i veckan, eller 99,99 % av tiden. Beställningar som kommer in till oss måste upprätthålla ordningen, eftersom vi inte kan slå av och på anslutningen för abonnenten slumpmässigt – allt måste vara strikt i sekvens. Den tidigare prenumerationen påverkar den nästa, så uppgifterna är viktiga – inget får gå förlorat.

Lösning. Man kan försöka lösa det direkt och fråga databasutvecklarna, men problemet är matematiskt olösligt. Man kan minnas teoremer, bevarande lagar, kvantfysik, men varför - det kan inte lösas på databasnivå.

Här fungerar den gamla, goda arkitektoniska metoden – man behöver ha en bra förståelse för ämnesområdet och lösa denna gåta genom det.

Vår lösning: vi skapar ett distribuerat register för ansökningar på Tarantool – ett geo-distribuerat kluster. På diagrammet ser vi tre olika datacenter – två före Ural och ett bakom Ural, och vi fördelar alla ansökningar mellan dessa centra.

Netflix, som nu anses vara en av ledarna inom IT, hade fram till 2012 bara ett datacenter. Dagen före den katolska julen den 24 december gick detta datacenter ner. Användare i Kanada och USA blev utan sina favoritfilmer, blev mycket besvikna och skrev om det på sociala medier. Nu har Netflix tre datacenter på västkusten och ett i Västeuropa.

Vi bygger ursprungligen en geo-distribuerad lösning – vi värdesätter fel-tolerans.

Så vi har ett kluster, men hur ska vi hantera RPO = 0 och RTO = 0? Lösningen är enkel och beror på ämnesområdet.

Vad är viktigt i ansökningarna? Två delar: att fånga varukorgen FÖRE beslutet om köp, och EFTER. Den FÖRE delen inom telekommunikation kallas vanligtvis order capturing eller order negotiation. In telekom bör det vara betydligt mer komplicerat än i en webbutik, eftersom kunden måste betjänas, få 5 alternativ, och allt detta tar tid medan varukorgen fylls. Vid det här tillfället kan ett fel inträffa, men det är inte katastrofalt eftersom det sker i interaktivt läge under övervakning av en person.

Om datacentret i Moskva plötsligt går ner, kommer vi automatiskt att växla till ett annat datacenter och fortsätta arbetet. Teoretiskt kan en produkt i varukorgen gå förlorad, men du ser detta, fyller på varukorgen igen och fortsätter. I detta fall är RTO = 0.

Samtidigt finns det ett andra alternativ: när vi trycker på "skicka", vill vi att uppgifterna inte ska gå förlorade. Från och med det ögonblicket börjar automatiken att fungera - det är redan RPO = 0. Tillämpning av dessa två olika mönster i ett fall kan vara en geo-distribuerad kluster med en växlande master, i det andra fallet en quorum-anteckning. Mallarna kan variera, men vi löser problemet.

Vidare, med en distribuerad register över ansökningar kan vi också skala detta - ha många förmän och utförare som pekar på detta register.

Cassandra och Tarantool tillsammans

Det finns också ett annat fall - "balansvitrin". Här är just ett intressant fall av samarbete mellan 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ärgsätta trafik efter källor, det kommer fler detaljer om sociala nätverk, till exempel. Detta ökar historien.

Cassandra möjliggör horisontell skalning till valfria volymer.

Vi känner oss bekväma med Cassandra, men den har ett problem - den är inte bra på att läsa. När det gäller skrivning är allt okej, 30 000 per sekund är inget problem - problemet ligger i läsningen..

Därför uppstod temat med cache, och vi passade samtidigt på att lösa följande problem: det finns ett gammalt traditionellt fall där utrustningen från switchen för online-tarifiering kommer i filer som vi laddar upp i Cassandra. Vi har kämpat med problemet att på ett tillförlitligt sätt ladda upp dessa filer, vi använde till och med råd från en IBM-chef för filöverföring – det finns sådana lösningar som effektivt hanterar filöverföring via UDP-protokollet, till exempel, istället för TCP. Det är bra, men det tar fortfarande minuter, och så länge vi inte har laddat upp allt, kan operatören i callcentret inte svara kunden på vad som har hänt med hans balans – man måste vänta.

För att detta inte ska hända, använder vi parallell funktionell redundans. När vi skickar ett händelse genom Kafka till Tarantool, medan vi omberäknar aggregat i realtid, till exempel för idag, får vi cache av saldon, som kan ge saldon med vilken hastighet som helst, till exempel 100 000 transaktioner per sekund och de samma 2 sekunder.

Målet är att efter att ett samtal har genomförts, ska det redan efter 2 sekunder i den personliga panelen finnas inte bara den ändrade balansen, utan även information om varför den har förändrats.

Slutsats

Detta var exempel på hur vi använder Tarantool. Vi gillade mycket öppenheten hos Mail.ru, deras vilja att överväga olika fall.

För konsulter från BCG eller McKinsey, Accenture eller IBM är det redan svårt att överraska oss med något nytt – mycket av det de erbjuder gör vi redan, har gjort, eller planerar att göra. Jag tror att Tarantool i vår teknologiska stack kommer att få en värdig plats och ersätta många befintliga teknologier. Vi är i aktiv fas av att utveckla detta projekt.

Oleg och Andrey's presentation var en av de bästa på Tarantool Conference förra året, och redan den 17 juni kommer Oleg Ivlev att tala på T+ Conference 2019 med presentationen «Varför Tarantool i Enterprise». Också från MegaFon kommer Alexander Deulin att tala med presentationen «Cacher Tarantool och replikering från Oracle». Vi får veta vad som har förändrats, vilka planer som har kunnat realiseras. Gå med oss – konferensen är gratis, man måste bara registrera sig. Alla presentationer är godkända och konferensprogrammet är fastställt: nya fall, ny erfarenhet av att använda Tarantool, arkitektur, enterprise, handledningar och mikrotjänster.

Källa: habr.com