Perché un'azienda come MegaFon ha bisogno di Tarantool per la fatturazione? Dall'esterno sembra che il venditore di solito arrivi, porti una specie di grande scatola, infili la spina nella presa - e questo è la fatturazione! Una volta era così, ma ora è arcaico e tali dinosauri si sono già estinti o si stanno estinguendo. Inizialmente, la fatturazione è un sistema per l'emissione di fatture: una macchina per contare o una calcolatrice. Nelle telecomunicazioni moderne questo è sistema di automazione per l'intero ciclo di vita dell'interazione con un abbonato dalla conclusione del contratto alla risoluzione, inclusa fatturazione in tempo reale, accettazione dei pagamenti e molto altro. La fatturazione nelle società di telecomunicazioni è come un robot da combattimento: grande, potente e carico di armi.
Cosa c'entra il Tarantoolo? Ne parleranno Oleg Ivlev и Andrey Knyazev. Oleg è l'architetto capo dell'azienda con una vasta esperienza di lavoro in aziende straniere, Andrey è direttore dei sistemi aziendali. Dalla trascrizione del loro rapporto su imparerai perché le aziende hanno bisogno di ricerca e sviluppo, cos'è Tarantool, come l'impasse del ridimensionamento verticale e della globalizzazione sono diventati i prerequisiti per la comparsa di questo database nell'azienda, le sfide tecnologiche, la trasformazione dell'architettura e come il technostack di MegaFon è simile a Netflix , Google e Amazon.
Progetto "Fatturazione Unificata"
Il progetto in questione si chiama “Unified Billing”. È stato qui che il Tarantool ha mostrato le sue migliori qualità.
La crescita della produttività delle apparecchiature Hi-End non ha tenuto il passo con la crescita della base di abbonati e con la crescita del numero di servizi; ci si aspettava un'ulteriore crescita del numero di abbonati e dei servizi a causa delle funzionalità M2M, IoT e delle filiali. ad un deterioramento del time-to-market. L'azienda ha deciso di creare un sistema aziendale unificato con un'architettura modulare unica e di livello mondiale, invece degli 8 diversi sistemi di fatturazione attuali.
MegaFon è otto aziende in una. Nel 2009 la riorganizzazione è stata completata: le filiali in tutta la Russia si sono fuse in un'unica società, MegaFon OJSC (ora PJSC). L'azienda dispone quindi di 8 sistemi di fatturazione con soluzioni “personalizzate”, caratteristiche di filiale e diverse strutture organizzative, informatiche e di marketing.
Tutto andava bene finché non abbiamo dovuto lanciare un prodotto federale comune. Qui sono sorte molte difficoltà: per alcuni le tariffe vengono arrotondate per eccesso, per altri per difetto e per altri in base alla media aritmetica. Ci sono migliaia di momenti simili.
Nonostante esistesse una sola versione del sistema di fatturazione e un unico fornitore, le impostazioni divergevano così tanto che ci è voluto molto tempo per metterle insieme. Abbiamo provato a ridurne il numero e ci siamo imbattuti in un secondo problema familiare a molte aziende.
Scala verticale. Anche l'hardware più interessante dell'epoca non soddisfaceva le esigenze. Abbiamo utilizzato apparecchiature Hewlett-Packard della linea Superdome Hi-End, ma non soddisfacevano le esigenze nemmeno di due filiali. Volevo un ridimensionamento orizzontale senza grandi costi operativi e investimenti di capitale.
Aspettativa di crescita del numero di abbonati e di servizi. I consulenti portano da tempo storie su IoT e M2M nel mondo delle telecomunicazioni: verrà il momento in cui ogni telefono e ferro avrà una scheda SIM e due nel frigorifero. Oggi abbiamo un numero di abbonati, ma nel prossimo futuro ce ne saranno molti di più.
Sfide tecnologiche
Questi quattro motivi ci hanno motivato ad apportare cambiamenti seri. C'era una scelta tra l'aggiornamento del sistema e la progettazione da zero. Abbiamo pensato a lungo, preso decisioni serie, giocato gare. Di conseguenza, abbiamo deciso di progettare fin dall'inizio e abbiamo affrontato sfide interessanti: sfide tecnologiche.
scalabilità
Se fosse prima, diciamo, diciamo 8 fatturazioni per 15 milioni di abbonati, e ora avrebbe dovuto funzionare 100 milioni di abbonati e altro ancora - il carico è un ordine di grandezza superiore.
Siamo diventati paragonabili in scala ai grandi player di Internet come Mail.ru o Netflix.
Ma l’ulteriore movimento per aumentare il carico e la base di abbonati ci ha posto sfide serie.
Geografia del nostro vasto Paese
Tra Kaliningrad e Vladivostok 7500 km e 10 fusi orari. La velocità della luce è finita e a tali distanze i ritardi sono già notevoli. 150 ms sui canali ottici moderni più interessanti sono troppi per la fatturazione in tempo reale, soprattutto perché lo è ora nelle telecomunicazioni in Russia. Inoltre, è necessario eseguire l'aggiornamento entro un giorno lavorativo e con fusi orari diversi questo è un problema.
Non forniamo solo servizi a pagamento, ma disponiamo di tariffe complesse, pacchetti e vari modificatori. Dobbiamo non solo consentire o negare all'abbonato di parlare, ma dargli una certa quota: calcolare chiamate e azioni in tempo reale in modo che non se ne accorga.
tolleranza ai guasti
Questo è l’altro lato della centralizzazione.
Se raccogliamo tutti gli abbonati in un unico sistema, qualsiasi evento di emergenza e disastro sarà disastroso per le aziende. Pertanto, progettiamo il sistema in modo tale da eliminare l'impatto degli incidenti sull'intera base abbonati.
Anche questa è una conseguenza del rifiuto di scalare verticalmente. Quando abbiamo scalato orizzontalmente, abbiamo aumentato il numero di server da centinaia a migliaia. Devono essere gestiti e intercambiabili, eseguire automaticamente il backup dell'infrastruttura IT e ripristinare il sistema distribuito.
Abbiamo affrontato sfide davvero interessanti. Abbiamo progettato il sistema e in quel momento abbiamo cercato di trovare le migliori pratiche globali per verificare quanto siamo in tendenza, quanto seguiamo le tecnologie avanzate.
Esperienza mondiale
Sorprendentemente, non abbiamo trovato un solo riferimento nelle telecomunicazioni globali.
L'Europa è diminuita in termini di numero di abbonati e dimensioni, gli Stati Uniti - in termini di piattezza delle sue tariffe. Ne abbiamo esaminati alcuni in Cina, ne abbiamo trovati alcuni in India e abbiamo assunto specialisti di Vodafone India.
Per analizzare l'architettura, abbiamo riunito un Dream Team guidato da IBM, composto da architetti provenienti da diversi campi. Queste persone potevano valutare adeguatamente ciò che stavamo facendo e apportare determinate conoscenze alla nostra architettura.
Scala
Alcuni numeri per illustrare.
Progettiamo il sistema per 80 milioni di abbonati con una riserva di un miliardo. In questo modo rimuoviamo le soglie future. Questo non perché prenderemo il controllo della Cina, ma a causa dell’assalto dell’IoT e del M2M.
300 milioni di documenti elaborati in tempo reale. Anche se abbiamo 80 milioni di abbonati, lavoriamo sia con i potenziali clienti che con quelli che ci hanno lasciato se abbiamo bisogno di recuperare crediti. Pertanto, i volumi effettivi sono notevolmente più grandi.
2 miliardi di transazioni Il saldo cambia ogni giorno: si tratta di pagamenti, addebiti, chiamate e altri eventi. 200 TB di dati stanno cambiando attivamente, cambia un po' più lentamente 8 PB di dati, e non si tratta di un archivio, ma di dati live in un'unica fatturazione. Scala per data center - 5mila server su 14 siti.
Pila tecnologica
Quando abbiamo progettato l'architettura e iniziato ad assemblare il sistema, abbiamo importato le tecnologie più interessanti e avanzate. Il risultato è uno stack tecnologico familiare a qualsiasi attore di Internet e alle aziende che realizzano sistemi ad alto carico.
Lo stack è simile agli stack degli altri principali attori: Netflix, Twitter, Viber. È composto da 6 componenti, ma vogliamo accorciarlo e unificarlo.
La flessibilità è positiva, ma in una grande azienda non esiste soluzione senza unificazione.
Non cambieremo lo stesso Oracle in Tarantool. Nella realtà delle grandi aziende, questa è un'utopia, o una crociata di 5-10 anni con un esito poco chiaro. Ma Cassandra e Couchbase possono essere facilmente sostituiti con Tarantool, ed è quello a cui miriamo.
Perché il Tarantolo?
Ci sono 4 semplici criteri per cui abbiamo scelto questo database.
velocità. Abbiamo condotto test di carico sui sistemi industriali MegaFon. Tarantool ha vinto: ha mostrato la prestazione migliore.
Questo non vuol dire che altri sistemi non soddisfino le esigenze di MegaFon. Le attuali soluzioni di memoria sono così produttive che le riserve dell'azienda sono più che sufficienti. Ma a noi interessa avere a che fare con un leader e non con qualcuno che è in ritardo, anche nel test di carico.
Tarantool copre il fabbisogno aziendale anche nel lungo termine.
Costo del TCO. Il supporto per Couchbase sui volumi MegaFon costa cifre astronomiche, ma con Tarantool la situazione è molto più piacevole e sono simili nella funzionalità.
Un’altra caratteristica interessante che ha influenzato leggermente la nostra scelta è che Tarantool funziona meglio con la memoria rispetto ad altri database. Lui mostra massima efficienza.
Affidabilità. MegaFon investe nell'affidabilità, probabilmente più di chiunque altro. Quindi, quando abbiamo esaminato Tarantool, ci siamo resi conto che dovevamo adattarlo alle nostre esigenze.
Abbiamo investito tempo e denaro e insieme a Mail.ru abbiamo creato una versione aziendale, che ora viene utilizzata in molte altre aziende.
Tarantool-enterprise ci ha completamente soddisfatto in termini di sicurezza, affidabilità e registrazione.
associazione
La cosa più importante per me è contatto diretto con lo sviluppatore. Questo è esattamente ciò con cui hanno corrotto i ragazzi di Tarantool.
Se vai da un giocatore, soprattutto da uno che lavora con un cliente ancorato, e gli dici che hai bisogno del database per poter fare questo, questo e quest'altro, di solito risponde:
- Ok, metti i requisiti in fondo a quella pila: un giorno probabilmente ci arriveremo.
Molti hanno una tabella di marcia per i prossimi 2-3 anni ed è quasi impossibile integrarsi lì, ma gli sviluppatori di Tarantool affascinano con la loro apertura, e non solo di MegaFon, e adattano il loro sistema al cliente. È bello e ci piace davvero.
Dove abbiamo usato il Tarantoolo
Usiamo Tarantool in diversi elementi. Il primo è nel pilot, che abbiamo creato nel sistema di directory degli indirizzi. Un tempo volevo che fosse un sistema simile a Yandex.Maps e Google Maps, ma il risultato è stato leggermente diverso.
Ad 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, sostituiamo Oracle con un altro database nella console ed eseguiamo la stessa ricerca, otteniamo una velocità di 200 volte! La città appare dopo la terza lettera. Ora stiamo adattando l'interfaccia in modo che ciò avvenga dopo la prima. Tuttavia, la velocità di risposta è completamente diversa: millisecondi anziché secondi.
La seconda applicazione è un tema di tendenza chiamato IT a due velocità. Questo perché consulenti di ogni angolo dicono che le aziende dovrebbero andare lì.
C'è un livello di infrastruttura, sopra di esso ci sono domini, ad esempio un sistema di fatturazione come quello delle telecomunicazioni, sistemi aziendali, reporting aziendale. Questo è il nucleo che non ha bisogno di essere toccato. Questo, ovviamente, è possibile, ma paranoicamente garantisce la qualità, perché porta soldi all'azienda.
Poi arriva il livello dei microservizi: ciò che differenzia l'operatore o l'altro giocatore. I microservizi possono essere creati rapidamente in base a determinate cache, portando lì dati da diversi domini. Qui campo per gli esperimenti - se qualcosa non funzionava, chiudevo un microservizio e ne aprivo un altro. Ciò garantisce un time-to-market realmente aumentato e aumenta l’affidabilità e la velocità dell’azienda.
I microservizi sono forse il ruolo principale di Tarantool presso MegaFon.
Dove prevediamo di utilizzare Tarantool
Se confrontiamo il nostro progetto di fatturazione di successo con i programmi di trasformazione di Deutsche Telekom, Svyazcom, Vodafone India, risulta sorprendentemente dinamico e creativo. Nel processo di implementazione di questo progetto, non solo MegaFon e la sua struttura sono stati trasformati, ma anche l'impresa Tarantool è apparsa su Mail.ru e il nostro fornitore Nexign (ex Peter-Service) - BSS Box (una soluzione di fatturazione in scatola).
Si tratta, in un certo senso, di un progetto storico per il mercato russo. Può essere paragonato a quanto descritto nel libro “The Mythical Man-Month” di Frederick Brooks. Poi, negli anni '60, IBM assunse 360 persone per sviluppare il nuovo sistema operativo OS/5 per mainframe. Ne abbiamo meno: 000, ma i nostri sono in gilet e, tenendo conto dell'uso dell'open source e dei nuovi approcci, lavoriamo in modo più produttivo.
Di seguito sono riportati gli ambiti della fatturazione o, più in generale, dei sistemi aziendali. Le persone del mondo aziendale conoscono molto bene il CRM. Tutti dovrebbero già avere altri sistemi: Open API, API Gateway.
Open API
Diamo ancora un'occhiata ai numeri e a come funziona attualmente l'Open API. Il suo carico è 10 transazioni al secondo. Poiché prevediamo di sviluppare attivamente il livello dei microservizi e di creare l'API pubblica MegaFon, prevediamo una maggiore crescita in futuro in questa parte. Ci saranno sicuramente 100 transazioni.
Non so se possiamo paragonarci a Mail.ru in SSO: sembra che i ragazzi abbiano 1 di transazioni al secondo. La loro soluzione è estremamente interessante per noi e intendiamo adottare la loro esperienza, ad esempio realizzando un backup SSO funzionale utilizzando Tarantool. Ora gli sviluppatori di Mail.ru lo stanno facendo per noi.
CRM
Il CRM sono gli stessi 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. Non vediamo l'ora di nuovi servizi e qui punto di crescita sono i servizi connessi. Questa è una palla che crescerà, perché ci saranno sempre più servizi. Avremo quindi bisogno di una storia; non vogliamo inciampare in questa.
Fatturarsi in termini di emissione di fatture, lavorare con i crediti dei clienti trasformato in un dominio separato. Per migliorare le prestazioni, modello architettonico dell'architettura del dominio applicato.
Il sistema è suddiviso in domini, il carico è distribuito e la tolleranza ai guasti è garantita. Inoltre, abbiamo lavorato con un'architettura distribuita.
Tutto il resto sono soluzioni di livello aziendale. Nella memoria delle chiamate - 2 miliardi al giorno, 60 miliardi al mese. A volte bisogna contarli in un mese, ed è meglio in fretta. Monitoraggio finanziario - sono esattamente gli stessi 300 milioni che crescono e crescono costantemente: gli abbonati spesso corrono tra operatori, aumentando questa parte.
La componente più telecom delle comunicazioni mobili è fatturazione online. Sono i sistemi che permettono di chiamare o non chiamare, prendere decisioni in tempo reale. Qui il carico è di 30 transazioni al secondo, ma tenendo conto della crescita del trasferimento dei dati, pianifichiamo 250 transazioni, e quindi siamo molto interessati al Tarantoolo.
L'immagine precedente mostra i domini in cui utilizzeremo Tarantool. Il CRM stesso, ovviamente, è più ampio e lo utilizzeremo nel core stesso.
La nostra cifra TTX stimata di 100 milioni di abbonati mi confonde come architetto: e se fossero 101 milioni? Devi rifare tutto daccapo? Per evitare che ciò accada, utilizziamo le cache, aumentando allo stesso tempo l'accessibilità.
In generale, esistono due approcci all’utilizzo del Tarantoolo. Primo - creare tutte le cache a livello di microservizio. Per quanto ho capito, VimpelCom sta seguendo questa strada, creando una cache di client.
Siamo meno dipendenti dai fornitori, stiamo cambiando il core BSS, quindi abbiamo un unico file client pronto all'uso. Ma vogliamo espanderlo. Pertanto, adottiamo un approccio leggermente diverso: creare cache all'interno dei sistemi.
In questo modo c'è meno sincronizzazione: un sistema è responsabile sia della cache che della fonte principale principale.
Il metodo si adatta bene all'approccio Tarantool con uno scheletro transazionale, quando vengono aggiornate solo le parti relative agli aggiornamenti, ovvero alle modifiche dei dati. Tutto il resto può essere archiviato altrove. Non esiste un enorme data lake o una cache globale non gestita. Le cache sono progettate per il sistema, o per i prodotti, o per i clienti, o per rendere la vita più facile alla manutenzione. Quando un abbonato chiama ed è arrabbiato per la qualità del tuo servizio, desideri fornire un servizio di qualità.
RTO e RPO
Ci sono due termini in IT: RTO и RPO.
Obiettivo tempi di recupero è il tempo necessario per ripristinare il servizio dopo un errore. RTO = 0 significa che anche se qualcosa fallisce, il servizio continua a funzionare.
Obiettivo del punto di ripristino - questo è il tempo di recupero dei dati, quanti dati possiamo perdere in un certo periodo di tempo. RPO = 0 significa che non stiamo perdendo dati.
Compito del tarantolo
Proviamo a risolvere un problema per il Tarantoolo.
Dano: un paniere di applicazioni che tutti comprendono, ad esempio, in Amazon o altrove. Richiesto in modo che il carrello funzioni 24 ore su 7, 99,99 giorni su XNUMX, ovvero il XNUMX% del tempo. Gli ordini che ci arrivano devono rimanere in ordine, perché non possiamo accendere o spegnere in modo casuale la connessione dell'abbonato: tutto deve essere rigorosamente coerente. L'abbonamento precedente influisce su quello successivo, quindi i dati sono importanti: non deve mancare nulla.
Soluzione. Puoi provare a risolverlo direttamente e chiedere agli sviluppatori del database, ma il problema non può essere risolto matematicamente. Puoi ricordare teoremi, leggi di conservazione, fisica quantistica, ma perché: non può essere risolto a livello DB.
Il buon vecchio approccio architettonico funziona qui: devi conoscere bene l'argomento e usarlo per risolvere questo enigma.
La nostra soluzione: creare un registro distribuito delle applicazioni su Tarantool - un cluster geo-distribuito. Nel diagramma si tratta di tre diversi centri di elaborazione dati: due prima degli Urali, uno oltre gli Urali, e distribuiamo tutte le richieste tra questi centri.
Netflix, che oggi è considerato uno dei leader nel settore IT, fino al 2012 aveva un solo data center. Alla vigilia del Natale cattolico, il 24 dicembre, questo data center è andato in tilt. Gli utenti in Canada e negli Stati Uniti sono rimasti senza i loro film preferiti, sono rimasti molto turbati e ne hanno scritto sui social network. Netflix ora ha tre data center sulla costa occidentale-orientale e uno nell’Europa occidentale.
Inizialmente stiamo costruendo una soluzione geograficamente distribuita: per noi la tolleranza agli errori è importante.
Quindi abbiamo un cluster, ma che dire di RPO = 0 e RTO = 0? La soluzione è semplice, dipende dall'argomento.
Cosa è importante nelle applicazioni? Due parti: lancio del canestro PRIMA prendere una decisione di acquisto e DOPO. La parte DO nelle telecomunicazioni viene solitamente chiamata acquisizione dell'ordine o negoziazione dell'ordine. Nelle telecomunicazioni questo può essere molto più difficile che in un negozio online, perché lì il cliente deve essere servito, offrire 5 opzioni, e tutto questo accade per qualche tempo, ma il carrello è pieno. In questo momento un fallimento è possibile, ma non è spaventoso, perché avviene in modo interattivo sotto la supervisione umana.
Se il data center di Mosca fallisce improvvisamente, passando automaticamente a un altro data center, continueremo a lavorare. In teoria, un prodotto potrebbe perdersi nel carrello, ma se lo vedi, aggiungilo nuovamente al carrello e continua a lavorare. In questo caso RTO = 0.
Allo stesso tempo, esiste una seconda opzione: quando abbiamo cliccato su "invia", vogliamo che i dati non vadano persi. Da questo momento in poi, l'automazione inizia a funzionare: questo è RPO = 0. Utilizzando questi due modelli diversi, in un caso potrebbe essere semplicemente un cluster geo-distribuito con un master commutabile, nell'altro caso una sorta di record del quorum. I modelli possono variare, ma risolviamo il problema.
Inoltre, avendo un registro distribuito delle applicazioni, possiamo anche ridimensionarlo: avere molti dispatcher ed esecutori che accedono a questo registro.
Cassandra e Tarantool insieme
C'è un altro caso - "vetrina degli equilibri". Ecco un caso interessante dell'uso congiunto di Cassandra e Tarantool.
Usiamo Cassandra perché 2 miliardi di chiamate al giorno non sono il limite e ce ne saranno di più. Gli esperti di marketing adorano colorare il traffico in base alla fonte; sempre più dettagli appaiono, ad esempio, sui social network. Tutto si aggiunge alla storia.
Cassandra ti consente di ridimensionare orizzontalmente a qualsiasi dimensione.
Ci sentiamo a nostro agio con Cassandra, ma ha un problema: non è bravo a leggere. Va tutto bene nella registrazione, 30 al secondo non sono un problema - problema di lettura.
Pertanto, è apparso un argomento con una cache e allo stesso tempo abbiamo risolto il seguente problema: esiste un vecchio caso tradizionale in cui l'attrezzatura proveniente da un passaggio dalla fatturazione online entra nei file che carichiamo in Cassandra. Abbiamo lottato con il problema del download affidabile di questi file, anche seguendo i consigli del responsabile del trasferimento file IBM: esistono soluzioni che gestiscono il trasferimento file in modo efficiente, utilizzando il protocollo UDP, ad esempio, anziché TCP. Va bene, ma sono ancora pochi minuti e non abbiamo ancora caricato tutto, l'operatore del call center non può rispondere al cliente su cosa è successo al suo saldo: dobbiamo aspettare.
Per evitare che ciò accada, noi utilizziamo la riserva funzionale parallela. Quando inviamo un evento tramite Kafka a Tarantool, ricalcolando gli aggregati in tempo reale, ad esempio, per oggi, otteniamo saldi di cassa, che può trasferire saldi a qualsiasi velocità, ad esempio 100mila transazioni al secondo e gli stessi 2 secondi.
L'obiettivo è che dopo aver effettuato una chiamata, entro 2 secondi nel tuo account personale ci sarà non solo il saldo modificato, ma anche informazioni sul motivo per cui è cambiato.
conclusione
Questi erano esempi di utilizzo del Tarantoolo. Ci è piaciuta molto l'apertura di Mail.ru e la loro disponibilità a considerare casi diversi.
È già difficile per i consulenti di BCG o McKinsey, Accenture o IBM sorprenderci con qualcosa di nuovo: gran parte di ciò che offrono, noi lo facciamo già, lo abbiamo fatto o stiamo pianificando di farlo. Penso che Tarantool prenderà il posto che gli spetta nel nostro stack tecnologico e sostituirà molte tecnologie esistenti. Siamo nella fase attiva di sviluppo di questo progetto.
Il resoconto di Oleg e Andrey è uno dei migliori della Conferenza Tarantool dell'anno scorso, e il 17 giugno Oleg Ivlev parlerà al con un rapporto . Anche Alexander Deulin terrà una presentazione da parte di MegaFon . Scopriamo cosa è cambiato, quali piani sono stati attuati. Partecipa: la conferenza è gratuita, tutto ciò che devi fare è . tutto ed è stato definito il programma del convegno: nuovi casi, nuove esperienze nell'uso di Tarantool, architettura, impresa, tutorial e microservizi.
Fonte: habr.com