De ce are o corporație precum MegaFon nevoie de Tarantool în facturare? Din exterior, pare că un furnizor aduce o cutie mare, o conectează la priză – și iată factura! Cândva așa era, dar acum este o relicvă, iar astfel de dinosauri au dispărut sau sunt pe cale să dispară. În esență, facturarea este un sistem pentru emiterea de note de plată – o mașină de calcul sau un calculator. În telecomunicațiile moderne – aceasta este un sistem de automatizare a întregului ciclu de viață al interacțiunii cu abonatul, de la încheierea contractului până la rezilierea acestuia, incluzând tarifarea în timp real, acceptarea plăților și multe altele. Facturarea în companiile de telecomunicații este asemănătoare cu un robot de luptă – mare, puternic și încărcat cu arme.
Și ce legătură are aici Tarantool? Despre asta vor vorbi Oleg Ivlev și Andrei Knyazev. Oleg este arhitectul șef al companiei , cu o experiență vastă în companii internaționale, iar Andrei este directorul sistemelor de afaceri. Din desfășurarea raportului lor de la veți afla de ce este necesar R&D în corporații, ce este Tarantool, cum impasul scalării verticale și globalizarea au fost premisele apariției acestei Baze de Date în companie, despre provocările tehnologice, transformarea arhitecturii și în ce fel tehnologiiile MegaFon sunt asemănătoare cu Netflix, Google și Amazon.
Proiectul „Facturarea Unificată”
Proiectul despre care se va vorbi se numește „Facturarea Unificată”. Exact în acesta, Tarantool și-a demonstrat cele mai bune calități.
Creșterea performanței echipamentului de tip Hi-End nu reușea să țină pasul cu creșterea bazei de clienți și a numărului de servicii, anticipându-se o creștere suplimentară a numărului de abonați și servicii datorită M2M, IoT, iar particularitățile filialelor duceau la o agravare a timpului de lansare pe piață. Compania a decis să creeze un sistem de afaceri unificat cu o arhitectură modulară unică de nivel mondial, înlocuind cele 8 sisteme de facturare diferite existente.
MegaFon este opt companii într-una. În 2009, s-a încheiat reorganizarea: filialele din întreaga Rusie s-au unit într-o singură companie OAO „MegaFon” (acum PAO). Astfel, în companie au apărut 8 sisteme de facturare cu propriile soluții „personalizate”, particularități filiale și structuri organizaționale, IT și marketing diferite.
Totul a fost bine până când a trebuit să lansăm un produs federal comun. Aici au apărut o mulțime de dificultăți: unii aveau tarifare cu rotunjire în sus, alții în jos, iar unii - pe media aritmetică. Astfel de momente sunt mii.
În ciuda faptului că versiunea sistemului de facturare este aceeași, un singur furnizor, setările au variat atât de mult încât a fost greu de reunit. Am încercat să reducem numărul acestora și ne-am lovit de o a doua problemă, cunoscută multor corporații.
Scalare verticală. Chiar și cele mai puternice echipamente de atunci nu au răspuns nevoilor. În activitate am folosit echipamente Hewlett-Packard, din seria Superdome Hi-End, dar nu făceau față nevoilor nici măcar a două filiale. Ne-am dorit scalare orizontală fără mari costuri operaționale și investiții de capital.
Așteptarea creșterii numărului de abonați și servicii. Consultanții au adus de mult timp în lumea telecom povești despre IoT și M2M: vor veni vremuri când în fiecare telefon și fier de călcat va fi câte o cartelă SIM, iar în frigider câte două. Astăzi avem un număr de abonați, iar în viitorul apropiat va crește cu mult.
Provocările tehnologice
Aceste patru motive ne-au determinat să facem schimbări serioase. A fost o alegere între modernizarea sistemului și proiectarea de la zero. Am gândit mult timp, am luat decizii serioase, am desfășurat licitații. În final, am decis să proiectăm totul de la început și ne-am angajat în provocări interesante - provocările tehnologice.
Scalabilitate
Dacă anterior erau, să zicem, 8 sisteme de facturare cu 15 milioane de abonați, iar acum ar trebui să avem 100 milioane de abonați și mai mult — încărcătura este cu mult mai mare.
Am devenit comparabili ca dimensiune cu marii jucători de internet, precum Mail.ru sau Netflix.
Dar continuarea creșterii încărcăturii și a bazei de abonați ne-a pus înainte provocări serioase.
Geografia patriei noastre vaste
Între Kaliningrad și Vladivostok 7500 km și 10 fusuri orare. Viteza luminii este finită și, pe astfel de distanțe, întârzierile devin semnificative. 150 ms pe cele mai avansate canale optice moderne - este prea mult pentru tarifarea în timp real, mai ales așa cum este acum în telecomunicatii în Rusia. În plus, este necesar să ne actualizăm într-o zi lucrătoare, iar cu diferitele fusuri orare aceasta devine o problemă.
Nu oferim doar servicii pe bază de abonament, ci avem tarife complexe, pachete și diferite modificări. Trebuie să nu ne limităm doar la a permite sau interzice abonatului să vorbească, ci să-i oferim o anumită cotă – să calculăm apelurile și acțiunile în timp real astfel încât el să nu observe.
Redundanță
Aceasta este reversul centralizării.
Dacă adunăm toți abonații într-un singur sistem, atunci orice eveniment de urgență și catastrofă este deosebit de dăunător pentru afacere. De aceea, proiectăm sistemul astfel încât să excludem influența incidentelor asupra întregii baze de abonați.
Aceasta este din nou o consecință a renunțării la scalarea verticală. Când am trecut la scalarea orizontală, am crescut numărul serverelor de la sute la mii. Acestea trebuie gestionate, trebuie să construim interschimbabilitate, să rezervăm automat infrastructura IT și să restabilim sistemul distribuit.
A fost provocări interesante în fața noastră. Am proiectat sistemul și în acel moment am încercat să găsim cele mai bune practici globale pentru a verifica în ce măsură suntem în tendințe și cât de bine ne aliniem tehnologiilor avansate.
Experiență globală
Este uimitor, dar în telecomunicațiile globale nu am găsit niciun referință.
Europa a fost exclusă din cauza numărului de abonați și a dimensiunii, iar SUA - din cauza diversității tarifelor lor. Am analizat ceva în China, iar în India am întâlnit specialiști de la Vodafone India.
Pentru analiza arhitecturii, am adunat o echipă de vis condusă de IBM - arhitecți din diferite domenii. Aceste persoane au putut evalua adecvat ceea ce facem și să aducă anumite cunoștințe în arhitectura noastră.
Scalabilitate
Câteva cifre pentru ilustrare.
Proiectăm sistemul pentru 80 milioane de abonați, cu un rezervor pentru un miliard. Astfel eliminăm pragurile viitoare. Nu pentru că ne îndreptăm să cucerim China, ci din cauza avansului IoT și M2M.
300 milioane de documente sunt procesate în timp real. Deși avem 80 milioane de abonați, lucrăm și cu clienți potențiali și cu cei care ne-au părăsit, dacă trebuie să recuperăm datoriile. De aceea, volumele reale sunt semnificativ mai mari.
2 miliarde de tranzacții schimbă zilnic soldul - acestea sunt plăți, venituri, apeluri și alte evenimente. 200 TB de date se schimbă activ, se schimbă puțin mai încet 8 PB de date, și aceasta nu este un arhiv, ci date live într-un sistem de facturare unificat. Scalarea pentru centrele de date — 5 mii de servere pe 14 site-uri.
Stiva tehnologică
Când am planificat arhitectura și am început să construim sistemul, am importat cele mai interesante și avansate tehnologii. Am făcut o stivă tehnologică cunoscută de orice actor din internet și de corporațiile care construiesc sisteme cu încărcare mare.
Stiva este similară cu cele ale altor jucători mari: Netflix, Twitter, Viber. Aceasta se compune din 6 componente, dar ne dorim să o reducem și să o unificăm.
Flexibilitatea este bună, dar într-o mare corporație, fără unificare nu se poate.
Nu ne propunem să schimbăm Oracle cu Tarantool. În realitatea companiilor mari, aceasta este o utopie, sau o cruciadă de 5–10 ani cu un rezultat incert. Dar Cassandra și Couchbase pot fi cu siguranță înlocuite cu Tarantool, și ne străduim spre aceasta.
De ce Tarantool?
Există 4 criterii simple pentru care am ales această bază de date.
Viteză. Am efectuat teste de încărcare pe sisteme industriale MegaFon. Tarantool a câștigat — a arătat cea mai bună performanță.
Nu se poate spune că alte sisteme nu satisfac nevoile MegaFon. Soluțiile actuale de memorie sunt atât de performante, încât rezervele companiei sunt mai mult decât suficiente. Dar ne interesează să lucrăm cu liderul, nu cu cel care rămâne în urmă, inclusiv în testul de încărcare.
Tarantool satisface nevoile companiei chiar și pe termen lung.
Costul TCO. Suportul pentru Couchbase la volumurile MegaFon costă bani foarte mulți, în timp ce situația cu Tarantool este mult mai plăcută, iar în ceea ce privește funcționalitatea, sunt aproape identice.
O altă caracteristică plăcută, care a influenițat puțin alegerea noastră — Tarantool lucrează mai bine cu memoria decât celelalte baze de date. Acesta arată eficiență maximă.
Fiabilitate. MegaFon investește în fiabilitate, probabil, ca nimeni altcineva. Așadar, când ne-am uitat la Tarantool, am înțeles că trebuie să facem așa încât să satisfacă cerințele noastre.
Am investit timpul și finanțele noastre și, împreună cu Mail.ru, am creat o versiune enterprise, care este folosită deja în câteva alte companii.
Tarantool-enterprise ne-a satisfăcut complet în ceea ce privește securitatea, fiabilitatea și înregistrarea.
Parteneriate
Cel mai important pentru mine — contactul direct cu dezvoltatorul. Acesta este exact ceea ce l-a convins pe tipii de la Tarantool.
Dacă te duci la un jucător, mai ales unul care lucrează cu un client de bază, și îi spui că ai nevoie ca baza de date să poată face asta, asta și asta, de obicei el răspunde:
— Bine, pune cerințele sub fundul acelei stive — probabil că în cele din urmă vom ajunge la ele.
Multe companii au un roadmap pentru următorii 2-3 ani, și este practic imposibil să te integrezi acolo, iar dezvoltatorii de Tarantool sunt atrăgători prin deschiderea lor, și nu doar cu MegaFon, și își adaptează sistemul la client. Este grozav, și ne place foarte mult.
Unde am folosit Tarantool
În cazul nostru, Tarantool este utilizat în câteva elemente. Primul — în pilot, pe care l-am realizat pe sistemul de catalog de adrese. La vremea respectivă, ne doream să fie un sistem asemănător cu Yandex Maps și Google Maps, dar a ieșit puțin diferit.
Ca exemplu, catalogul de adrese în interfața de vânzări. Pe Oracle, căutarea unei adrese durează 12-13 secunde — cifre incomode. Când trecem la Tarantool, înlocuim Oracle cu o altă bază de date în consolă, și efectuăm aceeași căutare, obținem o accelerare de 200 de ori! Orașul apare după a treia literă. Acum adaptăm interfața, astfel încât să se întâmple după prima. Totuși, viteza de reacție este complet diferită — deja milisecunde în loc de secunde.
A doua utilizare — tema populară care se numește IT cu două viteze. Totul pentru că consultanții din fiecare colț spun că corporațiile ar trebui să meargă în această direcție.
Aici există un strat de infrastructură, deasupra căruia sunt domeniile, de exemplu, sistemul de facturare, ca în telecomunicații, sistemele corporative, raportarea corporativă. Acesta este nucleul, pe care nu trebuie să-l atingi. Adică, desigur, se poate, dar trebuie să asiguri calitatea în mod paranoic, deoarece aceasta aduce bani corporației.
Următorul strat este cel al microserviciilor — ceea ce diferențiază operatorul sau alt jucător. Microserviciile pot fi create rapid pe baza unor anumite cache-uri, ridicând date din diferite domenii. Aici este un domeniu pentru experimente — dacă ceva nu a funcționat, închizi un microserviciu, deschizi altul. Acest lucru garantează cu adevărat un time-to-market crescut și îmbunătățește fiabilitatea și viteza companiei.
Microserviciile reprezintă, probabil, rolul principal al Tarantool în MegaFon.
Unde planificăm să aplicăm Tarantool
Comparând proiectul nostru de facturare de succes cu programele de transformare de la Deutsche Telekom, Svyaznoy, Vodafone India, acesta este surprinzător de dinamic și creativ. În procesul de implementare al acestui proiect, nu doar că a fost transformat MegaFon și structura sa, dar a apărut și Tarantool-enterprise la Mail.ru, iar furnizorul nostru Nexign (fost „Peterservice”) a lansat BSS Box (o soluție de facturare de tip cutie).
Acesta este, într-un anumit sens, un proiect istoric pentru piața rusă. Poate fi comparat cu ceea ce este descris în cartea lui Frederick Brooks „Mythical Man-Month”. Atunci, în anii '60, pentru dezvoltarea unui nou sistem de operare OS/360 pentru mainframe-urile IBM, au fost atrași 5.000 de oameni. Noi avem mai puțini — 1.800, dar avem un avantaj, iar având în vedere utilizarea open source și noilor abordări, lucrăm mai eficient.
Mai jos sunt afișate domeniile de facturare sau, dacă dorim să extindem, - sistemele de afaceri. Oamenii din mediul enterprise cunosc bine CRM. Alte sisteme ar trebui să fie deja disponibile pentru toată lumea: Open API, API Gateway.
Open API
Să ne uităm din nou la numere și la modul în care funcționează acum Open API. În prezent, sarcina sa este de 10.000 de tranzacții pe secundă. Deoarece intenționăm să dezvoltăm activ stratul de microservicii și să construim un API public pentru MegaFon, așteptăm o creștere și mai mare în viitor, în special în acest domeniu. 100.000 de tranzacții vor fi cu siguranță realizate.
Nu știu dacă ne vom compara în privința SSO cu Mail.ru — se pare că au 1.000.000 de tranzacții pe secundă. Soluția lor este extrem de interesantă pentru noi și plănuim să le adoptăm experiența — de exemplu, să realizăm un rezervor funcțional SSO cu ajutorul Tarantool. Acum, dezvoltatorii de la Mail.ru se ocupă de acest lucru pentru noi.
CRM
CRM-ul reprezintă acei 80 de milioane de abonați pe care vrem să îi ducem la un miliard, deoarece deja există 300 de milioane de documente, care includ o istorie de trei ani. Așteptăm cu adevărat noi servicii, iar aici punctul de creștere este serviciile conectate. Aceasta este o sferă care va crește, deoarece vor exista din ce în ce mai multe servicii. Prin urmare, va fi nevoie de istorie, nu dorim să ne împiedicăm în acest aspect.
Întreaga facturare în ceea ce privește emiterea de facturi, gestionarea creanțelor clienților s-a transformat într-un domeniu separat. Pentru a extinde performanța, s-a aplicat un model arhitectural de arhitectură domenială..
Sistemul este împărțit în domenii, sarcina este distribuită și este asigurată redundanța. În plus, s-a lucrat pe arhitectura distribuită.
Tot ce rămâne sunt soluții la nivel enterprise. În depozitul de apeluri - 2 miliarde pe zi, 60 miliarde pe lună. Uneori trebuie să le recalculăm pentru luna respectivă, iar mai bine este să o facem rapid. Monitorizarea financiară — reprezintă tocmai cele 300 milioane, care cresc constant: abonații trec frecvent între operatori, sporind această parte.
Cel mai telecom component din serviciile mobile este tarifarea online. Acestea sunt sistemele care îți permit să suni sau să nu suni, luând decizii în timp real. Aici, sarcina este de 30.000 de tranzacții pe secundă, dar având în vedere creșterea transferului de date, planificăm 250.000 de tranzacții, de aceea suntem foarte interesați de Tarantool.
Imaginea anterioară reprezintă domeniile unde ne propunem să aplicăm Tarantool. Întreg CRM-ul, desigur, este mai extins și ne propunem să îl aplicăm în nucleul său.
Numărul nostru estimat de capacitate tehnică de 100 milioane de abonați mă îngrijorează ca arhitect — ce se întâmplă dacă ajungem la 101 milioane? Trebuie să refacem totul? Pentru a evita acest lucru, aplicăm cache-uri, sporind în același timp disponibilitatea.
În general, există două abordări pentru utilizarea Tarantool. Prima este să construim toate cache-urile la nivel de microservicii. Din câte știu, pe această cale merge VimpelCom, creând cache-uri pentru clienți.
Noi suntem mai puțin dependenți de furnizori, schimbăm nucleul BSS, de aceea avem deja un catalog unitar de clienți din cutie. Dar dorim să îl extindem. De aceea aplicăm o abordare puțin diferită — facem cache-uri în interiorul sistemelor.
Astfel, există mai puțin desincronizare — un singur sistem răspunde atât pentru cache, cât și pentru sursa principală.
Metoda se aliniază bine cu abordarea Tarantool utilizând un schelet tranzacțional, când se actualizează doar părțile care țin de actualizări, adică modificările de date. Tot restul poate fi stocat altundeva. Nu există un lac de date imens, un cache global necontrolat. Cache-urile sunt proiectate pentru sistem, fie pentru produse, fie pentru clienți, fie pentru a ușura viața întreținerii. Când un abonat deranjat de calitate sună, vrei să îi oferi un serviciu de calitate.
RTO și RPO
În IT există doi termeni — RTO și RPO.
Obiectivul timpului de recuperare — este timpul de recuperare a serviciului după o defecțiune. RTO = 0 înseamnă că, chiar dacă ceva cedează, serviciul continuă să funcționeze.
Obiectivul punctului de recuperare — este timpul de recuperare a datelor, cât de multe date putem pierde într-o anumită perioadă de timp. RPO = 0 înseamnă că nu pierdem date.
Sarcina pe Tarantool
Să încercăm să rezolvăm sarcina pentru Tarantool.
Dat: un coș de cereri bine cunoscut, de exemplu, în Amazon sau altundeva. Este necesar ca coșul să funcționeze 24 de ore pe zi, 7 zile pe săptămână, sau 99,99% din timp. Comenzile care vin la noi trebuie să păstreze o ordine, deoarece nu putem activa sau dezactiva haotic conexiunea clientului — totul trebuie să fie strict secvențial. Abonamentul anterior influențează pe cel următor, așa că datele sunt importante — nimic nu trebuie să dispară.
Soluție. Se poate încerca să se abordeze direct și să se întrebe dezvoltatorii de Baze de Date, dar sarcina nu se rezolvă matematic. Se pot aminti teoremele, legile conservării, fizica cuantică, dar de ce — nu poate fi rezolvată la nivelul Bazei de Date.
Aici funcționează vechiul și bunul principiu arhitectural — trebuie să cunoști bine domeniul și, folosind aceasta, să rezolvi acest rebus.
Soluția noastră: creăm un registru distribuit de cereri pe Tarantool — un cluster geo-distribuit. Pe schemă, acestea sunt trei centre diferite de procesare a datelor — două înainte de Ural, unul după Ural, iar noi distribuim toate cererile între aceste centre.
Netflix, care acum este considerat unul dintre liderii în IT, până în 2012 avea doar un singur DC. Cu o zi înainte de Crăciunul catolic, pe 24 decembrie, acest DC a căzut. Utilizatorii din Canada și SUA au rămas fără filmele lor preferate, s-au supărat foarte mult și au scris despre asta pe rețelele sociale. Acum Netflix are trei DC-uri pe coasta de vest-est și unul în vestul Europei.
Noi construim inițial o soluție geo-distribuită — ne pasă de reziliența în fața defecțiunilor.
Așadar, avem un cluster, dar cum rămâne cu RPO = 0 și RTO = 0? Soluția este simplă, depinde de subiect.
Ce este important în cereri? Două părți: compilarea coșului ÎNAINTE de a lua decizia de cumpărare, și DUPĂ. Partea ÎNAINTE în telecomunicații este de obicei numită captarea comenzii sau negocierea comenzii. În telecomunicații, acest lucru poate fi mult mai complicat decât într-un magazin online, deoarece trebuie să deservim clientul, să oferim 5 opțiuni, și toate acestea se întâmplă pentru o anumită perioadă de timp, dar coșul se umple. În acest moment, o defecțiune este posibilă, dar nu este o problemă, deoarece se desfășoară într-un mod interactiv sub supravegherea unei persoane.
Dacă centrul de date din Moscova ar ieși brusc din funcțiune, atunci, comutându-ne automat pe un alt centru de date, vom continua activitatea. Teoretic, un produs din coș ar putea fi pierdut, dar tu îl vezi, completezi din nou coșul și continui să lucrezi. În acest caz, RTO = 0.
În același moment, există o a doua opțiune: când am apăsat „submit”, dorim ca datele să nu se piardă. Din acest punct, automatizarea începe să funcționeze — aceasta este deja RPO = 0. Aplicarea acestor două modele diferite într-un caz, poate fi pur și simplu un cluster georepartizat cu un master comutabil, în celălalt caz, o înregistrare cu un număr de voturi. Modelele pot varia, dar noi rezolvăm problema.
Mai departe, având un registru distribuit al cererilor, putem să scalăm totul — să avem mulți dispeceri și executanți care accesează acest registru.
Cassandra și Tarantool împreună
Există și un alt caz — „vitrina soldurilor”. Aici avem un caz interesant de aplicare comună a Cassandra și Tarantool.
Folosim Cassandra pentru că 2 miliarde de apeluri pe zi nu sunt limita, și vor fi mai multe. Marketerii adoră să coloreze traficul în funcție de surse, apar tot mai multe detalii pe rețelele sociale, de exemplu. Toate acestea cresc istoricul.
Cassandra permite scalarea orizontală la orice volum.
Ne simțim confortabil cu Cassandra, dar are o problemă — nu este bună la citire. La scriere, totul este OK, 30.000 pe secundă nu este o problemă — problema este la citire.
Prin urmare, a apărut problema cache-ului și, de asemenea, am rezolvat următoarea problemă: există un caz tradițional vechi, când echipamentul de la comutator, de la tarificarea online, vine în fișiere pe care le încărcăm în Cassandra. Am luptat cu problema încărcării fișierelor în mod fiabil, am aplicat chiar, la recomandarea managerului de transfer de fișiere IBM, soluții care administrează eficient transferul fișierelor, utilizând protocolul UDP, de exemplu, și nu TCP. Este bine, dar sunt totuși minute și, până nu încărcăm totul, operatorul din call center nu poate răspunde clientului ce s-a întâmplat cu balanța sa - trebuie să aștepte.
Pentru a evita acest lucru, noi utilizăm un rezervor funcțional paralel. Când trimitem un eveniment prin Kafka în Tarantool, recalculând agregatele în timp real, de exemplu, pentru astăzi, atunci obținem cache-ul balanțelor, care poate livra balanțe cu orice viteză, de exemplu, 100 de mii de tranzacții pe secundă și aceleași 2 secunde.
Scopul este ca, după efectuarea apelului, să avem deja în cabineta personalizat, în termen de 2 secunde, nu doar balanța modificată, ci și informația despre motivul pentru care a fost modificată.
Concluzie
Acestea au fost exemple de utilizare a Tarantool. Ne-a plăcut foarte mult deschiderea Mail.ru, disponibilitatea lor de a analiza diferite cazuri.
Consultanții de la BCG sau McKinsey, Accenture sau IBM deja au dificultăți să ne surprindă cu ceva nou — multe dintre cele ce le propun, fie le facem deja, fie le-am făcut, fie planificăm să le facem. Cred că Tarantool va ocupa un loc de cinste în teaca noastră tehnologică și va înlocui multe tehnologii deja existente. Suntem în faza activă de dezvoltare a acestui proiect.
Prezentarea lui Oleg și Andrei a fost una dintre cele mai bune de la Tarantool Conference de anul trecut, iar pe 17 iunie Oleg Ivlev va vorbi la cu o prezentare . De asemenea, de la MegaFon va vorbi Alexander Deulin cu prezentarea . Vom afla ce s-a schimbat, ce planuri au fost realizate. Alăturați-vă — conferința este gratuită, trebuie doar să . Toate iar programul conferinței a fost format: cazuri noi, noi experiențe de utilizare a Tarantool, arhitectură, enterprise, tutoriale și microservicii.
Sursa: habr.com
