Zakaj korporacija, kot je MegaFon, potrebuje Tarantool pri zaračunavanju? Od zunaj se zdi, da ponavadi pride prodajalec, prinese nekakšno veliko škatlo, vtakne vtič v vtičnico - in to je obračun! Nekoč je bilo tako, zdaj pa je arhaično in taki dinozavri so že izumrli ali pa izumirajo. Sprva je obračun sistem za izdajanje računov - števec ali kalkulator. V sodobnih telekomunikacijah je to sistem avtomatizacije za celoten življenjski cikel interakcije z naročnikom od sklenitve pogodbe do odpovedi, vključno z zaračunavanjem v realnem času, sprejemanjem plačil in še veliko več. Zaračunavanje v telekomunikacijskih podjetjih je kot bojni robot – velik, močan in poln orožja.
Kaj ima Tarantool s tem? Govorili bodo o tem Oleg Ivlev и Andrej Knyazev. Oleg je glavni arhitekt podjetja z bogatimi izkušnjami dela v tujih podjetjih je Andrey direktor poslovnih sistemov. Iz prepisa njihovega poročila o izvedeli boste, zakaj so v korporacijah potrebne raziskave in razvoj, kaj je Tarantool, kako je brezizhodnost vertikalnega skaliranja in globalizacije postala predpogoj za pojav te podatkovne baze v podjetju, o tehnoloških izzivih, arhitekturni transformaciji in kako je MegaFonov technostack podoben Netflixu , Google in Amazon.
Projekt "Enotno obračunavanje"
Zadevni projekt se imenuje »Enotno obračunavanje«. Tu je Tarantool pokazal svoje najboljše lastnosti.
Rast produktivnosti Hi-End opreme ni sledila rasti naročniške baze in rasti števila storitev, nadaljnja rast števila naročnikov in storitev je bila pričakovana zaradi M2M, IoT in funkcij poslovalnic. do poslabšanja časa do trga. Podjetje se je odločilo namesto 8 dosedanjih različnih sistemov obračunavanja ustvariti enoten poslovni sistem z edinstveno modularno arhitekturo svetovnega razreda.
MegaFon je osem podjetij v enem. Leta 2009 je bila reorganizacija zaključena: podružnice po vsej Rusiji so se združile v eno samo podjetje MegaFon OJSC (zdaj PJSC). Tako ima podjetje 8 sistemov obračunavanja z lastnimi rešitvami »po meri«, značilnostmi podružnic in različnimi organizacijskimi strukturami, IT in trženjem.
Vse je bilo v redu, dokler nismo morali lansirati enega skupnega zveznega izdelka. Tu se je pojavilo veliko težav: za nekatere so tarife zaokrožene navzgor, za druge navzdol, za tretje pa na podlagi aritmetične sredine. Takih trenutkov je na tisoče.
Kljub temu, da je obstajala le ena različica obračunskega sistema, en dobavitelj, so se nastavitve tako razhajale, da je trajalo dolgo sestavljanje. Poskušali smo zmanjšati njihovo število in naleteli na drugo težavo, ki je znana številnim korporacijam.
Navpično skaliranje. Tudi najbolj kul strojna oprema v tistem času ni ustrezala potrebam. Uporabili smo opremo Hewlett-Packard iz linije Superdome Hi-End, ki pa ni zadovoljila potreb niti dveh podružnic. Želel sem horizontalno skaliranje brez velikih obratovalnih stroškov in kapitalskih investicij.
Pričakovanje rasti števila naročnikov in storitev. Svetovalci že dolgo prinašajo zgodbe o IoT in M2M v svet telekomunikacij: prišel bo čas, ko bo vsak telefon in likalnik imel SIM kartico, dve pa v hladilniku. Danes imamo eno število naročnikov, v bližnji prihodnosti pa jih bo veliko več.
Tehnološki izzivi
Ti štirje razlogi so nas spodbudili k resnim spremembam. Izbirati je bilo med nadgradnjo sistema in načrtovanjem iz nič. Dolgo smo razmišljali, sprejemali resne odločitve, igrali razpise. Zato smo se že na začetku odločili za oblikovanje in se lotili zanimivih izzivov – tehnoloških.
Razširljivost
Če je bilo prej, recimo, recimo 8 obračunov za 15 milijonov naročnikov, in zdaj bi moralo delovati 100 milijonov naročnikov in več - obremenitev je za red velikosti večja.
Po obsegu smo postali primerljivi z velikimi internetnimi igralci, kot sta Mail.ru ali Netflix.
Toda nadaljnje gibanje k povečanju obremenitve in baze naročnikov je pred nas postavilo resne izzive.
Geografija naše velike države
Med Kaliningradom in Vladivostokom 7500 km in 10 časovnih pasov. Hitrost svetlobe je končna in na takih razdaljah so zamude že znatne. 150 ms na najbolj kul sodobnih optičnih kanalih je preveč za obračunavanje v realnem času, še posebej, kot je zdaj v telekomunikacijah v Rusiji. Poleg tega morate posodobiti v enem delovnem dnevu, pri različnih časovnih pasovih pa je to težava.
Ne ponujamo samo storitev za naročnino, imamo kompleksne tarife, pakete in različne modifikatorje. Naročniku moramo ne samo dovoliti ali zavrniti pogovor, ampak mu dati določeno kvoto - izračunati klice in dejanja v realnem času, tako da tega ne opazi.
toleranca napak
To je druga stran centralizacije.
Če zberemo vse naročnike v enem sistemu, potem so vsi izredni dogodki in katastrofe pogubni za poslovanje. Zato sistem načrtujemo tako, da izločimo vpliv nesreč na celotno bazo naročnikov.
To je spet posledica zavračanja vertikalnega skaliranja. Ko smo povečali vodoravno, smo število strežnikov povečali s stotin na tisoče. Morajo biti upravljani in zamenljivi, samodejno varnostno kopirati IT infrastrukturo in obnoviti porazdeljeni sistem.
Soočili smo se s tako zanimivimi izzivi. Zasnovali smo sistem in v tistem trenutku poskušali poiskati najboljše svetovne prakse, da preverimo, kako v trendu smo, koliko sledimo naprednim tehnologijam.
Svetovne izkušnje
Presenetljivo nismo našli niti ene reference v svetovnem telekomu.
Evropa je odpadla po številu naročnikov in obsegu, ZDA - po pavšalnosti svojih tarif. Nekaj smo si ogledali na Kitajskem, nekaj pa našli v Indiji in najeli strokovnjake iz Vodafona India.
Za analizo arhitekture smo sestavili Dream Team pod vodstvom IBM-a - arhitektov z različnih področij. Ti ljudje so lahko ustrezno ocenili, kaj počnemo, in v našo arhitekturo vnesli določeno znanje.
Lestvica
Nekaj številk za ilustracijo.
Načrtujemo sistem za 80 milijonov naročnikov z rezervo ene milijarde. Tako odstranimo prihodnje pragove. To ni zato, ker bomo prevzeli Kitajsko, ampak zaradi navala IoT in M2M.
300 milijonov dokumentov, obdelanih v realnem času. Čeprav imamo 80 milijonov naročnikov, delamo tako s potencialnimi strankami kot s tistimi, ki so nas zapustili, če moramo izterjati terjatve. Zato so dejanske količine opazno večje.
2 milijardi transakcij Stanje se dnevno spreminja - to so plačila, bremenitve, klici in drugi dogodki. 200 TB podatkov se aktivno spreminja, spreminjajte malo počasneje 8 PB podatkov, in to ni arhiv, ampak živi podatki v enem obračunu. Merilo po podatkovnem centru - 5 tisoč strežnikov na 14 mestih.
Tehnološki sklad
Ko smo načrtovali arhitekturo in začeli sestavljati sistem, smo uvozili najbolj zanimive in napredne tehnologije. Rezultat je tehnološki sklad, ki ga poznajo vsi internetni igralci in korporacije, ki izdelujejo visoko obremenjene sisteme.
Skupek je podoben skladom drugih večjih igralcev: Netflix, Twitter, Viber. Sestavljen je iz 6 komponent, vendar ga želimo skrajšati in poenotiti.
Fleksibilnost je dobra, a v veliki korporaciji brez združevanja ne gre.
Ne bomo spremenili istega Oracla v Tarantool. V realnosti velikih podjetij je to utopija ali križarska vojna za 5-10 let z nejasnim izidom. Toda Cassandra in Couchbase je mogoče enostavno nadomestiti s Tarantoolom in to je tisto, k čemur stremimo.
Zakaj Tarantool?
Obstajajo 4 preprosta merila, zakaj smo izbrali to zbirko podatkov.
Hitro. Izvedli smo obremenitvene teste na industrijskih sistemih MegaFon. Tarantool je zmagal - pokazal je najboljšo predstavo.
To ne pomeni, da drugi sistemi ne ustrezajo potrebam MegaFona. Trenutne pomnilniške rešitve so tako produktivne, da je rezerv podjetja več kot dovolj. Vendar nas zanima obravnavati vodjo in ne nekoga, ki zaostaja, tudi v obremenitvenem testu.
Tarantool pokriva potrebe podjetja tudi na dolgi rok.
TCO stroški. Podpora za Couchbase na nosilcih MegaFon stane astronomske zneske, vendar je s Tarantoolom situacija veliko bolj prijetna in po funkcionalnosti sta podobni.
Druga lepa lastnost, ki je nekoliko vplivala na našo izbiro, je ta, da Tarantool bolje deluje s pomnilnikom kot druge baze podatkov. On pokaže maksimalna učinkovitost.
Zanesljivost. MegaFon vlaga v zanesljivost, verjetno bolj kot kdorkoli drug. Ko smo torej pogledali Tarantool, smo ugotovili, da ga moramo prilagoditi našim zahtevam.
Vložili smo svoj čas in finance ter skupaj z Mail.ru ustvarili različico za podjetja, ki jo zdaj uporabljajo v številnih drugih podjetjih.
Tarantool-enterprise nas je popolnoma zadovoljil glede varnosti, zanesljivosti in beleženja.
Partnerstvo
Zame je najpomembnejše neposreden stik z razvijalcem. Točno to so podkupili fantje iz Tarantoola.
Če pridete do igralca, zlasti tistega, ki dela s sidrnim odjemalcem, in rečete, da potrebujete bazo podatkov, da lahko naredite to, to in to, običajno odgovori:
- V redu, postavite zahteve na dno tega kupa - nekega dne jih bomo verjetno dosegli.
Mnogi imajo načrt za naslednja 2-3 leta in tam se je skoraj nemogoče integrirati, vendar razvijalci Tarantoola očarajo s svojo odprtostjo, in ne samo od MegaFona, in prilagodijo svoj sistem stranki. Kul je in res nam je všeč.
Kjer smo uporabili Tarantool
Tarantool uporabljamo v več elementih. Prvi je v pilotu, ki smo ga izdelali na imeniškem sistemu. Nekoč sem želel, da bi bil sistem podoben Yandex.Maps in Google Maps, a se je izkazalo malo drugače.
Na primer naslovni katalog v prodajnem vmesniku. Na Oraclu iskanje želenega naslova traja 12-13 sekund. - neprijetne številke. Ko preklopimo na Tarantool, zamenjamo Oracle z drugo bazo podatkov v konzoli in izvedemo isto iskanje, dobimo 200-kratno pospešitev! Mesto se pojavi po tretji črki. Zdaj prilagajamo vmesnik tako, da se to zgodi po prvem. Hitrost odziva pa je popolnoma drugačna – milisekunde namesto sekund.
Druga aplikacija je trendovska tema, imenovana two-speed IT. To je zato, ker svetovalci z vseh koncev pravijo, da bi morale tja iti korporacije.
Obstaja infrastrukturna plast, nad njo so domene, na primer sistem zaračunavanja, kot je telekom, korporativni sistemi, korporativno poročanje. To je jedro, ki se ga ni treba dotikati. To je seveda možno, a paranoično zagotavljanje kakovosti, saj prinaša denar korporaciji.
Sledi plast mikrostoritev – tisto, kar razlikuje operaterja ali drugega igralca. Mikrostoritve je mogoče hitro ustvariti na podlagi določenih predpomnilnikov in tja prinesti podatke iz različnih domen. Tukaj polje za eksperimente — če nekaj ni šlo, sem zaprl eno mikroservis in odprl drugo. To zagotavlja resnično podaljšan čas do trženja ter poveča zanesljivost in hitrost podjetja.
Mikrostoritve so morda glavna vloga Tarantoola pri MegaFonu.
Kje nameravamo uporabljati Tarantool
Če primerjamo naš uspešen projekt zaračunavanja s programi transformacije pri Deutsche Telekom, Svyazcom, Vodafone India, je presenetljivo dinamičen in ustvarjalen. V procesu izvajanja tega projekta se ni preoblikoval samo MegaFon in njegova struktura, temveč se je na Mail.ru pojavil tudi Tarantool-enterprise in naš prodajalec Nexign (prej Peter-Service) - BSS Box (rešitev za obračunavanje v škatli).
To je v nekem smislu zgodovinski projekt za ruski trg. Primerjamo ga lahko s tem, kar je opisano v knjigi "The Mythical Man-Month" Fredericka Brooksa. Nato je v 60. letih IBM najel 360 ljudi za razvoj novega operacijskega sistema OS/5 za velike računalnike. Mi jih imamo manj - 000, vendar so naši v rokah, z uporabo odprte kode in novih pristopov pa delamo bolj produktivno.
Spodaj so področja obračunskih oziroma širše povedano poslovnih sistemov. Ljudje iz podjetij zelo dobro poznajo CRM. Vsi bi že morali imeti druge sisteme: Open API, API Gateway.
Odpri API
Ponovno poglejmo številke in trenutno delovanje odprtega API-ja. Njegova obremenitev je 10 transakcij na sekundo. Ker nameravamo aktivno razvijati plast mikrostoritev in graditi MegaFon javni API, v prihodnosti pričakujemo večjo rast v tem delu. Zagotovo bo 100 transakcij.
Ne vem, če se lahko primerjamo z Mail.ru v SSO - zdi se, da imajo fantje 1 transakcij na sekundo. Njihova rešitev je za nas izjemno zanimiva in nameravamo prevzeti njihove izkušnje - na primer izdelava funkcionalne varnostne kopije SSO s pomočjo Tarantoola. Zdaj razvijalci iz Mail.ru to počnejo za nas.
CRM
CRM je istih 80 milijonov naročnikov, ki jih želimo povečati na milijardo, ker je že 300 milijonov dokumentov, ki vključujejo triletno zgodovino. Zelo se veselimo novih storitev in tukaj točka rasti so povezane storitve. To je krogla, ki bo rasla, saj bo storitev vedno več. V skladu s tem bomo potrebovali zgodbo; ne želimo se spotikati ob to.
Samo obračunavanje v smislu izstavljanja računov, delo s terjatvami strank preoblikovati v ločeno domeno. Za izboljšanje delovanja, uporabna domenska arhitektura arhitekturni vzorec.
Sistem je razdeljen na domene, obremenitev je porazdeljena in zagotovljena toleranca na napake. Poleg tega smo delali s porazdeljeno arhitekturo.
Vse ostalo so rešitve na ravni podjetja. V shrambi klicev - 2 milijardi na dan, 60 milijard na mesec. Včasih jih je treba prešteti v enem mesecu in bolje je hitro. Finančno spremljanje - to je točno istih 300 milijonov, ki nenehno rastejo in rastejo: naročniki pogosto tečejo med operaterji in povečujejo ta del.
Najbolj telekomunikacijska komponenta mobilnih komunikacij je spletno tarifiranje. To so sistemi, ki vam omogočajo, da pokličete ali ne pokličete, sprejemate odločitve v realnem času. Tukaj je obremenitev 30 transakcij na sekundo, vendar ob upoštevanju rasti prenosa podatkov načrtujemo 250 transakcij, zato nas zelo zanima Tarantool.
Na prejšnji sliki so domene, kjer bomo uporabljali Tarantool. Sam CRM je seveda širši in ga bomo uporabili v samem jedru.
Naša ocenjena številka TTX 100 milijonov naročnikov me kot arhitekta zmede – kaj če 101 milijon? Ali morate vse ponoviti? Da do tega ne pride, uporabljamo predpomnilnike, hkrati pa povečujemo dostopnost.
Na splošno obstajata dva pristopa za uporabo Tarantoola. prvi - zgradite vse predpomnilnike na ravni mikrostoritve. Kolikor razumem, VimpelCom sledi tej poti in ustvarja predpomnilnik strank.
Manj smo odvisni od prodajalcev, spreminjamo jedro BSS, tako da imamo eno odjemalsko datoteko takoj po izdelavi. Vendar ga želimo razširiti. Zato imamo nekoliko drugačen pristop - ustvariti predpomnilnike znotraj sistemov.
Na ta način je manj sinhronizacije – en sistem je odgovoren tako za predpomnilnik kot za glavni glavni vir.
Metoda se dobro ujema s pristopom Tarantool s transakcijskim skeletom, ko se posodabljajo samo deli, ki se nanašajo na posodobitve, torej spremembe podatkov. Vse ostalo lahko shranite kam drugam. Ni velikega podatkovnega jezera, neupravljanega globalnega predpomnilnika. Predpomnilniki so zasnovani za sistem, ali za izdelke, ali za stranke ali za olajšanje življenja pri vzdrževanju. Ko naročnik kliče in je razburjen nad kakovostjo vaše storitve, želite zagotoviti kakovostno storitev.
RTO in RPO
V IT obstajata dva izraza - RTO и RPO.
Ciljni čas okrevanja je čas, potreben za obnovitev storitve po okvari. RTO = 0 pomeni, da tudi če nekaj ne uspe, storitev še naprej deluje.
Cilj točke obnovitve - to je čas obnovitve podatkov, koliko podatkov lahko izgubimo v določenem časovnem obdobju. RPO = 0 pomeni, da ne izgubljamo podatkov.
Tarantool naloga
Poskusimo rešiti težavo za Tarantool.
dano: košarica aplikacij, ki jih razume vsak, na primer v Amazonu ali kje drugje. Zahtevano tako da nakupovalna košarica deluje 24 ur 7 dni v tednu oziroma 99,99% časa. Naročila, ki prihajajo k nam, morajo ostati urejena, saj ne moremo naključno vklopiti ali izklopiti naročniške povezave - vse mora biti strogo usklajeno. Prejšnja naročnina vpliva na naslednjo, zato so podatki pomembni - nič ne sme manjkati.
odločitev. Lahko ga poskusite neposredno rešiti in vprašate razvijalce baze podatkov, vendar problema ni mogoče rešiti matematično. Lahko se spomnite izrekov, ohranitvenih zakonov, kvantne fizike, ampak zakaj – tega se ne da rešiti na ravni DB.
Tukaj deluje stari dobri arhitekturni pristop - predmet morate dobro poznati in z njim rešiti to uganko.
Naša rešitev: izdelava porazdeljenega registra aplikacij na Tarantool - geo-razdeljena gruča. V diagramu so to trije različni centri za obdelavo podatkov - dva pred Uralom, eden onkraj Urala in vse zahteve razdelimo med te centre.
Netflix, ki danes velja za enega vodilnih v IT, je imel do leta 2012 le en podatkovni center. Na predvečer katoliškega božiča, 24. decembra, je ta podatkovni center odpovedal. Uporabniki v Kanadi in ZDA so ostali brez svojih najljubših filmov, bili zelo razburjeni in o tem pisali na družbenih omrežjih. Netflix ima zdaj tri podatkovne centre na zahodno-vzhodni obali in enega v zahodni Evropi.
Na začetku gradimo geografsko porazdeljeno rešitev - toleranca napak nam je pomembna.
Torej imamo gručo, kaj pa RPO = 0 in RTO = 0? Rešitev je preprosta, odvisno od predmeta.
Kaj je pomembno pri aplikacijah? Dva dela: metanje na koš TO odločanje o nakupu in NAKON. Del DO v telekomu se običajno imenuje zajem naročila ali pogajanja o naročilu. Pri telekomu je to lahko veliko težje kot v spletni trgovini, saj je tam treba stranko ustreči, ji ponuditi 5 možnosti in vse to traja nekaj časa, a je košarica napolnjena. V tem trenutku je okvara možna, vendar ni strašljiva, saj se dogaja interaktivno pod človeškim nadzorom.
Če moskovski podatkovni center nenadoma odpove, bomo s samodejnim preklopom na drug podatkovni center nadaljevali z delom. Teoretično se en izdelek lahko izgubi v košarici, vendar ga vidite, znova dodate v košarico in nadaljujete z delom. V tem primeru je RTO = 0.
V istem trenutku obstaja še druga možnost: ko kliknemo na »pošlji«, želimo, da se podatki ne izgubijo. Od tega trenutka naprej začne delovati avtomatizacija - to je RPO = 0. Če uporabimo ta dva različna vzorca, bi lahko v enem primeru šlo preprosto za geografsko porazdeljeno gručo z enim preklopljivim glavnim, v drugem primeru pa za nekakšen zapis kvoruma. Vzorci so lahko različni, vendar rešimo težavo.
Nadalje, če imamo razpršen register aplikacij, ga lahko tudi skaliramo - imamo veliko dispečerjev in izvajalcev, ki dostopajo do tega registra.
Cassandra in Tarantool skupaj
Obstaja še en primer - "vitrina bilanc". Tu je zanimiv primer skupne uporabe Cassandre in Tarantoola.
Cassandro uporabljamo, ker 2 milijardi klicev na dan nista omejitev in jih bo še več. Tržniki zelo radi obarvajo promet po virih, na družbenih omrežjih se na primer pojavlja vedno več podrobnosti. Vse to prispeva k zgodbi.
Cassandra vam omogoča vodoravno skaliranje na poljubno velikost.
S Cassandro se počutimo udobno, vendar ima eno težavo - ni dobra pri branju. Na posnetku je vse OK, 30 na sekundo ni problem - težava z branjem.
Zato se je pojavila tema s predpomnilnikom, hkrati pa smo rešili sledečo težavo: obstaja stari tradicionalni primer, ko pride oprema iz stikala iz spletnega obračunavanja v datoteke, ki jih naložimo v Cassandro. S težavo zanesljivega prenosa teh datotek smo se ubadali tudi po nasvetu IBM managerja za prenos datotek - obstajajo rešitve, ki učinkovito upravljajo prenos datotek, na primer z uporabo protokola UDP in ne TCP. To je dobro, vendar je še nekaj minut in še nismo naložili vsega, operater v klicnem centru ne more odgovoriti stranki, kaj se je zgodilo z njegovim stanjem - počakati moramo.
Da do tega ne bi prišlo, smo uporabljamo vzporedno funkcionalno rezervo. Ko pošljemo dogodek preko Kafke v Tarantool, preračunavanje agregatov v realnem času, na primer za danes, dobimo stanja gotovine, ki lahko prenaša stanja s katero koli hitrostjo, na primer 100 tisoč transakcij na sekundo in te iste 2 sekundi.
Cilj je, da po opravljenem klicu v 2 sekundah v vašem osebnem računu ne bo samo spremenjeno stanje, ampak tudi informacija o tem, zakaj se je spremenilo.
Zaključek
To so bili primeri uporabe Tarantoola. Zelo nam je bila všeč odprtost Mail.ru in njihova pripravljenost obravnavati različne primere.
Svetovalci iz BCG ali McKinsey, Accenture ali IBM nas že zdaj težko presenetijo s čim novim - veliko tega, kar ponujajo, bodisi že počnemo, smo naredili ali nameravamo narediti. Mislim, da bo Tarantool zavzel svoje pravo mesto v našem tehnološkem nizu in bo nadomestil številne obstoječe tehnologije. Smo v aktivni fazi razvoja tega projekta.
Poročilo Olega in Andreja je eno najboljših lanskoletne konference Tarantool, 17. junija pa bo Oleg Ivlev govoril na s poročilom . Alexander Deulin bo predstavil tudi MegaFon . Ugotovimo, kaj se je spremenilo, kateri načrti so bili uresničeni. Pridružite se – konferenca je brezplačna, vse kar morate storiti je . Vse in program konference je oblikovan: novi primeri, nove izkušnje pri uporabi Tarantool-a, arhitektura, enterprise, tutoriali in mikrostoritve.
Vir: www.habr.com