PERF04-BP02 Avaliar as opções disponíveis - AWS Well-Architected Framework
Orientações para a implementaçãoNível de esforço do plano de implementação: Recursos

PERF04-BP02 Avaliar as opções disponíveis

Compreenda as opções de bancos de dados e como elas podem otimizar a performance antes de você selecionar a sua solução de gerenciamento de dados. Use testes de carga para identificar as métricas de banco de dados que são importantes para a sua workload. Ao explorar as opções de bancos de dados, considere vários aspectos, como grupos de parâmetros, opções de armazenamento, memória, computação, réplica de leitura, consistência eventual, pooling de conexão e opções de armazenamento em cache. Experimente com essas várias opções de configuração para melhorar as métricas.

Resultado desejado: Uma workload pode ter uma ou mais soluções de banco de dados usadas com base nos tipos de dados. A funcionalidade e os benefícios do banco de dados correspondem de maneira ideal as características dos dados, os padrões de acesso e os requisitos da workload. Para otimizar a performance e o custo do banco de dados, você deve avaliar os padrões de acesso aos dados para determinar as opções de banco de dados apropriadas. Avalie os tempos de consulta aceitáveis para garantir que as opções de bancos de dados atendam aos requisitos.

Antipadrões comuns:

  • Não identificação dos padrões de acesso aos dados.

  • Não ter ciência das opções de configuração da solução de gerenciamento de dados escolhida.

  • Contar somente com o aumento do tamanho da instância sem examinar outras opções de configuração.

  • Não testar as características de escalabilidade da solução escolhida.

Benefícios do estabelecimento desta prática recomendada: A exploração e a experimentação das opções de bancos de dados permitem que você reduza o custo da infraestrutura, melhore a performance e a escalabilidade e diminua o esforço necessário para manter suas workloads.

Nível de exposição a riscos quando esta prática recomendada não é estabelecida: Alto

  • Precisar otimizar para um banco de dados de tamanho único significa fazer compromissos desnecessários.

  • Custos mais altos como resultado da não configuração da solução de banco de dados para que corresponda aos padrões de tráfego.

  • Podem surgir problemas operacionais por causa da escalabilidade.

  • Os dados podem não estar protegidos no nível necessário.

Orientações para a implementação

Compreenda as características dos dados da sua workload para poder configurar as opções de seu banco de dados. Execute testes de carga para identificar as métricas-chave de performance e os gargalos. Use essas características e métricas para avaliar as opções do banco de dados e experimentar com diferentes configurações.

Serviços da AWS Amazon RDS, Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
Escalabilidade da computação Aumente o tamanho das instâncias, as instâncias do Aurora Serverless escalam automaticamente em resposta a mudanças na carga Escalabilidade automática de leitura/gravação com modo de capacidade sob demanda ou escalabilidade automática da capacidade de leitura/gravação provisionada em modo de capacidade provisionada Aumentar o tamanho das instâncias Aumentar o tamanho das instâncias, adicionar nós ao cluster Aumentar o tamanho das instâncias Escala automaticamente para ajustar a capacidade Escalabilidade automática de leitura/gravação com modo de capacidade sob demanda ou escalabilidade automática da capacidade de leitura/gravação provisionada em modo de capacidade provisionada Escala automaticamente para ajustar a capacidade
Aumento da escala de leituras horizontalmente Todos os mecanismos são compatíveis com réplicas de leitura. O Aurora é compatível com a escalabilidade automática de instâncias de réplicas de leitura. Aumentar as unidades de capacidade de leitura provisionadas Réplicas de leitura Réplicas de leitura Réplicas de leitura. Compatível com a escalabilidade automática de instâncias de réplicas de leitura Escala automaticamente Aumentar as unidades de capacidade de leitura provisionadas Automaticamente aumenta a escala verticalmente para limites de simultaneidade documentados
Aumento da escala de gravações horizontalmente Aumentando o tamanho da instância, realizando gravações em lote na aplicação ou adicionando uma fila na frente do banco de dados. A escalabilidade horizontal via fragmentação em nível de aplicação entre várias instâncias Aumentar as unidades de capacidade de leitura provisionadas. Garantir a chave de partição ideal para evitar o controle de utilização de gravação em nível de partição Aumento do tamanho da instância primária Usar o Redis em modo de cluster para distribuir gravações entre fragmentos Aumentar o tamanho das instâncias As solicitações de gravação podem ser limitadas durante a escalabilidade. Se você encontrar exceções de controle de utilização, continue a enviar dados no mesmo throughput (ou mais alto) para escalar automaticamente. Gravações em lote para reduzir solicitações de gravação simultâneas Aumentar as unidades de capacidade de leitura provisionadas. Garantir a chave de partição ideal para evitar o controle de utilização de gravação em nível de partição Automaticamente aumenta a escala verticalmente para limites de simultaneidade documentados
Configuração do mecanismo Grupos de parâmetros Não aplicável Grupos de parâmetros Grupos de parâmetros Grupos de parâmetros Não aplicável Não aplicável Não aplicável
Armazenamento em cache Armazenamento em cache na memória, configurável por meio de grupos de parâmetros. Emparelhar com um cache dedicado, como o ElastiCache for Redis, para descarregar solicitações de itens acessados comumente Cache totalmente gerenciado do DAX (DAX) disponível Armazenamento em cache na memória. Opcionalmente, emparelhar com um cache dedicado, como o ElastiCache for Redis, para descarregar solicitações de itens acessados comumente A função primária é o armazenamento em cache Usar cache dos resultados de consultas somente leitura para armazenar o resultado em cache O Timestream tem duas camadas de armazenamento, uma delas é uma camada na memória de alta performance Implantar um cache dedicado separado, como o ElastiCache for Redis, para descarregar solicitações de itens acessados comumente Não aplicável
Alta disponibilidade/recuperação de desastres A configuração recomendada para workloads de produção é a execução de uma instância em espera em uma segunda zona de disponibilidade, para fornecer resiliência em uma região.  Para obter resiliência entre regiões, o Aurora Global Database pode ser usado Altamente disponível em uma região. As tabelas podem ser replicada entre regiões usando as tabelas globais do DynamoDB Crie várias instâncias entre zonas de disponibilidade para obter disponibilidade.  Os snapshots podem ser compartilhados entre regiões, e os clusters podem ser replicados usando o DMS para fornecer replicação entre regiões/recuperação de desastres. A configuração recomenda para clusters de produção é criar pelo menos um nó em uma zona de disponibilidade secundária.  É possível usar o datastore global do ElastiCache para replicar clusters entre regiões. As réplicas de leitura em outas zonas de disponibilidade funcionam como destinos de failover.  Os snapshots podem ser compartilhados entre regiões, e os clusters podem ser replicados usando os streams do Neptune para replicação de dados entre dois clusters em duas regiões diferentes. Altamente disponibilidade em uma região. A replicação entre regiões exige o desenvolvimento de uma aplicação personalizada usando o SDK do Timestream Altamente disponível em uma região.  A replicação entre regiões exige a lógica de uma aplicação personalizada ou ferramentas de terceiros Altamente disponível em uma região.  Para replicação entre regiões, exporte o conteúdo do diário do Amazon QLDB para um bucket do S3 e configure o bucket para replicação entre regiões.

Etapas da implementação

  1. Quais opções de configuração estão disponíveis para os bancos de dados selecionados?

    1. Os grupos de parâmetros do Amazon RDS e do Aurora permitem ajustar as configurações em nível de mecanismo comum de bancos de dados, como a memória alocada para o cache ou o ajuste do fuso horário do banco de dados.

    2. Para serviços de bancos de dados provisionados, como o Amazon RDS, o Aurora, o Neptune, o Amazon DocumentDB e os implantados no Amazon EC2, é possível alterar o tipo de instância, o armazenamento provisionado e as réplicas de leitura.

    3. O DynamoDB permite especificar dois modos de capacidade: sob demanda e provisionado. Para levar workloads diferentes em conta, é possível alterar entre esses modos e aumentar a capacidade alocada em modo provisionado a qualquer momento.

  2. A leitura ou a gravação da workload é pesada? 

    1. Quais são as soluções disponíveis para descarregar leituras (réplicas de leitura, armazenamento em cache etc.)? 

      1. Em tabelas do DynamoDB, é possível descarregar leituras usando o DAX para armazenamento em cache.

      2. Em bancos de dados relacionais, é possível criar um cluster do ElastiCache for Redis e configurar a aplicação para ler no cache primeiro, recorrendo ao banco de dados se o item não estiver presente.

      3. Todos os bancos de dados relacionais, como o Amazon RDS e o Aurora, e os bancos de dados NoSQL provisionados, como o Neptune e o Amazon DocumentDB, são compatíveis com a adição de replicas de leitura para descarregar as partes de leitura da workload.

      4. Os bancos de dados de tecnologia sem servidor, como o DynamoDB, escalarão automaticamente. Verifique se você tem unidades de capacidade de leitura suficientes (RCU) provisionadas para tratar a workload.

    2. Quais são as soluções disponíveis para escalar gravações (fragmentação de chave de partição, introdução de uma fila etc.)?

      1. No caso de bancos de dados relacionais, é possível aumentar o tamanho da instância para acomodar uma workload maior, ou aumentar as IOPs provisionadas para permitir um throughput mais alto para o armazenamento subjacente.

        • Também é possível introduzir uma fila na frente do banco de dados, em vez de gravar diretamente no banco de dados. Esse padrão permite desacoplar a ingestão do banco de dados e controlar a taxa de fluxo, para que o banco de dados não fique sobrecarregado. 

        • O uso solicitações de gravação em lote em vez de criar muitas transações de curta duração pode ajudar a melhorar o throughput em bancos de dados relacionais de alto volume de gravação.

      2. Os bancos de dados de tecnologia sem servidor, como o DynamoDB, podem escalar o throughput de gravação automaticamente ou ajustar as unidades da capacidade de gravação (WCU) provisionadas, dependendo do modo da capacidade. 

        • Mas ainda pode ser possível encontrar problemas com partições quentes, ao atingir os limites do throughput de uma determinada chave de partição. Isso pode ser mitigado ao escolher uma chave de partição mais igualmente distribuída ou fragmentar a gravação da chave de partição. 

  3. Quais são os picos de transações por segundo (TPS) atuais ou esperados? Teste usando esse volume de tráfego e esse volume +X% para compreender as características da escalabilidade.

    1. Ferramentas nativas, como a pg_bench do PostgreSQL, podem ser usadas para testes de estresse do banco de dados e para compreender os gargalos e as características de escalabilidade.

    2. Tráfego do tipo produção deve ser capturado para que possa ser reproduzido para a simulação das condições reais, além de workloads sintéticas.

  4. Ao usar computação de tecnologia sem servidor ou escalável elasticamente, teste o impacto da escalabilidade disso no banco de dados. Se apropriado, introduza agrupamento ou gerenciamento de conexões para reduzir o impacto no banco de dados. 

    1. O RDS Proxy pode ser usado com o Amazon RDS e o Aurora para gerenciar as conexões ao banco de dados. 

    2. Bancos de dados de tecnologia sem servidor, como o DynamoDB, não têm conexões associadas a eles, mas considere a capacidade provisionada e as políticas de escalabilidade automática para lidar com picos na carga.

  5. A carga é previsível? Há picos na carga e períodos de inatividade?

    1. Se houver períodos de inatividade, considere reduzir a escala verticalmente da capacidade provisionada ou o tamanho da instância durante esses períodos. Aurora Serverless V2 aumentará e reduzirá a escala verticalmente com base na carga.

    2. No caso de instâncias que não são de produção, considere pausá-las ou interrompê-las durante os horários sem trabalho.

  6. É necessário segmentar e separar seus modelos de dados com base nos padrões de acesso e nas características dos dados?

    1. Considere usar o AWS DMS ou o AWS SCT para mover os dados para outros serviços.

Nível de esforço do plano de implementação: 

Ao estabelecer essa prática recomendada, lembre-se das características e das métricas atuais dos dados. A coleta dessas métricas, o estabelecimento de uma linha de base e o uso dessas métricas para identificar as opções ideais de configuração de bancos de dados é baixo to moderado . Isso é melhor validade com testes de carga e experimentação.

Recursos

Documentos relacionados:

Vídeos relacionados:

Exemplos relacionados: