Sharding por cliente e o shard 1 que cresceu demais

01 · CONTEXTO

Uma arquitetura que não durou o previsto

No podcast da InfoQ, Lucas Cavalcanti, do Nubank, conta que a arquitetura inicial de implantação comportava 500.000 clientes com folga e que a equipe achava que viveria com ela por alguns anos.

Segundo ele, quando a empresa começou não havia Kubernetes nem Docker, e a empresa cresceu mais rápido do que o projeto de migrar tudo para Docker ou para estruturas melhores na AWS. O projeto de sharding nasceu daí, da escolha inicial de implantação na AWS.

A nuvem permite escalar na vertical e, em alguns casos, na horizontal, mas ele diz que se chega a um limite, e foi por causa dele que o sharding precisou ser feito. Esse é o ponto de partida do caso: escalar na vertical e na horizontal tem teto.

1. O diagrama mostra uma única implantação dos serviços atendendo todos os clientes.

2. A mesma implantação lê e grava em um único banco de dados.

3. Escalar esse bloco na vertical, ou algumas instâncias na horizontal, chega a um limite na nuvem, e o relato liga o projeto de sharding a esse limite.

02 · A DECISÃO

Separar por cliente

A decisão de sharding foi separar por cliente: um shard guarda um conjunto de clientes e todos os dados desses clientes, e outro shard pode ter um conjunto diferente.

1. No diagrama com shards, cada grupo de clientes tem a sua própria pilha: serviços, banco e Kafka.

2. O segundo shard guarda um conjunto diferente de clientes e todos os dados deles.

3. O terceiro shard repete a mesma estrutura, de modo que o desenho cresce por cópias.

Na palestra publicada pela InfoQ, ele diz que o sharding ajudou muito a escalar na fase de consolidação, quando um caso raro que afetava 0,1% dos clientes passou a atingir milhares de clientes.

03 · A DÍVIDA

O primeiro shard que cresceu demais

Quando o projeto de sharding terminou, o primeiro shard estava maior do que deveria. Cavalcanti explica que não só o número de clientes pesa, mas também o tempo de casa de cada um.

Os primeiros clientes de uma startup são early adopters e os que mais usam o produto. O primeiro shard acabou com os clientes mais engajados, mais dados e mais clientes, porque o projeto de sharding demorou demais.

1. O primeiro shard reúne os clientes mais antigos, os early adopters, que mais usam o produto.

2. O provisionamento desse shard era de quatro a cinco vezes o dos shards criados depois.

3. Esse shard exigiu ajuste fino de desempenho.

4. O diagrama mostra os outros shards com a mesma estrutura do primeiro.

5. Com o tempo foi possível deixar todos os shards com tamanho parecido.

Segundo ele, a ideia do sharding no início era evitar ajuste de desempenho, e ainda assim o primeiro shard exigiu ajuste fino.

Sobre clientes fora da curva, a palestra diz que há clientes com 10x ou 100x mais transações que os outros. Para ele, isso afeta basicamente aquele cliente e não os demais, porque a maior parte das operações já é em lote.

Na palestra, ele também diz que o primeiro shard demorou mais que o esperado para ser montado e ficou com clientes antigos demais.

04 · ISOLAMENTO

O shard como unidade de isolamento e de previsão

Um post do blog de engenharia do Nubank descreve que o sharding foi além do banco: atinge bancos, serviços-chave e clusters inteiros de microsserviços. O Datomic roda vários transactors no Kubernetes, cada um com um subconjunto dos dados, e há vários clusters Kafka para diferentes shards, para espalhar a carga de mensagens.

O post aponta dois objetivos. O primeiro é impedir que problemas localizados se espalhem, porque cada shard é relativamente independente; é uma forma de isolar falhas. O segundo é prever capacidade em unidades menores e mais previsíveis, já que o uso de um shard ajuda a projetar os outros.

05 · QUOTAS

O que estoura primeiro na nuvem

O mesmo post lembra que todo provedor de nuvem impõe limites ou quotas, de balanceadores e instâncias EC2 a armazenamento, e que na escala do Nubank as quotas podem virar gargalo se não forem monitoradas.

1. O diagrama parte das contas AWS do Nubank.

2. O AWS Limit Smoke Detector é um pipeline de ETL que coleta uso, quota e custo de todas as contas AWS e agrega no BigQuery.

3. A ferramenta compara continuamente o uso real com as quotas atribuídas e aponta problemas antes de um limite crítico.

4. Quando o uso sobe rápido, o Smoke Detector alerta por dashboards e mensagens automáticas, e o time aumenta a quota ou otimiza o consumo do serviço.

06 · NA ENTREVISTA

Como usar o caso

Ao escolher uma chave de shard, pergunte se o tamanho de um shard depende só da contagem de clientes ou também de como eles usam o produto, e se há como distribuir os clientes mais ativos entre os shards.

Ao estimar o que estoura primeiro, liste os recursos que têm quota ou teto, compare o uso atual com cada um e diga como você seria avisado antes de chegar lá.