Zašto je korporaciji kao što je MegaFon potreban Tarantool za naplatu? Izvana se čini da obično dođe prodavac, donese neku veliku kutiju, utakne utikač u utičnicu - i to je naplata! Nekada je to bio slučaj, a sada je arhaično, a takvi dinosaurusi su već izumrli ili izumiru. U početku je naplata sistem za izdavanje računa – mašina za brojanje ili kalkulator. U modernim telekomunikacijama to je sistem automatizacije za čitav životni ciklus interakcije sa pretplatnikom od zaključenja ugovora do raskida, uključujući naplatu u realnom vremenu, prihvatanje plaćanja i još mnogo toga. Naplata u telekomunikacijskim kompanijama je poput borbenog robota - velik, moćan i napunjen oružjem.
Kakve veze ima Tarantool s tim? Oni će pričati o tome Oleg Ivlev и Andrey Knyazev. Oleg je glavni arhitekta kompanije sa velikim iskustvom rada u stranim kompanijama, Andrej je direktor poslovnih sistema. Iz transkripta njihovog izvještaja dana naučićete zašto je istraživanje i razvoj potreban u korporacijama, šta je Tarantool, kako su ćorsokak vertikalnog skaliranja i globalizacije postali preduvjeti za pojavu ove baze podataka u kompaniji, o tehnološkim izazovima, arhitektonskoj transformaciji i kako je tehnostak MegaFona sličan Netflixu , Google i Amazon.
Projekat "Jedinstvena naplata"
Predmetni projekat se zove „Jedinstvena naplata“. Tu je Tarantool pokazao svoje najbolje kvalitete.
Rast produktivnosti Hi-End opreme nije pratio rast pretplatničke baze i rast broja usluga, očekivao se daljnji rast broja pretplatnika i usluga zbog M2M, IoT-a i karakteristika grane koje su dovele do pogoršanja vremena za stavljanje na tržište. Kompanija je odlučila da kreira jedinstveni poslovni sistem sa jedinstvenom modularnom arhitekturom svetske klase, umesto 8 postojećih različitih sistema naplate.
MegaFon je osam kompanija u jednoj. Godine 2009. završena je reorganizacija: filijale širom Rusije spojene su u jednu kompaniju, MegaFon OJSC (sada PJSC). Dakle, kompanija ima 8 sistema naplate sa sopstvenim „prilagođenim“ rešenjima, karakteristikama filijala i različitim organizacionim strukturama, IT i marketingom.
Sve je bilo u redu dok nismo morali pokrenuti jedan zajednički savezni proizvod. Ovdje se pojavilo mnogo poteškoća: za neke se tarife zaokružuju naviše, za druge naniže, a za druge - na osnovu aritmetičke sredine. Postoje hiljade takvih trenutaka.
Uprkos činjenici da je postojala samo jedna verzija sistema naplate, jedan dobavljač, podešavanja su se toliko razlikovala da je trebalo mnogo vremena da se sastave. Pokušali smo smanjiti njihov broj, a naišli smo na drugi problem koji je poznat mnogim korporacijama.
Vertikalno skaliranje. Čak ni najhladniji hardver u to vrijeme nije zadovoljavao potrebe. Koristili smo Hewlett-Packard opremu iz Superdome Hi-End linije, ali nije zadovoljila potrebe ni dvije filijale. Htio sam horizontalno skaliranje bez velikih operativnih troškova i kapitalnih ulaganja.
Očekivanja rasta broja pretplatnika i usluga. Konsultanti su dugo donosili priče o IoT-u i M2M svijetu telekomunikacija: doći će vrijeme kada će svaki telefon i pegla imati SIM karticu, a dva u frižideru. Danas imamo jedan broj pretplatnika, ali će ih u bliskoj budućnosti biti mnogo više.
Tehnološki izazovi
Ova četiri razloga su nas motivisala na ozbiljne promjene. Postojao je izbor između nadogradnje sistema i projektovanja od nule. Dugo smo razmišljali, donosili ozbiljne odluke, igrali tendere. Kao rezultat toga, odlučili smo se za dizajn od samog početka, i prihvatili zanimljive izazove – tehnološke izazove.
Skalabilnost
Ako je bilo prije, recimo, recimo 8 naplata za 15 miliona pretplatnika, a sada je trebalo da upali 100 miliona pretplatnika i više - opterećenje je za red veličine veće.
Postali smo uporedivi po obimu sa velikim internet igračima kao što su Mail.ru ili Netflix.
Ali dalji pokret ka povećanju opterećenja i baze pretplatnika postavio nam je ozbiljne izazove.
Geografija naše ogromne zemlje
Između Kalinjingrada i Vladivostoka 7500 km i 10 vremenskih zona. Brzina svjetlosti je konačna i na takvim udaljenostima kašnjenja su već značajna. 150 ms na najkvalitetnijim modernim optičkim kanalima je previše za naplatu u realnom vremenu, pogotovo što je sada u telekomunikacijama u Rusiji. Osim toga, potrebno je ažuriranje u jednom radnom danu, a sa različitim vremenskim zonama to predstavlja problem.
Ne pružamo usluge samo uz pretplatu, imamo složene tarife, pakete i razne modifikatore. Pretplatniku ne samo da trebamo dozvoliti ili uskratiti razgovor, već mu dati određenu kvotu - izračunati pozive i akcije u realnom vremenu tako da on to ne primijeti.
tolerancije grešaka
Ovo je druga strana centralizacije.
Ako prikupimo sve pretplatnike u jednom sistemu, onda su svi hitni događaji i katastrofe pogubni za poslovanje. Stoga projektiramo sistem na način da eliminišemo uticaj havarija na cjelokupnu bazu pretplatnika.
Ovo je opet posljedica odbijanja vertikalnog skaliranja. Kada smo horizontalno skalirali, povećali smo broj servera sa stotina na hiljade. Njima je potrebno upravljati i međusobno ih zamijeniti, automatski napraviti sigurnosnu kopiju IT infrastrukture i vratiti distribuirani sistem.
Suočili smo se sa tako zanimljivim izazovima. Dizajnirali smo sistem i u tom trenutku smo pokušali da pronađemo najbolje svetske prakse kako bismo proverili koliko smo u trendu, koliko pratimo napredne tehnologije.
Svjetsko iskustvo
Iznenađujuće, nismo pronašli niti jednu referencu u globalnim telekomunikacijama.
Evropa je otpala u pogledu broja pretplatnika i obima, SAD - u pogledu ravnosti svojih tarifa. Pogledali smo neke u Kini, a neke smo pronašli u Indiji i unajmili stručnjake iz Vodafone Indije.
Da bismo analizirali arhitekturu, okupili smo Dream Team predvođen IBM-om - arhitekte iz različitih oblasti. Ti ljudi su mogli adekvatno procijeniti šta radimo i unijeti određena znanja u našu arhitekturu.
Skala
Nekoliko brojeva za ilustraciju.
Dizajniramo sistem za 80 miliona pretplatnika sa rezervom od milijardu. Na ovaj način uklanjamo buduće pragove. To nije zato što ćemo preuzeti Kinu, već zbog napada IoT-a i M2M-a.
300 miliona dokumenata obrađenih u realnom vremenu. Iako imamo 80 miliona pretplatnika, radimo i sa potencijalnim klijentima i sa onima koji su nas napustili ako treba da naplatimo potraživanja. Stoga su stvarne količine znatno veće.
2 milijarde transakcija Stanje se mijenja svakodnevno - to su plaćanja, naknade, pozivi i drugi događaji. 200 TB podataka se aktivno mijenja, mijenjajte se malo sporije 8 PB podataka, a ovo nije arhiva, već podaci uživo u jednom obračunu. Skala po data centru - 5 hiljada servera na 14 lokacija.
Tehnološki stog
Kada smo planirali arhitekturu i počeli da sklapamo sistem, uvezli smo najzanimljivije i najnaprednije tehnologije. Rezultat je niz tehnologija poznat svakom Internet igraču i korporacijama koje prave sisteme visokog opterećenja.
Stack je sličan stogovima drugih velikih igrača: Netflix, Twitter, Viber. Sastoji se od 6 komponenti, ali ga želimo skratiti i objediniti.
Fleksibilnost je dobra, ali u velikoj korporaciji nema načina bez ujedinjenja.
Nećemo mijenjati isti Oracle u Tarantool. U realnosti velikih kompanija, ovo je utopija, odnosno krstaški rat od 5-10 godina sa nejasnim ishodom. Ali Cassandra i Couchbase se lako mogu zamijeniti Tarantoolom, a to je ono čemu težimo.
Zašto Tarantool?
Postoje 4 jednostavna kriterijuma zašto smo odabrali ovu bazu podataka.
Brzina. Sproveli smo testove opterećenja na MegaFon industrijskim sistemima. Tarantool je pobijedio - pokazao je najbolji učinak.
To ne znači da drugi sistemi ne zadovoljavaju potrebe MegaFona. Trenutna memorijska rješenja su toliko produktivna da su rezerve kompanije više nego dovoljne. Ali nas zanima da imamo posla sa liderom, a ne sa nekim ko zaostaje, uključujući i test opterećenja.
Tarantool pokriva potrebe kompanije čak i na duži rok.
TCO trošak. Podrška za Couchbase na MegaFon volumenima košta astronomske svote novca, ali s Tarantoolom je situacija mnogo ugodnija, a slični su po funkcionalnosti.
Još jedna lijepa karakteristika koja je malo utjecala na naš izbor je ta što Tarantool radi bolje s memorijom od ostalih baza podataka. On pokazuje maksimalna efikasnost.
Pouzdanost. MegaFon ulaže u pouzdanost, vjerovatno više nego bilo ko drugi. Dakle, kada smo pogledali Tarantool, shvatili smo da ga moramo učiniti da ispuni naše zahtjeve.
Uložili smo svoje vrijeme i finansije, i zajedno sa Mail.ru-om napravili smo korporativnu verziju, koja se sada koristi u nekoliko drugih kompanija.
Tarantool-enterprise nas je u potpunosti zadovoljio u smislu sigurnosti, pouzdanosti i sječe.
Partnerstvo
Najvažnija stvar za mene je direktan kontakt sa programerom. To je upravo ono čime su se podmitili momci iz Tarantoola.
Ako dođete do igrača, posebno onog koji radi sa sidrenim klijentom, i kažete da vam je potrebna baza podataka da biste mogli ovo, ovo i to, on obično odgovara:
- Dobro, stavite zahtjeve na dno te gomile - jednog dana ćemo vjerovatno doći do njih.
Mnogi imaju mapu puta za naredne 2-3 godine i tu je skoro nemoguće integrisati se, ali Tarantool programeri plene svojom otvorenošću, i to ne samo od MegaFona, i prilagođavaju svoj sistem korisniku. Super je i stvarno nam se sviđa.
Gdje smo koristili Tarantool
Tarantool koristimo u nekoliko elemenata. Prvi je u pilotu, koji smo napravili na sistemu adresnog imenika. Svojevremeno sam želio da to bude sistem koji je sličan Yandex.Maps-u i Google Maps-u, ali je ispalo malo drugačije.
Na primjer, katalog adresa u prodajnom sučelju. Na Oracle-u, traženje željene adrese traje 12-13 sekundi. - neprijatne brojke. Kada se prebacimo na Tarantool, zamijenimo Oracle drugom bazom podataka u konzoli i izvršimo istu pretragu, dobićemo 200x ubrzanje! Grad se pojavljuje nakon trećeg slova. Sada prilagođavamo interfejs tako da se to desi nakon prvog. Međutim, brzina odziva je potpuno drugačija - milisekunde umjesto sekundi.
Druga aplikacija je trendi tema koja se zove informatička tehnologija sa dve brzine. To je zato što konsultanti sa svih strana kažu da bi korporacije trebalo da idu tamo.
Postoji infrastrukturni sloj, iznad njega postoje domeni, na primjer, sistem naplate kao što je telekom, korporativni sistemi, korporativno izvještavanje. Ovo je jezgro koje ne treba dirati. To je, naravno, moguće, ali paranoično osiguravajući kvalitet, jer to donosi novac korporaciji.
Zatim dolazi sloj mikroservisa – ono što razlikuje operatera ili drugog igrača. Mikroservis se može brzo kreirati na osnovu određenih keš memorija, donoseći tamo podatke iz različitih domena. Evo polje za eksperimente — ako nešto nije išlo, zatvorio sam jedan mikroservis i otvorio drugi. Ovo pruža zaista povećano vrijeme za izlazak na tržište i povećava pouzdanost i brzinu kompanije.
Mikroservis je možda glavna uloga Tarantoola u MegaFonu.
Gdje planiramo koristiti Tarantool
Ako uporedimo naš uspješan projekt naplate sa programima transformacije u Deutsche Telekomu, Svyazcomu, Vodafone India, on je iznenađujuće dinamičan i kreativan. U procesu implementacije ovog projekta transformisan je ne samo MegaFon i njegova struktura, već se pojavio i Tarantool-enterprise na Mail.ru, a naš dobavljač Nexign (ranije Peter-Service) - BSS Box (rešenje za naplatu u kutiji).
Ovo je, u izvesnom smislu, istorijski projekat za rusko tržište. Može se uporediti sa onim što je opisano u knjizi Fredericka Bruksa „Mjesec mitskog čoveka“. Zatim, 60-ih godina, IBM je unajmio 360 ljudi da razviju novi OS/5 operativni sistem za mainframe. Imamo manje - 000, ali naši su u prslucima, a uzimajući u obzir korištenje otvorenog koda i novih pristupa, radimo produktivnije.
Ispod su domeni naplate ili, šire govoreći, poslovni sistemi. Ljudi iz preduzeća veoma dobro poznaju CRM. Svi bi već trebali imati druge sisteme: Open API, API Gateway.
Open API
Pogledajmo ponovo brojke i kako Open API trenutno radi. Njegovo opterećenje je 10 transakcija u sekundi. Budući da planiramo da aktivno razvijamo sloj mikroservisa i gradimo MegaFon javni API, očekujemo veći rast u budućnosti u ovom dijelu. Sigurno će biti 100 transakcija.
Ne znam da li možemo da se poredimo sa Mail.ru-om u SSO-u - čini se da momci imaju 1 transakcija u sekundi. Njihovo rješenje nam je izuzetno zanimljivo i planiramo usvojiti njihovo iskustvo - na primjer, pravljenje funkcionalne SSO sigurnosne kopije pomoću Tarantool-a. Sada programeri sa Mail.ru to rade za nas.
CRM
CRM je istih 80 miliona pretplatnika koje želimo da povećamo na milijardu, jer već postoji 300 miliona dokumenata koji uključuju trogodišnju istoriju. Zaista se radujemo novim uslugama i ovdje tačka rasta su povezane usluge. Ovo je lopta koja će rasti, jer će biti sve više servisa. Shodno tome, trebat će nam priča; ne želimo da se spotaknemo o tome.
Sama naplata u smislu izdavanja faktura, rad sa računima kupaca transformisan u poseban domen. Za poboljšanje performansi, arhitektonski obrazac primijenjene arhitekture domena.
Sistem je podijeljen na domene, opterećenje je raspoređeno i osigurana je otpornost na greške. Osim toga, radili smo sa distribuiranom arhitekturom.
Sve ostalo su rješenja na nivou preduzeća. U memoriji poziva - 2 milijarde dnevno60 milijardi mjesečno. Ponekad ih morate prebrojati za mjesec dana, a bolje je brzo. Finansijski monitoring - ovo je upravo istih 300 miliona koji stalno rastu i rastu: pretplatnici često trče između operatera, povećavajući ovaj dio.
Najtelekomunikacijskija komponenta mobilnih komunikacija je online naplata. Ovo su sistemi koji vam omogućavaju da zovete ili ne zovete, donosite odluke u realnom vremenu. Ovdje je opterećenje 30 transakcija u sekundi, ali uzimajući u obzir rast prijenosa podataka, planiramo 250 transakcija, i stoga smo veoma zainteresovani za Tarantool.
Prethodna slika su domeni na kojima ćemo koristiti Tarantool. Sam CRM je, naravno, širi i mi ćemo ga koristiti u samom jezgru.
Naša procijenjena TTX brojka od 100 miliona pretplatnika me zbunjuje kao arhitektu - šta ako 101 milion? Morate li sve ponoviti? Kako bismo spriječili da se to dogodi, koristimo keš memorije, istovremeno povećavajući dostupnost.
Općenito, postoje dva pristupa korištenju Tarantool-a. Prvo - izgraditi sve keš memorije na nivou mikroservisa. Koliko sam shvatio, VimpelCom ide ovim putem, stvarajući keš klijenata.
Manje ovisimo o dobavljačima, mijenjamo jezgro BSS-a, tako da imamo jedan klijentski fajl iz kutije. Ali želimo da ga proširimo. Stoga, koristimo malo drugačiji pristup - napraviti keš unutar sistema.
Na ovaj način postoji manje sinhronizacije - jedan sistem je odgovoran i za keš i za glavni glavni izvor.
Metoda se dobro uklapa u Tarantool pristup sa transakcionim kosturom, kada se ažuriraju samo dijelovi koji se odnose na ažuriranja, odnosno promjene podataka. Sve ostalo se može pohraniti negdje drugdje. Ne postoji ogromno jezero podataka, neupravljana globalna keš memorija. Predmemorije su dizajnirane za sistem, ili za proizvode, ili za klijente, ili da olakšaju život za održavanje. Kada vas pretplatnik pozove i uznemiren je zbog kvaliteta vaše usluge, želite da pružite kvalitetnu uslugu.
RTO i RPO
U IT-u postoje dva pojma - OTR и RPO.
Cilj vremena oporavka je vrijeme potrebno za obnavljanje usluge nakon kvara. RTO = 0 znači da čak i ako nešto pokvari, usluga nastavlja da radi.
Cilj tačke oporavka - ovo je vrijeme oporavka podataka, koliko podataka možemo izgubiti u određenom vremenskom periodu. RPO = 0 znači da ne gubimo podatke.
Tarantool zadatak
Pokušajmo riješiti problem za Tarantool.
Dato: korpa aplikacija koje svi razumiju, na primjer, u Amazonu ili negdje drugdje. Obavezno tako da korpa radi 24 sata 7 dana u nedelji, odnosno 99,99% vremena. Narudžbe koje nam stižu moraju ostati u redu, jer ne možemo nasumično uključiti ili isključiti vezu pretplatnika - sve mora biti striktno dosljedno. Prethodna pretplata utiče na sledeću, tako da su podaci važni - ništa ne bi trebalo da nestane.
odluka. Možete pokušati to riješiti direktno i pitati programere baze podataka, ali problem se ne može riješiti matematički. Možete se sjetiti teorema, zakona održanja, kvantne fizike, ali zašto - to se ne može riješiti na nivou DB-a.
Ovdje funkcionira stari dobri arhitektonski pristup - potrebno je dobro poznavati predmetnu oblast i koristiti je za rješavanje ove zagonetke.
Naše rješenje: kreiranje distribuiranog registra aplikacija na Tarantool-u - geo-distribuiranom klasteru. Na dijagramu su to tri različita centra za obradu podataka - dva prije Urala, jedan iza Urala, a mi distribuiramo sve zahtjeve među tim centrima.
Netflix, koji se danas smatra jednim od vodećih u IT-u, imao je samo jedan data centar do 2012. godine. Uoči katoličkog Božića, 24. decembra, ovaj data centar se pokvario. Korisnici u Kanadi i SAD-u ostali su bez svojih omiljenih filmova, bili su jako uznemireni i pisali o tome na društvenim mrežama. Netflix sada ima tri data centra na zapadno-istočnoj obali i jedan u zapadnoj Evropi.
U početku gradimo geo-distribuirano rješenje - važna nam je tolerancija kvarova.
Dakle, imamo klaster, ali šta je sa RPO = 0 i RTO = 0? Rješenje je jednostavno, ovisno o temi.
Šta je važno u aplikacijama? Dva dijela: bacanje korpe TO donošenje odluke o kupovini, i NAKON. DO dio u telekomu se obično naziva hvatanje reda ili pregovaranje o narudžbi. U telekomu to može biti mnogo teže nego u online prodavnici, jer se tamo klijent mora uslužiti, ponuditi 5 opcija i sve se to dešava neko vrijeme, ali korpa je popunjena. U ovom trenutku kvar je moguć, ali nije strašno, jer se dešava interaktivno pod ljudskim nadzorom.
Ako moskovski data centar iznenada pokvari, automatskim prelaskom na drugi podatkovni centar nastavit ćemo raditi. Teoretski, jedan proizvod može biti izgubljen u korpi, ali vidite ga, dodajte ga ponovo u korpu i nastavite sa radom. U ovom slučaju RTO = 0.
Istovremeno, postoji i druga opcija: kada smo kliknuli na „pošalji“, želimo da podaci ne budu izgubljeni. Od ovog trenutka automatizacija počinje da radi - ovo je RPO = 0. Koristeći ova dva različita obrasca, u jednom slučaju bi to jednostavno mogao biti geo-distribuirani klaster sa jednim preklopnim masterom, u drugom slučaju neka vrsta zapisa kvoruma. Obrasci se mogu razlikovati, ali mi rješavamo problem.
Nadalje, imajući distribuirani registar aplikacija, možemo sve to i skalirati - imati mnogo dispečera i izvršitelja koji pristupaju ovom registru.
Cassandra i Tarantool zajedno
Postoji još jedan slučaj - "vitrina bilansa". Evo zanimljivog slučaja zajedničke upotrebe Cassandre i Tarantool-a.
Koristimo Cassandru jer 2 milijarde poziva dnevno nije granica, a bit će ih još. Marketinški stručnjaci vole kolorit promet prema izvoru; na primjer, na društvenim mrežama pojavljuje se sve više detalja. Sve to doprinosi priči.
Cassandra vam omogućava horizontalno skaliranje na bilo koju veličinu.
S Kasandrom se osjećamo ugodno, ali ona ima jedan problem - nije dobra u čitanju. Na snimku je sve OK, 30 u sekundi nije problem - problem čitanja.
Stoga se pojavila tema sa keš memorijom, a ujedno smo riješili i sljedeći problem: postoji stari tradicionalni slučaj kada oprema sa prekidača sa online naplate dolazi u fajlove koje učitavamo u Cassandru. Borili smo se s problemom pouzdanog preuzimanja ovih datoteka, čak i koristeći savjet IBM menadžera za prijenos datoteka - postoje rješenja koja efikasno upravljaju prijenosom datoteka, koristeći UDP protokol, na primjer, umjesto TCP. Ovo je dobro, ali još su minute, a još nismo sve učitali, operater u call centru ne može odgovoriti klijentu šta mu se desilo sa stanjem - moramo čekati.
Kako bismo spriječili da se to dogodi, mi koristimo paralelnu funkcionalnu rezervu. Kada pošaljemo događaj preko Kafke u Tarantool, preračunavajući agregate u realnom vremenu, na primjer, za danas, dobijamo salda gotovine, koji može prenijeti stanje bilo kojom brzinom, na primjer, 100 hiljada transakcija u sekundi i te iste 2 sekunde.
Cilj je da nakon upućivanja poziva, u roku od 2 sekunde na vašem ličnom računu ne bude samo promijenjeno stanje, već i informacija o tome zašto se promijenilo.
zaključak
Ovo su bili primjeri korištenja Tarantoola. Zaista nam se dopala otvorenost Mail.ru-a i njihova spremnost da razmotre različite slučajeve.
Već je teško konsultantima iz BCG-a ili McKinseyja, Accenturea ili IBM-a da nas iznenade nečim novim - mnogo od onoga što oni nude, mi ili već radimo, uradili smo ili planiramo da uradimo. Mislim da će Tarantool zauzeti mjesto koje mu pripada u našoj tehnologiji i zamijeniti mnoge postojeće tehnologije. Nalazimo se u aktivnoj fazi razvoja ovog projekta.
Izvještaj Olega i Andreja jedan je od najboljih na prošlogodišnjoj konferenciji Tarantool, a 17. juna Oleg Ivlev će govoriti na sa izvještajem . Aleksandar Deulin će takođe održati prezentaciju MegaFona . Hajde da saznamo šta se promenilo, koji planovi su realizovani. Pridružite se - konferencija je besplatna, sve što treba da uradite je . Sve i formiran je program konferencije: novi slučajevi, novo iskustvo u korišćenju Tarantoola, arhitektura, enterprise, tutorijali i mikroservis.
izvor: www.habr.com