As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Como otimizar os custos das tabelas do Amazon Keyspaces Esta seção aborda as práticas recomendadas sobre como otimizar os custos das tabelas do Amazon Keyspaces. Você deve examinar as estratégias a seguir para ver qual estratégia de otimização de custos é a melhor para atender às suas necessidades e abordá-las de forma iterativa. Cada estratégia fornece uma visão geral do que pode estar afetando seus custos, como procurar oportunidades para otimizar custos e orientações prescritivas sobre como implementar essas práticas recomendadas para ajudar a economizar. **Topics** + [Avaliar seus custos no nível da tabela](CostOptimization_TableLevelCostAnalysis.md) + [Avaliar o modo de capacidade de sua tabela](CostOptimization_TableCapacityMode.md) + [Avalie as configurações do Application Auto Scaling da sua tabela](CostOptimization_AutoScalingSettings.md) + [Identifique seus recursos para otimizar os custos do Amazon Keyspaces.](CostOptimization_UnusedResources.md) + [Avaliar seus padrões de uso de tabelas para otimizar o desempenho e o custo](CostOptimization_TableUsagePatterns.md) + [Avaliar sua capacidade provisionada para o provisionamento do tamanho certo](CostOptimization_RightSizedProvisioning.md) # Avaliar seus custos no nível da tabela A ferramenta Cost Explorer encontrada no Console de gerenciamento da AWS permite que você veja os custos divididos por tipo, por exemplo, taxas de leitura, gravação, armazenamento e backup. Também é possível ver esses custos resumidos por período, como mês ou dia. Um desafio comum com o Cost Explorer é que você não pode revisar facilmente os custos de apenas uma tabela específica, porque o Cost Explorer não permite filtrar ou agrupar por custos de uma tabela específica. Você pode visualizar o **tamanho métrico da tabela faturável (bytes)** de cada tabela no console do Amazon Keyspaces na guia **Monitor da tabela.** Se você precisar de mais informações relacionadas ao custo por tabela, esta seção mostra como usar a [marcação](tagging-keyspaces.md) para realizar análises de custos de tabelas individuais no Cost Explorer. **Topics** + [Como visualizar os custos de uma única tabela do Amazon Keyspaces](#CostOptimization_TableLevelCostAnalysis_ViewInfo) + [Visualização padrão do Explorador de Custos](#CostOptimization_TableLevelCostAnalysis_CostExplorer) + [Como usar e aplicar tags de tabela no Explorador de Custos](#CostOptimization_TableLevelCostAnalysis_Tagging) ## Como visualizar os custos de uma única tabela do Amazon Keyspaces Você pode ver informações básicas sobre uma tabela do Amazon Keyspaces no console, incluindo o esquema da chave primária, o tamanho da tabela faturável e as métricas relacionadas à capacidade. Você pode dimensionar a tabela para calcular o custo mensal de armazenamento para a tabela. Por exemplo, 0,25 USD por GB no Leste dos EUA (Norte da Virgínia). Região da AWS Se a tabela estiver no modo de capacidade provisionada, as configurações atuais de RCU (Read Capacity Unit) e WCU(Write Capacity Unit) também serão retornadas. Você pode usar essas informações para calcular os custos atuais de leitura e gravação da tabela. Observe que esses custos podem mudar, especialmente se você tiver configurado a tabela com a ajuste de escala automática do Amazon Keyspaces. ## Visualização padrão do Explorador de Custos A visualização padrão do Explorador de Custos fornece gráficos que mostram o custo dos recursos consumidos, como throughput e armazenamento. É possível optar por agrupar estes custos por período, como totais por mês ou por dia. Os custos de armazenamento, leituras, gravações e outras categorias também podem ser divididos e comparados. ![\[Imagem mostrando o custo dos recursos consumidos na visualização do Explorador de Custos.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/CostOptimization/CostExplorerView.png) ## Como usar e aplicar tags de tabela no Explorador de Custos Por padrão, o Explorador de Custos não fornece um resumo dos custos de nenhuma tabela específica, pois combina os custos de várias tabelas em um total. No entanto, é possível usar a [marcação de recursos da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) para identificar cada tabela por uma tag de metadados. As tags são pares de chave-valor que podem ser usadas para diversas finalidades, como identificar todos os recursos pertencentes a um projeto ou departamento. Para obter mais informações, consulte [Como trabalhar com tags e rótulos para recursos do Amazon Keyspaces](tagging-keyspaces.md). Neste exemplo, usamos uma tabela com o nome **MyTable**. 1. Defina uma tag com a chave de **table\$1name** e o valor de. **MyTable** 1. [Ative a tag no Explorador de Custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) e filtre o valor da tag para obter mais visibilidade dos custos de cada tabela. **nota** Pode levar um ou dois dias para que a tag comece a aparecer no Explorador de Custos. Você mesmo pode definir tags de metadados no console ou programaticamente com o CQL AWS CLI, o ou o SDK. AWS Considere exigir que uma tag **table\$1name** seja definida como parte do processo de criação de tabelas da sua organização. Para obter mais informações, consulte [Crie relatórios de alocação de custos usando tags para Amazon Keyspaces](CostAllocationReports.md). # Avaliar o modo de capacidade de sua tabela Esta seção apresenta uma visão geral de como selecionar o modo de capacidade adequado para a tabela do Amazon Keyspaces. Cada modo é ajustado para atender às necessidades de uma carga de trabalho diferente em termos de capacidade de resposta a mudanças no throughput, bem como de como esse uso é cobrado. Você deve ponderar sobre esses fatores ao tomar sua decisão. **Topics** + [Quais modos de capacidade de tabela estão disponíveis](#CostOptimization_TableCapacityMode_Overview) + [Quando selecionar o modo de capacidade sob demanda](#CostOptimization_TableCapacityMode_OnDemand) + [Quando selecionar o modo de capacidade provisionada](#CostOptimization_TableCapacityMode_Provisioned) + [Fatores adicionais a serem considerados ao escolher um modo de capacidade de tabela](#CostOptimization_TableCapacityMode_AdditionalFactors) ## Quais modos de capacidade de tabela estão disponíveis Ao criar uma tabela do Amazon Keyspaces, é necessário selecionar o modo de capacidade sob demanda ou provisionada. Para obter mais informações, consulte [Configurar modos de read/write capacidade no Amazon Keyspaces](ReadWriteCapacityMode.md). **Modo de capacidade sob demanda** O modo de capacidade sob demanda foi projetado para eliminar a necessidade de planejar ou provisionar a capacidade da tabela do Amazon Keyspaces. Nesse modo, a tabela atende instantaneamente às solicitações de acomodação feitas sem a necessidade de escalar recursos (até o dobro do throughput máximo anterior da tabela). As tabelas sob demanda são cobradas pela contagem do número de solicitações reais à tabela. Portanto, você paga apenas pelo que usar e não pelo que foi provisionado. **Modo de capacidade provisionada** O modo de capacidade provisionada é um modelo mais tradicional em que é possível definir que capacidade a tabela tem disponível para solicitações feitas diretamente ou com a ajuda do Application Auto Scaling. Como uma capacidade específica é provisionada para a tabela a qualquer momento, o faturamento baseia-se na capacidade provisionada e não no número de solicitações. Ultrapassar a capacidade alocada também pode fazer com que a tabela rejeite solicitações e reduza a experiência dos usuários de seu aplicativo. O modo de capacidade provisionada exige um equilíbrio entre não superprovisionar ou subprovisionar a tabela para obter a baixa ocorrência de erros de capacidade de throughput insuficiente e os custos otimizados. ## Quando selecionar o modo de capacidade sob demanda Para otimizar o custo, o modo sob demanda é a melhor opção quando se tem uma carga de trabalho semelhante ao gráfico a seguir. Esses fatores contribuem para esse tipo de carga de trabalho: + Tempo de solicitação imprevisível (resultando em picos de tráfego) + Volume variável de solicitações (resultante de cargas de trabalho em lote) + Queda para zero ou abaixo de 18% do pico em determinada hora (resultante de ambientes de desenvolvimento ou teste) ![\[Imagem mostrando uma carga de trabalho de pico, com picos aleatórios no tráfego.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeOnDemand.png) Em workloads com as características acima, usar o Application Auto Scaling para manter a capacidade suficiente para que a tabela responda aos picos de tráfego pode levar a resultados indesejáveis. Ou a tabela pode estar superprovisionada e custar mais do que o necessário, ou a tabela pode estar subprovisionada e as solicitações estão causando erros desnecessários de throughput de baixa capacidade. Em casos como esse, as mesas sob demanda são a melhor opção. Como as tabelas sob demanda são cobradas por solicitação, não há mais nada a fazer no nível da tabela para otimizar o custo. É necessário avaliar regularmente as tabelas sob demanda para verificar se a carga de trabalho ainda tem as características acima. Caso a carga de trabalho esteja estabilizada, considere a possibilidade de mudar para o modo provisionado a fim de otimizar ainda mais os custos. ## Quando selecionar o modo de capacidade provisionada Uma carga de trabalho ideal para o modo de capacidade provisionada é aquela com um padrão de uso mais previsível, como o gráfico abaixo. Os seguintes fatores contribuem para esse tipo de carga de trabalho previsível: + Tráfego previsível/cíclico em determinada hora ou determinado dia + Intermitências limitadas de tráfego de curto prazo ![\[Imagem mostrando uma carga de trabalho bastante previsível com picos de tráfego limitados.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeProvisioned.png) Como os volumes de tráfego em determinada hora ou determinado dia são mais estáveis, podemos definir a capacidade provisionada relativamente próxima à capacidade real consumida. A otimização de custos de uma tabela de capacidade provisionada é, em última análise, um exercício para obter a capacidade provisionada (linha azul) o mais próximo possível da capacidade consumida (linha laranja) sem aumentar os eventos de `ThrottledRequests` na tabela. O espaço entre as duas linhas representa tanto capacidade desperdiçada quanto garantia contra uma experiência inadequada do usuário devido aos erros de capacidade de throughput. O Amazon Keyspaces fornece Application Auto Scaling para tabelas de capacidade provisionada que equilibrarão isso automaticamente por você. Isso permite que você acompanhe a capacidade consumida ao longo do dia e configure a capacidade provisionada da tabela com base em algumas variáveis. **Unidades de capacidade mínima** É possível definir a capacidade mínima de uma tabela para limitar a ocorrência de erros de capacidade de throughput insuficiente, mas isso não reduz o custo da tabela. Se a tabela tiver períodos de baixo uso seguidos de uma expansão repentina de alto uso, definir o mínimo poderá impedir que o Application Auto Scaling defina a capacidade da tabela com um valor muito baixo. **Unidades de capacidade máxima** É possível definir a capacidade máxima de uma tabela para impedir que a tabela escale acima do pretendido. Considere a possibilidade de aplicar um máximo para tabelas de desenvolvimento ou teste em que os testes de carga em grande escala não são desejados. É possível definir um máximo para qualquer tabela, mas avalie regularmente essa configuração em relação à linha de base da tabela ao usá-la na produção para evitar erros de capacidade de throughput insuficiente. **Utilização pretendida** Definir a utilização pretendida da tabela é o principal meio de otimização de custos para uma tabela de capacidade provisionada. Definir um valor percentual mais baixo aqui aumenta o superprovisionamento da tabela, o que eleva os custos, mas reduz os erros de capacidade de throughput insuficiente. Definir um valor percentual mais alto diminui o quanto a tabela está superprovisionada, mas aumenta o risco de erros de capacidade de throughput insuficiente. ## Fatores adicionais a serem considerados ao escolher um modo de capacidade de tabela Ao decidir entre os dois modos de capacidade, há alguns fatores adicionais que vale a pena considerar. Ao decidir entre os dois modos de tabela, considere quanto esse desconto adicional afeta o custo da tabela. Em muitos casos, até mesmo uma carga de trabalho relativamente imprevisível pode ser mais barata de ser executada em uma tabela de capacidade provisionada em excesso com capacidade reservada. **Melhorar a previsibilidade da carga de trabalho** Em algumas situações, uma carga de trabalho pode aparentemente ter um padrão previsível e imprevisível. Embora isso possa ser facilmente atendido com uma tabela sob demanda, os custos provavelmente serão mais baixos se for possível melhorar os padrões imprevisíveis da carga de trabalho. Uma das causas mais comuns para esses padrões são as importações em lote. Esse tipo de tráfego geralmente pode exceder a capacidade básica da tabela a tal ponto que erros de capacidade de throughput insuficiente ocorreriam se ela fosse executada. Para manter uma carga de trabalho como essa em execução em uma tabela de capacidade provisionada, considere as seguintes opções: + Se o lote ocorrer em horários programados, será possível programar um aumento na capacidade de ajuste de escala automático do seu aplicativo antes da execução. + Caso o lote ocorra aleatoriamente, considere a possibilidade de tentar estender o tempo de execução em vez de executá-lo o mais rápido possível. + Adicione um período de aceleração à importação no qual a velocidade da importação começa pequena, mas aumenta lentamente em alguns minutos até que o ajuste de escala automático do seu aplicativo tenha a oportunidade de começar a ajustar a capacidade da tabela. # Avalie as configurações do Application Auto Scaling da sua tabela Esta seção apresenta uma visão geral de como avaliar as configurações de Application Auto Scaling nas tabelas do Amazon Keyspaces. O [Application Auto Scaling do Amazon Keyspaces](autoscaling.md) é um atributo que gerencia o throughput da tabela com base no tráfego do seu aplicativo e na métrica de utilização desejada. Isso garante que suas tabelas tenham a capacidade necessária para os padrões de seu aplicativo. O serviço Application Auto Scaling monitora a utilização atual da tabela e compara com o valor de utilização pretendido: `TargetValue`. Ele te notifica se for hora de aumentar ou diminuir a capacidade alocada. **Topics** + [Entenda as configurações do Application Auto Scaling](#CostOptimization_AutoScalingSettings_UnderProvisionedTables) + [Como identificar tabelas com baixa utilização prevista (<= 50%)](#CostOptimization_AutoScalingSettings_IdentifyLowUtilization) + [Como lidar com cargas de trabalho com variação sazonal](#CostOptimization_AutoScalingSettings_SeasonalVariance) + [Como lidar com cargas de trabalho com pico com padrões desconhecidos](#CostOptimization_AutoScalingSettings_UnknownPatterns) + [Como lidar com cargas de trabalho com aplicações vinculadas](#CostOptimization_AutoScalingSettings_BetweenRanges) ## Entenda as configurações do Application Auto Scaling Definir o valor correto para a utilização pretendida, a etapa inicial e os valores finais é uma atividade que exige o envolvimento de sua equipe de operações. Isso permite que você defina adequadamente os valores com base no histórico de uso do aplicativo, que será usado para acionar as políticas de Application Auto Scaling. A utilização prevista é a porcentagem de sua capacidade total que deve ser atingida durante um período antes que as regras do Application Auto Scaling sejam aplicadas. Quando você define uma **utilização prevista alta (uma utilização de cerca de 90%)**, isso significa que seu tráfego deve ser superior a 90% por um período de tempo antes que o Application Auto Scaling seja ativado. Você não deve usar uma alta utilização prevista, a menos que sua aplicação seja muito constante e não receba picos de tráfego. Quando você define uma **utilização prevista muito baixa (uma utilização inferior a 50%)**, isso significa que seu aplicativo deveria atingir 50% da capacidade provisionada antes de acionar uma política de Application Auto Scaling. A menos que o tráfego da sua aplicação cresça a uma taxa muito agressiva, isso geralmente se traduz em capacidade não utilizada e desperdício de recursos. ## Como identificar tabelas com baixa utilização prevista (<= 50%) Você pode usar o AWS CLI ou Console de gerenciamento da AWS para monitorar e identificar as políticas do `TargetValues` Application Auto Scaling em seus recursos do Amazon Keyspaces. **nota** Ao usar tabelas multirregionais no modo de capacidade provisionada com o ajuste de escala automático do Amazon Keyspaces, certifique-se de usar as operações da API do Amazon Keyspaces para configurar o ajuste de escala automático. As operações subjacentes da API Application Auto Scaling que o Amazon Keyspaces chama em seu nome não têm recursos multirregionais. Para obter mais informações, consulte [Exibir a capacidade provisionada e as configurações de ajuste de escala automático para uma tabela multirregional no Amazon Keyspaces](tables-mrr-view.md). ------ #### [ AWS CLI ] 1. Retorne a lista completa de recursos executando o seguinte comando: ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra ``` Esse comando retornará a lista completa de políticas de Application Auto Scaling emitidas para qualquer recurso do Amazon Keyspaces. Se quiser apenas recuperar os recursos de uma tabela específica, você poderá adicionar o `–resource-id parameter`. Por exemplo: ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” ``` 1. Retorne somente as políticas de ajuste de escala automático para uma tabela específica executando o seguinte comando ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” ``` Os valores nas políticas de Application Auto Scaling estão destacados abaixo. É necessário garantir que o valor alvo seja maior que 50% para evitar o provisionamento excessivo. Você deverá obter um resultado semelhante ao seguinte: ``` { "ScalingPolicies": [ { "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy", "PolicyName": $”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "KeyspacesWriteCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:48.641000+10:00" }, { "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy", "PolicyName":$”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:ReadCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "KeyspacesReadCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:47.820000+10:00" } ] } ``` ------ #### [ Console de gerenciamento da AWS ] 1. Faça login no Console de gerenciamento da AWS e navegue até a página de CloudWatch serviço em [Introdução ao Console de gerenciamento da AWS](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html). Selecione o apropriado, Região da AWS se necessário. 1. Na barra de navegação à esquerda, selecione **Tabelas**. Na página **Tabelas**, selecione o **Nome** da tabela. 1. Na página **Detalhes da tabela**, na guia **Capacidade**, revise as configurações de Application Auto Scaling da sua tabela. ------ Se os valores de suas metas de utilização forem menores ou iguais a 50%, você deverá explorar as métricas de utilização da tabela para ver se elas estão [subprovisionadas ou superprovisionadas](CostOptimization_RightSizedProvisioning.md). ## Como lidar com cargas de trabalho com variação sazonal Considere o seguinte cenário: sua aplicação está operando abaixo de um valor médio mínimo na maioria das vezes, mas a meta de utilização é baixa para que sua aplicação possa reagir rapidamente a eventos que acontecem em determinadas horas do dia e você tenha capacidade suficiente e evite ter controle de utilização. Esse cenário é comum quando você tem uma aplicação muito movimentada durante o horário normal de expediente (das 9h às 17h), mas funciona em um nível básico após o expediente. Como alguns usuários começam a se conectar antes das 9h, o aplicativo usa esse limite baixo para aumentar rapidamente a capacidade *necessária* durante os horários de pico. Esse cenário pode ser parecido com: + Entre 17h e 9h, as unidades `ConsumedWriteCapacityUnits` ficam entre 90 e 100 + Os usuários começam a se conectar à aplicação antes das 9h e as unidades de capacidade aumentam consideravelmente (o valor máximo que você viu é 1,5 mil WCU) + Em média, o uso da sua aplicação varia entre 800 e 1.200 durante o horário comercial Se o cenário anterior for aplicável, considere usar o [Application Auto Scaling programado](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html), em que sua tabela ainda pode ter uma regra de Application Auto Scaling de aplicativos configurada, mas com uma utilização pretendida menos agressiva que forneça somente a capacidade extra nos intervalos específicos necessários. Você pode usar o AWS CLI para executar as etapas a seguir para criar uma regra de escalonamento automático programada que seja executada com base na hora do dia e no dia da semana. 1. Registre sua tabela do Amazon Keyspaces como um destino escalável com Application Auto Scaling. Um destino escalável é um recurso cuja escala pode ser aumentada ou reduzida horizontalmente pelo Application Auto Scaling . ``` aws application-autoscaling register-scalable-target \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --min-capacity 90 \ --max-capacity 1500 ``` 1. Configure ações programadas de acordo com seus requisitos. São necessárias duas regras para cobrir o cenário: uma para aumentar e outra para reduzir a escala verticalmente. A primeira regra para aumentar a escala verticalmente da ação programada é mostrada no exemplo a seguir. ``` aws application-autoscaling put-scheduled-action \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --scheduled-action-name my-8-5-scheduled-action \ --scalable-target-action MinCapacity=800,MaxCapacity=1500 \ --schedule "cron(45 8 ? * MON-FRI *)" \ --timezone "Australia/Brisbane" ``` A segunda regra para reduzir a escala verticalmente da ação programada é mostrada nesse exemplo. ``` aws application-autoscaling put-scheduled-action \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --scheduled-action-name my-5-8-scheduled-down-action \ --scalable-target-action MinCapacity=90,MaxCapacity=1500 \ --schedule "cron(15 17 ? * MON-FRI *)" \ --timezone "Australia/Brisbane" ``` 1. Execute o seguinte comando para validar que ambas as regras foram ativadas: ``` aws application-autoscaling describe-scheduled-actions --service-namespace cassandra ``` Você deve obter um resultado parecido com este: ``` { "ScheduledActions": [ { "ScheduledActionName": "my-5-8-scheduled-down-action", "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-5-8-scheduled-down-action", "ServiceNamespace": "cassandra", "Schedule": "cron(15 17 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "ScalableTargetAction": { "MinCapacity": 90, "MaxCapacity": 1500 }, "CreationTime": "2022-03-15T17:30:25.100000+10:00" }, { "ScheduledActionName": "my-8-5-scheduled-action", "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-8-5-scheduled-action", "ServiceNamespace": "cassandra", "Schedule": "cron(45 8 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "ScalableTargetAction": { "MinCapacity": 800, "MaxCapacity": 1500 }, "CreationTime": "2022-03-15T17:28:57.816000+10:00" } ] } ``` A figura a seguir mostra um exemplo de carga de trabalho que sempre mantém a utilização prevista de 70%. Observe como as regras de ajuste de escala automático ainda se aplicam e o throughput não será reduzido. ![\[Um gráfico que mostra o uso de gravação em unidades por segundo comparando a capacidade provisionada com a capacidade consumida no período de um dia.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings3.png) Ao ampliar, podemos ver que houve um pico na aplicação que acionou o limite de Auto Scaling de 70%, forçando o Auto Scaling a entrar em ação e fornecer a capacidade extra necessária para a tabela. A ação programada de ajuste de escala automático afetará os valores máximo e mínimo, e é sua responsabilidade configurá-los. ![\[Uma visão mais detalhada do gráfico que mostra o uso de gravação em unidades por segundo comparando a capacidade provisionada com a capacidade consumida, ampliando um horário específico.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings4.png) ![\[Mostrando a visão detalhada do gráfico que mostra o uso de gravação em unidades por segundo comparando a capacidade provisionada com a capacidade consumida durante o período de um dia.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings5.png) ## Como lidar com cargas de trabalho com pico com padrões desconhecidos Nesse cenário, o aplicativo usa uma utilização prevista muito baixa porque você ainda não conhece os padrões do aplicativo e quer garantir que sua carga de trabalho não passe por erros de capacidade de throughput insuficiente. Em vez disso, considere usar o [modo de capacidade sob demanda](ReadWriteCapacityMode.OnDemand.md). As tabelas sob demanda são perfeitas para cargas de trabalho com pico nas quais você não conhece os padrões de tráfego. Com o modo de capacidade sob demanda, você paga por solicitação pelas leituras e gravações de dados que sua aplicação executa em suas tabelas. Não é necessário especificar o throughput de leitura e gravação que você espera que seu aplicativo execute, pois o Amazon Keyspaces acomoda instantaneamente o crescimento e redução de workloads. ## Como lidar com cargas de trabalho com aplicações vinculadas Nesse cenário, a aplicação depende de outros sistemas, como cenários de processamento em lote, nos quais você pode ter grandes picos de tráfego de acordo com os eventos na lógica da aplicação. Considere desenvolver uma lógica personalizada de Application Auto Scaling que reaja aos eventos em que você pode aumentar a capacidade da tabela e dos `TargetValues` dependendo de suas necessidades específicas. Você pode se beneficiar Amazon EventBridge e usar uma combinação de AWS serviços como λ e Step Functions para reagir às necessidades específicas de seu aplicativo. # Identifique seus recursos para otimizar os custos do Amazon Keyspaces. Esta seção apresenta uma visão geral de como avaliar recursos não utilizados regularmente. À medida que os requisitos do aplicativo evoluem, você deve garantir que os recursos sejam utilizados e evite custos desnecessários do Amazon Keyspaces. Os procedimentos descritos abaixo usam CloudWatch métricas da Amazon para identificar recursos não utilizados e tomar medidas para reduzir custos. Você pode monitorar o Amazon Keyspaces usando CloudWatch, que coleta e processa dados brutos do Amazon Keyspaces em métricas legíveis e 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 métricos do Amazon Keyspaces são enviados automaticamente para CloudWatch . Para obter mais informações, consulte [O que é a Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) e [retenção de métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#metrics-retention) no *Guia do CloudWatch usuário da Amazon*. **Topics** + [Como identificar recursos não utilizados](#CostOptimization_UnusedResources_Identifying) + [Identificar recursos de tabela não utilizados](#CostOptimization_UnusedResources_Tables) + [Limpar recursos de tabela não utilizados](#CostOptimization_UnusedResources_Tables_Cleanup) + [Limpando backups de point-in-time recuperação não utilizados (PITR)](#CostOptimization_UnusedResources_Backups) ## Como identificar recursos não utilizados Para identificar tabelas não utilizadas, você pode dar uma olhada nas seguintes CloudWatch métricas durante um período de 30 dias para entender se há alguma leitura ou gravação ativa em uma tabela específica: **`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. **`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. ## Identificar recursos de tabela não utilizados CloudWatch A Amazon é um serviço de monitoramento e observabilidade que fornece as métricas da tabela Amazon Keyspaces que você pode usar para identificar recursos não utilizados. CloudWatch as métricas podem ser visualizadas por meio do Console de gerenciamento da AWS , bem como por meio do AWS Command Line Interface. ------ #### [ AWS Command Line Interface ] Para visualizar as métricas de suas tabelas por meio do AWS Command Line Interface, você pode usar os seguintes comandos. 1. Primeiro, avalie as leituras da tabela: **nota** Se o nome da tabela não for exclusivo em sua conta, você também deverá especificar o nome do espaço de chaves. ``` aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` 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 uma tabela com tráfego de leitura no período avaliado: ``` { "Timestamp": "2022-08-25T19:40:00Z", "Sum": 36023355.0, "Unit": "Count" }, { "Timestamp": "2022-08-12T19:40:00Z", "Sum": 38025777.5, "Unit": "Count" }, ``` O resultado a seguir mostra uma tabela sem tráfego de leitura no período avaliado: ``` { "Timestamp": "2022-08-01T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-20T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, ``` 1. Em seguida, avalie as gravações da tabela: ``` aws cloudwatch get-metric-statistics --metric-name ConsumedWriteCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` 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 uma tabela com tráfego de gravação no período avaliado: ``` { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 41014457.0, "Unit": "Count" }, { "Timestamp": "2022-08-18T20:15:00Z", "Sum": 40048531.0, "Unit": "Count" }, ``` O resultado a seguir mostra uma tabela sem tráfego de gravação no período avaliado: ``` { "Timestamp": "2022-07-31T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, ``` ------ #### [ Console de gerenciamento da AWS ] As etapas a seguir permitem avaliar a utilização do seu recurso por meio do Console de gerenciamento da AWS. 1. Faça login Console de gerenciamento da AWS e navegue até a página CloudWatch de serviço em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). Selecione o apropriado Região da AWS no canto superior direito do console, se necessário. 1. Na barra de navegação à esquerda, localize a seção **Metrics** (Métricas) e selecione **All metrics** (Todas as métricas). 1. A ação acima abrirá uma tela com dois painéis. No painel superior, você verá as métricas atualmente representadas graficamente. Na parte inferior, você selecionará as métricas disponíveis para representar graficamente. Escolha Amazon Keyspaces no painel inferior. 1. No painel de seleção de métricas do Amazon Keyspaces, selecione a categoria **Table Metrics** (Métricas de tabela) para mostrar as métricas das tabelas na região atual. 1. Identifique o nome da sua tabela rolando o menu para baixo e, em seguida, selecione as métricas das `ConsumedReadCapacityUnits` e das `ConsumedWriteCapacityUnits` para a tabela. 1. Selecione a guia **Graphed metrics (2)** [Métricas gráficas (2)] e ajuste a coluna **Statistic** (Estatística) como **Sum** (Soma). 1. Para evitar a identificação errada de uma tabela como não usada, avalie as métricas da tabela por um período mais longo. Na parte superior do painel gráfico, escolha um período de tempo apropriado, como 1 mês, para avaliar sua tabela. Selecione **Custom** (Personalizado), selecione **1 Months** (Um mês) nos menus suspensos e escolha **Apply** (Aplicar). 1. Avalie as métricas gráficas da tabela para determinar se ela está sendo usada. Métricas acima de **0** indicam que uma tabela foi usada durante o período avaliado. Um gráfico plano em **0** para leitura e gravação indica uma tabela que não está sendo usada. ------ ## 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 a exclusão da tabela. **Modos de capacidade** O Amazon Keyspaces cobra pela leitura, gravação e armazenamento de dados em tabelas do Amazon Keyspaces. O Amazon Keyspaces oferece [dois modos de capacidade](ReadWriteCapacityMode.md), 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 read/write de capacidade controla como você é cobrado pela taxa de transferência 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 Amazon Keyspaces cobra você pelas leituras e gravações que sua aplicativo realiza em suas 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, você não pagará pelo throughput, mas ainda terá uma taxa de armazenamento. **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 realizados AWS Backup podem aproveitar a hierarquização do armazenamento a frio, reduzindo ainda mais os custos. Consulte a documentação [Gerenciar de planos de backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans) para informações sobre como usar um ciclo de vida para mover o backup para armazenamento frio. Depois de fazer o backup da tabela, é possível optar por excluí-la por meio do Console de gerenciamento da AWS ou do AWS Command Line Interface. ## Limpando backups de point-in-time recuperação não utilizados (PITR) O Amazon Keyspaces oferece Point-in-time recuperação, que fornece backups contínuos por 35 dias para ajudar você a se proteger contra gravações ou exclusões acidentais. Os backups PITR têm custos associados a eles. Consulte a documentação do [Faça backup e restaure dados com point-in-time recuperação para Amazon Keyspaces](PointInTimeRecovery.md) para saber se as tabelas têm backups habilitados que podem não ser mais necessários. # Avaliar seus padrões de uso de tabelas para otimizar o desempenho e o custo Esta seção apresenta uma visão geral de como avaliar se você está usando suas tabelas do Amazon Keyspaces de forma eficiente. Existem certos padrões de uso que não são ideais para o Amazon Keyspaces e permitem a otimização tanto do ponto de vista do desempenho quanto do custo. **Topics** + [Realizar menos operações de leitura altamente consistente](#CostOptimization_TableUsagePatterns_StronglyConsistentReads) + [Habilitar a vida útil (TTL)](#CostOptimization_TableUsagePatterns_TTL) ## Realizar menos operações de leitura altamente consistente O Amazon Keyspaces permite que você configure [a consistência de leitura](consistency.md#ReadConsistency) por solicitação. As solicitações de leitura são finais consistentes por padrão. Leituras finais consistentes são cobradas a 0,5 RCU para até 4 KB de dados. A maioria das partes das cargas de trabalho distribuídas é flexível e pode tolerar uma eventual consistência. No entanto, pode haver padrões de acesso que exijam leituras altamente consistentes. Leituras altamente consistentes são cobradas em 1 RCU para até 4 KB de dados, basicamente dobrando seus custos de leitura. O Amazon Keyspaces oferece a flexibilidade de usar os dois modelos de consistência na mesma tabela. Você pode avaliar sua carga de trabalho e o código da aplicação para confirmar se leituras altamente consistentes são usadas somente quando necessário. ## Habilitar a vida útil (TTL) O [tempo de vida (TTL)](TTL.md) ajuda você a simplificar a lógica do aplicativo e otimizar o preço do armazenamento ao expirar automaticamente os dados das tabelas. Os dados que você não precisa mais são excluídos automaticamente da sua tabela com base no valor de Vida útil que você definiu. # Avaliar sua capacidade provisionada para o provisionamento do tamanho certo Esta seção apresenta uma visão geral de como avaliar o provisionamento adequado para a tabela do Amazon Keyspaces. À medida que sua carga de trabalho evolui, você deve modificar seus procedimentos operacionais adequadamente, especialmente quando sua tabela do Amazon Keyspaces está configurada no modo provisionado e você corre o risco de provisionar demais ou subprovisionar suas tabelas. Os procedimentos descritos nessa seção exigem informações estatísticas que devem ser capturadas das tabelas do Amazon Keyspaces que oferecem suporte a seu aplicativo de produção. Para entender o comportamento do seu aplicativo, você deve definir um período de tempo significativo o suficiente para capturar a sazonalidade dos dados do aplicativo. Por exemplo, se a aplicação mostrar padrões semanais, usar um período de três semanas deve fornecer espaço suficiente para analisar as necessidades de throughput da aplicação. Se não souber por onde começar, use pelo menos um mês de uso de dados para os cálculos abaixo. Ao avaliar a capacidade, para tabelas do Amazon Keyspaces, você pode **configurar unidades de capacidade de leitura RCUs () e unidades de capacidade de gravação (****WCU**) de forma independente. **Topics** + [Como recuperar métricas de consumo em suas tabelas do Amazon Keyspaces](#CostOptimization_RightSizedProvisioning_ConsumptionMetrics) + [Como identificar tabelas do Amazon Keyspaces subprovisionadas](#CostOptimization_RightSizedProvisioning_UnderProvisionedTables) + [Como identificar tabelas superprovisionadas do Amazon Keyspaces](#CostOptimization_RightSizedProvisioning_OverProvisionedTables) ## Como recuperar métricas de consumo em suas tabelas do Amazon Keyspaces Para avaliar a capacidade da tabela, monitore as seguintes CloudWatch métricas e selecione a dimensão apropriada para recuperar as informações da tabela: | Unidades de capacidade de leitura | Unidades de capacidade de gravação | | --- | --- | | `ConsumedReadCapacityUnits` | `ConsumedWriteCapacityUnits` | | `ProvisionedReadCapacityUnits` | `ProvisionedWriteCapacityUnits` | | `ReadThrottleEvents` | `WriteThrottleEvents` | Você pode fazer isso por meio do AWS CLI ou do Console de gerenciamento da AWS. ------ #### [ AWS CLI ] Antes de recuperar as métricas de consumo da tabela, você precisa começar capturando alguns pontos de dados históricos usando a CloudWatch API. Comece criando dois arquivos:`write-calc.json` e `read-calc.json`. Esses arquivos representam os cálculos da tabela. Você deverá atualizar alguns dos campos, conforme indicado na tabela abaixo, para corresponder ao seu ambiente. **nota** Se o nome da tabela não for exclusivo em sua conta, você também deverá especificar o nome do espaço de chaves. | Nome do campo | Definição | Exemplo | | --- | --- | --- | | | Nome da tabela que você analisará | SampleTable | | | O período de tempo que você usará para avaliar a utilização prevista, com base em segundos | Por um período de uma hora, você deve especificar: 3600 | | | O início do seu intervalo de avaliação, especificado no ISO8601 formato | 2022-02-21T23:00:00 | | | O final do seu intervalo de avaliação, especificado no ISO8601 formato | 2022-02-22T06:00:00 | O arquivo de cálculos de gravação recupera o número de WCU provisionado e consumido no período de tempo para o intervalo de datas especificado. Também gera uma porcentagem de utilização que é usada para análise. O conteúdo completo do arquivo `write-calc.json` deve ser como o exemplo a seguir. ``` { "MetricDataQueries": [ { "Id": "provisionedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ProvisionedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ConsumedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": """ } ] }, "Period": , "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedWCU/PERIOD(consumedWCU)", "Label": "Consumed WCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedWCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "", "EndTime": "", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 } ``` O arquivo de cálculos de leitura usa uma métrica semelhante. Esse arquivo recupera quantos RCUs foram provisionados e consumidos durante o período do intervalo de datas especificado. O conteúdo do arquivo `read-calc.json` deve ser semelhante a este exemplo. ``` { "MetricDataQueries": [ { "Id": "provisionedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ProvisionedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ConsumedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedRCU/PERIOD(consumedRCU)", "Label": "Consumed RCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedRCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "", "EndTime": "", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 } ``` Depois de criar os arquivos, você poderá começar a recuperar os dados de utilização. 1. Para recuperar dados de utilização de gravação, emita o seguinte comando: ``` aws cloudwatch get-metric-data --cli-input-json file://write-calc.json ``` 1. Para recuperar dados de utilização de leitura, emita o seguinte comando: ``` aws cloudwatch get-metric-data --cli-input-json file://read-calc.json ``` O resultado de ambas as consultas é uma série de pontos de dados no formato JSON usados para análise. Seu resultado depende do número de pontos de dados que você especificou, do período e de seus próprios dados específicos da carga de trabalho. Ela se parece com o exemplo a seguir. ``` { "MetricDataResults": [ { "Id": "utilizationPercentage", "Label": "Utilization Percentage", "Timestamps": [ "2022-02-22T05:00:00+00:00", "2022-02-22T04:00:00+00:00", "2022-02-22T03:00:00+00:00", "2022-02-22T02:00:00+00:00", "2022-02-22T01:00:00+00:00", "2022-02-22T00:00:00+00:00", "2022-02-21T23:00:00+00:00" ], "Values": [ 91.55364583333333, 55.066631944444445, 2.6114930555555556, 24.9496875, 40.94725694444445, 25.61819444444444, 0.0 ], "StatusCode": "Complete" } ], "Messages": [] } ``` **nota** Se você especificar um período curto e um longo intervalo de tempo, talvez seja necessário modificar o valor `MaxDatapoints` que, por padrão, está definido como 24 no script. Isso representa um ponto de dados por hora e 24 por dia. ------ #### [ Console de gerenciamento da AWS ] 1. Faça login no Console de gerenciamento da AWS e navegue até a página de CloudWatch serviço em [Introdução ao Console de gerenciamento da AWS](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html). Selecione o apropriado, Região da AWS se necessário. 1. Localize a seção Metrics (Métricas) na barra de navegação à esquerda e selecione **All metrics** (Todas as métricas). 1. Isso abrirá uma tela com dois painéis. O painel superior mostra o gráfico e o painel inferior tem as métricas que você deseja representar graficamente. Escolha o painel Amazon Keyspaces. 1. Selecione a categoria **Table Metrics** (Métricas da tabela) nos subpainéis. Isso mostra as tabelas em sua tabela atual Região da AWS. 1. Identifique o nome da sua tabela rolando o menu para baixo e, em seguida, selecione as métricas da operação de gravação: `ConsumedWriteCapacityUnits` e `ProvisionedWriteCapacityUnits`. **nota** Este exemplo fala sobre métricas da operação de gravação, mas você também pode usar essas etapas para representar graficamente as métricas da operação de leitura. 1. Selecione a guia **Graphed metrics (2)** (Métricas em gráfico (2)) para modificar as fórmulas. Por padrão, CloudWatch escolhe a função estatística **Média** para os gráficos. 1. Com as duas métricas em gráfico selecionadas (a caixa de seleção à esquerda), selecione o menu **Add math** (Adicionar matemática), seguido por **Common** (Comum), e selecione a função **Percentage** (Porcentagem). Repita o procedimento duas vezes. Primeira vez selecionando a função **Percentage** (Porcentagem): Pela segunda vez, selecionando a função **Percentage** (Porcentagem): 1. Nesse ponto, você deve ter quatro métricas no menu inferior. Vamos trabalhar no cálculo de `ConsumedWriteCapacityUnits`. Para ser consistente, você precisa combinar os nomes com os usados na AWS CLI seção. Clique no **ID m1** e altere esse valor para **consumedWCU**. 1. Altere a estatística de **Average** (Média) para **Sum** (Soma). Essa ação cria automaticamente outra métrica chamada **ANOMALY\$1DETECTION\$1BAND**. Para saber o escopo desse procedimento, vamos ignorá-lo removendo a caixa de seleção na **métrica ad1** recém-gerada. 1. Repita a etapa 8 para renomear o **ID m2** como **provisionedWCU**. Deixe a estatística definida como **Average** (Média). 1. **Escolha o rótulo **Expression1** e atualize o valor para **m1** e o rótulo para Consumido. WCUs** **nota** Certifique-se de ter selecionado somente **m1** (caixa de seleção à esquerda) e **provisionedWCU** para visualizar corretamente os dados. Atualize a fórmula clicando em **Details** (Detalhes) e alterando a fórmula para **consumedWCU/PERIOD(consumedWCU)**. Essa etapa também pode gerar outra métrica **ANOMALY\$1DETECTION\$1BAND**, mas, para o escopo desse procedimento, podemos ignorá-la. 1. Agora você deve ter dois gráficos: um que indica que você está provisionado WCUs na tabela e outro que indica o que foi consumido. WCUs 1. Atualize a fórmula de porcentagem selecionando o gráfico Expression2 (**e2**). Renomeie os rótulos IDs para **UtilizationPercentage**. Renomeie a fórmula para corresponder a **100\$1(m1/provisionedWCU)**. 1. Remova a caixa de seleção de todas as métricas, exceto **utilizationPercentage**, para visualizar seus padrões de utilização. O intervalo padrão é definido como 1 minuto, mas fique à vontade para modificá-lo conforme necessário. Os resultados obtidos dependem dos dados reais de sua carga de trabalho. Intervalos com mais de 100% de utilização estão sujeitos a eventos de erros de capacidade de throughput insuficiente. O Amazon Keyspaces oferece [capacidade de expansão](throughput-bursting.md), mas assim que a capacidade de throughput se esgota, qualquer coisa acima de 100% experimenta eventos de erro de baixa capacidade de transferência. ------ ## Como identificar tabelas do Amazon Keyspaces subprovisionadas Para a maioria das workloads, uma tabela é considerada subprovisionada quando consome constantemente mais de 80% de sua capacidade provisionada. A [capacidade de intermitência](throughput-bursting.md) é um recurso do Amazon Keyspaces que permite que os clientes consumam temporariamente mais do que o provisionado originalmente ( RCUs/WCUs mais do que a taxa de transferência provisionada por segundo que foi definida para a tabela). A capacidade de expansão foi criada para absorver aumentos repentinos no tráfego devido a eventos especiais ou picos de uso. Essa capacidade de expansão é limitada; para obter mais informações, consulte[Use a capacidade de expansão de forma eficaz no Amazon Keyspaces](throughput-bursting.md). Assim que não WCUs forem utilizados RCUs e esgotados, você poderá enfrentar eventos de erro de taxa de transferência de baixa capacidade se tentar consumir mais capacidade do que a provisionada. Quando o tráfego do seu aplicativo está se aproximando da taxa de utilização de 80%, o risco de passar por erros desnecessários de throughput de baixa capacidade é significativamente maior. A regra da taxa de utilização de 80% varia com a sazonalidade de seus dados e com o crescimento do tráfego. Considere os seguintes cenários: + Se o seu tráfego se manteve **estável** com uma taxa de utilização de \$190% nos últimos 12 meses, sua tabela tem a capacidade certa + Se o tráfego da sua aplicação estiver **crescendo** a uma taxa de 8% ao mês em menos de 3 meses, você chegará a 100% + Se o tráfego da sua aplicação estiver **crescendo** a uma taxa de 5% em pouco mais de 4 meses, você ainda chegará a 100% Os resultados das consultas acima fornecem uma imagem da sua taxa de utilização. Use-os como um guia para avaliar melhor outras métricas que podem ajudar você a escolher aumentar a capacidade da tabela conforme necessário (por exemplo: uma taxa de crescimento mensal ou semanal). Trabalhe com sua equipe de operações para definir qual é uma boa porcentagem para sua carga de trabalho e suas tabelas. Há cenários especiais em que os dados são distorcidos quando os analisamos diariamente ou semanalmente. Por exemplo, com aplicativos sazonais que têm picos de uso durante o horário comercial (mas depois caem para quase zero fora do horário comercial), você pode se beneficiar do [Application Auto Scaling programado](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html), em que especifica as horas do dia (e os dias da semana) para aumentar a capacidade provisionada e quando reduzi-la. Em vez de buscar maior capacidade para cobrir as horas de pico, você também pode se beneficiar das configurações de [ajuste de escala automático de tabelas do Amazon Keyspaces](autoscaling.md) se a sua sazonalidade for menos acentuada. ## Como identificar tabelas superprovisionadas do Amazon Keyspaces Os resultados da consulta obtidos dos scripts acima fornecem os pontos de dados necessários para realizar algumas análises iniciais. Se o seu conjunto de dados apresentar valores inferiores a 20% de utilização em vários intervalos, sua tabela pode estar superprovisionada. Para definir melhor se você precisa reduzir o número de WCUs e o RCUS, você deve revisitar as outras leituras nos intervalos. Quando suas tabelas contêm vários intervalos de uso baixos, você pode se beneficiar do uso de políticas de Application Auto Scaling, seja programando o Application Auto Scaling ou simplesmente configurando as políticas de Application Auto Scaling padrão para a tabela, com base na utilização. Se você tem uma carga de trabalho com baixa utilização e alta taxa de aceleração (**Máximo (ThrottleEvents) /Min () no intervaloThrottleEvents)**, isso pode acontecer quando você tem uma carga de trabalho muito alta, em que o tráfego aumenta significativamente em dias específicos (ou horários do dia), mas é consistentemente baixo. Nesses cenários, pode ser benéfico usar o [Application Auto Scaling programado](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html).