DynamoDB (paper de 2022): performance previsível

01 · CONTEXTO

Um banco que promete latência previsível

O artigo de 2022 descreve o Amazon DynamoDB, serviço de banco NoSQL em nuvem da AWS. A meta de projeto declarada é completar todas as requisições com latência de um dígito em milissegundos, e os autores afirmam que, para os clientes, desempenho consistente costuma importar mais que o tempo mediano de resposta.

Para dar a dimensão da escala: no evento Prime Day de 2021, que durou 66 horas, o pico citado chegou a 89,2 milhões de requisições por segundo, conforme citado por Marc Brooker.

O serviço é multi-inquilino: ele guarda dados de clientes diferentes nas mesmas máquinas físicas, e o isolamento entre tabelas vizinhas vem de reservas de recursos, provisionamento ajustado e monitoramento de uso.

02 · ARQUITETURA

Partições, réplicas e roteamento

Uma tabela é dividida em partições que atendem às necessidades de vazão e armazenamento. Cada partição tem réplicas em Zonas de Disponibilidade diferentes, e o grupo de replicação usa Multi-Paxos para eleição de líder e consenso.

Só a réplica líder atende escritas e leituras fortemente consistentes. A escrita é confirmada quando um quórum de pares persiste o registro no log local. Na frente ficam o serviço de roteamento, que autentica, autoriza e roteia cada requisição, e o serviço de metadados, de onde os roteadores obtêm as rotas.

1. A aplicação envia a requisição ao roteador, responsável por autenticar, autorizar e rotear cada requisição.

2. O roteador consulta o serviço de metadados para obter as informações de roteamento.

3. Uma escrita vai ao líder, que envia o registro de log às seguidoras e confirma depois que um quórum o persiste.

4. O serviço autoadmin monitora a saúde das partições e substitui réplicas consideradas não saudáveis.

03 · O PROBLEMA

Controle de admissão preso à partição

O DynamoDB usa controle de admissão para que os nós de armazenamento não fiquem sobrecarregados. Na versão original, o cliente declarava a vazão da tabela em unidades de capacidade de leitura e de escrita, e cada nó fazia a admissão de forma independente, com base nas alocações das partições que hospedava.

Quando uma partição era dividida por tamanho, a vazão da partição mãe era dividida igualmente entre as filhas. O próprio paper ilustra: supondo um máximo de 1000 WCUs por partição, uma tabela criada com 3200 WCUs vira quatro partições de 800; ao subir para 6000 WCUs, a tabela passa a oito partições de 750.

Essa divisão uniforme pressupõe que a aplicação acesse as chaves de modo uniforme. Na prática surgiram dois problemas: as hot partitions, com tráfego constante para poucos itens, e a diluição de vazão, comum quando partições eram divididas por tamanho. O resultado era throttling, isto é, leituras e escritas rejeitadas mesmo com a vazão total da tabela suficiente.

04 · EVOLUÇÃO

Respostas sucessivas ao mesmo problema

A primeira resposta foi o bursting: deixar a aplicação usar a capacidade ociosa da partição, em regime de melhor esforço, para absorver picos curtos. A capacidade não usada era retida por até 300 segundos. A segunda foi a capacidade adaptativa, criada para absorver melhor cargas com padrões de acesso muito enviesados entre partições.

A capacidade adaptativa foi, segundo o paper, de melhor esforço, mas eliminou mais de 99,99% do throttling causado por acesso enviesado. O paper aponta que a capacidade da partição estava acoplada ao controle de admissão e conclui que seria benéfico remover o controle de admissão.

05 · ADMISSÃO GLOBAL

Tokens no roteador, contabilidade no GAC

A admissão global (GAC) aproveita a mesma ideia de baldes de tokens. O serviço rastreia centralmente o consumo da tabela em tokens, e cada roteador mantém um balde local para decidir a admissão, repondo tokens com o GAC em intervalos regulares. O estado do GAC é efêmero: um servidor pode ser parado e reiniciado sem impacto na operação.

1. A requisição chega ao roteador, que debita tokens.

2. Quando os tokens acabam, o roteador pede mais ao GAC.

3. O GAC estima o consumo global da tabela e distribui os tokens do próximo intervalo.

4. Os baldes por partição foram mantidos além do esquema global, com capacidade limitada.

Outras peças completam o quadro. Há balanceamento proativo de partições entre nós por consumo de vazão e armazenamento, e a divisão automática de partições conforme a vazão consumida, com ponto de corte escolhido pela distribuição de chaves observada. O paper diz que o sistema detecta certos padrões de acesso e evita dividir a partição. Nas tabelas on-demand, o serviço acomoda instantaneamente até o dobro do pico anterior.

06 · PREVISIBILIDADE

O cache que esconde trabalho

Entre as lições do paper está projetar para previsibilidade, não para eficiência absoluta. Caches melhoram o desempenho, mas não devem esconder o trabalho que seria feito sem eles, de modo que o sistema esteja sempre dimensionado para o inesperado.

O exemplo é o cache de rotas dos roteadores. A taxa de acerto chegava a cerca de 99,75%, mas numa partida a frio toda requisição geraria uma consulta de metadados. A resposta foi o MemDS, um datastore distribuído em memória; no novo cache, um acerto também dispara uma chamada assíncrona ao MemDS, e a frota recebe tráfego constante independentemente da taxa de acerto.