AWS: células e shuffle sharding (Builders' Library)

01 · CONTEXTO

Por que isolar clientes em vez de só escalar

Mesmo sabendo que está num ambiente multi-tenant, o cliente ainda quer a experiência de um ambiente dedicado. Segundo a AWS, o shuffle sharding virou um padrão central para entregar serviços multi-tenant de custo eficiente com experiência de single-tenant, e a orientação sobre arquitetura em células busca reduzir o efeito das falhas a um número limitado de componentes. Ambos tratam do raio de impacto de uma falha.

O shuffle sharding aparece como a invenção que atendeu uma necessidade do Amazon Route 53. Segundo a AWS, o maior desafio de qualquer provedor de DNS é lidar com ataques DDoS, e comprar capacidade de servidor em grande volume é uma estratégia perdedora. A necessidade era gastar recursos só na defesa dos domínios que de fato estavam sob ataque, e a invenção que a atendeu foi o shuffle sharding.

02 · LINHA DE BASE

O raio de impacto de uma frota compartilhada

Sem sharding, qualquer worker precisa tratar qualquer pedido. Isso é ótimo para eficiência e redundância, e pouca folga de capacidade é necessária, porque os demais workers absorvem o trabalho de quem falha.

1. Sem sharding, qualquer worker trata qualquer pedido; se um falha, os demais absorvem o trabalho dele.

2. Um tipo particular de pedido, ou uma inundação de pedidos, derruba o primeiro worker atingido.

3. Os workers restantes assumem a carga do que caiu e o problema se propaga por eles.

4. O escopo de impacto vira o serviço inteiro e todos os clientes.

O sharding regular divide a frota em shards. Como cada shard tem poucos workers, é preciso manter mais capacidade ociosa para absorver falhas; em troca, o escopo de impacto cai na proporção do número de shards. No exemplo da AWS, um shard representa um quarto do serviço, e um impacto de 25 por cento é muito melhor que um de 100 por cento.

03 · SHUFFLE SHARDING

Cada cliente, uma combinação de workers

No shuffle sharding criam-se shards virtuais de dois workers, e cada cliente (ou recurso a isolar) é atribuído a um deles. O problema de um cliente afeta o seu shard virtual, mas não afeta totalmente nenhum outro: no máximo um worker de outro shard é atingido.

1. Cada cliente é atribuído a uma combinação de dois workers, o seu shuffle shard; o Arco-íris usa alfa e beta.

2. Os outros clientes recebem outras combinações: Rosa e Girassol dividem um worker cada um com o Arco-íris, mas nenhum divide os dois.

3. O Arco-íris dispara um pedido problemático ou uma inundação de pedidos, e o problema atinge o seu shard virtual.

4. Rosa e Girassol continuam atendidos pelos workers delta e gama, desde que o cliente tolere a falha parcial, por exemplo com retentativas.

5. Nenhum outro shard perde os dois workers: no máximo um worker de cada outro shard é afetado.

A conta explica o ganho. Com oito workers há 28 combinações de dois workers, ou seja, 28 shuffle shards possíveis; com muitos clientes distribuídos entre eles, o escopo de impacto de um problema é de 1/28, sete vezes melhor que o sharding regular.

Quanto mais workers e clientes, melhor: a maioria dos desafios de escala piora nessas dimensões, mas o shuffle sharding fica mais eficaz. Com workers suficientes pode haver mais shuffle shards do que clientes, e cada cliente pode ser isolado.

04 · EM ESCALA

O shuffle sharding no Amazon Route 53

No Route 53, a capacidade é organizada em 2048 servidores de nomes virtuais, que não correspondem aos servidores físicos e podem ser movidos para gerir capacidade. Cada domínio de cliente recebe um shuffle shard de quatro servidores virtuais, o que dá 730 bilhões de shuffle shards possíveis, e nenhum domínio compartilha mais de dois servidores virtuais com outro.

Se um domínio sofre um ataque DDoS, os quatro servidores virtuais dele têm pico de tráfego, mas nenhum outro domínio percebe. O shuffle sharding também permite identificar o cliente alvo e isolá-lo em capacidade dedicada a ataques.

05 · CÉLULAS

Células: isolar a carga de trabalho inteira

Uma arquitetura em células usa várias instâncias isoladas da carga de trabalho, cada uma chamada de célula. Cada célula é independente, não compartilha estado com as outras e atende um subconjunto dos pedidos. Uma camada de roteamento distribui os pedidos pela chave de partição, como o ID do cliente, e apresenta um único endpoint aos clientes.

A ideia vem do conceito de anteparo (bulkhead) de um navio, com compartimentos estanques, e em sistemas complexos esse padrão costuma ser replicado para isolar falhas. As células contêm falhas difíceis de conter de outro modo, como deploys malsucedidos e pedidos corrompidos ou que acionam um modo de falha específico (poison pill requests).

1. O cliente fala com um único endpoint; o roteador de células usa a chave de partição para decidir qual célula atende o pedido.

2. O pedido segue para a célula A, uma carga de trabalho completa, com serviço e banco próprios.

3. Uma atualização de software ruim, ou um pedido corrompido, atinge a célula B: o efeito fica restrito a ela e aos pedidos que ela processa.

4. As demais células não compartilham estado com a B e seguem atendendo seus clientes.

5. O plano de controle provisiona células e informa o roteador; se ele ficar indisponível, o que já foi provisionado continua atendendo.

A AWS dá a conta do isolamento: com 10 células atendendo 100 pedidos, quando uma célula falha, 90% dos pedidos não são afetados. Ela também observa que montar células não exige necessariamente dobrar ou triplicar a infraestrutura; 30 hosts podem continuar sendo os mesmos 30 hosts, com um roteador e tarefas agrupadas entre células.

São três peças. O roteador é a camada mais fina possível e só roteia pedidos para a célula certa; a célula é uma carga de trabalho completa; e o plano de controle faz a administração, com APIs para provisionar, mover, migrar, atualizar, remover, implantar e monitorar células. Depois de provisionado, o plano de dados não depende do plano de controle, que tem estatisticamente mais chance de falhar.

Como o roteador é compartilhado entre células, ele não segue a compartimentalização delas; por isso deve ser o mais simples e horizontalmente escalável possível, sem lógica de negócio complexa. Quanto à chave de partição, a boa é a de fácil acesso na maioria das chamadas de API, e é preciso pensar em como tratar clientes muito grandes. Chamadas entre células devem voltar pelo roteador normal.

06 · DECISÕES

Onde traçar a fronteira da célula e quando vale o custo

A fronteira da célula pode seguir as zonas de disponibilidade de duas formas. Na Multi-AZ, as células são Multi-AZ ou regionais. Na Single-AZ, o serviço é dividido seguindo as fronteiras de AZ.

A AWS propõe uma pergunta para decidir: é melhor 100% dos clientes terem 5% de falha ou 5% dos clientes terem 100% de falha? Ela vê benefício em aplicações em que qualquer indisponibilidade tem grande impacto negativo e em serviços multi-tenant em que alguns tenants exigem a própria célula, e avisa que a arquitetura não serve para todas as cargas.

O preço é real: mais complexidade pela redundância de infraestrutura e componentes, custo alto de infraestrutura e serviços, ferramentas e práticas operacionais especializadas e a necessidade de investir numa camada de roteamento de células.