Amazon Aurora: "o log é o banco"

01 · CONTEXTO

Quando o gargalo vira a rede

O Amazon Aurora é um serviço de banco relacional para cargas OLTP oferecido como parte da AWS. O traço central da arquitetura é tirar do motor do banco várias funções (registro do redo log, armazenamento durável, recuperação de queda e backup com restauração) e entregá-las a um serviço de armazenamento próprio, multi-tenant, que escala horizontalmente e é fracamente acoplado à frota de instâncias de banco.

Em nuvem, o I/O se espalha por muitos nós e discos de uma frota compartilhada, então discos e nós individuais deixam de ficar quentes. O gargalo passa a ser a rede entre a camada de banco, que pede os I/Os, e a camada de armazenamento, que os executa. Além do limite de pacotes por segundo e de banda, há amplificação de tráfego, porque um banco de bom desempenho emite as escritas em paralelo para a frota. O desempenho do nó, disco ou caminho de rede mais lento pode dominar o tempo de resposta.

02 · O PROBLEMA

Por que replicar um MySQL tradicional não escala

Instâncias falham, clientes as desligam e as redimensionam conforme a carga, e o tempo de vida de uma instância não acompanha o do armazenamento. Por isso, segundo o paper, ajuda desacoplar a camada de armazenamento da de computação.

O problema é que um MySQL tradicional gera muitos I/Os reais para cada escrita da aplicação. Entre os dados gravados estão o redo log, o log binário arquivado no S3, as páginas de dados modificadas, uma segunda escrita temporária da página (double-write) contra páginas rasgadas e os arquivos de metadados. A replicação amplifica esse volume, impõe uma carga pesada de pacotes por segundo e cria pontos de sincronização que travam pipelines e dilatam a latência.

1. A aplicação escreve no MySQL ativo, que roda numa AZ com armazenamento em rede.

2. A escrita vai ao volume EBS, que a repassa a um espelho local da AZ; a confirmação só chega quando os dois terminam.

3. Em seguida a escrita é enviada ao standby, em outra AZ, por espelhamento síncrono em nível de bloco.

4. Por fim o standby grava no próprio volume EBS e no espelho associado.

5. À parte, o log binário é arquivado no S3.

6. Parte desses passos é sequencial e síncrona, então a latência se soma; o paper vê o modelo como um quórum de escrita 4/4, vulnerável a falhas e a desempenho de componentes lentos (outliers).

Para medir o tráfego de rede, os autores rodaram um teste com a carga de escrita do SysBench sobre um conjunto de dados de 100 GB, comparando MySQL espelhado entre AZs e Aurora, por 30 minutos em uma instância r3.8xlarge. O Aurora sustentou 35 vezes mais transações; no nó de banco, o número de I/Os por transação foi 7,7 vezes menor, apesar de o Aurora amplificar as escritas seis vezes. Cada nó de armazenamento vê escritas não amplificadas, pois guarda só uma das seis cópias, o que dá 46 vezes menos I/Os para processar nessa camada.

03 · DURABILIDADE

Seis cópias em três AZs

A abordagem comum para tolerar a perda de um nó é replicar em três nós, com quórum de escrita de 2/3 e quórum de leitura de 2/3. Para a consistência, o quórum obedece a duas regras: toda leitura deve conhecer a escrita mais recente, o que se formula como Vr + Vw > V, e toda escrita deve conhecer a escrita mais recente para evitar escritas conflitantes, formulada como Vw > V/2.

Os autores consideram os quóruns de 2/3 inadequados. Numa frota grande, a qualquer momento algum conjunto de discos ou nós pode estar falhado e em reparo, com falhas espalhadas de forma independente pelas AZs, e a falha de uma AZ inteira quebra o quórum de qualquer réplica que já tenha falha concorrente em outra AZ. Em outras palavras, as falhas individuais por AZ são não correlacionadas, mas a falha de uma AZ é uma falha correlacionada de todos os discos e nós dela.

A escolha do Aurora é tolerar a perda de uma AZ inteira mais um nó adicional sem perder dados, e a perda de uma AZ inteira sem perder a capacidade de escrever. Para isso, replica cada item seis vezes em três AZs, com duas cópias por AZ, usando seis votos, quórum de escrita de 4/6 e de leitura de 3/6. Assim dá para perder uma AZ e mais um nó (três nós) sem perder disponibilidade de leitura, e perder quaisquer dois nós, o que inclui a falha de uma AZ, mantendo a disponibilidade de escrita. Garantir o quórum de leitura permite reconstruir o quórum de escrita adicionando cópias.

Com esses valores, as duas regras de quórum se verificam: a soma dos quóruns de leitura e de escrita passa do total de votos, e o quórum de escrita passa da metade dos votos.

1. O volume é replicado em seis cópias, duas em cada uma de três AZs.

2. Uma AZ inteira falha e leva consigo suas duas cópias; as escritas continuam disponíveis.

3. Com a AZ fora e mais um nó perdido, ainda há disponibilidade de leitura.

4. Com o quórum de leitura, o sistema reconstrói o quórum de escrita adicionando cópias.

A partir de certo ponto é difícil reduzir a probabilidade de falhas independentes (MTTF); por isso o Aurora foca em reduzir o tempo de reparo (MTTR), encolhendo a janela de vulnerabilidade a uma falha dupla. Ele particiona o volume em segmentos pequenos de tamanho fixo, hoje de 10 GB, e cada segmento é replicado seis vezes num Protection Group (PG): seis segmentos de 10 GB em três AZs, dois por AZ. Um segmento de 10 GB pode ser reparado em 10 segundos num link de 10 Gbps. Para perder o quórum seria preciso ver duas dessas falhas na mesma janela de 10 segundos mais a falha de uma AZ que não contém nenhuma delas, e, nas taxas observadas, isso é suficientemente improvável.

04 · O LOG É O BANCO

Só o redo cruza a rede

No Aurora, as únicas escritas que cruzam a rede são registros de redo log. Nenhuma página é escrita pela camada de banco, nem em escritas de fundo, nem em checkpoint, nem na remoção do cache; o aplicador de log é levado para o storage, que gera as páginas em segundo plano ou sob demanda. Para o motor, o log é o banco: as páginas que o storage materializa continuamente são só um cache de aplicações do log.

Diferente do checkpoint, governado pelo comprimento de toda a cadeia de redo, a materialização de páginas é governada pelo comprimento da cadeia de cada página, e só páginas com cadeia longa precisam ser rematerializadas.

1. A aplicação envia a transação ao writer, cujo motor é um fork do MySQL/InnoDB que diverge principalmente em como lê e grava dados em disco.

2. O writer envia ao storage apenas registros de redo, agrupados em lotes por PG, para as seis cópias.

3. Quando quatro das seis cópias confirmam, o lote é durável e o banco avança o ponto durável do volume.

4. O commit é assíncrono: a thread que o recebe anota o LSN de commit e segue trabalhando, e uma thread dedicada avisa o cliente quando o ponto durável alcança esse LSN.

5. O mesmo fluxo de log segue para as réplicas de leitura, de forma assíncrona em relação ao writer.

6. Em segundo plano, serviços de backup e restauração copiam continuamente para o S3 os dados alterados no storage.

Um writer e até 15 réplicas de leitura montam o mesmo volume de armazenamento compartilhado, então as réplicas não adicionam custo de armazenamento consumido nem de escrita em disco. A réplica aplica apenas registros com LSN menor ou igual ao VDL e aplica de forma atômica os registros de uma mesma mini-transação, para enxergar uma visão consistente; na prática, cada réplica costuma ficar atrás do writer por 20 ms ou menos.

O princípio de projeto do storage é minimizar a latência da escrita em primeiro plano e mover o grosso do processamento para o fundo. Cada nó de armazenamento executa oito atividades, mas só as duas primeiras ficam no caminho em primeiro plano.

1. O nó recebe o registro, o coloca numa fila em memória, grava em disco e confirma; só esse trecho fica no caminho em primeiro plano.

2. Depois ele organiza os registros e identifica lacunas no log, pois alguns lotes podem ter se perdido.

3. Para preencher as lacunas, o nó troca gossip com os pares do mesmo grupo.

4. Em segundo plano, ele junta (coalesce) os registros de log em novas páginas de dados.

5. Periodicamente, envia o log e as páginas novas ao S3.

6. A coleta de lixo de versões antigas e a validação de CRC também são periódicas; a coleta pode esperar enquanto o nó está ocupado com escritas, a menos que o disco esteja perto da capacidade.

Se o atraso se acumula, o storage freia a atividade em primeiro plano. Como os segmentos são espalhados com alta entropia pelos nós, o freio num nó aparece ao quórum de escrita 4/6 apenas como um nó lento.

05 · CONSISTÊNCIA E RECUPERAÇÃO

Sem 2PC e sem recuperação na partida

Em vez de um protocolo como o 2PC, descrito como falante e intolerante a falhas, o Aurora trata o consenso de forma assíncrona: mantém pontos de consistência e durabilidade e os avança continuamente à medida que recebe confirmações do storage. Um nó que perdeu registros troca gossip com os outros membros do seu PG para preencher as lacunas.

Cada registro de log tem um LSN, valor monotonicamente crescente gerado pelo banco. O banco não aloca LSN acima da soma do VDL atual com o LAL (LSN Allocation Limit), hoje de 10 milhões. Esse limite impede que o banco se adiante demais do storage e introduz contrapressão que pode frear as escritas se o storage ou a rede não acompanharem.

Exemplo do paper: mesmo com os dados completos até o LSN 1007, o banco pode ter declarado como CPLs apenas 900, 1000 e 1100; então o truncamento é em 1000. O volume está completo até 1007, mas só durável até 1000.

Em condições normais o banco não precisa de leitura de quórum: ao ler uma página do disco, fixa um ponto de leitura (o VDL no momento do pedido) e escolhe um nó de armazenamento completo em relação a esse ponto. O estado mantido em tempo de execução permite leituras de um único segmento em vez de leituras de quórum, exceto na recuperação, quando o estado é perdido e precisa ser reconstruído.

Num banco tradicional, a recuperação de queda reaplica o redo desde o último checkpoint, o que pode ser caro; reduzir o intervalo de checkpoint ajuda, mas à custa de interferência nas transações em primeiro plano. No Aurora esse trade-off não existe: o redo é aplicado no storage de forma contínua, assíncrona e distribuída, e nada é exigido na partida do banco. O paper relata recuperação geralmente em menos de 10 segundos, mesmo com mais de 100.000 escritas por segundo no momento da queda.

1. O writer cai, mas o storage já aplicava o redo continuamente, em segundo plano e distribuído pela frota; nada é exigido na partida do banco.

2. Ao subir, o banco contata, para cada PG, um quórum de leitura de segmentos, suficiente para descobrir qualquer dado que possa ter atingido o quórum de escrita.

3. Com o quórum de leitura de cada PG, ele recalcula o VDL e anula os registros acima dele; o limite superior do truncamento é inferido do limite de alocação de LSN, e os intervalos são versionados por épocas e gravados de forma durável.

4. O undo das transações em andamento ainda é necessário, mas pode acontecer com o banco já online.

06 · RESULTADOS E LIMITES

O que o paper mostra e o que ele assume

Nos benchmarks do paper, com a carga de escrita do SysBench e banco de 100 GB, o Aurora chegou a ser até 67 vezes mais rápido que o MySQL; com banco de 1 TB e carga fora do cache, ainda 34 vezes. No benchmark OLTP do SysBench, com as conexões subindo de 50 para 500 e 5000, o Aurora escala de 40.000 a 110.000 escritas por segundo, enquanto o MySQL tem pico perto de 500 conexões e depois cai bruscamente.

A seção de cargas reais traz resultados relatados por clientes que migraram do MySQL. Numa empresa de tecnologia educacional, o atraso de réplica chegava a picos de 12 minutos, o que afetava a correção da aplicação e deixava a réplica útil só como standby; depois da migração, o atraso máximo entre 4 réplicas nunca passou de 20 ms. Na mesma empresa, as latências P95 variavam de 40 ms a 80 ms, bem piores que as P50 de cerca de 1 ms, e depois da migração se aproximaram das P50.

O desenho tem uma premissa explícita: em qualquer momento há um único writer gerando atualizações de log, com LSNs alocados de um único domínio ordenado, e é com essa simplificação que o Aurora oferece os níveis de isolamento. O controle de concorrência é implementado inteiramente no motor do banco, sem impactar o storage, e o writer oferece os mesmos níveis de isolamento do MySQL comunitário.

Entre as lições operacionais, o paper cita que muitos clientes têm baixa tolerância a atualizações do software do banco, mesmo que isso signifique uma parada planejada de 30 segundos a cada 6 semanas, mais ou menos. O paper descreve o recurso ZDP, que permite aplicar o patch a um cliente enquanto as conexões em andamento não são afetadas.