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á.
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 é 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.
Tópicos
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 AWS Management Console 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.
-
Retorne a lista completa de recursos executando o seguinte comando:
aws application-autoscaling describe-scaling-policies --service-namespace cassandraEsse 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” -
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:<region>:<account-id>:scalingPolicy:<uuid>:resource/keyspaces/table/table-name-scaling-policy", "PolicyName": $<full-gsi-name>”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:index:WriteCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "KeyspacesWriteCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:48.641000+10:00" }, { "PolicyARN": "arn:aws:autoscaling:<region>:<account-id>:scalingPolicy:<uuid>:resource/keyspaces/table/table-name/index/<index-name>:policyName/$<full-gsi-name>-scaling-policy", "PolicyName":$<full-table-name>”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:index:ReadCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "CassandraReadCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:47.820000+10:00" } ] }
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.
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
ConsumedWriteCapacityUnitsficam 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, 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.
-
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 -
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" -
Execute o seguinte comando para validar que ambas as regras foram ativadas:
aws application-autoscaling describe-scheduled-actions --service-namespace cassandraVocê deve obter um resultado parecido com este:
{ "ScheduledActions": [ { "ScheduledActionName": "my-5-8-scheduled-down-action", "ScheduledActionARN": "arn:aws:autoscaling:<region>:<account>:scheduledAction:<uuid>: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:<region>:<account>:scheduledAction:<uuid>: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.
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.
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. 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.
