¿Por qué una corporación como MegaFon necesita Tarantool en la facturación? Desde fuera parece que el vendedor suele venir, trae una especie de caja grande, enchufa el enchufe a la toma de corriente y ¡ya está la facturación! Esto fue así alguna vez, pero ahora es arcaico y estos dinosaurios ya se han extinguido o se están extinguiendo. Inicialmente, la facturación es un sistema para emitir facturas: una máquina contadora o una calculadora. En las telecomunicaciones modernas esto es sistema de automatización para todo el ciclo de vida de la interacción con un suscriptor desde la celebración del contrato hasta la terminación, incluida facturación en tiempo real, aceptación de pagos y mucho más. La facturación en las empresas de telecomunicaciones es como un robot de combate: grande, potente y cargado de armas.
¿Qué tiene que ver Tarantool con esto? hablarán de eso Oleg Ivlev и Andrey knyazev. Oleg es el arquitecto jefe de la empresa. Con amplia experiencia trabajando en empresas extranjeras, Andrey es director de sistemas empresariales. De la transcripción de su informe sobre aprenderá por qué se necesita I + D en las corporaciones, qué es Tarantool, cómo el estancamiento del escalamiento vertical y la globalización se convirtieron en los requisitos previos para la aparición de esta base de datos en la empresa, sobre los desafíos tecnológicos, la transformación arquitectónica y en qué se parece el Technostack de MegaFon a Netflix. , Google y Amazon.
Proyecto "Facturación Unificada"
El proyecto en cuestión se llama “Facturación Unificada”. Fue aquí donde Tarantool mostró sus mejores cualidades.
El crecimiento de la productividad de los equipos de alta gama no siguió el ritmo del crecimiento de la base de suscriptores y del número de servicios; se esperaba un mayor crecimiento en el número de suscriptores y servicios debido a las características de M2M, IoT y sucursales. a un deterioro del time-to-market. La empresa decidió crear un sistema empresarial unificado con una arquitectura modular única de clase mundial, en lugar de los 8 sistemas de facturación diferentes actuales.
MegaFon son ocho empresas en una.. En 2009, se completó la reorganización: las sucursales en toda Rusia se fusionaron en una sola empresa, MegaFon OJSC (ahora PJSC). Así, la empresa cuenta con 8 sistemas de facturación con soluciones propias “a medida”, características de sucursal y diferentes estructuras organizativas, informáticas y de marketing.
Todo iba bien hasta que tuvimos que lanzar un producto federal común. Aquí surgieron muchas dificultades: para algunos, las tarifas se redondean hacia arriba, para otros, hacia abajo y para otros, según la media aritmética. Hay miles de momentos así.
A pesar de que solo había una versión del sistema de facturación, un proveedor, las configuraciones divergían tanto que llevó mucho tiempo armarlas. Intentamos reducir su número y nos topamos con un segundo problema que resulta familiar para muchas corporaciones.
Escalado vertical. Incluso el hardware más moderno de la época no cubría las necesidades. Utilizamos equipos Hewlett-Packard de la línea Superdome Hi-End, pero no cubrían las necesidades ni siquiera de dos sucursales. Quería escalamiento horizontal sin grandes costos operativos ni inversiones de capital.
Expectativa de crecimiento en el número de suscriptores y servicios. Los consultores llevan mucho tiempo trayendo historias sobre IoT y M2M al mundo de las telecomunicaciones: llegará el 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, pero en un futuro próximo habrá muchos más.
Desafíos tecnológicos
Estas cuatro razones nos motivaron a realizar cambios serios. Había que elegir entre actualizar el sistema o diseñarlo desde cero. Pensamos durante mucho tiempo, tomamos decisiones serias, jugamos licitaciones. Por eso decidimos diseñar desde el principio y asumimos desafíos interesantes: desafíos tecnológicos.
Escalabilidad
Si fue antes digamos, digamos 8 facturaciones para 15 millones de suscriptores, y ahora debería haber funcionado 100 millones de suscriptores y más - la carga es un orden de magnitud mayor.
Nos hemos vuelto comparables en escala a los grandes actores de Internet como Mail.ru o Netflix.
Pero el mayor movimiento para aumentar la carga y la base de suscriptores nos ha planteado serios desafíos.
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 tales distancias los retrasos ya son importantes. 150 ms en los canales ópticos más modernos es demasiado para la facturación en tiempo real, especialmente ahora que ocurre en las telecomunicaciones en Rusia. Además, es necesario actualizar en un día hábil, y con diferentes zonas horarias esto es un problema.
No solo brindamos servicios por una tarifa de suscripción, tenemos tarifas, paquetes y varios modificadores complejos. No solo debemos permitir o negar 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
Ésta es la otra cara de la centralización.
Si reunimos a todos los suscriptores en un solo sistema, cualquier emergencia o desastre será desastroso para los negocios. Por lo tanto, diseñamos el sistema de tal manera que elimine el impacto de los accidentes en toda la base de suscriptores.
Esto es nuevamente una consecuencia de la negativa a escalar verticalmente. Cuando escalamos horizontalmente, aumentamos la cantidad de servidores de cientos a miles. Deben ser administrados e intercambiables, realizar una copia de seguridad automática de la infraestructura de TI y restaurar el sistema distribuido.
Nos enfrentamos a desafíos tan interesantes. Diseñamos el sistema y en ese momento intentamos encontrar las mejores prácticas globales para comprobar qué tan en tendencia estamos, cuánto seguimos las tecnologías avanzadas.
Experiencia mundial
Sorprendentemente, no encontramos ni una sola referencia en las telecomunicaciones globales.
Europa ha caído en términos de número de abonados y escala, EE.UU. en términos de uniformidad de sus tarifas. Buscamos algunos en China, encontramos algunos en India y contratamos especialistas de Vodafone India.
Para analizar la arquitectura, reunimos un Dream Team liderado por IBM: arquitectos de diferentes campos. Estas personas podían evaluar adecuadamente lo que estábamos haciendo y aportar ciertos conocimientos a nuestra arquitectura.
escala
Algunos números a modo de ilustración.
Diseñamos el sistema para 80 millones de suscriptores con una reserva de mil millones. Así es como eliminamos los umbrales futuros. Esto no se debe a que vayamos a apoderarnos de China, sino al ataque de IoT y M2M.
300 millones de documentos procesados en tiempo real. Aunque tenemos 80 millones de suscriptores, trabajamos tanto con clientes potenciales como con aquellos que nos han dejado si necesitamos cobrar cuentas por cobrar. Por lo tanto, los volúmenes reales son notablemente mayores.
2 mil millones de transacciones El saldo cambia a diario: se trata de pagos, cargos, llamadas y otros eventos. 200 TB de datos están cambiando activamente, cambia un poco más lento 8 PB de datos, y esto no es un archivo, sino datos en vivo en una sola facturación. Escalar por centro de datos - 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 es una pila de tecnología familiar para cualquier actor de Internet y corporaciones que fabrican sistemas de alta carga.
La pila es similar a la de otros jugadores importantes: Netflix, Twitter, Viber. Consta de 6 componentes, pero queremos acortarlo y unificarlo.
La flexibilidad es buena, pero en una gran corporación no hay manera sin unificación.
No vamos a cambiar el mismo Oracle por Tarantool. En la realidad de las grandes empresas, esto es una utopía o una cruzada de 5 a 10 años con un resultado incierto. Pero Cassandra y Couchbase se pueden reemplazar fácilmente con Tarantool, y eso es por lo que nos esforzamos.
¿Por qué Tarantool?
Hay 4 criterios simples por los que elegimos esta base de datos.
velocidad. Realizamos pruebas de carga en los sistemas industriales MegaFon. Tarantool ganó: mostró el mejor desempeño.
Esto no quiere decir que otros sistemas no satisfagan las necesidades de MegaFon. Las soluciones de memoria actuales son tan productivas que las reservas de la empresa son más que suficientes. Pero nos interesa tratar con un líder y no con alguien que se queda atrás, incluso en 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 MegaFon cuesta cantidades astronómicas de dinero, pero con Tarantool la situación es mucho más agradable y tienen una funcionalidad similar.
Otra característica interesante que influyó ligeramente en nuestra elección es que Tarantool funciona mejor con la memoria que otras bases de datos. Él muestra Máxima eficiencia.
Confiabilidad. MegaFon invierte en confiabilidad, probablemente más que nadie. Entonces, cuando analizamos Tarantool, nos dimos cuenta de que teníamos que adaptarlo a nuestros requisitos.
Invertimos nuestro tiempo y dinero y, junto con Mail.ru, creamos una versión empresarial que ahora se utiliza en varias otras empresas.
Tarantool-enterprise nos satisfizo completamente en términos de seguridad, confiabilidad y registro.
Asociación
Lo más importante para mí es contacto directo con el desarrollador. Esto es exactamente con lo que sobornaron a los chicos de Tarantool.
Si te acercas a un jugador, especialmente uno que trabaja con un cliente ancla, y le dices que necesitas la base de datos para poder hacer esto, esto y esto, normalmente responde:
- Bien, ponga los requisitos al final de esa pila; algún día, probablemente los alcanzaremos.
Muchos tienen una hoja de ruta para los próximos 2 o 3 años y es casi imposible integrarse allí, pero los desarrolladores de Tarantool cautivan con su apertura, y no solo de MegaFon, y adaptan su sistema al cliente. Es genial y nos gusta mucho.
Donde usamos Tarantool
Usamos Tarantool en varios elementos. El primero está en el piloto., que hicimos en el sistema de directorio de direcciones. Hubo un tiempo en que quería 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 tarda entre 12 y 13 segundos. - 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 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 del primero. Sin embargo, la velocidad de respuesta es completamente diferente: milisegundos en lugar de segundos.
La segunda aplicación es un tema de moda llamado TI de dos velocidades.. Esto se debe a que consultores de todos los rincones dicen que las corporaciones deberían ir allí.
Hay una capa de infraestructura, encima hay dominios, por ejemplo, un sistema de facturación como el de telecomunicaciones, sistemas corporativos, informes corporativos. Este es el núcleo que no necesita ser tocado. Eso es, por supuesto, posible, pero garantizando paranoicamente la calidad, porque aporta dinero a la corporación.
Luego viene la capa de microservicios, lo que diferencia al operador de otro jugador. Se pueden crear rápidamente microservicios basados en ciertos cachés, trayendo allí datos de diferentes dominios. Aquí campo para experimentos — si algo no funcionaba, cerraba un microservicio y abría otro. Esto proporciona un tiempo de comercialización realmente mayor y aumenta la confiabilidad y velocidad de la empresa.
Los microservicios son quizás el papel principal de Tarantool en MegaFon.
Dónde planeamos utilizar Tarantool
Si comparamos nuestro exitoso proyecto de facturación con los programas de transformación de Deutsche Telekom, Svyazcom y Vodafone India, resulta 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 (antes Peter-Service) - BSS Box (una solución de facturación en caja).
Se trata, en cierto sentido, de un proyecto histórico para el mercado ruso. Se puede comparar con lo que se describe en el libro “El mes del hombre mítico” de Frederick Brooks. Luego, en los años 60, IBM contrató a 360 personas para desarrollar el nuevo sistema operativo OS/5 para mainframes. Tenemos menos: 000, pero los nuestros son inversiones y, teniendo en cuenta el uso de código abierto y nuevos enfoques, trabajamos de manera más productiva.
A continuación se detallan los dominios de la facturación o, más ampliamente, los sistemas empresariales. La gente de la empresa conoce muy bien el CRM. Todo el mundo debería tener ya otros sistemas: Open API, API Gateway.
API abierta
Veamos los números nuevamente y cómo funciona actualmente la Open API. Su carga es 10 transacciones por segundo. Dado que planeamos desarrollar activamente la capa de microservicios y construir la API pública de MegaFon, esperamos un mayor crecimiento en el futuro en esta parte. Definitivamente habrá 100 transacciones..
No sé si podemos compararlo con Mail.ru en SSO: los chicos parecen tener 1 de transacciones por segundo. Su solución es extremadamente interesante para nosotros y planeamos adoptar su experiencia, por ejemplo, haciendo una copia de seguridad SSO funcional usando Tarantool. Ahora los desarrolladores de Mail.ru están haciendo esto por nosotros.
CRM
CRM son los mismos 80 millones de suscriptores que queremos aumentar a mil millones, porque ya hay 300 millones de documentos que incluyen una historia de tres años. Estamos ansiosos por nuevos servicios y aquí El punto de crecimiento son los servicios conectados.. Esta es una pelota que irá creciendo, porque cada vez habrá más servicios. En consecuencia, necesitaremos una historia; no queremos toparnos con ella.
Facturación propia en términos de emisión de facturas, trabajo con cuentas por cobrar de clientes. transformado en un dominio separado. Para mejorar el rendimiento, patrón arquitectónico de arquitectura de dominio aplicada.
El sistema se divide en dominios, la carga se distribuye y se garantiza la tolerancia a fallos. Además, trabajamos con arquitectura distribuida.
Todo lo demás son soluciones de nivel empresarial. En el almacenamiento de llamadas - 2 mil millones por día, 60 mil millones por mes. A veces hay que contarlos en un mes y es mejor rápidamente. Seguimiento financiero - Estos son exactamente los mismos 300 millones que crecen y crecen constantemente: los suscriptores a menudo corren entre operadores, lo que aumenta esta parte.
El componente más telecomunicaciones de las comunicaciones móviles es arancelización en línea. Estos son los sistemas que te permiten llamar o no llamar, tomar decisiones en tiempo real. Aquí la carga es de 30 transacciones por segundo, pero teniendo en cuenta el crecimiento de la transferencia de datos, planeamos 250 transacciones, y por eso estamos muy interesados en Tarantool.
La imagen anterior son los dominios donde vamos a utilizar Tarantool. El CRM en sí, por supuesto, es más amplio y lo vamos a utilizar en el propio núcleo.
Nuestra cifra TTX estimada de 100 millones de suscriptores me confunde como arquitecto: ¿y si 101 millones? ¿Tienes que rehacer todo de nuevo? Para evitar que esto suceda, utilizamos cachés, al mismo tiempo que aumentamos la accesibilidad.
En general, existen dos enfoques para utilizar Tarantool. Primero - construir todos los cachés a nivel de microservicio. Según tengo entendido, VimpelCom está siguiendo este camino, creando un caché de clientes.
Dependemos menos de los proveedores, estamos cambiando el núcleo BSS, por lo que tenemos un único archivo de cliente listo para usar. Pero queremos ampliarlo. Por lo tanto, adoptamos un enfoque ligeramente diferente: hacer cachés dentro de los sistemas.
De esta manera hay menos sincronización: un sistema es responsable tanto del caché como de la fuente maestra principal.
El método encaja bien con el enfoque de Tarantool con un esqueleto transaccional, cuando solo se actualizan las partes relacionadas con las actualizaciones, es decir, los cambios de datos. Todo lo demás se puede guardar en otro lugar. No existe un gran lago de datos ni un caché global no administrado. Los cachés están diseñados para el sistema, o para productos, o para clientes, o para facilitar el mantenimiento. Cuando un suscriptor llama y está molesto por la calidad de su servicio, desea brindarle un servicio de calidad.
RTO y RPO
Hay dos términos en TI: RTO и RPO.
Objetivo de tiempo de recuperación es el tiempo que lleva restaurar el servicio después de una falla. RTO = 0 significa que incluso si algo falla, el servicio continúa funcionando.
Objetivo del punto de recuperación - este es el tiempo de recuperación de datos, cuántos datos podemos perder durante un período de tiempo determinado. RPO = 0 significa que no estamos perdiendo datos.
Tarea de Tarantool
Intentemos resolver un problema para Tarantool.
Dado: una cesta de aplicaciones que todo el mundo entiende, por ejemplo, en Amazon o en otro lugar. Necesario para que el carrito de compras funcione las 24 horas los 7 días de la semana, o el 99,99% del tiempo. Las órdenes que nos llegan deben permanecer en orden, porque no podemos encender o apagar la conexión del suscriptor al azar; todo debe ser estrictamente consistente. La suscripción anterior afecta a la siguiente, por lo que los datos son importantes: no debería faltar nada.
Solución. Puedes intentar resolverlo de frente y preguntar a los desarrolladores de la base de datos, pero el problema no se puede resolver matemáticamente. Puedes recordar teoremas, leyes de conservación, física cuántica, pero por qué no se puede resolver en el nivel DB.
El viejo enfoque arquitectónico funciona aquí: es necesario conocer bien el área temática y utilizarla para resolver este rompecabezas.
Nuestra solución: crear un registro distribuido de aplicaciones en Tarantool: un clúster distribuido geográficamente. En el diagrama, estos son tres centros de procesamiento de datos diferentes: dos frente a los Urales, uno más allá de los Urales, y distribuimos todas las solicitudes entre estos centros.
Netflix, que ahora se considera uno de los líderes en TI, solo tenía un centro de datos hasta 2012. En vísperas de la Navidad católica, el 24 de diciembre, este centro de datos dejó de funcionar. Usuarios de Canadá y Estados Unidos se quedaron sin sus películas favoritas, se molestaron mucho y escribieron al respecto en las redes sociales. Netflix tiene ahora tres centros de datos en la costa oeste-este y uno en Europa occidental.
Inicialmente estamos construyendo una solución distribuida geográficamente; la tolerancia a fallos es importante para nosotros.
Entonces tenemos un clúster, pero ¿qué pasa con RPO = 0 y RTO = 0? La solución es sencilla, dependiendo del tema.
¿Qué es importante en las aplicaciones? Dos partes: lanzamiento de canasta A tomar una decisión de compra, y Despues. La parte DO en telecomunicaciones generalmente se llama captura de orden o negociación de pedidos. En telecomunicaciones esto puede ser mucho más difícil que en una tienda online, porque allí hay que atender al cliente, ofrecerle 5 opciones, y todo esto sucede durante un tiempo, pero la cesta está llena. En este momento, es posible que se produzca un fallo, pero no da miedo, porque ocurre de forma interactiva bajo la supervisión humana.
Si el centro de datos de Moscú falla repentinamente, al cambiar automáticamente a otro centro de datos, continuaremos trabajando. En teoría, un producto puede perderse en el carrito, pero lo ves, lo vuelves a agregar al carrito y continúas trabajando. En este caso RTO = 0.
Al mismo tiempo, existe 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 es RPO = 0. Usando estos dos patrones diferentes, en un caso podría ser simplemente un clúster distribuido geográficamente con un maestro conmutable, en otro caso, algún tipo de registro de quórum. Los patrones pueden variar, pero solucionamos el problema.
Además, al tener un registro distribuido de aplicaciones, también podemos escalarlo todo: tener muchos despachadores y ejecutores que acceden a este registro.
Cassandra y Tarantool juntos
Hay otro caso - "vitrina de balanzas". He aquí 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 especialistas en marketing les encanta colorear el tráfico por fuente; cada vez aparecen más detalles en las redes sociales, por ejemplo. Todo se suma a la historia.
Cassandra te permite escalar horizontalmente a cualquier tamaño.
Nos sentimos cómodos con Cassandra, pero tiene un problema: no es buena leyendo. Todo está bien en la grabación, 30 por segundo no es un problema. problema de lectura.
Por lo tanto, apareció un tema con un caché, y al mismo tiempo resolvimos el siguiente problema: hay un viejo caso tradicional en el que el equipo de un cambio de facturación en línea ingresa a los archivos que cargamos en Cassandra. Luchamos con el problema de la descarga confiable de estos archivos, incluso siguiendo el consejo del administrador de transferencia de archivos de IBM: existen soluciones que administran la transferencia de archivos de manera eficiente, utilizando el protocolo UDP, por ejemplo, en lugar de TCP. Esto es bueno, pero aún son minutos y aún no lo hemos cargado todo, el operador del centro de llamadas no puede responderle al cliente qué pasó con su saldo; tenemos que esperar.
Para evitar que esto suceda, nosotros utilizamos reserva funcional paralela. Cuando enviamos un evento a través de Kafka a Tarantool, recalculando agregados en tiempo real, por ejemplo, para hoy, obtenemos saldos de efectivo, que puede transferir saldos a cualquier velocidad, por ejemplo, 100 mil transacciones por segundo y esos mismos 2 segundos.
El objetivo es que después de realizar una llamada, en 2 segundos en su cuenta personal no solo aparezca el saldo modificado, sino también información sobre por qué cambió.
Conclusión
Estos fueron ejemplos del uso de Tarantool. Nos gustó mucho la apertura de Mail.ru y su disposición a considerar diferentes casos.
Ya es difícil para los consultores de BCG o McKinsey, Accenture o IBM sorprendernos con algo nuevo: gran parte de lo que ofrecen, ya lo hacemos, lo hemos hecho o planeamos hacerlo. Creo que Tarantool ocupará el lugar que le corresponde en nuestra pila de tecnología y reemplazará muchas tecnologías existentes. Nos encontramos en la fase activa de desarrollo de este proyecto.
El informe de Oleg y Andrey es uno de los mejores de la Conferencia Tarantool del año pasado, y el 17 de junio Oleg Ivlev hablará en con un informe . Alexander Deulin también hará una presentación de MegaFon . Averigüemos qué ha cambiado, qué planes se han implementado. Únase: la conferencia es gratuita, todo lo que tiene que hacer es . todos y se ha formado el programa de la conferencia: nuevos casos, nueva experiencia en el uso de Tarantool, arquitectura, empresa, tutoriales y microservicios.
Fuente: habr.com