Couchbase en Telecom

La transformación digital es una tendencia global para las grandes empresas y es vital para adaptar una empresa a las necesidades modernas de los clientes. Además de los problemas habituales de centralizar sistemas para grandes empresas y combinar sistemas de facturación y bases de datos de suscriptores, se agregan requisitos de alta disponibilidad y un modo de operación en tiempo real al que los clientes ya están acostumbrados por los líderes de la industria (Google, Amazon, Netflix).

Los nuevos desafíos requieren nuevas tecnologías y enfoques necesarios para reducir el tiempo de introducción de funciones convenientes para el cliente, ofertas comerciales personalizadas, respuesta rápida a las ofertas de la competencia, así como el control de costos para sistemas, infraestructura de TI, centros de datos y personal calificado. Estas tendencias también son un gran inconveniente: la complejidad de la arquitectura y las bases de datos transaccionales infladas que no pueden hacer frente al flujo y al procesamiento de la información. Las tecnologías de la generación anterior tienen un techo de escala vertical. Por ejemplo, una instancia de Oracle DBMS se ejecuta en el límite del servidor más potente en procesadores x86 con una carga de mil millones de transacciones por día.

Para soportar una carga similar a la que la industria de Internet ha estado enfrentando durante mucho tiempo, se utiliza una nueva pila de tecnologías, como cachés en memoria y bases de datos NoSQL. Entonces, Apple usa Cassandra, Sberbank - Ignite (GridGain), en MegaFon usamos Couchbase y Tarantool.

MegaFon usa diferentes patrones arquitectónicos para el DBMS en memoria:

1. Caché simple, actualizado según lo programado o por evento desde la base de datos y las aplicaciones
2. Todos los cambios en la base de datos se realizan a través de la memoria caché (secuencia de comandos de escritura), por ejemplo, conectando un cliente Oracle a DCP Couchbase

Para uno de nuestros sistemas de toma de decisiones para la vida del suscriptor, utilizamos la primera plantilla, ya que solo una aplicación sobre la totalidad de los datos toma una decisión y la envía a todos los sistemas, incluida la base de datos Oracle. Uno de los casos más brillantes de usar el ciclo de vida de un suscriptor es bloquear y desbloquear en un saldo negativo. Después de todo, todos los suscriptores de operadores móviles después de reponer el saldo desean estar en contacto de inmediato y hacer llamadas. Gracias a una aplicación separada y Couchbase, pudimos reducir el tiempo para salir de la cerradura de 90 segundos a 30 y este no es el límite. Solo el registro sobre el cambio en el estado del suscriptor ingresará a la base de datos principal (Fig. 1)

Con el uso de nuevas tecnologías, pudimos reducir 3 veces el tiempo para salir del bloqueo financiero. Pero para obtener los resultados actuales, hemos recorrido un largo camino en la transformación arquitectónica del circuito de facturación y en la elección de la base de datos NoSQL.

¿Por qué elegimos Couchbase? Hay varias razones para esto.

Requisito de rendimiento

1. Procesando hasta 200,000 solicitudes por segundo.
2. El tiempo de respuesta promedio (50%) es de hasta 5 ms (dentro de un solo centro de datos).
3. El tiempo de respuesta máximo (99%) es de hasta 15 ms (dentro de un centro de datos).
4. Máximo rendimiento de inserción 500 MB / seg.
5. Número máximo de operaciones de inserción 100,000 / s
6. Número máximo de operaciones de cambio (actualizaciones de documentos) 100,000 / s
7. Máximo rendimiento de los cambios (actualizaciones de documentos) 500 MB / seg.
8. Número máximo de operaciones de lectura 100,000 / s
9. Velocidad máxima de lectura 500 MB / seg.

Búsqueda de clave de alto rendimiento y acceso a datos

En el núcleo de Couchbase se encuentra Distributed Key Vault (KV). El repositorio de KV es un enfoque de gestión de datos extremadamente simple que almacena un identificador (clave) único junto con una información arbitraria. El repositorio KV en sí mismo puede aceptar cualquier dato, ya sea un blob binario o un documento JSON. Debido a la simplicidad de la implementación de KV, se garantiza el acceso a los datos con un retraso mínimo. Como muestra nuestra experiencia, con mayor frecuencia la latencia de la red es 2-3 veces mayor que proporcionar datos clave en el lado de Couchbase.

Esquema de almacenamiento dinámico ( JSON)

Los documentos se almacenan en el servidor Couchbase en formato JSON. El formato admite ambos tipos de datos básicos, como números, cadenas y tipos complejos, así como diccionarios y matrices incorporados.

El esquema de datos en Couchbase es una construcción lógica definida por la aplicación y el desarrollador. Debido a su flexibilidad y la capacidad de usar varias opciones, podemos usar una etiqueta en el documento, por ejemplo, con información de la versión. Esto permite que la aplicación determine en qué modo se procesará el documento, así como para garantizar una migración sin problemas de la base de datos al nuevo esquema de datos.

Alta disponibilidad

Uno de los parámetros constitutivos de un sistema de información es su disponibilidad. Couchbase proporciona alta disponibilidad de datos con muchas características diferentes. Una de ellas es la replicación de datos (la distribución de varias copias de datos en diferentes servidores de clúster), que le permite proporcionar un servicio durante el mantenimiento de rutina o la falla de algunos servidores.

La segunda característica importante para la alta disponibilidad es el DCP interno (Protocolo de cambio de base de datos). Proporciona transferencia de cambios a alta velocidad a todas las copias de datos, índices secundarios (GSI), replicación de clúster cruzado (XDCR) y consumidores externos.

Replicación bidireccional

Una buena práctica en las empresas es utilizar la redundancia para todos los procesos y equipos comerciales. Idealmente, esta es una copia de seguridad en modo Activo-Activo, cuando el cambio entre nodos problemáticos se produce automáticamente. La replicación bidireccional en Couchbase habilita el modo AA. Pero las pruebas de replicación han demostrado que solo es eficaz en centros de datos cercanos. Con un espacio de más de 100 km, aparecen conflictos. Couchbase tiene mecanismos de resolución de conflictos: basados ​​en la marca de tiempo y el número de secuencia. Sin embargo, debido al retraso de tiempo en la red, los datos obsoletos ingresan a la base de datos. Abandonamos el uso de la replicación bidireccional (consistencia entre grupos). Todos los cambios se llevan a cabo en un solo clúster. La disponibilidad de datos en modo de lectura se proporciona en todos los centros de datos (AA).

Escala horizontal

Una de las características importantes de la mayoría de las bases de datos NoSQL es el escalado horizontal (Fig. 3). La principal diferencia de Couchbase es el soporte del escalado multidimensional, cuando nosotros en el clúster solo podemos aumentar el rendimiento del servicio deseado. Por ejemplo, el juego Pokemon GO usa una arquitectura dividida. Al inicio del proyecto, se utilizaron 5 servidores con servicios combinados. Después de aumentar la carga, utilizaron una arquitectura diversa: 5 servidores de datos y 55 servidores para procesar consultas e índices. Una de las desventajas de escalar con Couchbase es que el orquestador tiene problemas cuando hay más de 50 nodos de fecha en el clúster.

Figura 3 MDS

Requisitos de IS

Los requisitos de seguridad de la información influyeron en nuestra elección en menor medida, pero su presencia en el sistema hizo un argumento adicional a favor de una u otra base de datos. Dado que el caché puede contener datos personales, debemos seguir los requisitos del regulador sin falta. Vale la pena decidir: ¿utilizaremos equipos adicionales o podemos proporcionar esto con la base de datos en sí misma?

En la versión empresarial, Couchbase admite cifrado de tráfico, cifrado de datos y acceso personalizado. Esto ahorra dinero en equipos como Cisco ASA.

Actualización fácil

Una de las fortalezas significativas de Couchbase es su mecanismo de actualización transparente y soporte para versiones anteriores de la API. Durante la actualización del clúster, funciona en modo de compatibilidad. Los nuevos mecanismos solo funcionarán después de una actualización completa del clúster. Los efectos sobre las aplicaciones en ejecución son mínimos debido a la compatibilidad con la antigua API.

PD: la actualización / degradación solo está permitida en las versiones principales vecinas

Funcionalidad adicional

Distribución lógica

Otra característica interesante es la combinación de servidores en un clúster en grupos lógicos, con réplicas adjuntas a ellos. Esto le permite distribuir copias completas de réplicas del mismo clúster a diferentes puertas automáticas. Eso permite que uno de los concesionarios de automóviles no tenga una copia completa de los datos en el segundo

Copia de seguridad y restauración

Couchbase contiene herramientas de respaldo y recuperación listas para usar. El proceso de copia de seguridad puede funcionar en tres modos: completo, diferencial y acumulativo. Esto permite en algunos casos ahorrar espacio en disco y recursos de procesador.

Couchbase vs mongo

Es difícil responder a la pregunta de elegir bases de datos NoSQL alternativas y, a menudo, el mejor Unix es el que conoce su administrador. Intentemos formular por qué preferimos Couchbase, y no otra plataforma muy popular: MongoDB.

Es bastante difícil comparar dos proyectos diferentes con diferente arquitectura y funcionalidad. Uno de los parámetros a los que prestamos atención es la facilidad de mantenimiento y la capacidad de reconfigurar rápidamente el sistema para satisfacer las necesidades del negocio.

Tabla 1 Comparación

Tabla 2 Comparación de replicación

En general, Couchbase es más flexible y más simple en la configuración requerida para nuestras tareas y la arquitectura híbrida que cambia rápidamente.

Experiencia operativa

Para empezar, nos gustaría dar los números con los que el sistema y el clúster ahora están operando en Couchbase.

1. Más de 80 millones de suscriptores [i]
2. 380 millones de documentos de información del cliente JSON
3. HDD de 3.5 TB (utilizamos memcached, la información en el disco se almacena para un inicio rápido)
4. 3 TB de RAM
5. 50 mil operaciones por segundo (Fig. 5)
6. 50 microservicios que procesan todo el flujo de mensajes

Los primeros hitos de la transformación comenzamos con la tercera versión de Couchbase. En la primera etapa, al comienzo del proyecto, todas las aplicaciones funcionaron de manera estable. Pero al traducir la lógica adicional a un nuevo mecanismo, nos enfrentamos al hecho de que el mecanismo de Vista comenzó a funcionar de manera impredecible. Es decir en algún momento, el proceso se congela y estas vistas desde dicho nodo dejan de regresar. Al mismo tiempo, no se interrumpió el acceso a los datos y su procesamiento. El problema se solucionó con bastante facilidad: reiniciando el nodo, lo que generalmente reducía la disponibilidad del servicio. En el curso de la comunicación con el soporte técnico de Couchbase, se nos ofreció un comando no documentado que reinicia solo el proceso de visualización

curl -s --data 'cb_couch_sup: restart_couch ().' -u Administrador: pase http://127.0.0.1:8091/diag/eval [ii]

El comando es válido solo en las versiones 3.x.

curl -s --data 'couch_server_sup: restart_core_server ().' -u Administrador: Administrador http://127.0.0.1:8091/diag/eval

El comando solo es válido en las versiones 4.x.

Otro problema de la tercera versión fue el mecanismo de compresión de datos de última hora (compactación). Debía iniciarse manualmente de acuerdo con las métricas de monitoreo activadas. Ambos problemas mantuvieron en tensión no solo el turno de trabajo, sino también los ingenieros funcionales.

En este sentido, decidimos migrar a la cuarta versión. La migración con un impacto mínimo en el servicio tomó aproximadamente dos semanas. El proceso de actualización en sí no requiere acciones y control complejos, pero al agregar o eliminar un nodo, se inicia un reequilibrio, que demora al menos dos horas. En el proceso, encontramos una manera de acelerar el proceso de actualización a través de un servidor de búfer: en este caso, no comienza un proceso de reequilibrio limpio, sino que transfiere datos de un nodo a otro. Esto redujo el proceso de actualización a 30 minutos.

Al actualizar un clúster industrial, se deben tener en cuenta los siguientes matices: trabajar en modo de compatibilidad, cuando el clúster funciona en el modo de la versión más reciente del software. En el lado positivo, el proceso de actualización se ejecuta sin problemas y sin problemas, pero, sin embargo, no podrá utilizar nuevas funciones, como el nuevo mecanismo de compresión, N1QL, hasta que todo el clúster esté completamente actualizado.

Después de la actualización, logramos solucionar solo un problema: la compresión. Comenzó a funcionar correctamente. Con el mecanismo de visualización, el problema aún persistía, aunque se repitió con mucha menos frecuencia. Fue posible corregirlo solo por las fuerzas de los desarrolladores de Couchbase en la versión 4.6.4.

Como parte de la resolución de problemas de soporte técnico, quedó claro que el mecanismo de visualización ya no se actualizará. Esto se hizo sobre la base de que la mayoría de los clientes de Couchbase no usan vistas para los fines para los que fueron creados, y Couchbase creó un nuevo mecanismo N1QL. Es ejecutado por un servicio separado y ahora no depende de nodos de datos (Fig. 7)

Cerramos todos los problemas críticos con la versión 4.6.4. Pero debido al aumento en el volumen de datos, decidieron migrar a la quinta versión, donde agregaron una nueva base de datos para índices y en nuestros datos la cantidad de memoria y discos disminuyó una vez y media. Pero, desafortunadamente, no vimos una disminución en la cantidad de datos en los nodos de datos.

Conclusiones

En general, Couchbase demostró ser un sistema maduro que soporta una gran carga, incluso en casos no específicos (Viber, utilizado como base de datos). Dentro de la arquitectura híbrida de MegaFon, el clúster se puede adaptar fácilmente para cualquier propósito sin tiempo de inactividad del equipo y sin una reconfiguración seria del servidor, lo que generalmente permite a la compañía reducir los costos de personal y hacer que el servicio para el suscriptor sea lo más conveniente posible.

PAO MegaFon

2018 Kovalchuk Egor

[i] El sistema procesa no solo suscriptores, sino también dispositivos con tarjetas SIM incorporadas, módems, etc.

[ii] Consulte a un especialista antes de usar