¿Por qué una corporación como MegaFon necesitaría Tarantool en su facturación? Desde afuera parece que simplemente un proveedor llega, trae una gran caja, la conecta a la corriente y ¡listo, aquí está la facturación! En algún momento así fue, pero ahora es una arcaica, y esos dinosaurios ya han desaparecido o están en proceso de extinción. Originalmente, la facturación era un sistema para emitir facturas: una calculadora o contador. En el telecomunicaciones moderna, es un sistema de automatización de todo el ciclo de vida de interacción con el abonado, desde la firma del contrato hasta la cancelación, incluyendo la tarificación en tiempo real, la aceptación de pagos y muchas otras cosas. La facturación en las empresas de telecomunicaciones es como un robot de combate: grande, poderoso y armado hasta los dientes.
¿Y qué tiene que ver aquí Tarantool? Eso lo explicarán Oleg Ivlev y Andrei Knyazev. Oleg es el arquitecto jefe de la empresa con una vasta experiencia en empresas extranjeras, Andrei es el director de sistemas de negocio. De la transcripción de su informe en aprenderás por qué la I+D es necesaria en las corporaciones, qué es Tarantool, cómo el estancamiento de la escalabilidad vertical y la globalización fueron condiciones para la aparición de esta base de datos en la empresa, sobre los desafíos tecnológicos, la transformación de la arquitectura, y cómo la pila tecnológica de MegaFon es similar a Netflix, Google y Amazon.
El proyecto 'Facturación Unificada'
El proyecto del que se hablará se llama 'Facturación Unificada'. En él, Tarantool mostró sus mejores cualidades.
El crecimiento del rendimiento del equipo Hi-End no se mantenía al ritmo del crecimiento de la base de abonados y el aumento de servicios, se esperaba un mayor crecimiento en el número de abonados y servicios debido a M2M, IoT, y las peculiaridades de las sucursales conducían a un deterioro en el time-to-market. La empresa decidió crear un sistema de negocios único con una arquitectura modular única de nivel mundial, en lugar de 8 sistemas de facturación diferentes.
MegaFon es ocho empresas en una. En 2009 se completó la reorganización: las sucursales en toda Rusia se unieron en la única empresa OAO 'MegaFon' (ahora PАО). Así, la empresa terminó teniendo 8 sistemas de facturación con sus propias soluciones 'personalizadas', peculiaridades de sucursales y diversas estructuras organizativas, de IT y marketing.
Todo iba bien, hasta que tuvimos que lanzar un producto federal común. Aparecieron un montón de complicaciones: algunos tenían tarifas redondeadas hacia arriba, otros hacia abajo, y otros por promedio aritmético. Hay miles de momentos como este.
A pesar de que la versión del sistema de facturación es la misma, y el proveedor también, la configuración era tan dispareja que llevaría mucho tiempo unirlas. Intentamos reducir su número y nos encontramos con un segundo problema conocido por muchas corporaciones.
Escalado vertical. Incluso el hardware más avanzado en ese momento no cumplía con las necesidades. Usábamos equipos de Hewlett-Packard, de la línea Superdome Hi-End, pero no soportaba la demanda ni de dos filiales. Queríamos escalado horizontal sin enormes costos operativos y inversiones de capital.
Esperando un crecimiento en la cantidad de suscriptores y servicios. Los consultores ya habían traído al mundo de las telecomunicaciones historias sobre IoT y M2M: llegará un momento en que habrá una tarjeta SIM en cada teléfono y plancha, y hasta dos en el refrigerador. Hoy tenemos una cantidad de suscriptores, pero en el futuro cercano habrá un número considerablemente más alto.
Desafíos tecnológicos
Estas cuatro razones nos impulsaron a realizar cambios significativos. Había una elección entre modernizar el sistema o diseñar uno desde cero. Reflexionamos mucho, tomamos decisiones importantes y realizamos licitaciones. Al final, decidimos diseñar desde el principio y nos enfrentamos a emocionantes desafíos: los desafíos tecnológicos.
Escalabilidad
Si antes había, digamos, 8 sistemas de facturación para 15 millones de suscriptores, ahora debería haber 100 millones de suscriptores o más — la carga es significativamente mayor.
Nos volvimos comparables en escala a grandes jugadores de internet como Mail.ru o Netflix.
Sin embargo, el movimiento hacia el aumento de la carga y la base de suscriptores nos presentó seriosos desafíos.
La geografía de nuestro vasto país
Entre Kaliningrado y Vladivostok 7500 km y 10 zonas horarias. La velocidad de la luz es finita y a esas distancias las latencias ya son significativas. 150 ms en los canales ópticos más avanzados es demasiado para la tarificación en tiempo real, especialmente como es actualmente en las telecomunicaciones en Rusia. Además, es necesario actualizarse en un día hábil, y con diferentes zonas horarias, eso es un problema.
No solo ofrecemos servicios de suscripción, sino que tenemos tarifas complejas, paquetes y diferentes modificadores. No solo debemos permitir o prohibir que el suscriptor hable, sino proporcionarle un presupuesto específico; debemos contabilizar las llamadas y acciones en tiempo real de manera que él no lo note.
Tolerancia a fallos
Este es el lado opuesto de la centralización.
Si reunimos a todos los suscriptores en un solo sistema, cualquier evento de emergencia o desastre sería desastroso para el negocio. Por lo tanto, diseñamos el sistema para eliminar el impacto de las fallas en toda la base de suscriptores.
Esto es nuevamente una consecuencia de abandonar la escalabilidad vertical. Cuando optamos por la escalabilidad horizontal, aumentamos la cantidad de servidores de cientos a miles. Es necesario gestionarlos y construir intercambiabilidad, automatizar la reserva de la infraestructura de TI y restaurar el sistema distribuido.
Hemos enfrentado desafíos interesantes. Diseñamos un sistema y en ese momento intentamos encontrar las mejores prácticas a nivel mundial para verificar qué tan alineados estamos con las tecnologías avanzadas.
Experiencia global
Es sorprendente, pero en el telecomunicaciones mundial no encontramos ninguna referencia.
Europa no es relevante en términos de cantidad de suscriptores y escala, y Estados Unidos por la limitada variedad de sus tarifas. Miramos algo en China y encontramos expertos en India, donde contratamos a especialistas de Vodafone India.
Para analizar la arquitectura, reunimos un Dream Team encabezado por IBM, arquitectos de diferentes campos. Estas personas podían evaluar adecuadamente lo que estamos haciendo y aportar ciertos conocimientos a nuestra arquitectura.
Escalabilidad
Algunos números para ilustrar.
Estamos diseñando el sistema para 80 millones de suscriptores con un margen para mil millones. De esta manera, eliminamos futuros obstáculos. No es porque planeemos conquistar China, sino por el impulso del IoT y M2M.
300 millones de documentos se procesan en tiempo real. Aunque tenemos 80 millones de suscriptores, también trabajamos con clientes potenciales y con aquellos que se fueron, en caso de necesitar cobrar deudas. Por lo tanto, los volúmenes reales son significativamente mayores.
2 mil millones de transacciones cambian diariamente el saldo; son pagos, cargos, llamadas y otros eventos. 200 TB de datos cambian activamente, cambian un poco más lentamente 8 PB de datos, y esto no es un archivo, sino datos en vivo en una única facturación. Escala de los centros de datos - 5 mil servidores en 14 ubicaciones.
Stack tecnológico
Cuando planificamos la arquitectura y comenzamos a construir el sistema, importamos las tecnologías más interesantes y avanzadas. Resultado: un stack tecnológico familiar para cualquier jugador de internet y corporaciones que desarrollan sistemas de alta carga.
El stack es similar al de otros grandes jugadores: Netflix, Twitter, Viber. Consiste en 6 componentes, pero queremos reducirlo y unificarlo.
La flexibilidad es buena, pero en una gran corporación la unificación es esencial.
No planeamos cambiar Oracle por Tarantool. En la realidad de las grandes empresas, eso es una utopía, o una cruzada de 5-10 años con un desenlace incierto. Pero Cassandra y Couchbase se pueden reemplazar con Tarantool, y esa es nuestra meta.
¿Por qué Tarantool?
Hay 4 criterios simples de por qué elegimos esta base de datos.
Velocidad. Realizamos pruebas de carga en los sistemas industriales de MegaFon. Tarantool ganó: mostró el mejor rendimiento.
No se puede decir que otros sistemas no satisfacen las necesidades de MegaFon. Las soluciones actuales basadas en memoria son tan eficientes que la empresa tiene recursos más que suficiente. Pero nos interesa tratar con un líder, no con quien queda rezagado, incluso en la prueba de carga.
Tarantool satisface las necesidades de la empresa incluso a largo plazo.
Costo total de propiedad (TCO). El soporte de Couchbase en los volúmenes de MegaFon cuesta una fortuna, mientras que la situación con Tarantool es mucho más favorable, y en funcionalidad son similares.
Otra característica agradable, que influyó un poco en nuestra elección, es que Tarantool trabaja mejor que otras bases de datos con la memoria. Muestra la máxima eficiencia.
Fiabilidad. MegaFon invierte en fiabilidad, quizás como nadie más. Por eso, cuando miramos a Tarantool, entendimos que teníamos que asegurarnos de que cumpliera con nuestros requisitos.
Hemos invertido nuestro tiempo y finanzas, y junto con Mail.ru creamos una versión enterprise, que ya se utiliza en varias otras empresas.
Tarantool-enterprise nos ha satisfecho completamente en términos de seguridad, fiabilidad y registro de eventos.
Asociación
Lo más importante para mí es el contacto directo con el desarrollador. Es justo eso lo que el equipo de Tarantool logró convencerme.
Si te acercas a un jugador, especialmente a uno que trabaja con un cliente ancla, y le dices que necesitas que la base de datos haga esto, esto y esto, normalmente te responde:
— Bien, coloca los requisitos en la parte inferior de esa pila; algún día, probablemente, llegaremos a ellos.
Muchos tienen una hoja de ruta para los próximos 2-3 años, y encajar allí es prácticamente imposible, mientras que los desarrolladores de Tarantool se destacan por su apertura, y no solo con MegaFon, adaptan su sistema para el cliente. Eso es genial, y nos gusta mucho.
Dónde aplicamos Tarantool
Usamos Tarantool en varios elementos. El primero es en el piloto, que hicimos en el sistema de catálogo de direcciones. En su momento, queríamos que fuera un sistema similar a Yandex.Maps y Google Maps, pero resultó un poco diferente.
Por ejemplo, el catálogo de direcciones en la interfaz de ventas. En Oracle, buscar la dirección deseada toma 12-13 s. — unas cifras incómodas. Cuando cambiamos a Tarantool, reemplazamos Oracle por otra base de datos en la consola, y realizamos la misma búsqueda, ¡obtenemos una aceleración de 200 veces! La ciudad aparece después de la tercera letra. Ahora estamos adaptando la interfaz para que esto suceda después de la primera. Sin embargo, la velocidad de respuesta es completamente diferente — ya son milisegundos en lugar de segundos.
La segunda aplicación es un tema de moda llamado IT de dos velocidades. Todo porque los consultores de cada rincón dicen que las corporaciones deberían dirigirse hacia allí.
Aquí hay una capa de infraestructura, sobre la cual se encuentran los dominios, por ejemplo, un sistema de facturación, como en telecomunicaciones, sistemas corporativos, informes corporativos. Este es el núcleo que no se debe tocar. Es decir, por supuesto, se puede, pero de manera paranoide asegurando la calidad, porque esto le reporta dinero a la corporación.
Luego viene la capa de microservicios — lo que diferencia al operador o a otro jugador. Los microservicios se pueden crear rápidamente sobre la base de ciertos cachés, elevando datos de diferentes dominios. Aquí hay un campo para experimentar — si algo no funciona, cierras un microservicio y abres otro. Esto proporciona un aumento real en el time-to-market y mejora la fiabilidad y velocidad de la empresa.
Los microservicios son, sin duda, el papel principal de Tarantool en MegaFon.
Dónde planeamos aplicar Tarantool
Comparando nuestro exitoso proyecto de facturación con los programas de transformación de Deutsche Telekom, Связьком, Vodafone India, es sorprendentemente dinámico y creativo. Durante la implementación de este proyecto, no solo se transformó Megafon y su estructura, sino que también nacieron Tarantool-enterprise en Mail.ru, y nuestro proveedor Nexign (anteriormente «Петер-Сервис») lanzó BSS Box (solución de facturación lista para usar).
Es, en cierto sentido, un proyecto histórico para el mercado ruso. Se puede comparar con lo que se describe en el libro de Frederick Brooks «El mito del hombre-mes». En aquel entonces, en los años 60, IBM atrajo a 5,000 personas para desarrollar un nuevo sistema operativo OS/360 para mainframes. Nosotros tenemos menos — 1,800, pero nuestros son expertos, y considerando el uso de código abierto y nuevos enfoques, somos más productivos.
A continuación se muestran los dominios de facturación o, si hablamos en términos más amplios, — sistemas empresariales. La gente de enterprise conoce bien CRM. Otros sistemas deben estar disponibles para todos: Open API, API Gateway.
Open API
Vamos a revisar nuevamente los números y cómo funciona actualmente Open API. Su carga es de 10,000 transacciones por segundo. Dado que planeamos desarrollar activamente la capa de microservicios y construir la API pública de Megafon, anticipamos un mayor crecimiento en el futuro precisamente en esta área. 100,000 transacciones seguramente serán.
No sé si nos compararemos en SSO con Mail.ru — ellos parecen tener 1,000,0000 transacciones por segundo. Su solución es muy interesante para nosotros y planeamos aprender de su experiencia — por ejemplo, crear una reserva funcional de SSO usando Tarantool. Actualmente, los desarrolladores de Mail.ru están trabajando en esto para nosotros.
CRM
CRM son esos 80 millones de suscriptores que queremos llevar a mil millones, porque ya hay 300 millones de documentos que incluyen una historia de tres años. Realmente esperamos nuevos servicios, y aquí el punto de crecimiento son los servicios conectados. Esta esfera seguirá creciendo, porque habrá cada vez más servicios. Por lo tanto, necesitaremos un historial, no queremos tropezar en eso.
La facturación en cuanto a la emisión de facturas y la gestión de la deuda de los clientes se ha transformado en un dominio separado. Para ampliar la productividad, se aplicó un patrón arquitectónico de arquitectura de dominio..
El sistema está dividido en dominios, la carga está distribuida y se garantiza la disponibilidad. Además, se ha trabajado en la arquitectura distribuida.
Todo lo demás son soluciones a nivel empresarial. En el almacenamiento de llamadas— 2 mil millones al día, 60 mil millones al mes. A veces es necesario recalcularlos por mes, y es mejor hacerlo rápidamente. Monitoreo financiero — son exactamente esos 300 millones que crecen y crecen: los abonados a menudo cambian de operador, aumentando esta parte.
El componente más telecomunicativo de la telefonía móvil es la tarificación online. Estos son los sistemas que le permiten realizar llamadas o no, tomando decisiones en tiempo real. Aquí la carga es de 30,000 transacciones por segundo, pero considerando el aumento en la transferencia de datos, planeamos 250,000 transacciones, y por eso nos interesa mucho Tarantool.
La imagen anterior muestra los dominios donde planeamos aplicar Tarantool. El CRM, por supuesto, es más amplio y planeamos aplicarlo en el núcleo mismo.
La cifra estimada de 100 millones de abonados me inquieta como arquitecto: ¿y si 101 millones? ¿Tendremos que rehacer todo? Para evitar esto, aplicamos cachés, aumentando la disponibilidad.
En general, hay dos enfoques para aplicar Tarantool. El primero es construir todos los cachés a nivel de microservicios.Hasta donde entiendo, este es el camino que sigue VimpelCom, creando el caché de clientes.
Nosotros dependemos menos de los proveedores, cambiamos el núcleo BSS, por lo que tenemos un único archivo de clientes ya listo. Pero queremos ampliarlo. Por eso aplicamos un enfoque algo diferente— creamos cachés dentro de los sistemas..
De este modo hay menos desincronización: un sistema es responsable tanto del caché como de la fuente maestra principal.
El método se adapta bien al enfoque de Tarantool con un esqueleto transaccional, donde solo se actualizan las partes relacionadas con las actualizaciones, es decir, los cambios de datos. Todo lo demás puede almacenarse en otro lugar. No hay un gran data lake, ni un caché global no gestionado. Los cachés se diseñan para el sistema, ya sea para productos, clientes, o para facilitar la vida del mantenimiento. Cuando un abonado insatisfecho llama, queremos atenderlo de manera eficaz.
RTO y RPO
En TI hay dos términos— RTO y RPO.
Recovery time objective — es el tiempo de recuperación del servicio tras una falla. RTO = 0 significa que, incluso si algo falla, el servicio sigue funcionando.
Objetivo de recuperación — es el tiempo de recuperación de datos, cuánto datos podemos perder durante un período específico. RPO = 0 significa que no perdemos datos.
Tarea sobre Tarantool
Intentemos resolver la tarea para Tarantool.
Dado: una cesta de pedidos conocida por todos, por ejemplo, en Amazon o en otro lugar. Se requiere que la cesta funcione 24 horas al día, 7 días a la semana, o el 99,99% del tiempo. Los pedidos que recibimos deben mantener el orden, porque no podemos habilitar o deshabilitar la conexión del suscriptor caóticamente; todo debe ser estrictamente secuencial. La suscripción anterior afecta a la siguiente, por lo que los datos son importantes; nada debe perderse.
Solución. Se puede intentar resolverlo directamente y preguntar a los desarrolladores de bases de datos, pero la tarea matemáticamente no puede resolverse. Se pueden recordar teoremas, leyes de conservación, física cuántica, pero ¿para qué? — no es posible resolverlo a nivel de base de datos.
Aquí se aplica el viejo enfoque arquitectónico — es necesario conocer bien el área temática y resolver este rompecabezas a partir de ella.
Nuestra solución: creamos un registro distribuido de pedidos en Tarantool — un clúster geodistribuido. En el esquema son tres centros de datos diferentes: dos antes de los Urales, uno después de los Urales, y distribuimos todos los pedidos entre estos centros.
Netflix, que ahora se considera uno de los líderes en IT, hasta 2012 tenía solo un centro de datos. La víspera de Navidad católica, el 24 de diciembre, ese centro de datos falló. Los usuarios de Canadá y EE. UU. se quedaron sin sus películas favoritas, se molestaron mucho y lo comentaron en redes sociales. Ahora Netflix tiene tres centros de datos en la costa este y oeste y uno en Europa occidental.
Desde el principio construimos una solución geodistribuida — la resistencia a fallos es importante para nosotros.
Entonces, tenemos un clúster, pero ¿cómo abordar RPO = 0 y RTO = 0? La solución es simple y depende del tema.
¿Qué es importante en los pedidos? Dos partes: la elaboración de la cesta ANTES de tomar una decisión de compra, y DESPUÉS. La parte ANTES en telecomunicaciones generalmente se llama captura de pedidos o negociación de pedidos. En telecomunicaciones, esto puede ser mucho más complicado que en una tienda en línea, porque hay que atender al cliente, ofrecer 5 opciones, y todo esto ocurre durante un tiempo, pero el carrito se va llenando. En ese momento, puede haber una falla, pero no es grave, porque sucede en un modo interactivo bajo la supervisión de una persona.
Si el centro de datos de Moscú se cae repentinamente, al cambiar automáticamente a otro centro de datos, seguimos trabajando. Teóricamente, puede perderse un producto en el carrito, pero lo ves, decides volver a llenar el carrito y continúas trabajando. En este caso, RTO = 0.
Al mismo tiempo, hay una segunda opción: cuando pulsamos 'enviar', queremos que los datos no se pierdan. A partir de ese momento, la automatización entra en funcionamiento — esto ya es RPO = 0. La aplicación de estos dos patrones diferentes en un caso puede ser simplemente un clúster geográficamente distribuido con un maestro conmutado, en otro caso, algún tipo de grabación de quórum. Los patrones pueden variar, pero resolvemos el problema.
Además, teniendo un registro distribuido de solicitudes, también podemos escalar todo esto: tener muchos despachadores y ejecutores que acceden a este registro.
Cassandra y Tarantool juntos
Hay otro caso — ‘vitrina de balances’. Aquí hay un caso interesante de aplicación conjunta de Cassandra y Tarantool.
Usamos Cassandra porque 2 mil millones de llamadas al día no son el límite, y habrá más. A los especialistas en marketing les gusta clasificar el tráfico por fuentes, aparecen más detalles sobre las redes sociales, por ejemplo. Todo esto aumenta el historial.
Cassandra permite escalar horizontalmente a cualquier volumen.
Nos sentimos cómodos con Cassandra, pero tiene un problema: no es buena para la lectura. En cuanto a la escritura todo está bien, 30,000 por segundo no es problema — el problema es la lectura..
Por lo tanto, surgió el tema de la caché, y además decidimos resolver el siguiente problema: existe un caso tradicional antiguo, donde los datos del equipo del conmutador de la tarificación en línea llegan en archivos, que cargamos en Cassandra. Luchamos contra el problema de la carga confiable de estos archivos, incluso aplicamos, por consejo de un gerente de IBM, la transferencia de archivos: existen soluciones que gestionan la transferencia de archivos de manera eficiente, utilizando el protocolo UDP, por ejemplo, en lugar de TCP. Esto es bueno, pero aún necesitamos minutos, y mientras no carguemos todo, el operador en el centro de llamadas no puede responder al cliente sobre lo que sucedió con su saldo: hay que esperar.
Para que esto no ocurra, nosotros aplicamos una reserva funcional paralela. Cuando enviamos un evento a través de Kafka a Tarantool, recalculando los agregados en tiempo real, por ejemplo, de hoy, obtenemos caché de saldos, que puede devolver saldos a cualquier velocidad, por ejemplo, 100 mil transacciones por segundo y los mismos 2 segundos.
El objetivo es que después de realizar una llamada, ya a los 2 segundos, no solo haya un saldo modificado en el área personal, sino también información sobre por qué cambió.
Conclusión
Estos fueron ejemplos de uso de Tarantool. Nos encantó mucho la apertura de Mail.ru, su disposición para considerar diferentes casos.
A los consultores de BCG o McKinsey, Accenture o IBM ya les resulta difícil sorprendernos con algo nuevo: muchas de las cosas que proponen, ya las hacemos, hemos hecho, o estamos planeando hacer. Creo que Tarantool ocupará un lugar digno en nuestra pila tecnológica y reemplazará muchas tecnologías existentes. Estamos en una fase activa de desarrollo de este proyecto.
La presentación de Oleg y Andrei fue una de las mejores en la Tarantool Conference del año pasado, y ya el 17 de junio Oleg Ivlev se presentará en con la presentación . También de Megafon, Alexander Deulin presentará con la charla . Nos enteraremos de lo que ha cambiado, qué planes se han logrado realizar. Únete — la conferencia es gratuita, solo hay que . Todas y el programa de la conferencia ha sido formado: nuevos casos, nueva experiencia en el uso de Tarantool, arquitectura, enterprise, tutoriales y microservicios.
Fuente: habr.com
