El escalado del datastore de Slack con Vitess

• La historia de cómo Slack cambió su arquitectura de clúster Active-Active a Vitess, un sistema de escalado horizontal para MySQL

• La migración comenzó en 2017 y ahora Vitess maneja el 99% de todas las consultas; está previsto completar la migración total para fin de año

  → Actualmente, en los picos, procesa 2.3 millones de QPS (2 millones de lectura y 300 mil de escritura)

  → La latencia mediana de las consultas es de 2 ms, y la latencia p99 es de 11 ms

• Slack comenzó con una pila LAMP (Linux, Apache, MySQL, PHP)

• 3 clústeres de base de datos

  → Shard: todos los datos de usuarios, como mensajes, canales y DM. Se particionan por workspace ID, por lo que cada workspace pertenece a un solo shard

  Es decir, la app de Slack solo necesita conectarse a una sola base de datos

  → Clúster de metadatos: tabla de búsqueda para vincular workspaces con shards

  → Clúster "kitchen sink": almacena todos los datos que no pertenecen a un workspace específico, como el directorio de apps

• El sharding era administrado y coordinado por el monolito webapp

• Cada clúster está compuesto por uno o más shards, y cada shard se aprovisiona con al menos dos instancias de MySQL ubicadas en distintos centros de datos

• Ventajas de la configuración Active-Active

  → Alta disponibilidad

  → Alta velocidad de desarrollo de producto

  → Depuración sencilla

  → Escalado sencillo

Pero, a medida que la organización creció y los equipos de producto empezaron a crear nuevas funciones, la velocidad de desarrollo se fue reduciendo

• Desventajas de Active-Active

  → Límite de escalado: al llegar clientes más grandes, alcanzaron el límite que podían soportar hosts de mayor rendimiento

  → Fijación en un solo modelo de datos:

  Con funciones como Enterprise Grid y Slack Connect, esto iba en contra del paradigma de conectarse a un solo servidor
  

  → Hotspots: no aprovechaban bien la flota de bases de datos. Era difícil dividir shards y mover equipos, y como era difícil predecir el uso de Slack, la mayoría de los shards se sobreaprovisionaban, lo que impedía aprovechar la long tail

  → Problemas de disponibilidad entre workspaces y shards: si había un problema en un shard, todos los clientes en ese shard no podían usar Slack

  → Operación: como no era una configuración estándar de MySQL, tuvieron que crear muchas herramientas internas

• En otoño de 2016, administraban cientos de miles de consultas MySQL por segundo y miles de hosts MySQL shardeados

• Sufrían regularmente problemas de escalado y rendimiento, así que empezaron a considerar un nuevo enfoque

• Consideraron evolucionar lo existente o introducir un producto nuevo, pero

  → Querían seguir usando MySQL ejecutándose en su nube privada

  → Tenían miles de consultas únicas, y algunas usaban configuraciones especiales de MySQL

  → Despliegue, respaldos, ETL hacia el data warehouse y cumplimiento estaban todos basados en MySQL

• ¿Por qué Vitess?: cumplía con la mayoría de los requisitos de la aplicación y de operación

  → MySQL Core: Vitess está basado en MySQL

  → Scalability: combina las funciones principales de MySQL con la escalabilidad de las bases de datos NoSQL. Su sharding integrado permite escalar con flexibilidad sin agregar lógica especial

  → Operability: maneja automáticamente conmutación por error, respaldos y más. Rastrea los metadatos de la configuración del clúster para mantener la consistencia

  → Extensibility: es open source y está basado en Go. Tiene amplia cobertura de pruebas y una comunidad de desarrolladores abierta

• Empezaron a llevar Vitess a producción desde funciones pequeñas

  → En 2017 probaron creando la función para integrar feeds RSS en canales de Slack

  → En 2018, todas las tablas nuevas se creaban solo en Vitess

  → A mediados de 2019, ya había más escrituras en Vitess que en la base de datos legacy

  → Y Slack siguió contribuyendo continuamente al open source de Vitess

  → A lo largo de 3 años migraron el 99% a Vitess. El 1% restante se completará este año

• ¿La adopción de Vitess por parte de Slack fue un éxito?

  → Varias regiones del mundo operan múltiples clústeres de Vitess con decenas de keyspaces

  → Los keyspaces son colecciones lógicas que escalan según la cantidad de usuarios, equipos y canales

  → El sharding flexible les permitió escalar Slack

  → Con COVID-19, la cantidad de consultas de Slack aumentó 50% en solo una semana

  → Escalaron horizontalmente el keyspace más ocupado usando el workflow de partición de Vitess

  → En el pasado, eso no habría podido escalarse y habría causado tiempo de inactividad.

[xguru]

https://vitess.io/

Vitess: "Middleware de sharding para MySQL"

• Una solución creada para desplegar, escalar y administrar fácilmente MySQL y MariaDB en la nube

• Opera y administra shards de MySQL sobre Docker (local) y Kubernetes

• La aplicación puede usar un proxy llamado VTGate como si se comunicara con MySQL, y por dentro este se conecta a otros servidores mediante gRPC

[xguru]

Hey, el servicio de correo electrónico, también usa Vitess

Stack tecnológico de Hey: https://es.news.hada.io/topic?id=2355