Identificar recursos não utilizados no DynamoDB
Esta seção apresenta uma visão geral de como avaliar recursos não utilizados regularmente. À medida que os requisitos da aplicação evoluem, você deve garantir que nenhum recurso não seja utilizado e contribua para custos desnecessários do Amazon DynamoDB. Os procedimentos descritos abaixo usarão as métricas do Amazon CloudWatch para identificar recursos não utilizados e ajudarão você a identificar e agir com base nesses recursos para reduzir custos.
É possível monitorar o Amazon DynamoDB usando o CloudWatch, o qual coleta e processa dados brutos do DynamoDB e os transforma em métricas legíveis quase em tempo real. Essas estatísticas são retidas por um período de tempo, para que você possa acessar informações do histórico e entender melhor a utilização. Por padrão, os dados de métrica do DynamoDB são enviados para o CloudWatch automaticamente. Para obter mais informações, consulte O que é o Amazon CloudWatch? e Retenção de métricas no Guia do usuário do Amazon CloudWatch.
Tópicos
- Como identificar recursos não utilizados
- Identificar recursos de tabela não utilizados
- Limpar recursos de tabela não utilizados
- Identificar recursos GSI não utilizados
- Limpar recursos GSI não utilizados
- Limpar tabelas globais não utilizadas
- Limpar backups não utilizados ou recuperação a um ponto anterior no tempo (PITR)
Como identificar recursos não utilizados
Para identificar tabelas ou índices não utilizados, analisaremos as seguintes métricas do CloudWatch durante um período de 30 dias para entender se há alguma leitura ou gravação ativa na tabela ou alguma leitura nos índices secundários globais (GSIs):
ConsumedReadCapacityUnits
O número de unidades de capacidade de leitura consumidas ao longo do período especificado para que você possa acompanhar quanto da capacidade consumida foi usada. Você pode recuperar a capacidade de leitura total consumida para uma tabela e todos os seus índices secundários globais ou para um índice secundário global específico.
ConsumedWriteCapacityUnits
O número de unidades de capacidade de gravação consumidas ao longo do período especificado para que você possa acompanhar quanto da capacidade consumida foi usada. Você pode recuperar a capacidade de gravação total consumida para uma tabela e todos os seus índices secundários globais ou para um índice secundário global específico.
Identificar recursos de tabela não utilizados
O Amazon CloudWatch é um serviço de monitoramento e capacidade de observação que fornece métricas de tabela do DynamoDB usadas para identificar recursos não utilizados. As métricas do CloudWatch podem ser visualizadas por meio do AWS Management Console e do AWS Command Line Interface.
Limpar recursos de tabela não utilizados
Se você identificou recursos de tabela não utilizados, poderá reduzir os custos contínuos das seguintes formas.
nota
Se você identificou uma tabela não utilizada, mas ainda gostaria de mantê-la disponível caso ela precise ser acessada no futuro, considere mudá-la para o modo sob demanda. Caso contrário, você pode considerar fazer backup e excluir totalmente a tabela.
Modos de capacidade
O DynamoDB cobra pela leitura, gravação e armazenamento de dados nas respectivas tabelas.
O DynamoDB oferece dois modos de capacidade, que vêm com opções de faturamento específicas do processamento de leitura e gravação nas tabelas: sob demanda e provisionada. O modo de capacidade de leitura/gravação controla como você é cobrado por throughput de leitura e gravação e como você gerencia a capacidade.
Para tabelas do modo sob demanda, não é necessário especificar o throughput de leitura e gravação que você espera que sua aplicação execute. O DynamoDB cobra pelas leituras e gravações que sua aplicação realiza nas tabelas em termos de unidades de solicitação de leitura e unidades de solicitação de gravação. Se não houver atividade na tabela/no índice, você não pagará pelo throughput, mas ainda terá uma taxa de armazenamento.
Classe de tabela
O DynamoDB também oferece duas classes de tabela projetadas para ajudar a otimizar o custo. A classe de tabela Standard do DynamoDB é a padrão e recomendada para a grande maioria das workloads. A classe de tabela do DynamoDB Standard-Infrequent Access (DynamoDB Standard-IA) é otimizada para tabelas em que o armazenamento é o custo dominante.
Se não houver atividade na tabela ou no índice, é provável que o armazenamento seja o custo dominante e a mudança de classe de tabela oferecerá uma economia significativa.
Excluir tabelas
Se você descobriu uma tabela não utilizada e gostaria de excluí-la, talvez queira fazer um backup ou exportar os dados antes.
Os backups feitos por meio do Backup da AWS podem aproveitar a hierarquização do armazenamento frio, reduzindo ainda mais os custos. Consulte a documentação Como usar a AWS Backup com o DynamoDB para obter informações sobre como habilitar backups por meio do Backup da AWS, bem como a documentação Gerenciar de planos de backup para obter informações sobre como usar o ciclo de vida para mover o backup para armazenamento frio.
Como alternativa, é possível exportar os dados da tabela para o S3. Para fazer isso, consulte a documentação Exportar para o Amazon S3. Depois de exportar os dados, caso queira aproveitar o S3 Glacier Instant Retrieval, S3 Glacier Flexile Retrieval ou S3 Glacier Deep Archive para reduzir ainda mais os custos, consulte Gerenciar o ciclo de vida do armazenamento.
Depois de fazer o backup da tabela, é possível optar por excluí-la por meio do AWS Management Console ou do AWS Command Line Interface.
Identificar recursos GSI não utilizados
As etapas para identificar um secundário global não utilizado são semelhantes a identificar uma tabela não utilizada. Como o DynamoDB replica itens gravados na tabela-base do GSI, se eles contiverem o atributo usado como chave de partição do GSI, é provável que um GSI não utilizado ainda tenha ConsumedWriteCapacityUnits mais de 0 se sua tabela-base estiver em uso. Como resultado, você avaliará somente a métrica das ConsumedReadCapacityUnits para determinar se o GSI não está sendo utilizado.
Para visualizar as métricas do GSI por meio da AWS CLI da AWS, é possível usar os seguintes comandos para avaliar as leituras das tabelas:
aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time <start-time> --end-time <end- time> --period <period> --namespace AWS/DynamoDB --statistics Sum -- dimensions Name=TableName,Value=<table-name> Name=GlobalSecondaryIndexName,Value=<index-name>
Para evitar a identificação errada de uma tabela como não usada, avalie as métricas por um período mais longo. Escolha um intervalo adequado de início e término, como 30 dias, e um período apropriado, como 86400.
Nos dados retornados, qualquer soma acima de 0 indica que a tabela que você está avaliando teve tráfego de leitura durante esse período.
O resultado a seguir mostra um GSI com tráfego de leitura no período avaliado:
{ "Timestamp": "2022-08-17T21:20:00Z", "Sum": 36319167.0, "Unit": "Count" }, { "Timestamp": "2022-08-11T21:20:00Z", "Sum": 1869136.0, "Unit": "Count" },
O resultado a seguir mostra um GSI com tráfego de leitura mínimo no período avaliado:
{ "Timestamp": "2022-08-28T21:20:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-15T21:20:00Z", "Sum": 2.0, "Unit": "Count" },
O resultado a seguir mostra um GSI sem tráfego de leitura no período avaliado:
{ "Timestamp": "2022-08-17T21:20:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-11T21:20:00Z", "Sum": 0.0, "Unit": "Count" },
Limpar recursos GSI não utilizados
Se você identificou um GSI não utilizado, poderá excluí-lo. Como todos os dados presentes em um GSI também estão presentes na tabela-base, não é necessário fazer backup adicional antes de excluir um GSI. Se no futuro o GSI for novamente necessário, será possível adicioná-lo novamente à tabela.
Caso você tenha identificado um GSI utilizado com pouca frequência, considere mudanças de design na aplicação que permitiriam excluí-lo ou reduzir o custo. Por exemplo, embora as verificações do DynamoDB devam ser utilizadas com moderação, pois podem consumir grandes quantidades de recursos do sistema, elas poderão ser mais econômicas do que um GSI se o padrão de acesso suportado for utilizado com pouca frequência.
Além disso, caso seja necessário um GSI para oferecer suporte a um padrão de acesso pouco frequente, considere projetar um conjunto mais limitado de atributos. Embora isso possa exigir consultas subsequentes na tabela-base para oferecer suporte aos padrões de acesso pouco frequentes, pode potencialmente oferecer uma redução significativa nos custos de armazenamento e gravação.
Limpar tabelas globais não utilizadas
As tabelas globais do Amazon DynamoDB fornecem uma solução totalmente gerenciada para a implantação de um banco de dados multiativo em várias regiões, sem exigir que você crie e mantenha sua própria solução de replicação.
As tabelas globais são ideais para fornecer acesso de baixa latência a dados próximos aos usuários e também a uma região secundária para recuperação de desastres.
Se a opção de tabelas globais estiver habilitada para um recurso em um esforço para fornecer acesso de baixa latência aos dados, mas não fizer parte de sua estratégia de recuperação de desastres, valide se as duas réplicas estão ativamente fornecendo tráfego de leitura ao avaliar suas métricas do CloudWatch. Se uma réplica não fornecer tráfego de leitura, talvez ela seja um recurso não utilizado.
Se as tabelas globais fizerem parte de sua estratégia de recuperação de desastres, uma réplica sem tráfego de leitura pode ser esperada em um padrão ativo/em espera.
Limpar backups não utilizados ou recuperação a um ponto anterior no tempo (PITR)
O DynamoDB oferece dois estilos de backup. A recuperação a um ponto anterior no tempo fornece backups contínuos por até 35 dias para ajudar a se proteger contra gravações ou exclusões acidentais, enquanto o backup sob demanda permite a criação de snapshots que podem ser salvos a longo prazo. É possível definir o período de recuperação para qualquer valor entre 1 e 35 dias. Os dois tipos de backup têm custos associados a eles.
Consulte a documentação do Backup e restauração para o DynamoDB e da Backups para um ponto no tempo do DynamoDB para determinar se as tabelas têm backups habilitados que podem não ser mais necessários.
