Desbloqueando Aurora DSQL com AWS Lambda: Uma Solução Integrada para Arquiteturas Serverless, Escaláveis e Orientadas a Eventos

Traduzido do English • Ver original

O AWS re:Invent já começou e há muitos anúncios de novos serviços e recursos pelo CEO da AWS, Matt Garman, na palestra principal (confira meu tópico x/bluesky nas atualizações da keynote)

Neste blog, vamos investigar sobre o Amazon Aurora DSQL, que é um banco de dados SQL distribuído e serverless, com escala praticamente ilimitada, alta disponibilidade e zero gerenciamento de infraestrutura que afirma 99,99% de disponibilidade em uma única região e 99,999% em múltiplas regiones.

Minha intenção com este blog é fazer você entender a arquitetura, inovação e componentes principais e fornecer uma solução totalmente serverless para gerenciar o Aurora DSQL usando a função AWS Lambda com código 🔥 funcional

Motivação

*4 de dezembro de 2024, 4h (JST) No segundo dia re:Invent 2024, a AWS lançou uma atualização empolgante apresentando o Amazon Aurora DSQL(Preview)!! *

O que essa atualização significa para você?

Aqui estão as principais razões pelas quais o Amazon Aurora DSQL é um divisor de águas:

Escalabilidade ilimitada: Escalar leituras, gravações, computação e armazenamento sem esforço para lidar com qualquer carga de trabalho sem sharding ou atualizações de instância.
Alta Disponibilidade: O design serverless ativo-ativo do Aurora DSQL automatiza a recuperação de falhas, garantindo disponibilidade contínua Multi-AZ e multi-região com forte consistência, eliminando preocupações com failovers ou perda de dados.
Desempenho Mais Rápido: Oferece as leituras e gravações SQL distribuídas mais rápidas, tornando-o ideal para aplicações de alto desempenho.
Gerenciamento de Infraestrutura Zero: O design totalmente serverless elimina a necessidade de patches, atualizações e tempo de manutenção inativo, economizando tempo e recursos.
Forte Consistência de Dados: Aurora DSQL é otimizado para cargas de trabalho transacionais que se beneficiam de transações ACID e de um modelo de dados relacional.
Compatibilidade pós-greSQL: Simplifica o desenvolvimento com uma interface SQL familiar e amplamente utilizada, reduzindo curvas de aprendizado.
Amigável ao Desenvolvedor: Uma experiência intuitiva que permite o desenvolvimento rápido de aplicações sem complexidades operacionais.

Custo do Aurora DSQL

Aurora DSQL está atualmente disponível em prévia sem custo.

Componentes Centrais em Aurora DSQL

Arquitetura Distribuída

O Aurora DSQL foi projetado como um banco de dados distribuído, ou seja, suas partes trabalham juntas em múltiplos locais (Zonas de Disponibilidade) para garantir alta disponibilidade e tolerância a falhas. Ele possui quatro componentes principais:

Relé e Conectividade: Cuida de como os dados se movem dentro do sistema e conecta os usuários ao banco de dados.
Computação e Bancos de Dados: Gerencia o processamento real das consultas e da lógica do banco de dados.
Registro de Transações e Isolamento: Garante o manuseio seguro e consistente de múltiplas operações simultâneas (por exemplo, sem conflitos de dados).
Armazenamento do Usuário: Armazena os dados reais de forma segura.

Um plano de controle supervisiona e coordena esses componentes, que são projetados para se auto-curar e escalar automaticamente caso algo falhe.

Aglomerados DSQL Aurora

Agrupamentos de Região Única:
- Seus dados são sincronizados entre múltiplos data centers (AZs) dentro de uma única Região.
- Essa configuração evita problemas como atrasos de replicação ou failovers de banco de dados.
- Forte consistência garante que todos os usuários vejam os mesmos dados, independentemente de onde se conectem.
- Se parte do sistema falhar, as solicitações automaticamente migram para uma infraestrutura saudável sem sua intervenção.
- Suporta transações ACID (garantindo confiabilidade, consistência e durabilidade).
Clusters Ligados Multi-Regionais:
- Esses recursos estendem os recursos acima para múltiplas Regiões, oferecendo dois endpoints (um em cada Região) que funcionam como um único banco de dados.
- Ambas as Regiões podem lidar com leituras e gravações simultaneamente, garantindo forte consistência.
- Ideal para aplicações globais onde desempenho e resiliência são cruciais.

Compatibilidade PostgreSQL

Aurora DSQL é construído sobre o PostgreSQL 16, um popular código aberto

Como Resiliência de Dados e Backup são suportados

Backup e Restauração

Atualmente, backup e restauração não são suportados durante a fase de prévia.
O Aurora DSQL planeja integrar-se ao console AWS Backup, permitindo capacidades completas de backup e restauração tanto para clusters de uma única região quanto de múltiplas regiones.

Replicação

Registros de Transações:
- O Aurora DSQL faz commit de todas as gravações em um log de transações distribuído e replica os dados de forma síncrona entre três AZs.
Replicação Multi-Região:
- Fornece replicação entre regiões tanto para Regiões de leitura quanto de escrita.
- Utiliza uma Região testemunha para armazenamento de logs de transações criptografadas, sem necessidade de configuração manual ou sobrecarga de armazenamento.
Gerenciamento de dados:
- Divide automaticamente, mescla e replica dados com base em padrões de acesso e intervalos de chaves primárias.
- Escala dinamicamente réplicas de leitura com base na demanda de leitura.
Autocura:
- Redireciona o acesso durante deficiências do AZ e repara dados ausentes de forma assíncrona.
- Réplicas reparadas são adicionadas automaticamente de volta ao quórum de armazenamento.

Alta Disponibilidade

Design Ativo-Ativo:
- Tanto clusters de região única quanto multi-região são ativos-ativos, com recuperação totalmente automatizada.
- Elimina a necessidade de processos tradicionais de failover primário-secundário.
Replicação Multi-AZ:
- Garante replicação síncrona entre três AZs, evitando riscos de perda de dados ou lag.
Pontos Finais Regionais:
- Clusters de Região Única oferecem um endpoint redundante para leituras e gravações consistentes em três AZs.
- Clusters Multi-Região fornecem dois endpoints regionais para acesso zero e altamente consistente entre Regiões.
- Use a Amazon Route 53 para endpoints globais gerenciados, se necessário.

Usando AWS Lambda com Aurora DSQL

Claro que é o re:Invent e eu explicaria aos meus leitores uma forma inovadora de se conectar ao banco de dados Aurora DSQL e realizar operações de banco de dados, como criar tabelas e inserir alguns dados usando a função AWS Lambda

Durante a prévia, você pode interagir com clusters em EUA-leste-1 – EUA Leste (N. Virginia) e EUA-leste-2 – EUA Leste (Ohio).

Criar banco de dados DSQL Aurora

Buscar Aurora DSQL no console

Para este blog, estou criando banco de dados de região única e mantendo outras configurações como padrão. Na prévia, o nome do cluster é configurado usando Etiquetas de Nome-Valor.
Selecione criar cluster e, após a criação, copie a URL do endpoint do banco de dados.

Isso é tudo, não há mais nada para gerenciar, provisão. É uma implantação de 1 clique do Aurora DSQL para você!!

Criar função Lambda

Essa função lambda vai se conectar ao banco de dados DSQL Aurora, criar tabelas, inserir alguns dados e depois verificar esses dados lendo novamente. Sim, uma operação verdadeiramente sem servidor usando Lambda e Aurora DSQL

Autorize seu papel de execução Lambda a se conectar ao seu cluster adicionando o papel de Administrador de Políticas inline como Política inline a todos os recursos.
Lambda -> Configuração -> Permissões -> adicionar política inline

{ 
    "Versão": "2012-10-17", 
    "Declaração": [ 
        { 
            "Sid": "Declaração1", 
            "Efeito": "Permitir", 
            "Ação": ["dsql:DbConnectAdmin"], 
            "Recurso": ["*"]
        }
    ]
}

Nota: Você não deve usar uma função de banco de dados administrativo para suas aplicações de produção, fazendo isso para o blog

Se você já trabalhou com Lambda, então sabe que precisamos enviar um pacote postal. Eu compartilhei o código lambda no meu repositório
Use os seguintes comandos após fazer fork e puxar o repositório para sua máquina local

instalação de NPM. Gera package-lock.json
cd ~/caminho-para-código
zip -r pkg.zip .

Enviar o pacote

Na aba Test da sua função Lambda, use o seguinte JSON de Evento modificado para especificar o endpoint do seu cluster.

{"ponto final": "replace_with_your_cluster_endpoint"}

Você também pode usar Variáveis de Ambiente, então precisa mudar o código e se referir ao endpoint como 'process.env.ENDPOINT'

Teste as operações verdadeiramente serverless (LAMBDA + Aurora DSQL)

A implementação funcionou, mas falhou
Vamos usar o Amazon Q para diagnosticar e corrigir para nós

Aumentando o tempo de espera do Lambda para 10 segundos a partir dos 3 segundos padrão
Voilà, funcionou.

**Nota:**PARA verificar os dados, estamos usando o seguinte código dentro da nossa Função Lambda

        assert.strictEqual(result.rows[0].city, "Anytown"); 
        assert.notStrictEqual(result.rows[0].id, null);

Agora vamos tentar falhar o lambda dando o ponto final errado

Entendendo autenticação e autorização para Aurora DSQL

O Aurora DSQL usa funções e políticas IAM para autorização e autenticação de clusters. Você associa funções IAM com funções de banco de dados PostgreSQLs para autorização de banco de dados.
Quando você se conecta, em vez de fornecer uma credencial, você usa um token de autenticação temporário (válido por 1 hora).
Para autenticação:
- *Se você está usando o papel de administrador:* A identidade IAM deve ter a ação de política 'dsql:DbConnectAdmin'
- *Se você estiver usando o papel de banco de dados personalizado:* A identidade IAM deve ter a ação de política 'dsql:DbConnect'

Interaja com seu banco de dados usando funções de banco de dados PostgreSQL e funções IAM

Para Autorização de Banco de Dados:
- Use funções de banco de dados PostgreSQL para autorização em nível de banco de dados.
- A Aurora DSQL oferece dois tipos de funções:
- Função de Administrador: Pré-criada pela Aurora DSQL, não modificável e usada para tarefas administrativas como criação de papéis personalizados.
- Funções Personalizadas: Criadas por você e atribuídas permissões PostgreSQL conforme necessário.
Associação de Papéis:
- Vincule papéis personalizados de banco de dados com papéis IAM para permitir que identidades IAM se conectem ao banco de dados.
Autenticação e Autorização:
- Use o papel de administrador para conectar a clusters e gerenciar funções personalizadas.
- Use o comando AWS IAM GRANT para associar identidades IAM a papéis personalizados para acesso ao banco de dados.

Para passos detalhados, consulte:

Explorando Aurora DSQL: Acesso, Desenvolvimento e Melhores Práticas

Estou muito satisfeito e satisfeito com a documentação do Aurora DSQL. É direto ao ponto e muito bem escrito.

Ao trabalhar com aurora, há certos tópicos que podem ser interessantes, como:

Acessando o Aurora DSQL
Trabalhando com Amazon Aurora DSQL
Programação com Aurora DSQL
Utilitários, tutoriais e código de exemplo no Amazon Aurora DSQL
Segurança e suas melhores práticas: É importante entender tanto as melhores práticas de detetive quanto as melhores práticas de segurança preventiva
No momento em que escrevo este blog, há recursos PostgreSQL não suportados no Aurora DSQL que também devem ser considerados

Da perspectiva do Arquiteto de Soluções

Vimos neste blog como podemos criar um cluster DSQL Aurora com apenas um clique. Ele é realmente sem servidor.
Também vimos como um exemplo de uma solução verdadeiramente serverless para gerenciar banco de dados Aurora DSQL usando funções AWS Lambda tornando o Aurora DSQL é ideal para padrões de aplicações de microserviços, serverless e arquiteturas orientadas a eventos
A Amazon Aurora é um divisor de águas para desenvolvedores, oferecendo arquitetura serverless com escalonamento automático, alta disponibilidade e resiliência. Ela elimina a necessidade de gerenciamento manual de banco de dados, permitindo que os desenvolvedores foquem na construção de aplicações. Com a Aurora, os desenvolvedores podem inovar mais rápido, garantindo confiabilidade e eficiência.
O Aurora DSQL é compatível com PostgreSQL, então você pode usar drivers familiares, mapeamentos objeto-relacional (ORMs), frameworks e recursos SQL.

*Você já tentou a solução Lambda apresentada no blog e acha que isso vai mudar o jogo para arquiteturas serverless orientadas a eventos e micrservice? *