Escalando o datastore do Slack com Vitess

• A história da mudança do Slack de uma arquitetura de cluster Active-Active para o Vitess, um sistema de escalabilidade horizontal para MySQL

• A migração começou em 2017 e agora o Vitess já processa 99% de todas as consultas, com a migração completa prevista até o fim do ano

→ Atualmente, no pico, são 2,3 milhões de QPS (2 milhões de leitura, 300 mil de escrita)

→ A mediana da latência das consultas é de 2 ms, e a latência p99 das consultas é de 11 ms

• O Slack começou com a stack LAMP (Linux, Apache, MySQL, PHP)

• 3 clusters de banco de dados

→ Shards: todos os dados de usuários, como mensagens, canais e DMs. O particionamento é feito por workspace ID, então cada workspace fica em um único shard

Ou seja, o app do Slack precisa se conectar a apenas um banco de dados

→ Cluster de metadados: tabela de lookup para conectar workspaces aos shards

→ Cluster kitchen sink: armazena todos os dados que não pertencem a um workspace específico, como o diretório de apps

• O sharding era gerenciado e coordenado pelo monólito "webapp"

• Cada cluster é composto por um ou mais shards, e cada shard é provisionado com pelo menos duas instâncias MySQL em datacenters diferentes

• Vantagens da configuração Active-Active

→ Alta disponibilidade

→ Alta velocidade no desenvolvimento de produto

→ Depuração fácil

→ Expansão fácil

Mas, à medida que a organização cresceu e as equipes de produto passaram a criar novos recursos, a velocidade de desenvolvimento diminuiu

• Desvantagens do Active-Active

→ Limites de escalabilidade: com a entrada de clientes maiores, chegaram ao limite do que hosts mais potentes conseguiam suportar

→ Preso a um único modelo de dados:

Com recursos como Enterprise Grid e Slack Connect, isso passou a contrariar o paradigma de se conectar a apenas um servidor

→ Hotspots: a frota de bancos de dados não era bem aproveitada. Era difícil dividir shards e mover equipes, e como o uso do Slack era difícil de prever, a maioria dos shards era superprovisionada, o que dificultava aproveitar a long tail

→ Problemas de disponibilidade entre workspace e shard: se um shard apresentava problema, todos os clientes naquele shard ficavam sem conseguir usar o Slack

→ Operação: como não era uma configuração MySQL comum, muitas ferramentas internas precisaram ser desenvolvidas

• No outono de 2016, eles já administravam centenas de milhares de consultas MySQL por segundo e milhares de hosts MySQL com sharding

• Como enfrentavam regularmente problemas de escalabilidade e desempenho, passaram a considerar uma nova abordagem

• Consideraram evoluir o que já existia ou adotar um novo produto, mas

→ Queriam continuar usando MySQL executando em sua própria nuvem

→ Havia milhares de consultas únicas, e algumas delas usavam configurações especiais de MySQL

→ Deploy, backup, ETL para data warehouse, compliance etc. já eram todos baseados em MySQL

• Por que Vitess? : atendia à maior parte dos requisitos de aplicação e operação

→ MySQL Core: o Vitess é baseado em MySQL

→ Scalability: combina os principais recursos do MySQL com a escalabilidade de bancos NoSQL. Com sharding embutido, é possível escalar com flexibilidade sem adicionar lógica especial

→ Operability: lida automaticamente com failover e backup por padrão. Rastreia metadados sobre a configuração do cluster para manter a consistência

→ Extensibility: open source baseado em Go, com ampla cobertura de testes e uma comunidade de desenvolvedores aberta

• Aplicação prática do Vitess começou por recursos pequenos

→ Em 2017, criaram um recurso para integrar feeds RSS a canais do Slack

→ Em 2018, todas as novas tabelas passaram a ser criadas apenas no Vitess

→ Em meados de 2019, o Vitess já recebia mais escritas do que o banco legado

→ E o Slack continuou contribuindo para o open source do Vitess

→ Ao longo de 3 anos, migraram 99% para o Vitess. O 1% restante será concluído ainda este ano

• A adoção do Vitess pelo Slack foi um sucesso?

→ Vários clusters Vitess em diferentes regiões do mundo estão operando dezenas de keyspaces

→ Keyspaces são coleções lógicas que escalam de acordo com o número de usuários, equipes e canais

→ O sharding flexível passou a permitir escalar o Slack

→ Com a COVID-19, o número de consultas do Slack aumentou 50% em apenas uma semana

→ O keyspace mais movimentado foi expandido horizontalmente usando o workflow de split do Vitess

→ Antes, isso teria sido impossível de escalar e teria causado downtime

[xguru]

https://vitess.io/

Vitess: "Middleware de sharding para MySQL"

• Solução criada para facilitar a implantação, o escalonamento e o gerenciamento de MySQL e MariaDB na nuvem

• Opera e gerencia shards de MySQL sobre Docker (local) e Kubernetes

• A aplicação pode usar um proxy chamado VTGate como se estivesse se comunicando com o MySQL, enquanto internamente ele se conecta a outros servidores via gRPC

[xguru]

O serviço de e-mail Hey também usa Vitess

A stack tecnológica do Hey https://pt.news.hada.io/topic?id=2355