Slack: escalando datastores com Vitess

01 · CONTEXTO

Um datastore no caminho de cada mensagem

Desde o início do Slack, o MySQL foi o motor de armazenamento de todos os dados, numa configuração ativo-ativo. Em 2017 começou a migração para o Vitess, um sistema de escala horizontal para MySQL, e, segundo o post de engenharia de 1 de dezembro de 2020, ele já atendia 99% da carga de consultas.

O armazenamento é crítico porque toda mensagem enviada é persistida antes de seguir pela pilha de websocket em tempo real e aparecer para os demais membros do canal. Por isso o acesso ao armazenamento precisa ser muito rápido e muito confiável.

Na época do post, o pico era de 2,3 milhões de consultas por segundo, sendo 2 milhões de leituras e 300 mil escritas, com latência mediana de 2 ms e p99 de 11 ms.

02 · O MODELO ORIGINAL

Shards por workspace, ativo-ativo

O Slack nasceu como uma pilha LAMP simples e guardava tudo em três clusters primários baseados em MySQL: os shards, o cluster de metadados e o chamado kitchen sink.

Os shards continham praticamente todos os dados de clientes, como mensagens, canais e DMs, particionados por id de workspace. O cluster de metadados era uma tabela de consulta que ligava o workspace ao shard, e o kitchen sink guardava o que não estava ligado a um workspace.

1. O monólito webapp gerencia todo o acesso a dados: ele tem a lógica de consultar os metadados do workspace e então criar a conexão com o shard.

2. Primeiro ele consulta o cluster de metadados para descobrir qual é o shard do workspace.

3. Depois conecta ao shard, que tem ao menos dois MySQL em datacenters diferentes replicando um ao outro de forma assíncrona.

4. A aplicação prefere um dos lados por um hash simples; se um host falha, repete o pedido no outro, e os dois aceitam leituras e escritas.

5. Dados que não pertencem a nenhum workspace, como o diretório de apps, vão para o kitchen sink.

6. Se um shard inteiro sofre uma queda, todo cliente cujos dados estão nele fica sem o Slack.

03 · POR QUE MUDAR

Os limites do modelo por workspace

No outono de 2016 o Slack lidava com centenas de milhares de consultas MySQL por segundo e milhares de hosts com shards, e as equipes de performance viviam contornando limitações da arquitetura por workspace. A tabela resume os limites que a própria fonte descreve.

04 · ALTERNATIVAS

Evoluir no lugar ou substituir

A meta era, em vez de colocar todas as mensagens de um workspace no mesmo shard, fragmentá-las pelo id do canal, o que espalharia a carga de forma bem mais uniforme.

O Slack queria continuar com MySQL em servidores próprios na nuvem. Havia milhares de consultas distintas na aplicação, algumas com construções específicas do MySQL. Sair do paradigma relacional seria uma mudança muito mais disruptiva, e por isso o Slack descartou praticamente os NoSQL, como DynamoDB e Cassandra, e os NewSQL, como Spanner e CockroachDB.

Colocar o novo modelo de sharding na própria aplicação foi considerado e chegou a ter protótipos, mas já havia muito acoplamento entre a lógica da aplicação e a forma de guardar os dados. Além disso, esse caminho não resolvia os problemas operacionais nem permitia usar réplicas de leitura com mais eficiência.

O Vitess é construído sobre o MySQL e o usa como motor de armazenamento e replicação. Seu sharding embutido permite fragmentar e crescer o banco sem lógica extra na aplicação, e ele trata failovers de primário e backups, mantendo a aplicação alheia à topologia por meio de um servidor de bloqueio.

05 · MIGRAÇÃO ONLINE

Do protótipo aos dados em produção

O primeiro uso em produção foi um recurso pequeno: integrar um feed RSS a um canal. Para isso o Slack precisou desenvolver pontos de integração para rotear consultas ao Vitess, um sistema genérico de backfill que clona tabelas existentes enquanto a aplicação faz escritas duplas, e um sistema paralelo de leituras duplas com comparação.

1. O sistema de backfill clona a tabela existente do banco legado para o Vitess.

2. Enquanto isso, a aplicação faz escritas duplas a partir do código.

3. Um sistema paralelo de leituras duplas compara as respostas para garantir que as tabelas no Vitess têm a mesma semântica das legadas.

4. O primeiro recurso migrado foi pequeno, a integração de um feed RSS; ele mostrou resiliência e confiabilidade e deu confiança para continuar investindo.

5. Três anos depois do início, 99% do tráfego MySQL do Slack já estava no Vitess.

A migração moveu tabelas: uma única tabela, que compõe 20% da carga de consultas, ganhou um estudo de caso próprio, e o post anunciava um futuro artigo sobre a mudança de estratégia para mover shards inteiros em vez de tabelas.

06 · VITESS EM PRODUÇÃO

Keyspaces, regiões e novos serviços

No momento do post, o Slack operava vários clusters Vitess, com dezenas de keyspaces em regiões geográficas do mundo. Cada keyspace é uma coleção lógica de dados que escala aproximadamente pelo mesmo fator: número de usuários, equipes e canais. O Vitess é usado tanto pelo monólito webapp quanto por outros serviços.

1. O webapp e os outros serviços falam com a camada de acesso do Vitess, e a aplicação fica alheia à topologia do banco.

2. O servidor de bloqueio guarda os metadados da configuração do cluster, para que a visão seja atualizada e consistente entre os clientes.

3. Os dados ficam em keyspaces, coleções lógicas que escalam por usuários, equipes e canais.

4. Em março de 2020 as consultas subiram 50% em uma semana, e um dos keyspaces mais ocupados foi escalado na horizontal com os fluxos de divisão do Vitess.

5. No produto de residência internacional de dados, o Vitess é a camada de armazenamento, com clusters em seis regiões.

O Slack não adotou o Vitess pronto: identificou lacunas para necessidades próprias e investiu em preenchê-las. Entre as contribuições estão a refatoração do serviço de metadados de topologia para escalar entre regiões de isolamento, melhorias na compatibilidade com consultas MySQL e o vtexplain, um motor de simulação que ajuda a entender como as consultas se comportarão no Vitess.

Escolher o Vitess em vez de criar uma camada de sharding no monólito permitiu usar a mesma tecnologia em todos os novos serviços. No estudo de caso da CNCF, a latência de conexão com o Vitess é de um milissegundo a mais em média, imperceptível para os usuários.

07 · BALANÇO

Foi a escolha certa?

Em retrospecto, o Slack considera o Vitess a solução certa. A equipe diz que isso não significa que não teria achado um jeito de escalar sem ele, mas que, com seus requisitos, chegaria a uma solução bem parecida.