De ce o corporație precum MegaFon are nevoie de Tarantool în facturare? Din exterior se pare că de obicei vine vânzătorul, aduce un fel de cutie mare, conectează ștecherul în priză - și asta e facturare! Așa a fost cândva, dar acum este arhaic, iar astfel de dinozauri au dispărut deja sau sunt pe cale de dispariție. Inițial, facturarea este un sistem de emitere a facturilor - o mașină de numărat sau un calculator. În telecomunicațiile moderne asta este sistem de automatizare pentru întregul ciclu de viață al interacțiunii cu un abonat de la încheierea unui contract până la reziliere, inclusiv facturarea în timp real, acceptarea plăților și multe altele. Facturarea în companiile de telecomunicații este ca un robot de luptă - mare, puternic și încărcat cu arme.
Ce legătură are Tarantool cu el? Vor vorbi despre asta Oleg Ivlev и Andrei Knyazev. Oleg este arhitectul șef al companiei cu o vastă experiență de lucru în companii străine, Andrey este director de sisteme de afaceri. Din transcrierea raportului lor de pe veți afla de ce este nevoie de cercetare și dezvoltare în corporații, ce este Tarantool, cum impasul scalarii verticale și globalizării a devenit premisele pentru apariția acestei baze de date în companie, despre provocările tehnologice, transformarea arhitecturală și cum technostack-ul MegaFon este similar cu Netflix , Google și Amazon.
Proiect „Facturare unificată”
Proiectul în cauză se numește „Facturare unificată”. Aici Tarantool și-a arătat cele mai bune calități.
Creșterea productivității echipamentelor Hi-End nu a ținut pasul cu creșterea bazei de abonați și cu creșterea numărului de servicii; era de așteptat o creștere suplimentară a numărului de abonați și servicii datorită caracteristicilor M2M, IoT și ale filialelor. la o deteriorare a time-to-market. Compania a decis să creeze un sistem de afaceri unificat cu o arhitectură modulară unică de clasă mondială, în loc de 8 sisteme de facturare diferite actuale.
MegaFon este opt companii într-una. În 2009, reorganizarea a fost finalizată: filialele din toată Rusia au fuzionat într-o singură companie, MegaFon OJSC (acum PJSC). Astfel, compania are 8 sisteme de facturare cu propriile soluții „personalizate”, caracteristici ale filialelor și diferite structuri organizaționale, IT și marketing.
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: pentru unii, tarifele sunt rotunjite în sus, pentru alții rotunjite în jos, iar pentru alții - pe baza mediei aritmetice. Sunt mii de astfel de momente.
În ciuda faptului că a existat o singură versiune a sistemului de facturare, un singur furnizor, setările s-au diferențiat atât de mult încât a durat mult timp să fie puse împreună. Am încercat să le reducem numărul și am întâlnit o a doua problemă care este familiară multor corporații.
Scalare pe verticală. Nici cel mai tare hardware din acel moment nu satisfacea nevoile. Am folosit echipamente Hewlett-Packard din linia Superdome Hi-End, dar nu a îndeplinit nevoile nici măcar a două filiale. Am vrut o scalare orizontală fără costuri mari de operare și investiții de capital.
Așteptări de creștere a numărului de abonați și servicii. Consultanții au adus de multă vreme povești despre IoT și M2M în lumea telecomunicațiilor: va veni vremea când fiecare telefon și fier de călcat vor avea o cartelă SIM și două în frigider. Astăzi avem un număr de abonați, dar în viitorul apropiat vor fi mulți alții.
Provocări tehnologice
Aceste patru motive ne-au motivat să facem schimbări serioase. A existat o alegere între modernizarea sistemului și proiectarea de la zero. Ne-am gândit mult timp, am luat decizii serioase, am jucat licitații. Drept urmare, am decis să proiectăm încă de la început și am acceptat provocări interesante - provocări tehnologice.
Scalabilitate
Dacă a fost înainte, să spunem, să spunem 8 facturi pentru 15 milioane de abonați, iar acum ar fi trebuit să funcționeze 100 de milioane de abonați și mai mult - sarcina este cu un ordin de mărime mai mare.
Am devenit comparabili la scară cu jucătorii mari de internet precum Mail.ru sau Netflix.
Dar mișcarea ulterioară de creștere a încărcăturii și a bazei de abonați a creat provocări serioase pentru noi.
Geografia vastei noastre țări
Între Kaliningrad și Vladivostok 7500 km și 10 fusuri orare. Viteza luminii este finită și la astfel de distanțe întârzierile sunt deja semnificative. 150 ms pe cele mai tari canale optice moderne este prea mult pentru facturarea în timp real, mai ales că acum este în telecomunicații în Rusia. În plus, trebuie să actualizați într-o zi lucrătoare, iar cu diferite fusuri orare aceasta este o problemă.
Nu oferim doar servicii pentru o taxă de abonament, avem tarife complexe, pachete și diferiți modificatori. Trebuie nu numai să permitem sau să refuzăm abonatului să vorbească, ci să îi oferim o anumită cotă - să calculăm apelurile și acțiunile în timp real, astfel încât să nu observe.
toleranta la greseli
Aceasta este cealaltă latură a centralizării.
Dacă colectăm toți abonații într-un singur sistem, atunci orice eveniment de urgență și dezastru sunt dezastruoase pentru afaceri. Prin urmare, proiectăm sistemul în așa fel încât să eliminăm impactul accidentelor asupra întregii baze de abonați.
Aceasta este din nou o consecință a refuzului de a scala vertical. Când am scalat orizontal, am crescut numărul de servere de la sute la mii. Acestea trebuie să fie gestionate și interschimbabile, să facă backup automat la infrastructura IT și să restabilească sistemul distribuit.
Ne-am confruntat cu provocări atât de interesante. Am proiectat sistemul și în acel moment am încercat să găsim cele mai bune practici globale pentru a verifica cât de în tendințe suntem, cât de mult urmărim tehnologiile avansate.
Experiență mondială
În mod surprinzător, nu am găsit o singură referință în telecomunicațiile globale.
Europa a scăzut în ceea ce privește numărul de abonați și scara, SUA - în ceea ce privește uniformitatea tarifelor sale. Ne-am uitat la unele din China și am găsit unele în India și am angajat specialiști de la Vodafone India.
Pentru a analiza arhitectura, am asamblat o echipă de vis condusă de IBM - arhitecți din diferite domenii. Acești oameni puteau să evalueze în mod adecvat ceea ce făceam și să aducă anumite cunoștințe arhitecturii noastre.
scară
Câteva numere pentru ilustrare.
Proiectăm sistemul pentru 80 de milioane de abonați cu o rezervă de un miliard. Așa eliminăm pragurile viitoare. Acest lucru nu se datorează faptului că vom prelua China, ci din cauza atacului IoT și M2M.
300 de milioane de documente procesate în timp real. Deși avem 80 de milioane de abonați, lucrăm atât cu potențiali clienți, cât și cu cei care ne-au părăsit dacă trebuie să încasăm creanțe. Prin urmare, volumele reale sunt considerabil mai mari.
2 miliarde de tranzacții Soldul se modifică zilnic - acestea sunt plăți, taxe, apeluri și alte evenimente. 200 TB de date se schimbă în mod activ, schimba putin mai incet 8 PB de date, iar aceasta nu este o arhivă, ci date live într-o singură facturare. Scalare în funcție de centrul de date - 5 mii de servere pe 14 site-uri.
Stiva de tehnologie
Când am planificat arhitectura și am început asamblarea sistemului, am importat cele mai interesante și avansate tehnologii. Rezultatul este o stivă de tehnologie familiară oricărui jucător de internet și corporații care produc sisteme cu încărcare mare.
Stiva este similară cu cele ale altor jucători majori: Netflix, Twitter, Viber. Este format din 6 componente, dar vrem să-l scurtăm și să unificăm.
Flexibilitatea este bună, dar într-o corporație mare nu există cale fără unificare.
Nu vom schimba același Oracol în Tarantool. În realitățile marilor companii, aceasta este o utopie, sau o cruciadă de 5-10 ani cu un rezultat neclar. Dar Cassandra și Couchbase pot fi înlocuite cu ușurință cu Tarantool și pentru asta ne străduim.
De ce Tarantool?
Există 4 criterii simple pentru care am ales această bază de date.
Viteză. Am efectuat teste de sarcină pe sistemele industriale MegaFon. Tarantool a câștigat - a arătat cea mai bună performanță.
Acest lucru nu înseamnă că alte sisteme nu îndeplinesc nevoile MegaFon. Soluțiile actuale de memorie sunt atât de productive încât rezervele companiei sunt mai mult decât suficiente. Dar ne interesează să avem de-a face cu un lider, și nu cu cineva care rămâne în urmă, inclusiv în testul de sarcină.
Tarantool acoperă nevoile companiei chiar și pe termen lung.
Costul TCO. Suportul pentru Couchbase pe volume MegaFon costă sume astronomice de bani, dar cu Tarantool situația este mult mai plăcută și sunt similare ca funcționalitate.
O altă caracteristică plăcută care a influențat ușor alegerea noastră este că Tarantool funcționează mai bine cu memoria decât alte baze de date. El arată eficienta maxima.
Încredere. MegaFon investește în fiabilitate, probabil mai mult decât oricine altcineva. Așa că, când ne-am uitat la Tarantool, ne-am dat seama că trebuie să-l facem să îndeplinească cerințele noastre.
Ne-am investit timpul și finanțele, iar împreună cu Mail.ru am creat o versiune enterprise, care este acum folosită în alte câteva companii.
Tarantool-enterprise ne-a mulțumit pe deplin în ceea ce privește securitatea, fiabilitatea și înregistrarea în jurnal.
asociere
Cel mai important lucru pentru mine este contact direct cu dezvoltatorul. Exact cu asta au mituit băieții de la Tarantool.
Dacă vii la un jucător, în special unul care lucrează cu un client anchor, și spui că ai nevoie de baza de date pentru a putea face asta, asta și asta, de obicei el răspunde:
- Bine, pune cerințele în partea de jos a acelui teanc - într-o zi, probabil că vom ajunge la ele.
Mulți au o foaie de parcurs pentru următorii 2-3 ani și este aproape imposibil să se integreze acolo, dar dezvoltatorii Tarantool captivează prin deschiderea lor, și nu numai de la MegaFon, și își adaptează sistemul la client. E tare și ne place foarte mult.
Unde am folosit Tarantool
Folosim Tarantool în mai multe elemente. Primul este în pilot, pe care l-am făcut pe sistemul directorului de adrese. La un moment dat am vrut să fie un sistem care să fie similar cu Yandex.Maps și Google Maps, dar sa dovedit puțin diferit.
De exemplu, catalogul de adrese din interfața de vânzări. Pe Oracle, căutarea adresei dorite durează 12-13 secunde. - numere 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 scrisoare. Acum adaptăm interfața astfel încât acest lucru să se întâmple după primul. Cu toate acestea, viteza de răspuns este complet diferită - milisecunde în loc de secunde.
A doua aplicație este o temă la modă numită IT cu două viteze. Asta pentru că consultanții din toate colțurile spun că corporațiile ar trebui să meargă acolo.
Există un strat de infrastructură, deasupra acestuia există domenii, de exemplu, un sistem de facturare precum telecom, sisteme corporative, raportare corporativă. Acesta este miezul care nu trebuie atins. Adică, desigur, se poate, dar paranoic asigură calitatea, pentru că aduce bani corporației.
Urmează stratul de microservicii - ceea ce diferențiază operatorul sau alt jucător. Microservicii pot fi create rapid pe baza anumitor cache-uri, aducând acolo date din diferite domenii. Aici câmp pentru experimente — dacă ceva nu a funcționat, am închis un microserviciu și am deschis altul. Acest lucru asigură un time-to-market cu adevărat crescut și crește fiabilitatea și viteza companiei.
Microserviciile sunt probabil rolul principal al Tarantool la MegaFon.
Unde intenționăm să folosim Tarantool
Dacă comparăm proiectul nostru de facturare de succes cu programele de transformare de la Deutsche Telekom, Svyazcom, Vodafone India, este surprinzător de dinamic și creativ. În procesul de implementare a acestui proiect, nu numai MegaFon și structura sa au fost transformate, ci și Tarantool-întreprinderea a apărut la Mail.ru, iar furnizorul nostru Nexign (fostul Peter-Service) - BSS Box (o soluție de facturare în cutie).
Acesta este, într-un fel, un proiect istoric pentru piața rusă. Poate fi comparat cu ceea ce este descris în cartea „The Mythical Man-Month” de Frederick Brooks. Apoi, în anii 60, IBM a angajat 360 de oameni pentru a dezvolta noul sistem de operare OS/5 pentru mainframe. Avem mai puține - 000, dar ai noștri sunt în veste și, ținând cont de utilizarea surselor deschise și a noilor abordări, lucrăm mai productiv.
Mai jos sunt domeniile sistemelor de facturare sau, mai larg vorbind, de afaceri. Oamenii de la întreprindere cunosc foarte bine CRM. Toată lumea ar trebui să aibă deja alte sisteme: Open API, API Gateway.
Deschide API
Să ne uităm din nou la numere și la modul în care funcționează în prezent Open API. Sarcina lui este 10 de tranzacții pe secundă. Deoarece intenționăm să dezvoltăm în mod activ stratul de microservicii și să construim API-ul public MegaFon, ne așteptăm la o creștere mai mare în viitor în această parte. Cu siguranță vor fi 100 de tranzacții.
Nu știu dacă putem compara cu Mail.ru în SSO - băieții par să aibă 1 de tranzacții pe secundă. Soluția lor este extrem de interesantă pentru noi și intenționăm să adoptăm experiența lor - de exemplu, realizarea unui backup SSO funcțional folosind Tarantool. Acum dezvoltatorii de la Mail.ru fac asta pentru noi.
CRM
CRM este aceiași 80 de milioane de abonați pe care vrem să-i creștem la un miliard, pentru că există deja 300 de milioane de documente care includ o istorie de trei ani. Așteptăm cu nerăbdare noi servicii și aici punctul de creștere este serviciile conectate. Aceasta este o minge care va crește, pentru că vor fi tot mai multe servicii. În consecință, vom avea nevoie de o poveste; nu vrem să ne împiedicăm de asta.
Facturarea propriu-zisă în ceea ce privește emiterea facturilor, lucrul cu creanțele clienților transformat într-un domeniu separat. Pentru a îmbunătăți performanța, arhitectura domeniului aplicat model arhitectural.
Sistemul este împărțit în domenii, sarcina este distribuită și toleranța la erori este asigurată. În plus, am lucrat cu arhitectură distribuită.
Orice altceva sunt soluții la nivel de întreprindere. În stocarea apelurilor - 2 miliarde pe zi, 60 de miliarde pe lună. Uneori trebuie să le numeri într-o lună și este mai bine rapid. Monitorizare financiară - este exact aceleași 300 de milioane care sunt în continuă creștere și creștere: abonații aleargă adesea între operatori, crescând această parte.
Cea mai mare componentă de telecomunicații a comunicațiilor mobile este facturare online. Acestea sunt sistemele care vă permit să sunați sau nu, să luați decizii în timp real. Aici încărcarea este de 30 de tranzacții pe secundă, dar ținând cont de creșterea transferului de date, planificăm 250 de tranzacții, și, prin urmare, suntem foarte interesați de Tarantool.
Imaginea anterioară este domeniile în care vom folosi Tarantool. CRM-ul în sine, desigur, este mai larg și îl vom folosi în nucleu însuși.
Cifra noastră estimată TTX de 100 de milioane de abonați mă confundă ca arhitect - și dacă 101 milioane? Trebuie să refaci totul din nou? Pentru a preveni acest lucru, folosim cache-urile, crescând în același timp accesibilitatea.
În general, există două abordări pentru utilizarea Tarantool. În primul rând - construiți toate cache-urile la nivel de microserviciu. Din câte am înțeles, VimpelCom urmează această cale, creând un cache de clienți.
Suntem mai puțin dependenți de furnizori, schimbăm nucleul BSS, așa că avem un singur fișier client din cutie. Dar vrem să-l extindem. Prin urmare, adoptăm o abordare ușor diferită - face cache în interiorul sistemelor.
În acest fel, există mai puțină sincronizare - un sistem este responsabil atât pentru memoria cache, cât și pentru sursa principală principală.
Metoda se potrivește bine cu abordarea Tarantool cu un schelet tranzacțional, când sunt actualizate doar părțile care se referă la actualizări, adică modificările datelor. Orice altceva poate fi stocat în altă parte. Nu există un lac de date uriaș, cache global negestionat. Cache-urile sunt concepute pentru sistem, sau pentru produse, sau pentru clienți, sau pentru a face viața mai ușoară pentru întreținere. Când un abonat sună și este supărat de calitatea serviciului dvs., doriți să oferiți servicii de calitate.
RTO și RPO
Există doi termeni în IT - RTO и RPO.
Obiectiv timp de recuperare este timpul necesar pentru a restabili serviciul după o defecțiune. RTO = 0 înseamnă că, chiar dacă ceva eșuează, serviciul continuă să funcționeze.
Obiectiv punct de recuperare - acesta este timpul de recuperare a datelor, câte date putem pierde într-o anumită perioadă de timp. RPO = 0 înseamnă că nu pierdem date.
Sarcina Tarantool
Să încercăm să rezolvăm o problemă pentru Tarantool.
Dat: un coș de aplicații pe care toată lumea le înțelege, de exemplu, în Amazon sau în altă parte. Necesar astfel încât coșul de cumpărături să funcționeze 24 de ore, 7 zile pe săptămână, sau 99,99% din timp. Comenzile care vin la noi trebuie să rămână în ordine, deoarece nu putem activa sau opri aleatoriu conexiunea abonatului - totul trebuie să fie strict consecvent. Abonamentul anterior îl afectează pe următorul, așa că datele sunt importante - nu trebuie să lipsească nimic.
decizie. Puteți încerca să o rezolvați direct și să întrebați dezvoltatorii bazei de date, dar problema nu poate fi rezolvată matematic. Vă puteți aminti teoreme, legile de conservare, fizica cuantică, dar de ce - nu poate fi rezolvată la nivel DB.
Vechea abordare arhitecturală bună funcționează aici - trebuie să cunoașteți bine domeniul și să o folosiți pentru a rezolva acest puzzle.
Soluția noastră: crearea unui registru distribuit de aplicații pe Tarantool - un cluster geo-distribuit. În diagramă, acestea sunt trei centre diferite de procesare a datelor - două înainte de Urali, unul dincolo de Urali și distribuim toate cererile între aceste centre.
Netflix, care este acum considerat unul dintre liderii IT, a avut un singur centru de date până în 2012. În ajunul Crăciunului Catolic, 24 decembrie, acest centru de date a căzut. Utilizatorii din Canada și SUA au rămas fără filmele lor preferate, au fost foarte supărați și au scris despre asta pe rețelele de socializare. Netflix are acum trei centre de date pe coasta de vest-est și unul în vestul Europei.
Inițial construim o soluție geo-distribuită - toleranța la erori este importantă pentru noi.
Deci avem un cluster, dar cum rămâne cu RPO = 0 și RTO = 0? Soluția este simplă, în funcție de subiect.
Ce este important în aplicații? Două părți: Aruncarea coșului tO luarea unei decizii de cumpărare și DUPĂ. Partea DO în telecomunicații este de obicei numită capturarea comenzii sau negocierea comenzii. În telecom, acest lucru poate fi mult mai dificil decât într-un magazin online, pentru că acolo trebuie servit clientul, oferite 5 opțiuni, iar asta se întâmplă de ceva timp, dar coșul este umplut. În acest moment, un eșec este posibil, dar nu este înfricoșător, pentru că se întâmplă interactiv sub supraveghere umană.
Dacă centrul de date din Moscova eșuează brusc, atunci prin trecerea automată la un alt centru de date, vom continua să lucrăm. Teoretic, un produs poate fi pierdut în coș, dar îl vedeți, adăugați din nou în coș și continuați să lucrați. În acest caz, RTO = 0.
În același moment, există o a doua opțiune: când am făcut clic pe „trimite”, dorim ca datele să nu se piardă. Din acest moment, automatizarea începe să funcționeze - acesta este RPO = 0. Folosind aceste două modele diferite, într-un caz ar putea fi pur și simplu un cluster geo-distribuit cu un master comutabil, în alt caz un fel de înregistrare de cvorum. Modelele pot varia, dar rezolvăm problema.
Mai mult, având un registru distribuit de aplicații, le putem scala pe toate - avem mulți dispeceri și executori care accesează acest registru.
Cassandra și Tarantool împreună
Mai este un caz - "vitrina soldurilor". Iată un caz interesant de utilizare în comun a Cassandrei și Tarantool.
Folosim Cassandra pentru că 2 miliarde de apeluri pe zi nu este limita și vor fi mai multe. Specialiștii în marketing le place să coloreze traficul după sursă; tot mai multe detalii apar pe rețelele sociale, de exemplu. Totul adaugă la poveste.
Cassandra vă permite să scalați orizontal la orice dimensiune.
Ne simțim confortabil cu Cassandra, dar are o problemă - nu se pricepe la citit. Totul este în regulă pe înregistrare, 30 pe secundă nu este o problemă - problema de citire.
Prin urmare, a apărut un subiect cu un cache și, în același timp, am rezolvat următoarea problemă: există un caz tradițional vechi când echipamentele de la o comutare de la facturarea online intră în fișierele pe care le încărcăm în Cassandra. Ne-am luptat cu problema descărcării fiabile a acestor fișiere, chiar și folosind sfatul IBM manager transfer de fișiere - există soluții care gestionează eficient transferul de fișiere, folosind protocolul UDP, de exemplu, mai degrabă decât TCP. Este bine, dar încă sunt câteva minute și nu am încărcat totul încă, operatorul din call center nu poate răspunde clientului ce sa întâmplat cu soldul său - trebuie să așteptăm.
Pentru a preveni acest lucru, noi folosim rezerva functionala paralela. Când trimitem un eveniment prin Kafka către Tarantool, recalculând agregatele în timp real, de exemplu, pentru astăzi, primim solduri de numerar, care poate transfera solduri cu orice viteză, de exemplu, 100 de mii de tranzacții pe secundă și aceleași 2 secunde.
Scopul este ca, după efectuarea unui apel, în 2 secunde în contul dvs. personal să apară nu doar soldul modificat, ci și informații despre motivul pentru care s-a schimbat.
Concluzie
Acestea au fost exemple de utilizare a Tarantoolului. Ne-a plăcut foarte mult deschiderea Mail.ru și disponibilitatea lor de a lua în considerare diferite cazuri.
Deja este dificil pentru consultanții de la BCG sau McKinsey, Accenture sau IBM să ne surprindă cu ceva nou - o mare parte din ceea ce oferă, fie o facem deja, fie am făcut, fie plănuim să facem. Cred că Tarantool își va ocupa locul cuvenit în tehnologia noastră și va înlocui multe tehnologii existente. Suntem în faza activă de dezvoltare a acestui proiect.
Raportul lui Oleg și Andrey este unul dintre cele mai bune la Conferința Tarantool de anul trecut, iar pe 17 iunie Oleg Ivlev va vorbi la cu un raport . Alexander Deulin va susține și o prezentare de la MegaFon . Să aflăm ce s-a schimbat, ce planuri au fost implementate. Alăturați-vă - conferința este gratuită, tot ce trebuie să faceți este ... Tot iar programul conferinței a fost format: cazuri noi, experiență nouă în utilizarea Tarantool, arhitectură, întreprindere, tutoriale și microservicii.
Sursa: www.habr.com