Per què una corporació com MegaFon necessita Tarantool en la facturació? Des de l'exterior sembla que el venedor sol venir, porta alguna mena de caixa gran, connecta l'endoll a la presa, i això és facturar! Això va ser abans, però ara és arcaic, i aquests dinosaures ja s'han extingit o s'estan extingint. Inicialment, la facturació és un sistema per emetre factures: una màquina de comptar o calculadora. En les telecomunicacions modernes això és sistema d'automatització per a tot el cicle de vida d'interacció amb un abonat des de la conclusió d'un contracte fins a la seva resolució, inclosa la facturació en temps real, l'acceptació de pagaments i molt més. La facturació a les empreses de telecomunicacions és com un robot de combat: gran, potent i carregat d'armes.
Què hi té a veure Tarantool? En parlaran Oleg Ivlev и Andrei Knyazev. Oleg és l'arquitecte en cap de l'empresa Amb una àmplia experiència treballant en empreses estrangeres, Andrey és director de sistemes empresarials. A partir de la transcripció del seu informe aprendràs per què es necessita R+D a les corporacions, què és Tarantool, com l'atzucac de l'escala vertical i la globalització es van convertir en els requisits previs per a l'aparició d'aquesta base de dades a l'empresa, sobre els reptes tecnològics, la transformació arquitectònica i com el technostack de MegaFon és similar a Netflix. , Google i Amazon.
Projecte "Facturació unificada"
El projecte en qüestió s'anomena "Facturació unificada". Va ser aquí on Tarantool va mostrar les seves millors qualitats.
El creixement de la productivitat dels equips Hi-End no va seguir el ritme del creixement de la base d'abonats i el creixement del nombre de serveis; s'esperava un major creixement del nombre d'abonats i serveis a causa de les característiques de M2M, IoT i sucursals. a un deteriorament del temps de comercialització. L'empresa va decidir crear un sistema empresarial unificat amb una arquitectura modular única de classe mundial, en lloc dels 8 sistemes de facturació diferents actuals.
MegaFon són vuit empreses en una. El 2009, es va completar la reorganització: les sucursals de tota Rússia es van fusionar en una única empresa, MegaFon OJSC (ara PJSC). Així, l'empresa disposa de 8 sistemes de facturació amb les seves pròpies solucions “personalitzades”, característiques d'oficina i diferents estructures organitzatives, informàtica i màrqueting.
Tot va anar bé fins que vam haver de llançar un producte federal comú. Aquí van sorgir moltes dificultats: per a alguns, els aranzels s'arrodonien cap amunt, per a altres s'arrodonien per avall i per a altres, basant-se en la mitjana aritmètica. Hi ha milers d'aquests moments.
Malgrat que només hi havia una versió del sistema de facturació, un proveïdor, la configuració va divergir tant que va trigar molt de temps a muntar-la. Vam intentar reduir-ne el nombre i vam trobar un segon problema que coneixen moltes empreses.
Escalat vertical. Fins i tot el maquinari més fantàstic d'aquell moment no va satisfer les necessitats. Vam utilitzar equips Hewlett-Packard de la línia Superdome Hi-End, però no va satisfer les necessitats de ni tan sols dues sucursals. Volia una escala horitzontal sense grans costos operatius i inversions de capital.
Expectació de creixement del nombre d'abonats i serveis. Els consultors fa temps que porten històries sobre IoT i M2M al món de les telecomunicacions: arribarà el moment en què cada telèfon i planxa tindran una targeta SIM i dues a la nevera. Avui tenim un nombre de subscriptors, però en un futur proper n'hi haurà molts més.
Reptes tecnològics
Aquests quatre motius ens van motivar a fer canvis seriosos. Hi havia una opció entre actualitzar el sistema i dissenyar des de zero. Vam pensar durant molt de temps, vam prendre decisions serioses, vam fer licitacions. Com a resultat, vam decidir dissenyar des del principi i vam assumir reptes interessants: reptes tecnològics.
Escalabilitat
Si ho era abans, diguem-ne, diguem-ne 8 factures per a 15 milions de subscriptors, i ara hauria d'haver funcionat 100 milions de subscriptors i més - la càrrega és un ordre de magnitud superior.
Ens hem tornat comparables en escala a grans jugadors d'Internet com Mail.ru o Netflix.
Però el moviment addicional per augmentar la càrrega i la base de subscriptors ens ha plantejat seriosos reptes.
Geografia del nostre vast país
Entre Kaliningrad i Vladivostok 7500 km i 10 zones horàries. La velocitat de la llum és finita i a aquestes distàncies els retards ja són importants. 150 ms als canals òptics moderns més fantàstics són massa per a la facturació en temps real, sobretot perquè ara ho són a les telecomunicacions a Rússia. A més, cal actualitzar en un dia laborable, i amb diferents zones horàries això és un problema.
No només oferim serveis per una quota de subscripció, tenim tarifes complexes, paquets i diversos modificadors. Hem de no només permetre o negar que l'abonat parli, sinó que li donem una quota determinada: calculeu les trucades i les accions en temps real perquè no se n'adoni.
falta de tolerància
Aquesta és l'altra cara de la centralització.
Si recollim tots els subscriptors en un sol sistema, qualsevol esdeveniment d'emergència i desastre serà desastrosos per a les empreses. Per això, dissenyem el sistema de manera que s'elimini l'impacte dels accidents en tota la base d'abonats.
Això és de nou una conseqüència de la negativa a escalar verticalment. Quan vam escalar horitzontalment, vam augmentar el nombre de servidors de centenars a milers. S'han de gestionar i intercanviar, fer una còpia de seguretat automàtica de la infraestructura informàtica i restaurar el sistema distribuït.
Ens hem enfrontat a reptes tan interessants. Vam dissenyar el sistema, i en aquell moment vam intentar trobar les millors pràctiques globals per comprovar com de tendència estem, fins a quin punt seguim les tecnologies avançades.
Experiència mundial
Sorprenentment, no hem trobat ni una sola referència a les telecomunicacions globals.
Europa ha caigut pel que fa al nombre d'abonats i l'escala, els EUA - pel que fa a la planitud de les seves tarifes. Vam mirar alguns a la Xina i vam trobar alguns a l'Índia i vam contractar especialistes de Vodafone India.
Per analitzar l'arquitectura, vam muntar un Dream Team liderat per IBM, arquitectes de diferents camps. Aquestes persones podien avaluar adequadament el que estàvem fent i aportar certs coneixements a la nostra arquitectura.
Escala
Uns quants números per il·lustrar.
Dissenyem el sistema per 80 milions de subscriptors amb una reserva de mil milions. Així és com eliminem els llindars futurs. Això no és perquè anem a fer-nos càrrec de la Xina, sinó per l'atac de l'IoT i M2M.
300 milions de documents processats en temps real. Tot i que tenim 80 milions de subscriptors, treballem tant amb clients potencials com amb els que ens han deixat si necessitem cobrar. Per tant, els volums reals són notablement més grans.
2 milions de transaccions El saldo canvia diàriament: aquests són pagaments, càrrecs, trucades i altres esdeveniments. 200 TB de dades estan canviant activament, canvia una mica més lentament 8 PB de dades, i això no és un arxiu, sinó dades en directe en una única facturació. Escala per centre de dades - 5 mil servidors en 14 llocs.
Pila de tecnologia
Quan vam planificar l'arquitectura i vam començar a muntar el sistema, vam importar les tecnologies més interessants i avançades. El resultat és una pila de tecnologia familiar per a qualsevol jugador d'Internet i corporacions que fabriquen sistemes d'alta càrrega.
La pila és similar a la d'altres jugadors importants: Netflix, Twitter, Viber. Consta de 6 components, però el volem escurçar i unificar.
La flexibilitat és bona, però en una gran corporació no hi ha manera sense unificació.
No canviarem el mateix Oracle per Tarantool. En les realitats de les grans empreses, això és una utopia, o una croada durant 5-10 anys amb un resultat poc clar. Però Cassandra i Couchbase es poden substituir fàcilment per Tarantool, i això és el que estem lluitant.
Per què Tarantool?
Hi ha 4 criteris senzills per què hem escollit aquesta base de dades.
Accelerar. Hem realitzat proves de càrrega en sistemes industrials MegaFon. Tarantool va guanyar: va mostrar el millor rendiment.
Això no vol dir que altres sistemes no compleixin les necessitats de MegaFon. Les solucions de memòria actuals són tan productives que les reserves de l'empresa són més que suficients. Però ens interessa tractar amb un líder, i no amb algú que s'està endarrerint, inclòs en la prova de càrrega.
Tarantool cobreix les necessitats de l'empresa fins i tot a llarg termini.
Cost TCO. El suport de Couchbase als volums de MegaFon costa quantitats astronòmiques de diners, però amb Tarantool la situació és molt més agradable i tenen una funcionalitat similar.
Una altra característica agradable que va influir lleugerament en la nostra elecció és que Tarantool funciona millor amb la memòria que altres bases de dades. Ell mostra màxima eficiència.
Fiabilitat. MegaFon inverteix en fiabilitat, probablement més que ningú. Així, quan vam mirar Tarantool, ens vam adonar que havíem de fer-lo complir amb els nostres requisits.
Vam invertir el nostre temps i les nostres finances, i juntament amb Mail.ru vam crear una versió empresarial, que ara s'utilitza en diverses altres empreses.
Tarantool-empresa ens va satisfer completament en termes de seguretat, fiabilitat i registre.
Associació
El més important per a mi és contacte directe amb el desenvolupador. Això és exactament amb el que van subornar els nois de Tarantool.
Si et trobes amb un jugador, sobretot un que treballa amb un client d'ancoratge, i dius que necessites la base de dades per poder fer això, això i això, normalment respon:
- D'acord, posa els requisits al fons d'aquesta pila; algun dia, probablement els arribarem.
Molts tenen un full de ruta per als propers 2-3 anys, i és gairebé impossible integrar-s'hi, però els desenvolupadors de Tarantool captiven amb la seva obertura, i no només des de MegaFon, i adapten el seu sistema al client. És xulo i ens agrada molt.
On hem utilitzat Tarantool
Utilitzem Tarantool en diversos elements. El primer està al pilot, que vam fer al sistema de directoris d'adreces. En un moment volia que fos un sistema semblant a Yandex.Maps i Google Maps, però va resultar una mica diferent.
Per exemple, el catàleg d'adreces a la interfície de vendes. A Oracle, la cerca de l'adreça desitjada triga entre 12 i 13 segons. - números incòmodes. Quan canviem a Tarantool, substituïm Oracle per una altra base de dades a la consola i fem la mateixa cerca, obtenim una velocitat de 200 vegades! La ciutat apareix després de la tercera lletra. Ara estem adaptant la interfície perquè això passi després de la primera. Tanmateix, la velocitat de resposta és completament diferent: mil·lisegons en lloc de segons.
La segona aplicació és un tema de moda anomenat IT de dues velocitats. Això és perquè consultors de tots els racons diuen que les corporacions haurien d'anar-hi.
Hi ha una capa d'infraestructura, per sobre hi ha dominis, per exemple, un sistema de facturació com una telecomunicació, sistemes corporatius, informes corporatius. Aquest és el nucli que no cal tocar. Això és, és clar, és possible, però paranoicament assegurant la qualitat, perquè aporta diners a la corporació.
A continuació ve la capa de microserveis, el que diferencia l'operador o un altre jugador. Els microserveis es poden crear ràpidament a partir de determinades memòria cau, aportant-hi dades de diferents dominis. Aquí camp per a experiments — si alguna cosa no funcionava, tancava un microservei i en obriria un altre. Això proporciona realment un major temps de llançament al mercat i augmenta la fiabilitat i la velocitat de l'empresa.
Els microserveis són potser el paper principal de Tarantool a MegaFon.
On pensem utilitzar Tarantool
Si comparem el nostre projecte de facturació d'èxit amb els programes de transformació de Deutsche Telekom, Svyazcom, Vodafone India, és sorprenentment dinàmic i creatiu. En el procés d'implementació d'aquest projecte, no només es van transformar MegaFon i la seva estructura, sinó que també va aparèixer l'empresa Tarantool a Mail.ru i el nostre proveïdor Nexign (abans Peter-Service) - BSS Box (una solució de facturació en caixa).
Aquest és, en cert sentit, un projecte històric per al mercat rus. Es pot comparar amb el que es descriu al llibre "The Mythical Man-Month" de Frederick Brooks. Aleshores, als anys 60, IBM va contractar 360 persones per desenvolupar el nou sistema operatiu OS/5 per a mainframes. Tenim menys: 000, però els nostres són d'armilles, i tenint en compte l'ús de codi obert i els nous enfocaments, treballem de manera més productiva.
A continuació es mostren els dominis de facturació o, de manera més àmplia, els sistemes empresarials. La gent de l'empresa coneix molt bé el CRM. Tothom ja hauria de tenir altres sistemes: Open API, API Gateway.
Obriu l'API
Vegem de nou els números i com funciona l'API oberta actualment. La seva càrrega és 10 transaccions per segon. Com que tenim previst desenvolupar activament la capa de microserveis i crear l'API pública de MegaFon, esperem un creixement més gran en el futur en aquesta part. Definitivament hi haurà 100 transaccions.
No sé si ens podem comparar amb Mail.ru en SSO: els nois semblen tenir 1 de transaccions per segon. La seva solució és molt interessant per a nosaltres i tenim previst adoptar la seva experiència, per exemple, fer una còpia de seguretat SSO funcional amb Tarantool. Ara els desenvolupadors de Mail.ru ho estan fent per nosaltres.
CRM
CRM són els mateixos 80 milions de subscriptors que volem augmentar fins als mil milions, perquè ja hi ha 300 milions de documents que inclouen una història de tres anys. Tenim moltes ganes de nous serveis i aquí El punt de creixement són els serveis connectats. Aquesta és una pilota que creixerà, perquè cada cop hi haurà més serveis. En conseqüència, necessitarem una història; no ens volem ensopegar amb això.
Facturació a si mateixa pel que fa a l'emissió de factures, treballant amb els comptes a cobrar dels clients transformat en un domini separat. Per millorar el rendiment, Patró arquitectònic d'arquitectura de domini aplicat.
El sistema es divideix en dominis, es distribueix la càrrega i es garanteix la tolerància a errors. A més, hem treballat amb arquitectura distribuïda.
Tota la resta són solucions a nivell empresarial. A l'emmagatzematge de trucades - 2 milions per dia, 60 milions al mes. De vegades cal comptar-los en un mes, i és millor ràpidament. Seguiment financer - són exactament els mateixos 300 milions que creixen i creixen constantment: els abonats sovint corren entre operadors, augmentant aquesta part.
El component més de telecomunicacions de les comunicacions mòbils és facturació en línia. Aquests són els sistemes que permeten trucar o no trucar, prendre decisions en temps real. Aquí la càrrega és de 30 transaccions per segon, però tenint en compte el creixement de la transferència de dades, planifiquem 250 transaccions, i per tant estem molt interessats en Tarantool.
La imatge anterior són els dominis on utilitzarem Tarantool. El propi CRM, per descomptat, és més ampli i el farem servir al nucli.
La nostra xifra estimada de TTX de 100 milions de subscriptors em confon com a arquitecte: i si 101 milions? Has de tornar a fer-ho tot? Per evitar que això passi, utilitzem memòria cau, alhora que augmentem l'accessibilitat.
En general, hi ha dos enfocaments per utilitzar Tarantool. Primer - crear totes les memòria cau a nivell de microservei. Pel que tinc entès, VimpelCom segueix aquest camí, creant una memòria cau de clients.
Depenem menys dels venedors, estem canviant el nucli BSS, de manera que tenim un únic fitxer de client des de la caixa. Però volem ampliar-lo. Per tant, adoptem un enfocament lleugerament diferent: fer memòria cau dins dels sistemes.
D'aquesta manera hi ha menys sincronització: un sistema és responsable tant de la memòria cau com de la font principal principal.
El mètode encaixa bé amb l'enfocament de Tarantool amb un esquelet transaccional, quan només s'actualitzen les parts relacionades amb les actualitzacions, és a dir, els canvis de dades. Tota la resta es pot emmagatzemar en un altre lloc. No hi ha un gran llac de dades, una memòria cau global no gestionada. Els cachés estan dissenyats per al sistema, o per als productes, o per als clients, o per facilitar la vida del manteniment. Quan un subscriptor truca i està molest per la qualitat del vostre servei, voleu oferir un servei de qualitat.
RTO i RPO
Hi ha dos termes en TI: OTR и RPO.
Objectiu de temps de recuperació és el temps que triga a restaurar el servei després d'una fallada. RTO = 0 significa que fins i tot si alguna cosa falla, el servei continua funcionant.
Objectiu del punt de recuperació - aquest és el temps de recuperació de dades, quantes dades podem perdre durant un període de temps determinat. RPO = 0 significa que no estem perdent dades.
Tasca de Tarantool
Intentem resoldre un problema per a Tarantool.
Donat: una cistella d'aplicacions que tothom entén, per exemple, a Amazon o en un altre lloc. Obligatori de manera que el carretó de la compra funciona les 24 hores els 7 dies de la setmana, o el 99,99% del temps. Les comandes que ens arriben han de mantenir-se en ordre, perquè no podem activar o desactivar aleatòriament la connexió del subscriptor; tot ha de ser estrictament coherent. La subscripció anterior afecta a la següent, de manera que les dades són importants: no hi hauria de perdre res.
decisió. Podeu provar de resoldre-ho directament i preguntar als desenvolupadors de bases de dades, però el problema no es pot resoldre matemàticament. Podeu recordar teoremes, lleis de conservació, física quàntica, però per què no es pot resoldre a nivell de DB.
El bon enfocament arquitectònic antic funciona aquí: cal conèixer bé l'àrea temàtica i utilitzar-la per resoldre aquest trencaclosques.
La nostra solució: crear un registre distribuït d'aplicacions a Tarantool, un clúster geodistribuït. Al diagrama, es tracta de tres centres de processament de dades diferents: dos abans dels Urals, un més enllà dels Urals, i distribuïm totes les sol·licituds entre aquests centres.
Netflix, que ara es considera un dels líders en TI, només tenia un centre de dades fins al 2012. La vigília del Nadal catòlic, el 24 de desembre, aquest centre de dades va caure. Els usuaris del Canadà i els EUA es van quedar sense les seves pel·lícules preferides, es van mostrar molt molests i van escriure sobre això a les xarxes socials. Netflix té ara tres centres de dades a la costa oest-est i un a l'oest d'Europa.
Inicialment estem construint una solució geodistribuïda; la tolerància a fallades és important per a nosaltres.
Així doncs, tenim un clúster, però què passa amb RPO = 0 i RTO = 0? La solució és senzilla, segons el tema.
Què és important en les aplicacions? Dues parts: Llançament de cistella TO prendre una decisió de compra, i DESPRÉS. La part DO en telecomunicacions se sol anomenar captura d'ordres o negociació d'ordres. En telecomunicacions, això pot ser molt més difícil que en una botiga online, perquè allà s'ha d'atendre el client, oferir 5 opcions, i tot això passa durant un temps, però la cistella s'omple. En aquest moment, un fracàs és possible, però no fa por, perquè passa de manera interactiva sota supervisió humana.
Si el centre de dades de Moscou falla de sobte, canviarem automàticament a un altre centre de dades, continuarem treballant. En teoria, un producte es pot perdre al carretó, però el veus, afegiu-lo de nou al carretó i continueu treballant. En aquest cas, RTO = 0.
Al mateix moment, hi ha una segona opció: quan fem clic a "enviar", volem que no es perdin les dades. A partir d'aquest moment, l'automatització comença a funcionar: això és RPO = 0. Utilitzant aquests dos patrons diferents, en un cas podria ser simplement un clúster geodistribuït amb un mestre commutable, en un altre cas una mena de registre de quòrum. Els patrons poden variar, però solucionem el problema.
A més, tenint un registre distribuït d'aplicacions, també podem escalar-ho tot: tenim molts despatxadors i executors que accedeixen a aquest registre.
Cassandra i Tarantool junts
Hi ha un altre cas - "aparador de saldos". Aquí teniu un cas interessant de l'ús conjunt de Cassandra i Tarantool.
Utilitzem Cassandra perquè 2 milions de trucades al dia no és el límit, i n'hi haurà més. Als màrquetings els encanta pintar el trànsit per font; cada cop apareixen més detalls a les xarxes socials, per exemple. Tot s'afegeix a la història.
Cassandra us permet escalar horitzontalment a qualsevol mida.
Ens sentim còmodes amb Cassandra, però té un problema: no és bo per llegir. Tot està bé a la gravació, 30 per segon no és un problema - problema de lectura.
Per tant, va aparèixer un tema amb una memòria cau i, al mateix temps, vam resoldre el següent problema: hi ha un vell cas tradicional quan un equip d'un canvi de facturació en línia entra als fitxers que carreguem a Cassandra. Hem lluitat amb el problema de la descàrrega fiable d'aquests fitxers, fins i tot utilitzant els consells de transferència de fitxers del gestor d'IBM: hi ha solucions que gestionen la transferència de fitxers de manera eficient, utilitzant, per exemple, el protocol UDP en lloc de TCP. Això està bé, però encara són uns minuts, i encara no ho hem carregat tot, l'operador del centre de trucades no pot respondre al client què ha passat amb el seu saldo: hem d'esperar.
Per evitar que això passi, nosaltres fem servir la reserva funcional paral·lela. Quan enviem un esdeveniment a Tarantool a través de Kafka, recalculant els agregats en temps real, per exemple, per avui, obtenim saldos d'efectiu, que pot transferir saldos a qualsevol velocitat, per exemple, 100 mil transaccions per segon i aquests mateixos 2 segons.
L'objectiu és que després de fer una trucada, en 2 segons al vostre compte personal no només hi hagi el saldo modificat, sinó informació sobre per què ha canviat.
Conclusió
Aquests eren exemples d'ús de Tarantool. Ens va agradar molt l'obertura de Mail.ru i la seva disposició a considerar diferents casos.
Ja és difícil que els consultors de BCG o McKinsey, Accenture o IBM ens sorprenguin amb alguna cosa nova: gran part del que ofereixen, ja ho fem, ja ho hem fet o tenim previst fer-ho. Crec que Tarantool ocuparà el lloc que li correspon a la nostra pila de tecnologia i substituirà moltes tecnologies existents. Estem en la fase activa de desenvolupament d'aquest projecte.
L'informe d'Oleg i Andrey és un dels millors de la Conferència de Tarantool l'any passat, i el 17 de juny Oleg Ivlev parlarà a amb un informe . Alexander Deulin també farà una presentació de MegaFon . Descobrim què ha canviat, quins plans s'han implementat. Uneix-te: la conferència és gratuïta, tot el que has de fer és ... Tots i s'ha format el programa de conferències: nous casos, nova experiència en l'ús de Tarantool, arquitectura, empresa, tutorials i microserveis.
Font: www.habr.com