Perché una corporation come MegaFon ha bisogno di Tarantool nella fatturazione? Dall'esterno sembra che di solito arrivi un fornitore, porti una grande scatola, colleghi la spina nella presa e voilà, è fatta la fatturazione! Una volta era così, ma ora è un'eresia, e quei dinosauri sono già estinti o stanno scomparendo. Inizialmente, la fatturazione era un sistema per emettere fatture - un contapassi o una calcolatrice. Nei moderni servizi di telecomunicazione, è un sistema di automazione dell'intero ciclo di vita dell'interazione con l'abbonato, dalla stipula del contratto alla risoluzione, inclusa la tarificazione in tempo reale, l'accettazione dei pagamenti e molto altro. La fatturazione nelle compagnie di telecomunicazioni somiglia a un robot da combattimento - grande, potente e armato fino ai denti.
E cosa c'entra Tarantool? Ne parleranno Oleg Ivlev e Andrey Knyazev. Oleg è il chief architect della compagnia con una vasta esperienza in aziende estere, Andrey è il direttore dei sistemi aziendali. Dalla trascrizione della loro relazione alla scoprirete perché è necessario R&D nelle corporation, cos'è Tarantool, come l'impasse della scalabilità verticale e la globalizzazione siano state le premesse per l'emergere di questo DB in azienda, le sfide tecnologiche, la trasformazione dell'architettura, e come la tech stack di MegaFon assomigli a Netflix, Google e Amazon.
Il progetto "Fatturazione Unificata"
Il progetto di cui si parlerà si chiama "Fatturazione Unificata". È proprio in questo che Tarantool ha dimostrato le sue migliori qualità.
La crescita delle prestazioni dell'hardware Hi-End non riusciva a tenere il passo con la crescita del numero di abbonati e dei servizi, si prevedeva una ulteriore crescita del numero di abbonati e servizi grazie a M2M, IoT, e le peculiarità delle filiali portavano a un aggravamento del time-to-market. L'azienda ha deciso di creare un'unica sistema aziendale con un'architettura modulare unica a livello mondiale, in sostituzione delle 8 diverse attuali fatturazioni.
MegaFon è otto aziende in una. Nel 2009 è terminata la riorganizzazione: le filiali in tutta la Russia si sono unite in un'unica azienda OAO "MegaFon" (ora PJSC). Così, nell'azienda sono apparse 8 fatturazioni con le proprie soluzioni "personalizzate", peculiarità delle filiali e diverse strutture organizzative, IT e marketing.
Tutto stava andando bene finché non ci siamo trovati a dover lanciare un prodotto federale comune. Sono emerse molte complessità: alcuni avevano tariffe che arrotondavano per eccesso, altri per difetto, e altri ancora secondo la media aritmetica. Ci sono migliaia di questi aspetti.
Nonostante la versione del sistema di fatturazione sia una, con un solo fornitore, le impostazioni erano così diverse che l'unione richiedeva tempo. Abbiamo cercato di ridurre il loro numero, ma ci siamo imbattuti in un secondo problema, familiare a molte corporazioni.
Scalabilità verticale. Anche l'hardware più avanzato dell'epoca non soddisfaceva le esigenze. Utilizzavamo apparecchiature Hewlett-Packard, della linea Superdome Hi-End, ma non erano sufficienti nemmeno per due filiali. Volevamo una scalabilità orizzontale senza grandi costi operativi e investimenti di capitale.
Aspettativa di crescita del numero di abbonati e servizi. I consulenti avevano da tempo portato nel mondo delle telecomunicazioni storie su IoT e M2M: arriverà il momento in cui ogni telefono e ogni ferro da stiro avrà una SIM, e ogni frigorifero ne avrà due. Oggi abbiamo un certo numero di abbonati, ma nel prossimo futuro saranno di gran lunga di più.
Sfide tecnologiche
Queste quattro ragioni ci hanno spinto a effettuare cambiamenti seri. Avevamo una scelta tra modernizzare il sistema e progettare da zero. Abbiamo riflettuto a lungo, preso decisioni importanti, indetto gare. Alla fine abbiamo deciso di progettare fin dall'inizio e ci siamo messi alla prova con sfide interessanti: sfide tecnologiche.
Scalabilità
Se in passato c'erano, diciamo così, 8 fatturazioni per 15 milioni di abbonati, ora dovevamo ottenere 100 milioni di abbonati e oltre — il carico era di gran lunga superiore.
Siamo diventati comparabili in termini di scala con grandi attori di Internet come Mail.ru o Netflix.
Ma il movimento successivo per aumentare il carico e il numero di abbonati ha posto davanti a noi compiti seri.
La geografia del nostro immenso paese
Tra Kaliningrad e Vladivostok 7500 km e 10 fusi orari. La velocità della luce è finita e a tali distanze i ritardi diventano significativi. 150 ms sui canali ottici più avanzati è troppo per la fatturazione in tempo reale, specialmente per quella attuale nelle telecomunicazioni in Russia. Inoltre, è necessario aggiornarsi in un giorno lavorativo, e con diversi fusi orari questo diventa un problema.
Non offriamo semplicemente servizi con abbonamento, ma abbiamo tariffe complesse, pacchetti e variatori. Non dobbiamo solo permettere o vietare all'abbonato di parlare, ma dargli una certa quota: calcolare le chiamate e le azioni in tempo reale in modo che lui non se ne accorga.
Resilienza
Questo è il rovescio della centralizzazione.
Se raggruppiamo tutti gli abbonati in un unico sistema, qualsiasi evento di emergenza e catastrofe è disastroso per il business. Pertanto, progettiamo il sistema in modo da escludere l'impatto delle emergenze su tutto il bacino di abbonati.
Questo è di nuovo una conseguenza del rifiuto della scalabilità verticale. Quando siamo passati alla scalabilità orizzontale, abbiamo aumentato il numero di server da centinaia a migliaia. Bisogna gestirli e costruire interscambiabilità, riservare automaticamente l'infrastruttura IT e ripristinare il sistema distribuito.
Abbiamo affrontato sfide così interessanti. Abbiamo progettato il sistema e in quel momento abbiamo cercato esperienze di successo a livello mondiale per verificare quanto fossimo in linea con le tendenze e quanto seguissero le tecnologie avanzate.
Esperienza mondiale
Sorprendentemente, ma nel settore delle telecomunicazioni globale non abbiamo trovato alcun riferimento.
L'Europa ha perso in termini di numero di abbonati e di scala, gli Stati Uniti per l'ampiezza delle loro tariffe. Abbiamo esaminato qualcosa in Cina e trovato altro in India, portando esperti da Vodafone India.
Per analizzare l'architettura, abbiamo riunito una Dream Team guidata da IBM - architetti provenienti da vari settori. Queste persone potrebbero valutare in modo adeguato ciò che stiamo facendo e portare nella nostra architettura determinate conoscenze.
Scalabilità
Alcuni numeri per illustrare.
Progettiamo il sistema per 80 milioni di abbonati con un margine per un miliardo. Così rimuoviamo le soglie future. Non perché abbiamo intenzione di conquistare la Cina, ma a causa della pressione dell'IoT e del M2M.
300 milioni di documenti vengono elaborati in tempo reale. Anche se abbiamo 80 milioni di abbonati, lavoriamo anche con clienti potenziali e con coloro che ci hanno lasciato, se è necessario recuperare crediti. Pertanto, i volumi reali sono notevolmente maggiori.
2 miliardi di transazioni cambiano quotidianamente il saldo: si tratta di pagamenti, accrediti, chiamate e altri eventi. 200 TB di dati cambiano attivamente, un po' più lentamente cambiano 8 PB di dati, e non è un archivio, ma dati live in un unico billing. Scalabilità sui datacenter - 5 mila server su 14 siti.
Stack tecnologico
Quando abbiamo pianificato l'architettura e ci siamo messi a costruire il sistema, abbiamo fatto nostro le tecnologie più interessanti e avanzate. È nato uno stack tecnologico, familiare a qualsiasi attore di internet e a corporation che realizzano sistemi ad alta capacità.
Lo stack è simile a quello di altri grandi player: Netflix, Twitter, Viber. È composto da 6 componenti, ma vogliamo ridurlo e unificarlo.
Flessibilità è importante, ma in una grande corporazione senza unificazione non si può andare avanti.
Non abbiamo intenzione di sostituire Oracle con Tarantool. Nella realtà delle grandi aziende è un'utopia, o una crociata di 5-10 anni con un esito incerto. Ma Cassandra e Couchbase possono essere sostituiti con Tarantool, e a questo miriamo.
Perché Tarantool?
Ci sono 4 criteri semplici per cui abbiamo scelto questo DB.
Velocità. Abbiamo condotto test di carico sui sistemi industriali di MegaFon. Tarantool ha vinto - ha mostrato le migliori prestazioni.
Non si può dire che altri sistemi non soddisfano le esigenze di MegaFon. Le attuali soluzioni di memoria sono così performanti che questa riserva è più che sufficiente all'azienda. Ma ci interessa collaborare con un leader, non con chi è in coda, anche in relazione ai test di carico.
Tarantool soddisfa le esigenze dell'azienda anche a lungo termine.
Costo totale di proprietà (TCO). Il supporto per Couchbase sui volumi di MegaFon costa cifre astronomiche, mentre la situazione con Tarantool è molto più favorevole e in termini di funzionalità sono simili.
Un'altra caratteristica piacevole che ha influenzato un po' la nostra scelta - Tarantool lavora meglio delle altre basi con la memoria. Mostra la massima efficienza..
Affidabilità. MegaFon investe nella sicurezza, probabilmente come nessun altro. Quindi, quando abbiamo esaminato Tarantool, abbiamo capito che dovevamo assicurarci che soddisfacesse le nostre esigenze.
Abbiamo investito tempo e denaro, e insieme a Mail.ru abbiamo creato una versione enterprise, già utilizzata in altre aziende.
Tarantool-enterprise ci ha completamente soddisfatti in termini di sicurezza, affidabilità, e log.
Partnership
La cosa più importante per me è il contatto diretto con lo sviluppatore. Questo è esattamente ciò che ci ha conquistati del team di Tarantool.
Se vieni da un giocatore, specialmente uno che lavora con un cliente ancorato, e dici che hai bisogno che il DB sappia fare questo, questo e quest'altro, di solito risponde:
— Va bene, mettete le richieste in fondo a quella pila — prima o poi, probabilmente, ci arriveremo.
Molti hanno una roadmap per i prossimi 2-3 anni, e integrarsi lì dentro è praticamente impossibile, mentre gli sviluppatori di Tarantool conquistano con la loro apertura, sia con MegaFon che con altri, e adattano il loro sistema per il cliente. Questo è fantastico, e ci piace molto.
Dove abbiamo applicato Tarantool
Da noi Tarantool viene utilizzato in diversi elementi. Il primo è nel pilota, che abbiamo creato sul sistema del catalogo indirizzi. Volevamo che fosse un sistema simile a Yandex.Maps e Google Maps, ma è venuto fuori in modo diverso.
Per esempio, il catalogo indirizzi nell'interfaccia di vendita. Su Oracle la ricerca di un indirizzo richiede 12-13 secondi — cifre poco confortanti. Quando ci spostiamo su Tarantool, sostituiamo Oracle con un altro DB nella console e facciamo la stessa ricerca, otteniamo un'accelerazione di 200 volte! La città compare dopo la terza lettera. Ora stiamo adattando l'interfaccia affinché questo avvenga dopo la prima. Tuttavia, la velocità di risposta è completamente diversa — già millisecondi invece di secondi.
La seconda applicazione è un argomento di moda chiamato IT a due velocità. Tutto perché i consulenti da ogni parte dicono che le corporazioni dovrebbero andarci.
C'è uno strato di infrastruttura, sopra ci sono i domini, ad esempio, un sistema di billing, come quello delle telecomunicazioni, sistemi aziendali, reportistica aziendale. Questo è il nucleo, che non bisogna toccare. Cioè, certo, si può fare, ma con un'ossessione paranoica per garantire la qualità, perché questo porta soldi alle corporazioni.
Poi c'è uno strato di microservizi — ciò che differenzia l'operatore o un altro giocatore. I microservizi possono essere creati rapidamente sulla base di alcune cache, portando i dati da diversi domini. Qui c'è un campo per esperimenti — se qualcosa non funziona, chiudi un microservizio e apri un altro. Questo garantisce un time-to-market realmente aumentato e incrementa l'affidabilità e la velocità dell'azienda.
I microservizi sono, probabilmente, il ruolo principale di Tarantool in MegaFon.
Dove prevediamo di applicare Tarantool
Se paragoniamo il nostro progetto di billing di successo con i programmi di trasformazione di Deutsche Telekom, Svjazn'kom, Vodafone India, risulta incredibilmente dinamico e creativo. Nel processo di realizzazione di questo progetto non solo è stata trasformata MegaFon e la sua struttura, ma è nato anche Tarantool-enterprise presso Mail.ru, e dal nostro fornitore Nexign (precedentemente "Peterservizi") – BSS Box (soluzione di billing in scatola).
Questo è, in un certo senso, un progetto storico per il mercato russo. Può essere paragonato a quanto descritto nel libro di Frederick Brooks "Il mito dell'uomo mese". Allora, negli anni '60, per sviluppare un nuovo sistema operativo OS/360 per i mainframe, IBM coinvolse 5.000 persone. Noi siamo meno – 1.800, ma i nostri in maglietta a righe, e tenendo conto dell'uso dell'open source e di nuovi approcci, lavoriamo in modo più produttivo.
Di seguito sono riportati i domini di billing o, per dirla in modo più ampio, – sistemi aziendali. Le persone dell'enterprise conoscono perfettamente il CRM. Altri sistemi dovrebbero già essere a disposizione di tutti: Open API, API Gateway.
Open API
Rivediamo di nuovo i numeri e come funziona attualmente l'Open API. Il suo carico è 10.000 transazioni al secondo. Poiché prevediamo di sviluppare attivamente il layer dei microservizi e costruire un API pubblico per MegaFon, ci aspettiamo una maggiore crescita in futuro proprio in questo settore. Sicuramente 100.000 transazioni ci saranno.
Non so se ci confronteremo in SSO con Mail.ru – i ragazzi hanno, a quanto pare, 1.000.000 transazioni al secondo. La loro soluzione è estremamente interessante per noi e prevediamo di apprendere dalla loro esperienza – ad esempio, creare una riserva funzionale SSO con l'aiuto di Tarantool. Attualmente i programmatori di Mail.ru se ne stanno occupando per noi.
CRM
Il CRM sono i famosi 80 milioni di abbonati che vogliamo portare a un miliardo, perché ci sono già 300 milioni di documenti che includono una storia di tre anni. Aspettiamo davvero nuovi servizi, e qui il punto di crescita sono i servizi connessi. Questo è un ambito che crescerà, perché i servizi saranno sempre di più. Di conseguenza, avremo bisogno di una storia, non vogliamo inciampare su questo.
Il billing stesso nella parte di emissione fatture e gestione dei crediti dei clienti si è trasformato in un dominio separato. Per aumentare la produttività, è stato applicato un modello architetturale di architettura a dominio.
Il sistema è suddiviso in domini, il carico è distribuito e garantita la disponibilità. Inoltre, sono stati effettuati interventi sull'architettura distribuita.
Tutto il resto è costituito da soluzioni di livello enterprise. Nel database delle chiamate - 2 miliardi al giorno, 60 miliardi al mese. A volte è necessario ricalcolarli per mese, e meglio farlo rapidamente. Monitoraggio finanziario è proprio l'insieme di 300 milioni che cresce costantemente: gli abbonati spesso passano da un operatore all'altro, aumentando questa parte.
Il componente più telecomunicativo della telefonia mobile è la tariffazione online. Questi sono i sistemi che ti permettono di chiamare o meno, prendendo decisioni in tempo reale. Qui il carico è di 30.000 transazioni al secondo, ma tenendo conto della crescita della trasmissione dati, prevediamo 250.000 transazioni, ed è per questo che siamo molto interessati a Tarantool.
L'immagine precedente mostra i domini in cui intendiamo applicare Tarantool. L'intero CRM, ovviamente, è più ampio e intendiamo applicarlo nel nucleo stesso.
La nostra cifra programmata TTH di 100 milioni di abbonati preoccupa me come architetto: e se fossero 101 milioni? Di nuovo tutto da rifare? Per evitare ciò, utilizziamo cache, aumentando al contempo la disponibilità.
Fondamentalmente, ci sono due approcci all'applicazione di Tarantool. Il primo è costruire tutte le cache a livello di microservizi. A quanto pare, su questa strada sta procedendo VimpelCom, creando cache per i clienti.
Noi, invece, siamo meno dipendenti dai fornitori, cambiamo il nucleo BSS, quindi abbiamo una scheda clienti già di serie. Ma vogliamo ampliare questo. Pertanto, applichiamo un approccio leggermente diverso — creiamo cache all'interno dei sistemi.
In questo modo si riduce la desincronizzazione: un sistema si occupa sia della cache che della fonte principale.
Il metodo si adatta bene all'approccio di Tarantool con uno scheletro transazionale, dove vengono aggiornati solo i pezzi relativi agli aggiornamenti, cioè le modifiche ai dati. Tutto il resto può essere conservato altrove. Non ci sono enormi data lake, cache globali incontrollabili. Le cache vengono progettate per il sistema, o per i prodotti, o per i clienti, o per semplificare la vita al servizio. Quando chiama un abbonato frustrato per la qualità, si desidera servirlo in modo efficace.
RTO e RPO
Nel settore IT esistono due termini - RTO e RPO.
Recovery time objective — è il tempo di ripristino del servizio dopo un guasto. RTO = 0 significa che anche se qualcosa va in crash, il servizio continua a funzionare.
obiettivo di punto di ripristino — è il tempo di recupero dei dati, quanta informazione possiamo perdere in un certo periodo di tempo. RPO = 0 significa che non perdiamo dati.
Compito per Tarantool
Proviamo a risolvere il compito per Tarantool.
Dati: un chiaro carrello di ordini, ad esempio, su Amazon o altrove. Richiesta affinché il carrello funzioni 24 ore su 24, 7 giorni su 7, o 99,99% del tempo. Gli ordini che ci arrivano devono mantenere un certo ordine, perché non possiamo attivare o disattivare la connessione al cliente in modo caotico — tutto deve essere rigorosamente sequenziale. L'abbonamento precedente influisce su quello successivo, quindi i dati sono importanti — nulla deve andare perso.
Soluzione. Si potrebbe provare a risolverlo in modo diretto e chiedere ai programmatori del DB, ma il problema non è matematicamente risolvibile. Si possono ricordare teoremi, leggi di conservazione, fisica quantistica, ma perché — non è possibile risolverlo a livello di DB.
Qui funziona il vecchio e caro approccio architetturale — è necessario conoscere bene il dominio per risolvere questo enigma.
La nostra soluzione: creiamo un registro distribuito di richieste su Tarantool — cluster geodistribuito. Nello schema ci sono tre diversi centri di elaborazione dati — due prima degli Urali, uno oltre gli Urali, e distribuiamo tutte le richieste tra questi centri.
Netflix, che ora è considerato uno dei leader nel settore IT, fino al 2012 aveva solo un data center. Alla vigilia del Natale cattolico, il 24 dicembre, quel data center ha smesso di funzionare. Gli utenti in Canada e negli Stati Uniti sono rimasti senza i loro film preferiti, si sono molto rattristati e hanno scritto di questo sui social media. Ora Netflix ha tre data center sulla costa occidentale-orientale e uno in Europa occidentale.
Iniziamo a costruire una soluzione geodistribuita — la resilienza è importante per noi.
Quindi, abbiamo un cluster, ma come affrontare RPO = 0 e RTO = 0? La soluzione è semplice, dipende dal dominio.
Cosa è importante nelle richieste? Due parti: la fase di riempimento del carrello PRIMA di prendere una decisione d'acquisto, e DOPO. La parte PRIMA nel telecomunicazioni è solitamente chiamata cattura ordine o negoziazione dell'ordine. Nel settore delle telecomunicazioni, questo può essere molto più complesso rispetto a un negozio online, poiché è necessario assistere il cliente, offrire 5 opzioni, e tutto ciò richiede del tempo, ma il carrello si riempie. In questo momento è possibile un guasto, ma non è un problema, perché si svolge in modalità interattiva sotto la supervisione di una persona.
Se il Data Center di Mosca dovesse improvvisamente guastarsi, passando automaticamente a un altro Data Center, continueremo a lavorare. Teoricamente potrebbe perdersi un prodotto nel carrello, ma lo vedete, potete riempire di nuovo il carrello e continuare a lavorare. In questo caso RTO = 0.
Allo stesso momento, c'è un'altra opzione: quando premiamo 'submit', vogliamo che i dati non vengano persi. Da questo momento viene attivata l'automazione - qui RPO = 0. L'applicazione di questi due diversi modelli in un caso può essere semplicemente un cluster geograficamente distribuito con un master switchable, nell'altro caso potrebbe essere qualche tipo di scrittura quorum. I modelli possono variare, ma risolviamo il problema.
Inoltre, avendo un registro distribuito delle richieste, possiamo anche scalare tutto questo - avere molti dispatcher ed esecutori che si rivolgono a questo registro.
Cassandra e Tarantool insieme
C'è un altro caso - "vetrina dei saldi". Qui c'è proprio un caso interessante di applicazione congiunta di Cassandra e Tarantool.
Utilizziamo Cassandra perché 2 miliardi di chiamate al giorno non sono un limite, e ce ne saranno di più. I marketer amano segmentare il traffico per fonte, emergono sempre più dettagli sui social network, per esempio. Questo aumenta la storia.
Cassandra consente di scalare orizzontalmente a qualsiasi volume.
Ci sentiamo a nostro agio con Cassandra, ma ha un problema: non è buona nella lettura. Nella scrittura tutto va bene, 30.000 al secondo non è un problema - il problema è nella lettura.
Pertanto è emersa la questione della cache, e abbiamo anche deciso di affrontare il seguente problema: esiste un vecchio caso tradizionale, quando i dati dall’online tariffazione del cambiatore arrivano in file, che carichiamo in Cassandra. Abbiamo affrontato il problema dell'affidabilità nel caricamento di questi file, abbiamo persino applicato il consiglio del manager IBM per il trasferimento file - ci sono soluzioni che gestiscono il trasferimento dei file in modo efficiente, utilizzando ad esempio il protocollo UDP, e non TCP. Questo è buono, ma ci vogliono comunque dei minuti, e finché non carichiamo tutto questo, l'operatore nel call center non può rispondere al cliente riguardo a cosa sia successo al suo saldo - bisogna aspettare.
Per evitare che ciò accada, noi utilizziamo un backup funzionale parallelo. Quando inviamo un evento attraverso Kafka a Tarantool, ricalcolando gli aggregati in tempo reale, ad esempio per oggi, otteniamo una cache dei saldi, che può restituire saldi a qualsiasi velocità, ad esempio, 100 mila transazioni al secondo e gli stessi 2 secondi.
L'obiettivo è che dopo aver effettuato una chiamata già dopo 2 secondi nell'area personale non ci sia solo il saldo modificato, ma anche le informazioni su perché sia cambiato.
Conclusione
Questi erano esempi di utilizzo di Tarantool. Ci è piaciuta molto l’apertura di Mail.ru, la loro disponibilità a considerare casi diversi.
Per i consulenti di BCG, McKinsey, Accenture o IBM è già difficile sorprenderci con qualcosa di nuovo: molto di quanto propongono, o lo facciamo già, o l'abbiamo fatto, oppure lo stiamo pianificando. Penso che Tarantool avrà un posto di riguardo nel nostro stack tecnologico e sostituirà molte delle tecnologie già esistenti. Siamo nella fase attiva di sviluppo di questo progetto.
La presentazione di Oleg e Andrey è stata una delle migliori alla Tarantool Conference dello scorso anno, e già il 17 giugno Oleg Ivlev si esibirà alla con una presentazione . Anche da MegaFon parlerà Alexander Deulin con una presentazione . Scopriremo cosa è cambiato, quali piani sono stati realizzati. Unitevi a noi - la conferenza è gratuita, basta solo . Tutti e il programma della conferenza è stato formato: nuovi casi, nuove esperienze di utilizzo di Tarantool, architettura, enterprise, tutorial e microservizi.
Fonte: habr.com
