Por que unha corporación como MegaFon necesita Tarantool na súa facturación? Desde fóra parece que o vendedor adoita vir, trae algún tipo de caixa grande, enchufa o enchufe na toma e iso é a facturación! Era unha vez así, pero agora é arcaico, e este tipo de dinosauros xa se extinguiron ou están a extinguirse. Inicialmente, a facturación é un sistema para emitir facturas: unha máquina contadora ou calculadora. Nas telecomunicacións modernas, isto é sistema de automatización para todo o ciclo de vida de interacción cun abonado desde a celebración dun contrato ata a súa rescisión, incluíndo facturación en tempo real, aceptación de pagos e moito máis. A facturación nas empresas de telecomunicacións é como un robot de combate: grande, poderoso e cargado de armas.
Que ten que ver Tarantool con iso? Falarán diso Oleg Ivlev и Andrei Knyazev. Oleg é o arquitecto xefe da empresa Con ampla experiencia en empresas estranxeiras, Andrey é director de sistemas empresariais. Da transcrición do seu informe sobre aprenderá por que se necesita I+D nas corporacións, que é Tarantool, como o impasse da escala vertical e a globalización se converteu nos requisitos previos para a aparición desta base de datos na empresa, sobre os retos tecnolóxicos, a transformación arquitectónica e como a tecnopila de MegaFon é semellante a Netflix. , Google e Amazon.
Proxecto "Facturación unificada"
O proxecto que se tratará chámase “Facturación unificada”. Foi aquí onde Tarantool mostrou as súas mellores calidades.
O crecemento da produtividade dos equipos Hi-End non seguiu o ritmo do crecemento da base de abonados e do crecemento do número de servizos; esperábase un maior crecemento no número de abonados e servizos debido ás características do M2M, IoT e as filiais. a un deterioro do tempo de comercialización. A empresa decidiu crear un sistema empresarial unificado cunha arquitectura modular única de clase mundial, en lugar dos 8 sistemas de facturación diferentes actuais.
MegaFon son oito empresas nunha. En 2009, a reorganización completouse: as sucursais de toda Rusia fusionáronse nunha única empresa, MegaFon OJSC (agora PJSC). Así, a compañía dispón de 8 sistemas de facturación coas súas propias solucións "personalizadas", características de sucursal e diferentes estruturas organizativas, informática e mercadotecnia.
Todo estivo ben ata que tivemos que lanzar un produto federal común. Aquí xurdiron moitas dificultades: algúns teñen as tarifas redondeadas cara arriba, outras para abaixo e outras baseadas na media aritmética. Hai miles de momentos deste tipo.
A pesar do feito de que só había unha versión do sistema de facturación, un provedor, a configuración era tan diferente que levou moito tempo montar. Tentamos reducir o seu número e atopamos un segundo problema que é familiar para moitas corporacións.
Escalado vertical. Incluso o hardware máis xenial daquela época non satisfacía as necesidades. O traballo utilizou equipos Hewlett-Packard da liña Superdome Hi-End, pero non cubriu as necesidades de nin sequera dúas sucursais. Quería escalar horizontalmente sen grandes custos operativos e investimentos de capital.
Expectativa de crecemento no número de abonados e servizos. Os consultores levan hai tempo historias sobre IoT e M2M ao mundo das telecomunicacións: chegará o momento no que cada teléfono e ferro terá unha tarxeta SIM e cada neveira terá dúas. Hoxe temos o mesmo número de abonados, pero nun futuro próximo haberá moitos máis.
Retos tecnolóxicos
Estes catro motivos motivaronnos a facer cambios serios. Houbo unha opción entre actualizar o sistema e deseñar desde cero. Pensamos durante moito tempo, tomamos decisións serias, xogamos a concursos. Como resultado, decidimos deseñar dende o principio e asumimos retos interesantes: desafíos tecnolóxicos.
Escalabilidade
Se foi antes, digamos, digamos 8 facturas para 15 millóns de subscritores, e agora debería funcionar 100 millóns de subscritores e máis - a carga é unha orde de magnitude superior.
Convertémonos en comparables en escala aos grandes xogadores de Internet como Mail.ru ou Netflix.
Pero máis movementos para aumentar a carga e a base de subscritores supuxo serios desafíos para nós.
Xeografía do noso vasto país
Entre Kaliningrado e Vladivostok 7500 km e 10 fusos horarios. A velocidade da luz é finita e a tales distancias os atrasos xa son importantes. 150 ms nas canles ópticas modernas máis xeniais son demasiado para a facturación en tempo real, especialmente porque agora está en telecomunicacións en Rusia. Ademais, cómpre actualizar nun día laborable, e con diferentes fusos horarios isto é un problema.
Non só ofrecemos servizos por unha tarifa de subscrición, temos tarifas complexas, paquetes e varios modificadores. Non só debemos permitir ou negar que o subscritor fale, senón darlle unha determinada cota: contar as chamadas e as accións en tempo real para que non se dea conta.
tolerancia a fallos
Esta é a outra cara da centralización.
Se recollemos todos os subscritores nun só sistema, calquera evento de emerxencia e desastre será desastroso para as empresas. Por iso, deseñamos o sistema de forma que se elimine o impacto dos accidentes en toda a base de abonados.
Isto é de novo unha consecuencia da negativa a escalar verticalmente. Cando escalamos horizontalmente, aumentamos o número de servidores de centos a miles. Deben ser xestionados e intercambiables, facer unha copia de seguranza automática da infraestrutura de TI e restaurarse no sistema distribuído.
Enfrontámonos a retos tan interesantes. Deseñamos o sistema e, nese momento, tentamos buscar as mellores prácticas globais para comprobar o que estamos de moda, canto seguimos tecnoloxías avanzadas.
Experiencia mundial
Sorprendentemente, non atopamos unha única referencia nas telecomunicacións globais.
Europa caeu en canto a número de abonados e escala, os Estados Unidos caeron en canto á plana das súas tarifas. Miramos algunhas cousas en China, atopamos algunhas cousas na India e contratamos especialistas de Vodafone India.
Para analizar a arquitectura, reunimos un Dream Team dirixido por IBM: arquitectos de varios campos. Estas persoas podían avaliar adecuadamente o que estabamos facendo e achegar certos coñecementos á nosa arquitectura.
Escala
Algúns números para ilustrar.
Deseñamos o sistema para 80 millóns de abonados con mil millóns de reservas. Así é como eliminamos os limiares futuros. Isto non é porque imos asumir China, senón pola embestida de IoT e M2M.
300 millóns de documentos son procesados en tempo real. Aínda que temos 80 millóns de abonados, traballamos tanto con clientes potenciais como cos que nos deixaron se necesitamos cobrar. Polo tanto, os volumes reais son notablemente maiores.
2 millóns de transaccións O saldo cambia diariamente debido a pagos, cargos, chamadas e outros eventos. 200 TB de datos están cambiando activamente, cambia un pouco máis lento 8 PB de datos, e este non é un arquivo, senón datos en directo nunha única facturación. Escala por centro de datos - 5 mil servidores en 14 sitios.
Pila de tecnoloxía
Cando planificamos a arquitectura e comezamos a montar o sistema, importamos as tecnoloxías máis interesantes e avanzadas. O resultado é unha pila de tecnoloxía familiar para calquera reprodutor de Internet e corporacións que fabriquen sistemas de alta carga.
A pila é semellante ás pilas doutros principais xogadores: Netflix, Twitter, Viber. Consta de 6 compoñentes, pero queremos acurtalo e unificalo.
A flexibilidade é boa, pero nunha gran corporación non hai camiño sen unificación.
Non imos cambiar o mesmo Oracle por Tarantool. Nas realidades das grandes empresas, esta é unha utopía, ou unha cruzada durante 5-10 anos cun resultado pouco claro. Pero Cassandra e Couchbase poden ser facilmente substituídas por Tarantool, e iso é o que nos esforzamos.
Por que Tarantool?
Hai 4 criterios sinxelos polos que escollemos esta base de datos.
Acelerar. Realizamos probas de carga en sistemas industriais MegaFon. Tarantool gañou porque mostrou o mellor rendemento.
Isto non quere dicir que outros sistemas non satisfagan as necesidades de MegaFon. As solucións de memoria actuais son tan potentes que as reservas da empresa son máis que suficientes. Pero estamos interesados en tratar cun líder, e non con alguén que está detrás, incluso nunha proba de esforzo.
Tarantool cobre as necesidades da empresa incluso a longo prazo.
Custo TCO. Apoiar Couchbase en volumes MegaFon custa unha fortuna, pero con Tarantool a situación é moito mellor e son similares en funcións.
Outra característica agradable que influíu lixeiramente na nosa elección é que Tarantool funciona mellor coa memoria que outras bases de datos. El amosa máxima eficiencia.
Confianza. MegaFon inviste en fiabilidade, probablemente como ningunha outra. Por iso, cando miramos a Tarantool, decatámonos de que necesitabamos facelo cumprir cos nosos requisitos.
Investimos o noso tempo e as nosas finanzas, e xunto con Mail.ru creamos unha versión empresarial, que agora se usa noutras empresas.
Tarantool-enterprise satisfizounos completamente en termos de seguridade, fiabilidade e rexistro.
Asociación
O máis importante para min é contacto directo co desenvolvedor. Isto é exactamente o que me compraron os rapaces de Tarantool.
Se chegas a un xogador, especialmente a un que traballa cun cliente de áncora, e dis que necesitas a base de datos para poder facer isto, isto e isto, adoita responder:
- Vale, pon os requisitos no fondo desa pila. Algún día, probablemente chegaremos a eles.
Moita xente ten unha folla de ruta para os próximos 2-3 anos, e é case imposible integrarse alí, pero os desenvolvedores de Tarantool cativan coa súa apertura, e non só con MegaFon, e adaptan o seu sistema ao cliente. É xenial e gústanos moito.
Onde usamos Tarantool
Usamos Tarantool en varios elementos. O primeiro está no piloto., que fixemos no sistema de directorios de enderezos. Nun tempo, quería que fose un sistema similar a Yandex.Maps e Google Maps, pero resultou un pouco diferente.
Por exemplo, o catálogo de enderezos na interface de vendas. En Oracle, a busca do enderezo desexado leva entre 12 e 13 segundos. - números incómodos. Cando cambiamos a Tarantool, substituímos Oracle por outra base de datos na consola e realizamos a mesma busca, ¡obtemos unha aceleración de 200 veces! A cidade aparece despois da terceira letra. Agora estamos adaptando a interface para que isto suceda despois da primeira. Non obstante, a velocidade de resposta é completamente diferente: agora milisegundos en lugar de segundos.
A segunda aplicación é un tema de moda chamado TI de dúas velocidades. Iso é porque os consultores de todos os recunchos din que as corporacións deberían ir alí.
Hai unha capa de infraestrutura, por riba hai dominios, por exemplo, un sistema de facturación como unha telecomunicación, sistemas corporativos, informes corporativos. Este é o núcleo que non se debe tocar. Iso é, por suposto, é posible, pero paranoico garantindo a calidade, porque achega diñeiro á corporación.
A continuación vén a capa de microservizos, que é o que diferencia ao operador ou outro xogador. Os microservizos pódense crear rapidamente baseándose en certos cachés, traendo alí datos de diferentes dominios. Aquí campo para experimentos — se algo non funcionaba, pechaba un microservizo e abría outro. Isto proporciona un tempo de comercialización realmente mellorado e aumenta a fiabilidade e a velocidade da empresa.
Os microservizos son quizais o papel principal de Tarantool en MegaFon.
Onde pensamos usar Tarantool
Se comparamos o noso exitoso proxecto de facturación cos programas de transformación de Deutsche Telekom, Svyazcom, Vodafone India, é sorprendentemente dinámico e creativo. No proceso de implementación deste proxecto, non só se transformou MegaFon e a súa estrutura, senón tamén Tarantool-enterprise apareceu en Mail.ru e o noso provedor Nexign (anteriormente Peter-Service) - BSS Box (unha solución de facturación en caixa).
Este é, en certo sentido, un proxecto histórico para o mercado ruso. Pódese comparar co que se describe no libro The Mythical Man-Month de Frederick Brooks. Daquela, nos anos 60, IBM contratou a 360 persoas para desenvolver o novo sistema operativo OS/5 para mainframes. Temos menos - 000, pero estamos con chalecos, e tendo en conta o uso de código aberto e novos enfoques, traballamos de forma máis produtiva.
A continuación móstranse os dominios dos sistemas de facturación ou, de forma máis ampla, dos sistemas empresariais. A xente empresarial coñece moi ben o CRM. Todo o mundo xa debería ter outros sistemas: Open API, API Gateway.
Abrir API
Vexamos de novo os números e como funciona a API aberta actualmente. A súa carga é 10 transaccións por segundo. Dado que pensamos desenvolver activamente a capa de microservizos e construír a API pública de MegaFon, esperamos un maior crecemento no futuro nesta parte. Definitivamente haberá 100 transaccións.
Non sei se SSO é comparable a Mail.ru: os mozos parecen ter 1 de transaccións por segundo. Estamos moi interesados na súa solución e pensamos adoptar a súa experiencia, por exemplo, creando unha copia de seguridade SSO funcional usando Tarantool. Agora os desenvolvedores de Mail.ru están a facer isto connosco.
CRM
CRM son os mesmos 80 millóns de subscritores que queremos chegar aos mil millóns, porque xa hai 300 millóns de documentos que inclúen unha historia de tres anos. Estamos moi ansiosos por novos servizos e aquí o punto de crecemento son os servizos conectados. Este é un balón que vai medrando porque cada vez haberá máis servizos. En consecuencia, necesitaremos unha historia; non queremos tropezar con isto.
Facturación en termos de emisión de facturas e traballo coas contas por cobrar dos clientes transformado nun dominio separado. Para mellorar o rendemento, patrón arquitectónico de arquitectura de dominio aplicado.
O sistema divídese en dominios, a carga distribúese e a tolerancia a fallos está garantida. Ademais, traballamos con arquitectura distribuída.
Todo o demais son solucións a nivel empresarial. No almacenamento de chamadas - 2 millóns por día, 60 mil millóns ao mes. Ás veces hai que contalos nun mes, e é mellor facelo rapidamente. Seguimento financeiro - estes son exactamente os mesmos 300 millóns que están en constante crecemento e crecemento: os abonados adoitan correr entre operadores, aumentando esta parte.
O compoñente máis telecomunicacións das comunicacións móbiles é facturación en liña. Estes son os sistemas que permiten chamar ou non chamar, tomando unha decisión en tempo real. Aquí a carga é de 30 transaccións por segundo, pero tendo en conta o crecemento da transferencia de datos, planeamos 250 transaccións, e polo tanto, estamos moi interesados en Tarantool.
A imaxe anterior mostra os dominios onde imos usar Tarantool. O propio CRM, por suposto, é máis amplo e imos usalo no propio núcleo.
A nosa cifra estimada de TTX de 100 millóns de subscritores confúndeme como arquitecto: e se 101 millóns? Tes que refacer todo de novo? Para evitar que isto suceda, utilizamos cachés, ao tempo que aumentamos a dispoñibilidade.
En xeral, hai dous enfoques para usar Tarantool. Primeira - crear todas as cachés a nivel de microservizos. Polo que teño entendido, VimpelCom segue este camiño, creando unha caché de clientes.
Dependemos menos dos provedores, estamos cambiando o núcleo BSS, polo que temos un único ficheiro de cliente listo para usar. Pero queremos amplialo. Polo tanto, adoptamos un enfoque lixeiramente diferente: facer cachés dentro dos sistemas.
Deste xeito, hai menos desincronización: un sistema é responsable tanto da caché como da fonte principal principal.
O método encaixa ben co enfoque de Tarantool cun esqueleto transaccional, cando só se actualizan as partes relacionadas coas actualizacións, é dicir, os cambios de datos. Todo o demais pódese gardar noutro lugar. Non hai un gran lago de datos, caché global non xestionado. Os cachés están deseñados para o sistema, ou para produtos, ou para clientes, ou para facilitar a vida do mantemento. Cando un subscritor chama e está molesto pola calidade do teu servizo, queres ofrecer un servizo de calidade.
RTO e RPO
Hai dous termos en TI: OTR и RPO.
Obxectivo de tempo de recuperación é o tempo que tarda en restaurar o servizo despois dun fallo. RTO = 0 significa que aínda que algo falle, o servizo segue funcionando.
Obxectivo do punto de recuperación - este é o tempo de recuperación de datos, cantos datos podemos perder durante un determinado período de tempo. RPO = 0 significa que non estamos a perder datos.
Tarefa de Tarantool
Imos tentar resolver un problema para Tarantool.
Dado: unha cesta de solicitudes que todos entenden, por exemplo, en Amazon ou noutro lugar. Requerido para que o carro da compra funcione as 24 horas os 7 días da semana, ou o 99,99% do tempo. Os pedidos que nos chegan deben estar en orde, porque non podemos activar ou desactivar aleatoriamente a conexión do subscritor; todo debe ser estritamente coherente. A subscrición anterior afecta á seguinte, polo que os datos son importantes: non debería faltar nada.
decisión. Podes tentar resolvelo de frente e preguntar aos desenvolvedores da base de datos, pero o problema non se pode resolver matematicamente. Podes lembrar teoremas, leis de conservación, física cuántica, pero por que non se pode resolver a nivel de DB.
O bo e vello enfoque arquitectónico funciona aquí: cómpre coñecer ben a área temática e, á súa costa, resolver este crebacabezas.
A nosa solución: crear un rexistro distribuído de aplicacións para Tarantool, un clúster xeodistribuido. No diagrama, son tres centros de procesamento de datos diferentes: dous antes dos Urais, un máis aló dos Urais, e distribuímos todas as solicitudes a estes centros.
Netflix, que agora é considerado un dos líderes en TI, ata 2012 tiña só un centro de datos. Na véspera do Nadal católico, o 24 de decembro, este centro de datos caeu. Os usuarios de Canadá e Estados Unidos quedaron sen as súas películas favoritas, estaban moi molestos e escribiron sobre iso nas redes sociais. Netflix ten agora tres centros de datos na costa oeste-leste e un no oeste de Europa.
Inicialmente estamos construíndo unha solución xeodistribuída; a tolerancia a fallos é importante para nós.
Entón, temos un clúster, pero que pasa con RPO = 0 e RTO = 0? A solución é sinxela, dependendo do tema.
Que é importante nas aplicacións? Dúas partes: Lanzamento de cestas TO tomar unha decisión de compra, e DESPOIS. A parte DO en telecomunicacións chámase normalmente captura de pedidos ou negociación de pedidos. Nunha telecomunicación, isto pode ser moito máis difícil que nunha tenda en liña, porque alí hai que atender ao cliente, ofrecerlle 5 opcións, e todo isto ocorre durante algún tempo, pero o carro está cheo. Neste punto, un fracaso é posible, pero non dá medo porque ocorre de forma interactiva baixo supervisión humana.
Se o centro de datos de Moscova falla de súpeto, ao cambiar automaticamente a outro centro de datos, seguiremos traballando. En teoría, un produto pode perderse no carro, pero ves isto, engádese de novo ao carro e continúa traballando. Neste caso, RTO = 0.
Ao mesmo tempo, hai unha segunda opción: cando facemos clic en "enviar", queremos que non se perdan os datos. A partir deste momento, a automatización comeza a funcionar: este é RPO = 0. O uso destes dous patróns diferentes nun caso podería ser só un clúster xeodistribuido cun mestre conmutable, noutro caso algún tipo de rexistro de quórum. Os patróns poden variar, pero resolvemos o problema.
Ademais, tendo un rexistro distribuído de aplicacións, tamén podemos escalalo todo: temos moitos despachadores e executores que acceden a este rexistro.
Cassandra e Tarantool xuntos
Hai outro caso - "Vitrina de saldos". Velaquí un caso interesante do uso conxunto de Cassandra e Tarantool.
Usamos Cassandra porque 2 millóns de chamadas ao día non son o límite, e haberá máis. Os comerciantes adoran colorear o tráfico por orixe; cada vez aparecen máis detalles nas redes sociais, por exemplo. Todo engádese á historia.
Cassandra permítelle escalar horizontalmente a calquera tamaño.
Sentímonos cómodos con Cassandra, pero ten un problema: non é boa ler. Todo está ben na gravación, 30 por segundo non é un problema. problema na lectura.
Xa que logo, apareceu un tema con caché e, ao mesmo tempo, resolvemos o seguinte problema: existe un vello caso tradicional cando os equipos dun cambio de facturación en liña entran en ficheiros que cargamos en Cassandra. Loitamos co problema da descarga fiable destes ficheiros, mesmo usando o consello do xestor de transferencia de ficheiros de IBM: hai solucións que xestionan a transferencia de ficheiros de forma eficiente usando o protocolo UDP, por exemplo, en lugar de TCP. Isto é bo, pero aínda son minutos, e ata que o descargamos todo, o operador do centro de chamadas non pode responder ao cliente o que pasou co seu saldo: temos que esperar.
Para evitar que isto suceda, nós utilizamos a reserva funcional paralela. Cando enviamos un evento a través de Kafka a Tarantool, recalculando os agregados en tempo real, por exemplo, para hoxe, recibimos saldos de caixa, que pode transferir saldos a calquera velocidade, por exemplo, 100 mil transaccións por segundo e eses mesmos 2 segundos.
O obxectivo é que despois de facer unha chamada, nun prazo de 2 segundos, a túa conta persoal teña non só o saldo modificado, senón tamén información sobre por que cambiou.
Conclusión
Estes foron exemplos de uso de Tarantool. Gustounos moito a apertura de Mail.ru e a súa disposición a considerar diferentes casos.
Xa é difícil para os consultores de BCG ou McKinsey, Accenture ou IBM sorprendernos con algo novo: gran parte do que ofrecen, xa o facemos, o fixemos ou planeamos facer. Creo que Tarantool ocupará o lugar que lle corresponde na nosa pila de tecnoloxía e substituirá moitas tecnoloxías existentes. Estamos na fase activa de desenvolvemento deste proxecto.
O informe de Oleg e Andrey é un dos mellores da Conferencia de Tarantool do ano pasado, e o 17 de xuño Oleg Ivlev falará en cun informe . Alexander Deulin tamén ofrecerá unha presentación de MegaFon . Imos descubrir que cambiou, que plans se implementaron. Únete: a conferencia é gratuíta, todo o que tes que facer é . Todo e conformouse o programa da conferencia: novos casos, nova experiencia no uso de Tarantool, arquitectura, empresa, titoriais e microservizos.
Fonte: www.habr.com