Almacenes de datos de autoservicio

Tradicionalmente, los almacenes de datos han sido gestionados por equipos especializados y su creación y gestión requieren mucho trabajo. Este enfoque puede funcionar para arquitecturas monolíticas. Sin embargo, en el caso de los microservicios con una mayor tasa de cambio y el objetivo de que cada uno tenga su propio almacén de datos, este modelo no es escalable. Esto puede encarecer la creación de microservicios y hacer que los equipos dependan de un equipo centralizado.

El VCC (Centro de contacto de Vonage) a este problema fue pasar a un sistema de autoservicio mediante la automatización, lo que permite a los equipos realizar muchas de estas tareas por sí mismos. Sin embargo, el autoservicio en sí es un concepto bastante abstracto, por lo que nuestra primera tarea fue definir qué significaba realmente para nosotros un almacén de datos de autoservicio.

¿Qué es un almacén de datos de autoservicio?

Un almacén de datos es "un repositorio para almacenar y gestionar de forma persistente colecciones de datos." Para nosotros, esto abarca

• Base de datos relacional, por ejemplo, MySQL

• Base de datos NoSQL, por ejemplo, DynamoDB

• Cachés, por ejemplo, Redis

• Otras tiendas como Elasticsearch

El autoservicio para estos significa que un equipo puede:

• Crear y gestionar su almacén de datos

• Realizar cambios en el esquema

• Realice cambios en los datos de forma segura

• Apoyo a su almacén de datos, incluido el acceso para depuración y apoyo a la producción

Estas cosas por sí solas son bastante fáciles de hacer. Sin embargo, para evitar crear más problemas de los que resolvemos, también tenemos que tener en cuenta:

• Herramientas que incorporan las mejores prácticas mediante pruebas automatizadas y puertas de calidad

• Audit trail de todos los accesos y cambios para garantizar la conformidad

• Barreras y fachadas multi-tenancy (no siempre es económico tener un cluster de base de datos por microservicio)

• Complejidad de la replicación en caliente, en caso necesario

• Facilidad de uso, robustez y ocultación de la complejidad interna

Beneficios

Las dos partes interesadas clave de los almacenes de datos (los equipos que gestionan los almacenes de datos y los equipos de funciones que utilizan los almacenes de datos) se benefician del autoservicio, pero de formas diferentes. Dependiendo de su estructura organizativa, ¡podrían ser incluso el mismo equipo! Los dos gráficos siguientes muestran el escenario de adoptar el autoservicio y seguir mejorándolo frente a no hacer nada, durante un periodo de 18 meses.

Estos gráficos muestran nuestra experiencia de cómo las tareas habituales, como realizar migraciones de esquemas, efectuar cambios en los datos, etc., afectaron a los equipos a medida que la demanda de almacenes de datos aumentaba con el tiempo.

Impact from BAU tasks increases over time

Si su organización está aumentando el número de microservicios y/o equipos que tiene, llegará un punto en el que la cantidad de BAU desbordará a su(s) equipo(s) de almacén de datos. Puede hacer frente a esta situación añadiendo más personal, pero es probable que esto no sea suficiente para satisfacer la demanda. El cambio a una estrategia de autoservicio reducirá el BAU al eliminar tareas como la migración de esquemas, al tiempo que permitirá al equipo del almacén de datos centrarse en tareas de mayor valor.

Time to make a datastore change increases over time

Los equipos de funciones también se beneficiarán del autoservicio, ya que realizar cambios en los almacenes de datos será más rápido y menos costoso a medida que se añadan más funciones de autoservicio. Si los equipos de funciones dependen de un equipo de almacén de datos para realizar estos cambios por ellos, ese equipo puede convertirse en un cuello de botella y aumentar el coste de los cambios. Este coste se refleja principalmente en el tiempo transcurrido. Si el equipo del almacén de datos empieza a estar desbordado, es posible que los equipos de funciones tengan que empezar a hacer un seguimiento de los cambios que han solicitado para asegurarse de que se realizan.

Lo que hemos hecho

Ahora que ya sabe qué es un almacén de datos de autoservicio y por qué lo queremos, probablemente sienta curiosidad por saber qué estamos haciendo para pasar a un modelo de autoservicio.

Los equipos que trabajan en VCC han adoptado el autoservicio para AWS Aurora MySQLlo que nos permite crear automáticamente nuevos esquemas para los servicios y realizar cambios de esquema como parte de la canalización de CI. También se encarga de proporcionar credenciales de base de datos y configuración de acceso a microservicios.

El proceso para ejecutar las migraciones (como se muestra en el siguiente diagrama) implica un lambda que orquesta la creación de contenedores Docker para realizar las migraciones. La mensajería se utiliza para la comunicación entre el sistema CI y el sistema de migración de esquemas. El proceso también creará una base de datos si el esquema aún no existe.

El flujo de trabajo del proceso de migración es que Jenkins solicita una nueva versión de un esquema para ser desplegado (1) subiendo la migración al bucket de scripts de migración y luego (2) publicando en un tema SNS. Esto es recogido por (3) un SQS, que se suscribe al tema y (4) activa la lambda de migración de esquema.

El lambda de migración de esquema (5) inicia una tarea ECS cuyo (6) contenedor extrae la migración del bucket de script de migración y luego (7) ejecuta flyway utilizando el script de migración contra el cluster aurora objetivo. Al finalizar la migración (8) el contenedor publica un mensaje SNS que es (9) recogido por una cola CI/CD SQS que (10) actualiza el estado del trabajo Jenkins para decir que se ha completado.

Para ello, también hemos elaborado directrices sobre las mejores prácticas específicas de nuestra arquitectura (por ejemplo, consideraciones para la replicación multiclúster en caliente y mejores prácticas para las migraciones, de modo que los equipos puedan evitar los errores más comunes).

Próximos pasos

A continuación, estamos estudiando la posibilidad de añadir más funciones de autoservicio, como permitir cambios de datos en autoservicio, proporcionar más métricas y herramientas para el análisis detallado de consultas. Queremos habilitar un acceso seguro a los datos de baja fricción con integración en nuestra pista de auditoría. También tenemos que comprobar que el trabajo que ya hemos realizado ha aportado los beneficios que esperamos.

Por último, estamos estudiando si otras partes de Vonage pueden aprovechar el trabajo que hemos realizado. Esto es especialmente relevante ya que estamos construyendo la plataforma de comunicaciones de Vonage y la arquitectura común de las plataformas internas que la sustentan.