Egor Kovalchuk es director de despliegue en MegaFon, una de las mayores empresas de telecomunicaciones de Rusia. Su carrera en telecomunicaciones abarca más de una década. El equipo de Egor se encarga de desarrollar, integrar y supervisar múltiples sistemas y aplicaciones empresariales que abarcan las once zonas horarias de Rusia.
Couchbase en las telecomunicaciones: MegaFon, Rusia
La transformación digital es una tendencia mundial para empresas grandes y pequeñas. Es vital que las empresas se adapten a las necesidades de los clientes modernos. Los clientes están acostumbrados a sistemas de alta disponibilidad y en tiempo real proporcionados por los líderes del sector (Google, Amazon, Netflix), y exigen la misma experiencia a todos los agentes del mercado.
Esta tendencia afecta de lleno a las empresas de telecomunicaciones rusas. Hay que implantar nuevas funciones que favorezcan al cliente rápido y escala fácilmente. Tenemos que reaccionar rápidamente a los movimientos de nuestros competidores. Todo esto debe conseguirse gestionando al mismo tiempo los crecientes costes del gasto en TI (infraestructura, centros de datos, personal cualificado). Ahí es donde resultan útiles las nuevas tecnologías, como la caché en memoria y las bases de datos NoSQL.
A continuación describiré dos casos de uso que utilizamos en MegaFon con bases de datos en memoria:
- Almacenamiento en caché sencilloCaché: la caché se rellena y actualiza según un calendario, así como por eventos de la base de datos y la aplicación.
- Caché de escrituralos cambios en la caché se propagan a la base de datos principal (por ejemplo, la base de datos Oracle recibe actualizaciones del flujo DCP de Couchbase).
El primer enfoque se utiliza en nuestro sistema de toma de decisiones para el ciclo de vida del abonado. Una sola aplicación analiza múltiples factores, toma una decisión y envía el cambio a múltiples sistemas (incluida una base de datos Oracle). Un ejemplo de este tipo de aplicación es el bloqueo y desbloqueo de cuentas de planes de prepago. Cuando se agota el importe prepagado, la cuenta se bloquea y no se presta ningún servicio hasta que el cliente la vuelve a llenar. Una vez rellenada la cuenta, hay que volver a activar el servicio lo antes posible. Gracias al uso de Couchbase, hemos acortado el tiempo de restablecimiento del servicio de 90 a 30 segundos, y aún hay margen de mejora. La única actualización que se envía a la base de datos principal es el cambio de estado de la cuenta (véase la Figura 1 a continuación).
Figura 1: Proceso de actualización rápida del estado de cuenta de MegaFon
¿Por qué elegimos Couchbase Server como parte de nuestros esfuerzos de transformación digital? Echemos un vistazo a nuestros requisitos de rendimiento y veamos lo bien que Couchbase se adapta a ellos.
NoSQL Rendimiento de la base de datos Requisitos
- Capacidad de procesamiento: hasta 200.000 solicitudes por segundo.
- Latencia media (50%), clúster único: dentro de 5 ms.
- Latencia máxima (99%), clúster único: dentro de 15 ms.
- Capacidad máxima de inserción: 500 MB por segundo.
- Número máximo de operaciones de inserción: 100.000 por segundo.
- Capacidad máxima de actualización: 500 MB por segundo.
- Número máximo de operaciones de actualización: 100.000 por segundo.
- Velocidad máxima de lectura: 500 MB por segundo.
- Número máximo de operaciones de lectura: 100.000 por segundo
Acceso de alto rendimiento a datos clave-valor
Couchbase Server, en su núcleo, es una base de datos distribuida Clave-Valor (KV). El almacenamiento KV es un enfoque simple de gestión de datos que almacena un identificador único (clave) junto con una pieza de información arbitraria (valor). El valor puede ser un objeto binario (BLOB/blob) o un documento JSON. Debido a la simplicidad de la implementación de la KV (especialmente si se compara con las bases de datos relacionales), el acceso a los datos se proporciona con una latencia mínima. En nuestros despliegues, la latencia de la red es a menudo 2-3 veces mayor que el tiempo para completar una operación KV en el clúster Couchbase.
Formato de datos flexible (JSON)
JavaScript Object Notation (JSON) es el formato de almacenamiento de datos preferido en Couchbase. El formato admite tipos de datos primitivos (booleanos, números, cadenas) y compuestos (matrices, listas, diccionarios).
El esquema de datos de sus documentos JSON puede modificarse fácilmente en función de los requisitos cambiantes de su aplicación. Las diferentes versiones del esquema se pueden rastrear mediante un campo de documento adicional, lo que garantiza actualizaciones de la aplicación sin problemas y compatibilidad con versiones anteriores.
Alta disponibilidad
Couchbase Sever proporciona varias características para soportar la alta disponibilidad (HA) de los datos. Dentro del cluster replicación de datos (distribución de varias copias de datos en diferentes servidores dentro de un mismo clúster) mantiene los datos 100% disponibles durante el mantenimiento programado del servidor o fallos inesperados del mismo.
Figura 2: Replicación intracluster de Couchbase
El Database Change Protocol (DCP) es otro importante componente de HA de Couchbase. Este protocolo de streaming de alto rendimiento comunica los cambios de datos a los consumidores internos y externos. Es responsable del mantenimiento de índices secundarios globales (GSI) utilizados para consultas SQL, índices de búsqueda de texto completo (FTS), replicación entre centros de datos (XDCR, protocolo de replicación entre clústeres) y otros servicios.
Replicación bidireccional (entre clústeres)
Las aplicaciones y equipos redundantes son desde hace tiempo una práctica recomendada en el sector. Lo ideal sería que bases de datos distribuidas se despliegan usando arquitectura Activo-Activo (AA), cuando las aplicaciones cambian automáticamente a un cluster diferente en caso de problemas de conectividad. modo AA, cuando el cambio entre nodos problemáticos se produce automáticamente. Couchbase Server soporta XDCR bidireccional para permitir escenarios AA. Sin embargo, la consistencia eventual de los datos en despliegues multi-cluster puede no ser aceptable para ciertas aplicaciones de negocio.
En nuestro entorno, descubrimos que cuando los centros de datos están situados a más de 100 km de distancia, la resolución de conflictos de datos se convierte en un reto. Couchbase proporciona dos mecanismos de resolución de conflictos: uno basado en revisiones y otro basado en marcas de tiempo. Debido a la latencia de nuestra red, ninguno de ellos podía proporcionar una consistencia de datos aceptable en un escenario AA completo (cuando las escrituras y lecturas pueden ocurrir en cualquier cluster). Como resultado, implementamos la arquitectura en la que todos los cambios (escrituras) se realizan en un único clúster que propaga los cambios a otros centros de datos. Las aplicaciones pueden leer datos de cualquier centro de datos.
Escala horizontal
El escalado horizontal (aumentar los recursos del clúster añadiendo nuevos servidores) es un gran argumento de venta de las bases de datos NoSQL. La característica importante de Couchbase Server es la capacidad de escalar diferentes cargas del clúster (operaciones KV, consultas SQL, indexación de datos, etc.) de forma independiente; Couchbase lo denomina "escalado multidimensional, MDS" (véase la Figura 3 a continuación). Cada nodo del cluster de Couchbase puede ejecutar un único servicio o múltiples servicios; la elección se realiza cuando se añade un nodo al cluster existente.
Figura 3: Escalado multidimensional (MDS) de Couchbase
Requisitos de seguridad de la información
Las características de seguridad de Couchbase fueron otra razón (aunque no la principal) para convertirlo en nuestro sistema de elección. Dado que es posible que la información personal identificable (PII) se almacene en caché, nuestra empresa tiene que cumplir las leyes vigentes. Si la plataforma de datos no ofrece las funciones de seguridad necesarias, puede ser necesario adquirir hardware adicional para cumplir la normativa.
Couchbase Server Enterprise Edition (EE) soporta encriptación de tráfico, encriptación de datos y control de acceso basado en roles (RBAC). Esto te permite potencialmente ahorrar en hardware de seguridad de red, como Cisco ASA.
Facilidad de actualización
Couchbase Server ofrece diferentes opciones de actualización. La opción de actualización en línea permite que tus aplicaciones sigan funcionando con el clúster con un impacto mínimo en el rendimiento y la funcionalidad (debido a la compatibilidad con versiones anteriores de la API). Mientras los nodos del clúster se actualizan, el clúster seguirá funcionando en modo de compatibilidad; las características de la nueva versión se activarán una vez que todos los nodos completen la actualización.
Funciones adicionales
Conocimiento de grupos de servidores (conocimiento de bastidores, zonas de disponibilidad)
En Couchbase, se pueden asignar servidores individuales a grupos de servidores específicos. Esta característica es similar a las zonas de disponibilidad (AZ) de los servicios en la nube. Cuando se utilizan grupos de servidores, el algoritmo de distribución de datos activos y réplicas asegura la plena disponibilidad de los datos en caso de que todo el grupo de servidores esté fuera de línea.
En el mundo de las telecomunicaciones, esto nos permite mantener conjuntos de datos totalmente replicados en diferentes salas de equipos del centro de datos. Si toda la sala de equipos (asignada a un grupo de servidores Couchbase) se desconecta, las aplicaciones seguirán funcionando con el conjunto de datos completo en la otra sala de equipos.
Figura 4: Grupos de servidores Couchbase
Copia de seguridad y restauración
Couchbase proporciona varias herramientas de copia de seguridad y recuperación; cbbackupmgr sólo está disponible en EE. La copia de seguridad se puede hacer de tres maneras diferentes: completa, diferencial y acumulativa. La combinación correcta de estos modos de copia de seguridad permite ahorrar espacio en disco y optimizar el uso de recursos del sistema.
Figura 5: Combinación de copias de seguridad de Couchbase
Couchbase frente a MongoDB
Elegir una base de datos NoSQL entre las tecnologías competidoras disponibles puede ser todo un reto. [Al menos con el sistema operativo Linux es más fácil: la mejor distribución de Linux es la que mejor conoce tu administrador de sistemas]. Resumimos en la siguiente tabla algunas de las diferencias importantes que nos convencieron para elegir la tecnología Couchbase sobre otra popular plataforma NoSQL, MongoDB.
Hay que reconocer que es difícil comparar dos proyectos distintos con arquitecturas y funcionalidades diferentes. Para nosotros era importante que el sistema fuera fácil de mantener y pudiera ajustarse rápidamente a las necesidades cambiantes de la empresa.
| Couchbase | MongoDB | |
| Fragmentación | Automático para todo el conjunto de datos | Selección manual de teclas por colección |
| Distribución de datos | Los datos siempre se distribuyen uniformemente entre todos los nodos de datos | La fragmentación por rangos puede dar lugar a una distribución no uniforme |
| Añadir/eliminar nodos o fragmentos | Simple, completado en un solo paso (a través de GUI, REST API o CLI), seguido de un reequilibrio. | Complejo, necesidad de crear conjuntos de réplicas. Cada colección se escala de forma diferente |
| Concienciación sobre estanterías | Integrado y fácil, mediante grupos de servidores | No incorporado, es necesario asignar manualmente nodos de conjuntos de réplica de diferentes bastidores. |
| Configuración equilibrada | El clúster siempre está equilibrado y cada nodo tiene el mismo número de vBuckets activos (shards). | No equilibrado. Los nodos secundarios no sirven ningún tráfico de escritura (ni siquiera de lectura por defecto). |
| Reducción del índice | Escala independientemente los índices de datos. Puede incluso utilizar distintos tipos de hardware para los nodos de índices. | El escalado de índices va unido al escalado de datos. Hay que añadir capacidad al clúster de datos para adaptarse a los cambios en la carga de trabajo de las consultas. |
| Metadatos del clúster | No se necesitan nodos especiales, se distribuyen por todos los nodos de datos. | Es necesario establecer servidores de configuración especial, un mínimo de 3 nodos |
| Arquitectura de replicación | Clúster completamente independiente, que puede escalarse y gestionarse sin dependencias. | Extensión de la replicación intracluster, no un sistema independiente. |
| Flexibilidad de replicación | Muy flexible; nivel de cubo, técnicas de optimización avanzadas para ajustarse a la necesidad. | No es posible ajustar, elegir la velocidad ni el ancho de banda. |
| Topología de replicación | Soporte de topologías complejas: bidireccional, estrella, malla, cadena, anillo, etc. | No admite topologías complejas: unidireccional, estrella. El primario es un cuello de botella. |
| Replicación activo-activo | Soporte | No se admite |
En general, Couchbase es más flexible y fácil de mantener y configurar para los casos de uso de MegaFon y la arquitectura híbrida en constante evolución.
Nuestro viaje con Couchbase
A continuación se muestran algunas estadísticas rápidas de nuestro clúster Couchbase de producción y su carga:
- El clúster maneja datos de más de 80 millones de abonados. Esta cifra incluye teléfonos móviles, routers LTE, múltiples dispositivos de consumo con tarjetas SIM incorporadas, etc.
- 380 millones de documentos JSON con datos de clientes
- 3,5 TB de almacenamiento en disco (conjunto de datos activo, réplicas no incluidas)
- 3 TB RAM
- 50.000 operaciones por segundo, sostenidas (véase la figura 6)
- 50 microservicios que procesan todo el flujo de mensajes
Figura 6: Carga de producción de Couchbase
Este proyecto de transformación comenzó con Couchbase Server versión 3.x. Inicialmente, todas las aplicaciones funcionaban de forma estable. Sin embargo, cuando añadimos nuevas funcionalidades a la aplicación que dependían del uso de vistas de Couchbase, empezamos a experimentar problemas con el comportamiento impredecible de las vistas. [Las vistas son un mecanismo de indexación y consulta map/reduce. Se considera una característica heredada de Couchbase Server 5.x-6.x. Se está eliminando en favor de índices secundarios globales y consultas N1QL]. El proceso de actualización de la vista en un nodo a veces se congelaba, lo que impedía a las aplicaciones recibir los datos de la vista de este nodo. Las operaciones de KV continuaban realizándose con normalidad.
Este problema podía solucionarse reiniciando el nodo, lo que afectaba a la disponibilidad de los datos. Como solución temporal (mientras planeábamos actualizar a la versión 4.x de Couchbase Server), el soporte técnico de Couchbase sugirió el siguiente comando no documentado específico de la versión para reiniciar únicamente el proceso de actualización de vistas:
|
1 2 3 |
# Este comando sólo funciona con Couchbase Server versión 3.x # ¡No lo uses sin la bendición de tu administrador! rizo -s --datos 'cb_couch_sup:restart_couch().' -u Administrador:pase http://127.0.0.1:8091/diag/eval |
|
1 2 3 |
# Este comando sólo funciona con Couchbase Server versión 4.x # ¡No lo uses sin la bendición de tu administrador! rizo -s --datos 'couch_server_sup:restart_core_server().' -u Administrador:pase http://127.0.0.1:8091/diag/eval |
Otro problema que encontrábamos con la versión 3.x de Couchbase Server era la finalización periódica del proceso de compactación. El proceso tenía que reiniciarse manualmente al recibir alarmas de monitorización. Ambos problemas de producción eran un quebradero de cabeza tanto para el personal de operaciones como para el de desarrollo.
Siguiendo la recomendación del soporte técnico de Couchbase, decidimos actualizar a la versión 4.x de Couchbase Server. El proceso general de actualización llevó unas dos semanas, ya que teníamos que asegurarlo con un impacto mínimo en las aplicaciones de producción. Los pasos de actualización son bastante sencillos, pero la actualización en línea continua - incluyendo la eliminación de nodos, reequilibrio, actualización de nodos, adición de nodos al clúster, y otro reequilibrio - llevaría más de 2 horas. Hemos podido optimizar este proceso introduciendo un nodo adicional para aprovechar el reequilibrio de intercambio de Couchbase. En este caso, los datos se copian directamente del nodo que se elimina al nodo que se añade, lo que acelera enormemente el reequilibrio. Esto redujo el tiempo de actualización por nodo a 30 minutos.
Al actualizar un clúster Couchbase de producción, debes tener en cuenta que el clúster funcionará en modo de compatibilidad, cuando sólo las características de la versión anterior estarán disponibles en todos los nodos. Esto asegura una actualización suave y sin problemas. El inconveniente es que las nuevas características y correcciones de la versión actualizada (índices y consultas N1QL, búsqueda de texto completo, etc.) sólo estarán disponibles cuando todos los nodos del clúster estén actualizados.
Nuestra actualización inicial a la versión 4.x sólo solucionó el problema de la compactación. El problema de la vista se mantuvo, aunque no surgió tan a menudo. Fue remediado completamente sólo en la versión 4.6.4 de Couchbase Server.
También hemos sido notificados por el soporte técnico de Couchbase que la funcionalidad de vistas ya no será mejorada y está en camino de ser obsoleta. Los Índices Secundarios Globales (GSI) y las consultas N1QL (pronunciado como "nickel", implementación SQL de Couchbase) son la mejor alternativa escalable para las vistas. Las cargas de índices y consultas pueden ser escaladas independientemente, sin estar atadas a nodos de datos (ver Figura 7 abajo):
Figura 7: Servicios Couchbase en diferentes nodos
Con la actualización a Couchbase Sever 4.6.4, hemos resuelto todos nuestros problemas críticos de producción. Sin embargo, las nuevas características y mejoras de Couchbase Server 5.1 nos obligaron a completar otro ciclo de actualización. Con el nuevo motor GSI, nuestros índices ocupan ahora 1,5 veces menos espacio en disco y memoria, lo que nos ayuda con nuestro creciente volumen de datos. Por desgracia, la versión 5.1 no ofrece ninguna mejora en el almacenamiento de datos (en memoria o en disco). En la versión 5.5 se ha añadido la compresión de datos.
Conclusión
En general, Couchbase Server demostró ser una plataforma de datos madura y de alto rendimiento. Como parte de la arquitectura híbrida de MegaFon, el clúster de Couchbase puede adaptarse fácilmente a cualquier carga de producción sin paradas del equipo ni grandes cambios de configuración en los servidores. En general, esto redunda en una reducción de los costes de personal y en la satisfacción del cliente.
El artículo original se ha publicado en un popular blog ruso de informática colaborativa, Habrahabr: https://habr.com/ru/post/436762/
