¿Por qué una corporación como MegaFon, Tarantool en facturación? Desde el exterior, parece que el vendedor generalmente viene, trae una caja grande, conecta el enchufe al enchufe, ¡aquí viene la facturación! Solía ser, pero ahora es arcaico, y tales dinosaurios ya se han extinguido o se están extinguiendo. Inicialmente, la facturación es un sistema de facturación: un lector o una calculadora. En las telecomunicaciones modernas, este es
un sistema de automatización para todo el ciclo de vida de la interacción con el suscriptor desde la conclusión del contrato hasta la terminación , incluida la facturación en tiempo real, la aceptación de pagos y mucho más. La facturación en las compañías de telecomunicaciones es similar a un robot de combate: grande, poderoso y lleno de armas.
¿Y aquí está Tarantool?
Oleg Ivlev y
Andrey Knyazev hablarán sobre esto. Oleg es el arquitecto jefe de
MegaFon con una amplia experiencia trabajando en empresas extranjeras, Andrey es el director de sistemas comerciales. A partir de la transcripción de su informe en la
Conferencia de Tarantool 2018, aprenderá por qué se necesita investigación y desarrollo en las corporaciones, qué es Tarantool, cómo el punto muerto para la escala vertical y la globalización se convirtieron en los requisitos previos para el surgimiento de esta base de datos en la empresa, sobre los desafíos tecnológicos, la transformación de la arquitectura y cómo el tecnostek de MegaFon se asemeja a Netflix, Google y Amazon.
Proyecto de facturación única
El proyecto que se discutirá se llama "Facturación única". Fue en él que Tarantool mostró sus mejores cualidades.
El crecimiento del rendimiento de los equipos Hi-End no siguió el ritmo del crecimiento de la base de suscriptores y el crecimiento en la cantidad de servicios, se esperaba un mayor crecimiento en la cantidad de suscriptores y servicios debido a M2M, IoT, y las características de las sucursales llevaron a un deterioro del tiempo de comercialización. La compañía decidió crear un sistema comercial unificado con una arquitectura modular única de clase mundial, en lugar de 8 sistemas de facturación diferentes actuales.
MegaFon es ocho empresas en una . En 2009, se completó la reorganización: las sucursales en toda Rusia se fusionaron en una sola compañía MegaFon OJSC (ahora PJSC). Por lo tanto, la empresa cuenta con 8 sistemas de facturación con sus propias soluciones "personalizadas", características de sucursal y una estructura organizativa, TI y marketing diferente.
Todo estuvo bien hasta que tuve que lanzar un producto federal común. Aquí aparecieron muchas dificultades: para algunos, aranceles con redondeo, para otros, en menor medida, y para otros, de acuerdo con la media aritmética. Hay miles de esos momentos.
A pesar de que la versión del sistema de facturación es la misma, un proveedor, las configuraciones divergieron para que el pegamento durante mucho tiempo. Intentamos reducir su número y encontramos un segundo problema que es familiar para muchas corporaciones.
Escalado vertical . Incluso el hierro más fresco en ese momento no satisfizo las necesidades. Utilizamos el equipo Hewlett-Packard, la línea Superdome Hi-End, pero no supuso la necesidad de incluso dos sucursales. Quería escala horizontal sin grandes costos de transacción e inversiones de capital.
Expectativa de crecimiento en el número de suscriptores y servicios . Los consultores han traído historias sobre IoT y M2M al mundo de las telecomunicaciones: llegará un momento en que cada teléfono y plancha tendrán una tarjeta SIM y dos en el refrigerador. Hoy tenemos un número de suscriptores, y en un futuro próximo habrá un orden de magnitud más.
Desafíos tecnológicos
Estas cuatro razones nos llevaron a cambios importantes. Había una opción entre actualizar el sistema y diseñar desde cero. Pensaron durante mucho tiempo, tomaron decisiones serias, jugaron licitaciones. Como resultado, decidieron diseñar desde el principio y asumieron desafíos interesantes: desafíos tecnológicos.
Escalabilidad
Si antes había, digamos,
8 cuentas de facturación para 15 millones de suscriptores , y ahora deberían haber resultado
100 millones de suscriptores y más : la carga es un orden de magnitud mayor.
Nos hemos convertido en una escala comparable a los principales jugadores de Internet como Mail.ru o Netflix.
Pero nuevos movimientos para aumentar la carga y la base de suscriptores nos plantearon serios 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 con tales demoras las distancias ya son significativas. 150 ms en los mejores canales ópticos modernos es un poco demasiado para la facturación en tiempo real, especialmente porque ahora está en las telecomunicaciones en Rusia. Además, debe actualizar en un día hábil y con diferentes zonas horarias; esto es un problema.
No solo brindamos servicios por una tarifa mensual, tenemos tarifas complejas, paquetes y varios modificadores. No solo necesitamos permitir o prohibir que el suscriptor hable, sino también darle una cierta cuota: calcular llamadas y acciones en tiempo real para que no se dé cuenta.
Tolerancia a fallos
Este es el otro lado de la centralización.
Si reunimos a todos los suscriptores en un sistema, cualquier evento de emergencia y desastre es desastroso para los negocios. Por lo tanto, diseñamos el sistema de tal manera que excluya el efecto de los accidentes en toda la base de suscriptores.
Esto es nuevamente una consecuencia del rechazo de la escala vertical. Cuando entramos en la escala horizontal, aumentamos la cantidad de servidores de cientos a miles. Deben ser gestionados e intercambiables, respaldados automáticamente por la infraestructura de TI y restaurado el sistema distribuido.
Tales desafíos interesantes nos confrontaron. Diseñamos el sistema, y en ese momento tratamos de encontrar las mejores prácticas del mundo para verificar cuánto estamos en tendencia, cuánto seguimos las tecnologías avanzadas.
Experiencia mundial
Sorprendentemente, en el mundo de las telecomunicaciones no encontramos una sola referencia.
Europa cayó por el número de suscriptores y la escala, los Estados Unidos, por el plano de sus tarifas. Buscamos algo en China, pero encontramos algo en India y tomamos especialistas de Vodafone India.
Para analizar la arquitectura, se formó el Dream Team, dirigido por IBM, arquitectos de diversos campos. Estas personas podrían evaluar adecuadamente lo que estamos haciendo y aportar cierto conocimiento a nuestra arquitectura.
Escala
Algunos números para ilustrar.
Diseñamos un sistema para
80 millones de suscriptores con una reserva de mil millones . Entonces eliminamos los umbrales futuros. Esto no se debe a que vamos a tomar China, sino a la presión de IoT y M2M.
Se procesan 300 millones de documentos en tiempo real . Aunque tenemos 80 millones de suscriptores, trabajamos con clientes potenciales y aquellos que nos dejaron si necesitamos cobrar cuentas por cobrar. Por lo tanto, los volúmenes reales son mucho más grandes.
2.000 millones de transacciones cambian diariamente el saldo: estos son pagos, cargos, llamadas y otros eventos.
200 TB de datos cambian activamente ,
8 PB de datos cambian un poco más lentamente, y esto no es un archivo, sino datos en vivo en una sola facturación. La escala del
centro de datos es de
5 mil servidores en 14 sitios .
Pila de tecnología
Cuando planificamos la arquitectura y comenzamos a ensamblar el sistema, importamos las tecnologías más interesantes y avanzadas. El resultado fue una pila tecnológica que es familiar para cualquier jugador de Internet y corporaciones que hacen sistemas altamente cargados.
La pila es similar a las pilas de otros jugadores importantes: Netflix, Twitter, Viber. Consta de 6 componentes, pero queremos reducirlo y unificarlo.
La flexibilidad es buena, pero en una gran corporación no hay forma sin unificación.
No vamos a cambiar el mismo Oracle a Tarantool. En las realidades de las grandes empresas, esto es una utopía, o una cruzada durante 5-10 años con un resultado incomprensible. Pero Cassandra y Couchbase se pueden reemplazar con Tarantool, y estamos comprometidos con esto.
¿Por qué Tarantool?
Hay 4 criterios simples por los que elegimos esta base de datos.
Velocidad . Realizamos pruebas de resistencia en sistemas industriales MegaFon. Tarantool ganó: mostró el mejor rendimiento.
Esto no quiere decir que otros sistemas no satisfagan las necesidades de MegaFon. Las soluciones de memoria actuales son tan productivas que este stock de la compañía es más que suficiente. Pero estamos interesados en tratar con el líder, y no con el que teje la cola, incluida la prueba de carga.
Tarantool cubre las necesidades de la empresa incluso a largo plazo.
Costo total de propiedad . El soporte para Couchbase en los volúmenes de MegaFon cuesta dinero espacial, con Tarantool la situación es mucho mejor, y en términos de funcionalidad están cerca.
Otra buena característica que influyó ligeramente en nuestra elección: Tarantool funciona mejor que otras bases de datos con memoria. Muestra la
máxima eficiencia .
Fiabilidad MegaFon está invertido en confiabilidad, probablemente como ningún otro. Por lo tanto, cuando miramos Tarantool, nos dimos cuenta de lo que hay que hacer para que cumpla con nuestros requisitos.
Invertimos nuestro tiempo y finanzas, y junto con Mail.ru creamos una versión empresarial, que ahora utilizan otras compañías.
Tarantool-enterprise nos satisfizo por completo con seguridad, confiabilidad y registro.
Asociación
Lo más importante para mí es
el contacto directo con el desarrollador . Esto es exactamente lo que los chicos de Tarantool sobornaron.
Si vienes a un jugador, especialmente a uno que trabaja con un cliente ancla, y dices que necesitas la base de datos para poder hacer esto, esto y aquello, generalmente responde:
- Bueno, pon los requisitos debajo de ese montón; algún día, probablemente, los alcanzaremos.Muchos tienen una hoja de ruta para los próximos 2-3 años, y es casi imposible integrarse allí, y los desarrolladores de Tarantool sobornan con apertura, y no solo con MegaFon, y adaptan su sistema al cliente. Esto es genial y realmente nos gusta.
¿Dónde aplicamos Tarantool?
En nosotros Tarantool se usa en varios elementos.
El primero está en el piloto , que hicimos en el sistema de directorio de direcciones. En un momento, quería que fuera un sistema similar a Yandex.Maps y Google Maps, pero resultó un poco diferente.
Por ejemplo, el directorio de direcciones en la interfaz de ventas. En Oracle, encontrar la dirección que necesita tarda entre 12 y 13 s. - números incómodos. Cuando cambiamos a Tarantool, reemplazamos Oracle con otra base de datos en la consola y realizamos la misma búsqueda, ¡obtenemos 200 veces la aceleración! La ciudad aparece después de la tercera letra. Ahora estamos adaptando la interfaz para que esto ocurra después del primero. Sin embargo, la velocidad de respuesta es completamente diferente: ya es milisegundos en lugar de segundos.
La segunda aplicación es un tema de moda llamado TI de dos velocidades . Esto se debe a que los consultores de cada hierro dicen que las corporaciones deberían ir allí.
Hay una capa de infraestructura, dominios por encima, por ejemplo, un sistema de facturación, como telecomunicaciones, sistemas corporativos, informes corporativos. Este es el núcleo que no necesita ser tocado. Eso es, por supuesto, posible, pero paranoico en proporcionar calidad, porque aporta dinero a la corporación.
Luego viene la capa de microservicios, la que diferencia al operador u otro jugador. Los microservicios se pueden crear rápidamente sobre la base de ciertos cachés, levantando datos de diferentes dominios allí. Aquí hay un
campo para experimentos : si algo no funcionó, cerró un microservicio y abrió otro. Esto proporciona un tiempo de comercialización verdaderamente mejorado y aumenta la fiabilidad y la velocidad de la empresa.
Los microservicios son quizás el papel principal de Tarantool en MegaFon.
Donde planeamos aplicar Tarantool
Si comparamos nuestro exitoso proyecto de facturación con programas de transformación en Deutsche Telekom, Svyazkome, Vodafone India, es sorprendentemente dinámico y creativo. En el proceso de implementación de este proyecto, no solo se transformaron MegaFon y su estructura, sino que también apareció Tarantool-enterprise en Mail.ru, y nuestro proveedor Nexign (anteriormente Peter-Service) tenía un BSS Box (solución de facturación en caja).
En cierto sentido, este es un proyecto histórico para el mercado ruso. Se puede comparar con lo que se describe en el libro de Frederick Brooks "Mythical Man-Month". Luego, en los años 60, IBM atrajo a 5,000 personas para desarrollar un nuevo sistema operativo OS / 360 para mainframes. Tenemos menos - 1,800, pero los nuestros están en chalecos, y teniendo en cuenta el uso de código abierto y nuevos enfoques, trabajamos de manera más productiva.
Los dominios de facturación o, más ampliamente, los sistemas empresariales se muestran a continuación. Las personas en la empresa conocen muy bien el CRM. Todos deberían tener otros sistemas: Open API, Gateway API.
API abierta
Veamos nuevamente los números y cómo funciona la API abierta ahora. Su carga es de
10.000 transacciones por segundo . Como planeamos desarrollar activamente la capa de microservicio y construir la API pública MegaFon, esperamos un mayor crecimiento en el futuro en esta parte en particular.
100,000 transacciones definitivamente serán .
No sé si el SSO es comparable a Mail.ru: los chicos, como, tienen 1,000,000 de transacciones por segundo. Estamos extremadamente interesados en su solución y planeamos aprender de su experiencia, por ejemplo, para hacer una reserva de SSO funcional utilizando Tarantool. Ahora los desarrolladores de Mail.ru están haciendo esto con nosotros.
CRM
CRM: estos son los 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 es una pelota que crecerá, porque habrá más y más servicios. En consecuencia, se necesitará una historia, no queremos tropezar con esto.
Facturarse a sí mismo en términos de facturación, trabajar con las cuentas por cobrar de los clientes se
transformó en un dominio separado . Para maximizar el rendimiento,
se aplica la plantilla arquitectónica de arquitectura de dominio .
El sistema se divide en dominios, la carga se distribuye y se proporciona tolerancia a fallas. Además, trabajamos con arquitectura distribuida.
Todo lo demás son soluciones de nivel empresarial. En la tienda de llamadas:
2 mil millones por día , 60 mil millones por mes. A veces tienes que contarlos por un mes, y mejor rápidamente.
El monitoreo financiero es precisamente los 300 millones que crecen y crecen constantemente: los suscriptores a menudo corren entre operadores, lo que aumenta esta parte.
El componente más telecom de las comunicaciones móviles es
la facturación en línea . Estos son los sistemas que le permiten llamar o no llamar, tomar una decisión en tiempo real. Aquí, la carga es de 30,000 transacciones por segundo, pero teniendo en cuenta el crecimiento en la transferencia de datos, planificamos
250,000 transacciones y, por lo tanto, estamos muy interesados en Tarantool.
La imagen anterior es los dominios donde vamos a usar Tarantool. El CRM en sí mismo, por supuesto, es más amplio y lo vamos a aplicar en el núcleo mismo.
Nuestro TTX estimado de 100 millones de suscriptores me confunde como arquitecto, ¿y si 101 millones? ¿Rehacer todo de nuevo? Para evitar esto, utilizamos cachés, al mismo tiempo que aumenta la accesibilidad.
En general, hay dos enfoques para usar Tarantool. El primero es
construir todas las memorias caché en el nivel de microservicio . Según tengo entendido, VimpelCom sigue este camino, creando un caché de cliente.
Dependemos menos de los proveedores, estamos cambiando el núcleo de BSS, por lo que tenemos un índice de tarjeta de cliente único listo para usar. Pero queremos bordarlo. Por lo tanto, usamos un enfoque ligeramente diferente:
hacemos cachés dentro de los sistemas .
Por lo tanto, hay menos de un rassynchron: un sistema es responsable tanto de la memoria caché como de la fuente maestra principal.
El método encaja bien con el enfoque de esqueleto transaccional de Tarantool, cuando solo se actualizan las partes relacionadas con las actualizaciones, es decir, los cambios de datos. Todo lo demás se puede almacenar en otro lugar. No hay un gran lago de datos, caché global no administrado. Los cachés están diseñados para el sistema, ya sea para productos o para clientes, o para facilitar la vida del servicio. Cuando un suscriptor llama molesto por la calidad, quiero servirlo cualitativamente.
RTO y RPO
Hay dos términos en TI:
RTO y
RPO .
El objetivo del tiempo de recuperación es el tiempo para recuperar un servicio después de una falla. RTO = 0 significa que incluso si algo cae, el servicio continúa funcionando.
El objetivo del punto de recuperación es el tiempo para recuperar datos, cuántos datos podemos perder en un período de tiempo. RPO = 0 significa que no estamos perdiendo datos.
Desafío de Tarantool
Intentemos resolver el problema de Tarantool.
Dado : todos entienden la cesta de aplicaciones, por ejemplo, en Amazon o en otro lugar.
Se requiere que la canasta trabaje las 24 horas, los 7 días de la semana, o el 99.99% del tiempo. Los pedidos que nos llegan deben mantener el orden, porque no podemos habilitar o deshabilitar al azar la comunicación para el suscriptor; todo debe ser estrictamente coherente. La suscripción anterior afecta a la siguiente, por lo que los datos son importantes: no se debe perder nada.
Solución Puede intentar resolverlo de frente y preguntar a los desarrolladores de la base de datos, pero el problema no se resuelve matemáticamente. Uno puede recordar teoremas, leyes de conservación, física cuántica, pero por qué, no se puede resolver a nivel DB.
El buen enfoque arquitectónico antiguo funciona aquí: debe conocer bien el área temática y, a su costa, resolver este acertijo.
Nuestra solución: crear un registro distribuido de aplicaciones para Tarantool, un clúster geodistribuido . En el diagrama, estos son tres centros de datos diferentes: dos para los Urales, uno más allá de los Urales, y distribuimos todas las aplicaciones a estos centros.
Netflix, que ahora se considera uno de los líderes en TI, solo tenía un centro de datos hasta 2012. En la víspera de la Navidad católica el 24 de diciembre, este centro de datos se cayó. Los usuarios de Canadá y Estados Unidos se quedaron sin sus películas favoritas, muy molestos y escribieron sobre esto en las redes sociales. Netflix ahora tiene tres centros de datos en la costa oeste-este y uno en Europa occidental.
Inicialmente creamos una solución geo-distribuida: la tolerancia a fallas es importante para nosotros.
Entonces, tenemos un clúster, pero ¿qué pasa con RPO = 0 y RTO = 0? La solución es simple, que depende del tema.
¿Qué es importante en las aplicaciones? Dos partes: tirar la canasta
ANTES de tomar una decisión de compra y
DESPUÉS . Una parte de DO en una telecomunicación generalmente se llama
captura de órdenes o
negociación de órdenes . En telecomunicaciones, esto puede ser mucho más complicado que en la tienda en línea, porque allí debe atender al cliente, ofrecer 5 opciones, y todo esto sucede por un tiempo, pero la canasta está llena. En este punto, es posible una falla, pero no da miedo, porque ocurre de manera interactiva bajo la supervisión de una persona.
Si el centro de datos de Moscú falla repentinamente y luego cambia automáticamente a otro centro de datos, continuaremos trabajando. Teóricamente, un producto en una cesta puede perderse, pero usted ve esto, complemente la cesta nuevamente y continúe trabajando. En este caso, RTO = 0.
En el mismo momento, hay una segunda opción: cuando hacemos clic en "enviar", queremos que los datos no se pierdan. A partir de este momento, la automatización comienza a funcionar: esto ya es RPO = 0. La aplicación de estos dos patrones diferentes en un caso puede ser solo un clúster geodistribuido con un maestro conmutable, en el otro caso algún tipo de entrada de quórum. Los patrones pueden variar, pero resolvemos el problema.
Además, al tener un registro distribuido de aplicaciones, también podemos escalarlo todo, para tener muchos despachadores y contratistas que acceden a este registro.
Cassandra y Tarantool juntas
Hay otro caso: el
"escaparate de los equilibrios" . Este es solo un caso interesante del uso conjunto de Cassandra y Tarantool.
Usamos Cassandra, porque 2 mil millones de llamadas por día no es el límite, y habrá más. A los vendedores les encanta colorear el tráfico por fuente, por ejemplo, cada vez hay más detalles en las redes sociales. Todo esto aumenta la historia.
Cassandra le permite escalar horizontalmente a cualquier volumen.
Nos sentimos cómodos con Cassandra, pero ella tiene un problema: no es buena para leer. , 30 000 —
.
, : , - , Cassandra. , IBM manager file transfer — , , UDP, , TCP. , , , - , — .
,
. Kafka Tarantool, , , ,
, , , 100 2 .
, 2 , , .
Conclusión
Tarantool. Mail.ru, .
BCG McKinsey, Accenture IBM - — , , , , . , Tarantool . .
— Tarantool Conference , 17 T+ Conference 2019 « Tarantool Enterprise» . « Tarantool Oracle» . , , . — , . : , Tarantool, , , .