Perché una corporazione come MegaFon ha bisogno di Tarantool nella fatturazione? Da fuori sembra che un venditore arrivi, porti una grande scatola, colleghi una spina alla presa e voilà, ecco la fatturazione! Un tempo era così, ma ora è un'arcaica, e questi dinosauri sono già estinti o stanno scomparendo. Inizialmente, la fatturazione era un sistema per emettere fatture — un contatore o una calcolatrice. Nel moderno telecomunicazioni, è un sistema per automatizzare l'intero ciclo di vita dell'interazione con l'abbonato, dalla conclusione del contratto fino alla risoluzione, inclusa la tariffazione in tempo reale, l'accettazione dei pagamenti e molto altro. La fatturazione nelle aziende di telecomunicazioni è simile a un robot da combattimento — grande, potente e armato fino ai denti.
Cosa c'entra Tarantool? Questo sarà spiegato da Oleg Ivlev e Andrey Knyazev. Oleg è il principale architetto dell'azienda con una vasta esperienza in aziende estere, Andrey è il direttore dei sistemi aziendali. Dalla trascrizione della loro relazione alla scoprirete perché la ricerca e sviluppo è importante nelle aziende, cos'è Tarantool, come il limite del ridimensionamento verticale e la globalizzazione abbiano dato origine a questo database all'interno dell'azienda, le sfide tecnologiche, la trasformazione dell'architettura, e in che modo la stack tecnologica di MegaFon sia simile a quella di Netflix, Google e Amazon.
Progetto "Unified Billing"
Il progetto di cui parleremo si chiama "Unified Billing". È qui che Tarantool ha dimostrato le sue migliori qualità.
La crescita delle prestazioni delle attrezzature Hi-End non ha tenuto il passo con l'aumento della base di abbonati e il numero di servizi; si prevedeva un ulteriore aumento del numero di abbonati e servizi grazie a M2M, IoT, e le peculiarità delle filiali portavano a un deterioramento del time-to-market. L'azienda ha deciso di creare un sistema commerciale unificato con un'architettura modulare unica di livello mondiale, in sostituzione delle 8 attuali diverse sistemi di fatturazione.
MegaFon è otto aziende in una. Nel 2009 è avvenuta la riorganizzazione: le filiali in tutta Russia si sono unite in un'unica azienda, OAO «MegaFon» (ora PАО). Così, l'azienda ha acquisito 8 sistemi di fatturazione con le proprie soluzioni «custom», caratteristiche filiali e strutture organizzative diverse, IT e marketing.
Tutto andava bene, fino a quando non è stato necessario lanciare un unico prodotto federale. Qui sono emerse una serie di complicazioni: alcune avevano la tariffazione con arrotondamento per eccesso, altre per difetto, e alcune ancora secondo la media aritmetica. Questi aspetti sono migliaia.
Nonostante la versione del sistema di fatturazione fosse una sola, un unico fornitore, le configurazioni erano così diverse che ci è voluto molto tempo per allinearle. Abbiamo cercato di ridurre il loro numero e ci siamo imbattuti in un secondo problema noto a molte aziende.
Scalabilità verticale. Anche l'hardware più all'avanguardia dell'epoca non soddisfaceva le esigenze. Sono stati utilizzati server Hewlett-Packard della linea Superdome Hi-End, ma non riuscivano a supportare nemmeno le necessità di due filiali. Si desiderava uno scaling orizzontale senza grandi costi operativi e investimenti di capitale.
Aspettando la crescita del numero di abbonati e dei servizi. Da tempo i consulenti hanno portato nel mondo delle telecomunicazioni storie su IoT e M2M: arriverà il momento in cui in ogni telefono e ferro da stiro ci sarà una SIM, e nel frigorifero ce ne saranno due. Oggi abbiamo un certo numero di abbonati, e nel prossimo futuro ci saranno molte di più.
Sfide tecnologiche
Queste quattro ragioni ci hanno spinto verso cambiamenti significativi. Abbiamo dovuto scegliere tra modernizzazione del sistema e progettazione da zero. Abbiamo riflettuto a lungo, preso decisioni importanti, e partecipato a gare d'appalto. Alla fine, abbiamo deciso di progettare fin dall'inizio e ci siamo confrontati con sfide interessanti: le sfide tecnologiche.
Scalabilità
Se prima avevamo, diciamo così, 8 sistemi di billing con 15 milioni di abbonati, ora doveva risultare 100 milioni di abbonati e oltre — il carico è considerevolmente maggiore.
Siamo diventati comparabili in scala ai grandi attori di internet, come Mail.ru o Netflix.
Ma il progresso successivo nell'aumento del carico e della base di abbonati ha presentato serie sfide.
La geografia del nostro vasto paese
Tra Kaliningrado e Vladivostok 7500 km e 10 fusi orari. La velocità della luce è finita e a tali distanze i ritardi sono già significativi. 150 ms sui più avanzati canali ottici moderni sono troppi per una tariffazione in tempo reale, specialmente come accade attualmente nel telecomunicazioni in Russia. Inoltre, è necessario aggiornarsi entro un giorno lavorativo e, con diversi fusi orari, questo diventa un problema.
Non offriamo semplicemente servizi a pagamento, ma abbiamo tariffe complesse, pacchetti e diversi modificatori. Dobbiamo non solo autorizzare o vietare a un 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.
Affidabilità
Questo è il rovescio della medaglia della centralizzazione.
Se raggruppiamo tutti gli abbonati in un unico sistema, qualsiasi evento d'emergenza e disastro risulterebbe catastrofico per il business. Pertanto, progettiamo il sistema in modo da escludere l'influenza di incidenti su tutta la base di abbonati.
Questa è nuovamente una conseguenza del rifiuto della scalabilità verticale. Quando siamo passati a una scalabilità orizzontale, abbiamo aumentato il numero di server da centinaia a migliaia. È necessario gestirli e costruire la sostituibilità, riservare automaticamente l'infrastruttura IT e ripristinare il sistema distribuito.
Davanti a noi si sono presentate sfide interessanti. Abbiamo progettato il sistema e in quel momento abbiamo cercato best practice globali per verificare quanto fossimo in linea, quanto seguissero tecnologie all'avanguardia.
Best practice globale
Incredibilmente, ma nel settore telecomunicazioni globale non abbiamo trovato alcun riferimento.
L'Europa è risultata deficitaria in termini di numero di abbonati e scala, mentre gli Stati Uniti per la varietà delle loro tariffe. Abbiamo visto qualcosa in Cina, e abbiamo trovato esperti in India, prendendo specialisti da Vodafone India.
Per l'analisi dell'architettura, abbiamo riunito un Dream Team guidato da IBM - architetti provenienti da diversi settori. Queste persone erano in grado di valutare adeguatamente ciò che stavamo facendo e di portare nella nostra architettura determinate conoscenze.
Scala
Alcuni numeri per illustrare.
Progettiamo il sistema per 80 milioni di abbonati con un margine per un miliardo. In questo modo eliminiamo le future soglie. Non è perché intendiamo conquistare la Cina, ma a causa della spinta dell'IoT e del M2M.
300 milioni di documenti elaborati in tempo reale. Anche se abbiamo 80 milioni di abbonati, lavoriamo anche con i clienti potenziali e con quelli che ci hanno lasciato, se dobbiamo riscuotere crediti. Pertanto i volumi reali sono notevolmente più alti.
2 miliardi di transazioni cambiano il saldo quotidianamente — si tratta di pagamenti, addebiti, chiamate e altri eventi. 200 TB di dati vengono modificati attivamente, cambiano leggermente più lentamente 8 PB di dati, e questi non sono archivio, ma dati vivi in un'unica fatturazione. La scala nei data center è 5.000 server su 14 sedi.
Stack tecnologico
Quando abbiamo pianificato l'architettura e ci siamo messi a costruire il sistema, abbiamo importato le tecnologie più interessanti e avanzate. Ne è risultato uno stack tecnologico, familiare a qualsiasi attore di Internet e alle aziende che realizzano sistemi ad alto carico.
Lo stack è simile a quello di altri grandi attori: Netflix, Twitter, Viber. È composto da 6 componenti, ma vogliamo ridurlo e unificarlo.
La flessibilità è importante, ma in una grande corporazione l'unificazione è essenziale.
Non abbiamo intenzione di sostituire Oracle con Tarantool. Nella realtà delle grandi aziende, questo è utopico, oppure un lungo peregrinaggio di 5-10 anni con esiti incerti. Tuttavia, possiamo sostituire Cassandra e Couchbase con Tarantool, e a questo puntiamo.
Perché Tarantool?
Ci sono 4 semplici criteri per cui abbiamo scelto questo database.
VelocitàAbbiamo condotto test di carico su sistemi industriali di MegaFon. Tarantool ha vinto, dimostrando la migliore performance.
Non si può dire che altri sistemi non soddisfino le esigenze di MegaFon. Le attuali soluzioni in-memory sono così performanti che l'azienda ha abbondanza di risorse. Tuttavia, ci interessa collaborare con un leader, non con chi è in fondo alla classifica, incluso nel test di carico.
Tarantool soddisfa le esigenze dell'azienda anche a lungo termine.
Costo totale di possesso (TCO)Il supporto per Couchbase a questi volumi di MegaFon costa una fortuna, mentre con Tarantool la situazione è molto più favorevole e la funzionalità è simile.
Un'altra piacevole caratteristica, che ha influito sulla nostra scelta, è che Tarantool lavora meglio di altri database con la memoria. Mostra efficienza massima.
Affidabilità. MegaFon investe nella affidabilità, forse come nessun altro. Quindi, quando abbiamo guardato a Tarantool, abbiamo capito che dovevamo fare in modo che soddisfacesse le nostre esigenze.
Abbiamo investito il nostro tempo e le nostre finanze, e insieme a Mail.ru abbiamo creato una versione enterprise che ora è utilizzata in diverse altre aziende.
Tarantool-enterprise ci ha soddisfatti completamente per quanto riguarda sicurezza, affidabilità e registrazione.
Collaborazioni
La cosa più importante per me è il contatto diretto con lo sviluppatore. Questo è ciò che ci ha conquistato del team di Tarantool.
Se vai da un operatore, soprattutto se lavora con un cliente chiave, e dici che hai bisogno di un database in grado di fare questo, questo e quest'altro, di solito risponde:
— Va bene, mettete i requisiti in fondo a quella pila: forse, un giorno, ci arriveremo.
Molti hanno una roadmap per i prossimi 2-3 anni, e integrarsi è praticamente impossibile, mentre gli sviluppatori di Tarantool attraggono grazie alla loro trasparenza, non solo con MegaFon, e adattano il loro sistema alle esigenze del cliente. È fantastico, e ci piace molto.
Dove abbiamo applicato Tarantool
Nel nostro caso, Tarantool viene utilizzato in diversi elementi. Il primo è nel progetto pilota, che abbiamo realizzato sul sistema del catalogo degli indirizzi. Un tempo volevamo che fosse un sistema simile a Yandex.Maps e Google Maps, ma è venuto fuori un po' diverso.
Per esempio, il catalogo degli indirizzi nell'interfaccia di vendita. Su Oracle, la ricerca dell'indirizzo desiderato richiede 12-13 secondi — numeri scomodi. Quando passiamo a Tarantool, sostituendo Oracle con un altro DB nella console e eseguendo la stessa ricerca, otteniamo un'accelerazione di 200 volte! La città appare dopo la terza lettera. Ora stiamo adattando l'interfaccia per fare in modo che ciò avvenga dopo la prima. Tuttavia, la velocità di risposta è completamente diversa — già millisecondi invece di secondi.
Il secondo utilizzo è un tema di moda che si chiama IT a doppia velocità. Tutto ciò perché i consulenti da ogni angolo dicono che le aziende dovrebbero muoversi in questa direzione.
Qui c'è uno strato di infrastruttura, sopra ci sono i domini, per esempio, il sistema di fatturazione, come nel settore delle telecomunicazioni, i sistemi aziendali, la reportistica aziendale. Questo è il nucleo che non deve essere toccato. Cioè, certo, si può fare, ma in modo paranoico assicurando la qualità, perché porta denaro all'azienda.
Successivamente c'è lo strato dei microservizi — ciò che differenzia l'operatore o un altro attore. I microservizi possono essere creati rapidamente sulla base di alcune cache, estraendo dati da vari domini. Qui c'è spazio per esperimenti — se qualcosa non funziona, chiudo un microservizio e ne apro un altro. Questo assicura un reale miglioramento del time-to-market e aumenta l'affidabilità e la velocità dell'azienda.
I microservizi sono, probabilmente, il ruolo principale di Tarantool in MTS.
Dove prevediamo di applicare Tarantool
Se paragoniamo il nostro successo nel progetto di billing con i programmi di trasformazione di Deutsche Telekom, Svyaznoy, Vodafone India, risulta sorprendentemente dinamico e creativo. Durante l'implementazione di questo progetto, non solo è stata trasformata MegaFon e la sua struttura, ma è emersa anche Tarantool-enterprise di Mail.ru, mentre il nostro fornitore Nexign (precedentemente "Peter-Service") ha lanciato BSS Box (una soluzione di billing pronta all'uso).
In un certo senso, questo è un progetto storico per il mercato russo. Può essere paragonato a quanto descritto nel libro di Frederick Brooks "The Mythical Man-Month". All'epoca, negli anni '60, IBM reclutò 5.000 persone per sviluppare il nuovo sistema operativo OS/360 per i mainframe. Noi ne abbiamo meno: 1.800, ma siamo agili, e considerando l'uso dell'open source e nuovi approcci, lavoriamo in modo più produttivo.
Di seguito sono riportati i domini del billing o, per dirla in modo più ampio, dei sistemi business. Le persone nel settore enterprise conoscono bene il CRM. Altri sistemi dovrebbero già essere accessibili a tutti: Open API, API Gateway.
Open API
Rivediamo ancora i numeri e come funziona attualmente Open API. Il suo carico è di 10.000 transazioni al secondo. Poiché prevediamo di sviluppare attivamente il livello dei microservizi e costruire un'API pubblica di Megafon, ci aspettiamo una maggiore crescita in futuro proprio in questo settore. 100.000 transazioni ci saranno sicuramente..
Non so se riusciremo a competere in SSO con Mail.ru — loro hanno circa 1.000.000 di transazioni al secondo. La loro soluzione ci interessa moltissimo e pianifichiamo di adottare la loro esperienza — ad esempio, per realizzare un backup funzionale SSO utilizzando Tarantool. Attualmente, i sviluppatori di Mail.ru se ne stanno occupando per noi.
CRM
CRM — sono quei 80 milioni di abbonati che vogliamo portare a un miliardo, poiché abbiamo già 300 milioni di documenti che includono una storia di tre anni. Ci aspettiamo davvero nuovi servizi e qui la crescita si concentra sui servizi collegati.È una sfera che crescerà sempre di più, perché i servizi aumenteranno. Di conseguenza, avremo bisogno di una storia, non vogliamo inciampare su questo.
La parte di billing relativa alla fatturazione e alla gestione del debito dei clienti si è trasformata in un dominio separato.. Per migliorare le prestazioni, è stato applicato un modello architetturale di architettura a dominio..
Il sistema è suddiviso in domini, il carico è distribuito e garantisce ridondanza. Inoltre, è stato implementato un lavoro con l'architettura distribuita.
Tutto il resto riguarda soluzioni di livello enterprise. Nel nostro sistema di archiviazione delle chiamate — 2 miliardi al giorno, 60 miliardi al mese. A volte dobbiamo ricalcolarli mensilmente, e meglio farlo rapidamente. Monitoraggio finanziario — questi sono proprio i 300 milioni che continuano a crescere: gli abbonati spesso cambiano operatore, alimentando questa parte.
Il componente più tipico delle telecomunicazioni mobili è la tariffazione online. Questi sono i sistemi che permettono di effettuare o meno una chiamata, prendendo decisioni in tempo reale. Qui gestiamo 30.000 transazioni al secondo, ma considerando la crescita del trasferimento dati, prevediamo 250.000 transazioni, e quindi siamo molto interessati a Tarantool.
L'immagine precedente rappresenta i domini in cui prevediamo di applicare Tarantool. Il CRM, ovviamente, è più ampio e intendiamo utilizzarlo nel nucleo stesso.
La nostra cifra stimata del TTH di 100 milioni di utenti mi preoccupa come architetto: e se diventassero 101 milioni? Dovremmo rifare tutto? Per evitare ciò, utilizziamo la cache, aumentando così anche la disponibilità.
Esistono fondamentalmente due approcci all'utilizzo di Tarantool. Il primo è costruire tutte le cache a livello di microservizi. Da quello che capisco, questa è la strada intrapresa da VimpelCom, creando una cache per i clienti.
Noi, invece, siamo meno dipendenti dai fornitori, stiamo cambiando il nucleo del BSS, quindi abbiamo un'unica scheda clienti già preconfigurata. Ma vogliamo espanderla. Per questo adottiamo un approccio leggermente diverso: creiamo cache all'interno dei sistemi.
In questo modo c'è meno disallineamento: un sistema si occupa sia della cache che della fonte principale.
Questo approccio si adatta bene alla soluzione Tarantool con scheletro transazionale, dove vengono aggiornate solo le parti relative alle modifiche, ovvero i cambiamenti dei dati. Tutto il resto può essere conservato altrove. Non esiste un grande data lake, né una cache globale non gestita. Le cache sono progettate per il sistema, o per i prodotti, o per i clienti, o per semplificare la vita al supporto. Quando un abbonato deluso dalla qualità chiama, si desidera fornirgli un servizio di qualità.
RTO e RPO
In IT ci sono due termini - RTO e RPO.
Recovery time objective è il tempo necessario per ripristinare il servizio dopo un guasto. RTO = 0 significa che anche se qualcosa è caduto, il servizio continua a funzionare.
Recovery point objective è il tempo di ripristino dei dati, ovvero quanti dati possiamo perdere in un certo periodo di tempo. RPO = 0 significa che non perdiamo dati.
Compito per Tarantool
Proviamo a risolvere un compito per Tarantool.
Dato: una ben nota cesta di richieste, ad esempio, su Amazon o altrove. Richiesta affinché il carrello funzioni 24 ore su 24, 7 giorni su 7, o il 99,99% del tempo. Gli ordini che riceviamo devono mantenere l'ordine, perché non possiamo attivare o disattivare la connessione all'utente in modo caotico: tutto deve seguire un rigoroso ordine. L'abbonamento precedente influisce su quello successivo, quindi i dati sono importanti: nulla deve andare perso.
Soluzione. Si potrebbe provare a risolvere in modo diretto e chiedere agli sviluppatori del database, ma il compito non può essere risolto matematicamente. Si potrebbero richiamare teoremi, leggi di conservazione, fisica quantistica, ma perché farlo: non è possibile risolverlo a livello di database.
Qui si applica il vecchio e caro approccio architetturale: è necessario conoscere bene il dominio e, grazie a questo, risolvere questo enigma.
La nostra soluzione: creiamo un registro distribuito delle richieste su Tarantool - un cluster geograficamente distribuito. Nello schema ci sono tre diversi data center: due prima degli Urali, uno dietro 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. La vigilia di Natale cattolica, il 24 dicembre, questo data center è andato offline. Gli utenti in Canada e negli Stati Uniti sono rimasti senza i loro film preferiti, si sono molto arrabbiati e ne hanno scritto sui social. Ora Netflix ha tre data center sulla costa occidentale e orientale e uno in Europa occidentale.
Iniziamo a costruire una soluzione geodistribuita - la resilienza è importante per noi.
Quindi abbiamo un cluster, ma come gestire RPO = 0 e RTO = 0? La soluzione è semplice, ma dipende dall'argomento.
Cosa è importante nelle richieste? Due parti: la costruzione del carrello PRIMA di prendere una decisione di acquisto, e DOPO. La parte PRIMA nelle telecomunicazioni è solitamente chiamata order capturing o order negotiation. Nelle telecomunicazioni può essere molto più complesso che in un negozio online, perché è necessario assistere il cliente, offrire 5 opzioni, e tutto questo richiede del tempo, ma il carrello si riempie. In quel momento è possibile un fallimento, ma non è grave, perché avviene in modalità interattiva sotto la supervisione di una persona.
Se il Data Center di Mosca dovesse improvvisamente guastarsi, passeremo automaticamente a un altro Data Center e continueremo a lavorare. Teoricamente potrebbe andare perso un prodotto nel carrello, ma lo vedrete, aggiungerete nuovamente il prodotto al carrello e continuerete a lavorare. In questo caso, RTO = 0.
Nello stesso momento, c'è un'altra opzione: quando facciamo clic su "submit", vogliamo assicurarci che i dati non vadano persi. Da questo momento in poi, entra in funzione l'automazione — qui abbiamo già RPO = 0. L'uso di questi due diversi schemi in un caso può essere semplicemente un cluster geodistribuito con un master switchabile, mentre nell'altro caso potrebbe essere una registrazione quorum. I modelli possono variare, ma noi risolviamo il problema.
Inoltre, avendo un registro distribuito delle richieste, possiamo scalare tutto ciò — avere molti dispatcher ed esecutori che accedono a questo registro.
Cassandra e Tarantool insieme
C'è anche un altro caso — "vetrina dei bilanci". Qui si presenta un caso interessante di applicazione congiunta di Cassandra e Tarantool.
Utilizziamo Cassandra perché 2 miliardi di chiamate al giorno non è un limite, e ci saranno molti di più. I marketer amano colorare il traffico in base alle fonti, e i dettagli sui social media, per esempio, stanno aumentando. Questo contribuisce a costruire una storia più ampia.
Cassandra consente una scalabilità orizzontale per qualsiasi volume.
Ci sentiamo a nostro agio con Cassandra, ma ha un problema: non è molto performante in lettura. In scrittura va bene, 30.000 operazioni al secondo non sono un problema - il problema è in lettura..
Pertanto, è emersa la questione della cache, e abbiamo anche risolto il seguente problema: esiste un vecchio caso tradizionale, in cui l'infrastruttura del commutatore per la tariffazione online produce file che carichiamo in Cassandra. Abbiamo affrontato il problema del caricamento affidabile di questi file, applicando persino il file transfer manager di IBM, ci sono soluzioni che gestiscono il trasferimento dei file in modo efficiente, utilizzando il protocollo UDP, per esempio, e non TCP. È un'ottima cosa, ma il processo richiede comunque minuti, e finché non abbiamo completato il caricamento, l'operatore del call center non può rispondere al cliente riguardo al suo saldo - bisogna aspettare.
Per evitare che questo accada, abbiamo applichiamo il failover funzionale parallelo. Quando inviamo un evento tramite Kafka a Tarantool, ricalcolando gli aggregati in tempo reale, ad esempio, per oggi, otteniamo la cache dei saldi, che può restituire i saldi a qualsiasi velocità, ad esempio, 100 mila transazioni al secondo e gli stessi 2 secondi.
L'obiettivo è che, dopo aver effettuato una chiamata, in soli 2 secondi nel pannello personale non ci sia solo il saldo modificato, ma anche un'informazione sul motivo per cui è cambiato.
Conclusione
Questi sono stati degli esempi di utilizzo di Tarantool. Ci è piaciuta molto l'apertura di Mail.ru, la loro disponibilità a considerare diversi casi.
Ai consulenti di BCG o McKinsey, Accenture o IBM è già difficile sorprenderci con qualcosa di nuovo — molto di ciò che propongono, noi lo facciamo già, lo abbiamo già fatto o intendiamo farlo. Penso che Tarantool occupi una posizione dignitosa nel nostro stack tecnologico e sostituirà molte tecnologie già esistenti. Siamo in una fase attiva di sviluppo di questo progetto.
La presentazione di Oleg e Andrey è stata una delle migliori alla Tarantool Conference dell'anno scorso, e il 17 giugno Oleg Ivlev parlerà alla con una presentazione . Inoltre, da MegaFon interverrà Aleksandr Deulin con una presentazione . Scopriremo cosa è cambiato e quali piani sono stati realizzati. Unisciti a noi: la conferenza è gratuita, basta . Tutti e il programma della conferenza è stato definito: nuovi casi, nuova esperienza nell'uso di Tarantool, architettura, enterprise, tutorial e microservizi.
Fonte: habr.com
