Amazon Aurora Auto Scaling com réplicas do Aurora
Para atender aos requisitos de conectividade e de workload, a autoescalabilidade do Aurora ajusta dinamicamente o número de réplicas do Aurora (instâncias de banco de dados do leitor) provisionadas para um cluster de banco de dados Aurora. O Auto Scaling do Aurora está disponível para ambos Aurora MySQL e Aurora PostgreSQL. O Auto Scaling do Aurora permite que o cluster de banco de dados Aurora processe aumentos repentinos de conectividade ou de workload. Quando a conectividade ou a workload diminui, o Auto Scaling do Aurora elimina as réplicas desnecessárias do Aurora para que você não pague por instâncias de banco de dados provisionadas não usadas.
Você define e aplica as políticas de escalabilidade do Aurora para um cluster de banco de dados. A política de escalabilidade define o número mínimo e máximo de réplicas do Aurora que o Auto Scaling do Aurora pode gerenciar. Com base nas políticas, o Auto Scaling do Aurora ajusta o número de réplicas do Aurora para mais ou para menos em resposta às workloads reais, usando as métricas e valores de destino do Amazon CloudWatch.
nota
O Aurora Auto Scaling não se aplica à workload na instância de banco de dados do gravador. O Aurora Auto Scaling é útil para a workload somente nas instâncias do leitor.
Você pode usar o AWS Management Console para uma política de escalabilidade com base em uma métrica predefinida. Se preferir, você pode usar a AWS CLI ou a API do Auto Scaling do Aurora para aplicar uma política de escalabilidade com base em uma métrica predefinida ou personalizada.
Tópicos
Antes de começar
Para usar o Aurora Auto Scaling com um cluster de banco de dados do Aurora, você deve primeiro criar um cluster de banco de dados do Aurora com uma instância de banco de dados (gravação) primária. Para ter mais informações sobre como criar um cluster de banco de dados Aurora, consulte Criar um cluster de bancos de dados do Amazon Aurora.
O Aurora Auto Scaling só dimensionará um cluster de banco de dados se o cluster de banco de dados estiver no estado disponível.
Quando o Auto Scaling do Aurora adicionar uma nova réplica do Aurora, a nova réplica do Aurora será da mesma classe de instância de banco de dados que a usada pela instância principal. Para mais informações sobre classes de instância de banco de dados, consulte Classes de instância de banco de dados do Amazon Aurora. Além disso, o nível de promoção para novas réplicas do Aurora está definido como a última prioridade, que é 15 por padrão. Isso significa que, durante um failover, uma réplica com uma prioridade maior, como uma criada manualmente, será promovida primeiro. Para ter mais informações, consulte Tolerância a falhas para um cluster de banco de dados do Aurora.
O Auto Scaling do Aurora remove somente as réplicas do Aurora que ele criou.
Para que se beneficiem do Auto Scaling do Aurora, seus aplicativos devem oferecer suporte a conexões com as novas réplicas do Aurora. Para fazer isso, recomendamos usar o endpoint do leitor do Aurora. É possível usar um driver, como o driver JDBC da AWS. Para ter mais informações, consulte Como conectar-se a um cluster de bancos de dados Amazon Aurora.
nota
No momento, os bancos de dados globais Aurora não oferecem suporte ao Aurora Auto Scaling para clusters de banco de dados secundários.
Políticas de Auto Scaling do Aurora
O Auto Scaling do Aurora usa uma política de escalabilidade para ajustar o número de réplicas do Aurora em um cluster de banco de dados Aurora. O Aurora Auto Scaling tem os seguintes componentes:
Uma função vinculada a serviços
Uma métrica de destino
Capacidades mínima e máxima
Um desaquecimento
Tópicos
Função vinculada ao serviço
O Auto Scaling do Aurora usa a função vinculada ao serviço AWSServiceRoleForApplicationAutoScaling_RDSCluster. Para ter mais informações, consulte Funções vinculadas a serviço do Application Auto Scaling, no Guia do usuário do Application Auto Scaling.
Métrica de destino
Neste tipo de política, uma métrica predefinida ou personalizada e um valor de destino dessa métrica são especificados na configuração de uma política de escalabilidade de rastreamento de destino. O Auto Scaling do Aurora cria e gerencia os alarmes do CloudWatch que acionam a política de escalabilidade e calculam o ajuste de escalabilidade com base na métrica e no valor de destino. A política de escalabilidade adiciona ou remove réplicas do Aurora conforme necessário para manter a métrica no valor de destino especificado ou próxima a ele. Além de manter a métrica próxima ao valor de destino, uma política de escalabilidade de rastreamento de destino também se ajusta às flutuações na métrica, devido a workloads variáveis. Essas políticas também minimizam flutuações rápidas no número de réplicas do Aurora disponíveis para seu cluster de banco de dados.
Por exemplo, considere uma política de escalabilidade que use a métrica predefinida de utilização média da CPU. Essa política pode manter a utilização da CPU a uma porcentagem específica de utilização específica, por exemplo, 40 por cento ou próxima disso.
nota
Para cada cluster de banco de dados Aurora, você pode criar somente uma política de Auto Scaling para cada métrica de destino.
Quando você configura o Aurora Auto Scaling, o valor da métrica de destino é calculado como a média de todas as instâncias de leitor no cluster. Esse cálculo é realizado da seguinte maneira:
-
Inclui todas as instâncias de leitor no cluster do Aurora, independentemente de serem gerenciadas pelo Auto Scaling ou adicionadas manualmente.
-
Inclui instâncias de banco de dados associadas a endpoints personalizados. Os endpoints personalizados não influenciam o cálculo das métricas de destino.
-
Não inclui a instância de gravador do cluster.
As métricas são derivadas do CloudWatch usando as seguintes dimensões:
-
DBClusterIdentifier -
Role=READER
Por exemplo, considere um cluster do Aurora MySQL com a seguinte configuração:
-
Instâncias manuais (não controladas pelo Auto Scaling):
-
Gravador com 50% de utilização da CPU
-
Leitor 1 (endpoint personalizado:
custom-reader-1) com 90% de utilização da CPU -
Leitor 2 (endpoint personalizado:
custom-reader-2) com 90% de utilização da CPU
-
-
Instância do Auto Scaling:
-
Leitor 3 (adicionado usando o Auto Scaling) com 10% de utilização da CPU
-
Nesse cenário, a métrica de destino para a política do Auto Scaling é calculada da seguinte forma:
Target metric = (CPU utilization of reader 1 + reader 2 + reader 3) / total number of readers Target metric = (90 + 90 + 10) / 3 = 63.33%
A política do Auto Scaling usa esse valor para avaliar se deve reduzir ou aumentar a escala horizontalmente com base no limite definido.
Considere o seguinte:
-
Embora os endpoints personalizados determinem como o tráfego é roteado para leitores específicos, eles não excluem os leitores do cálculo da métrica.
-
As instâncias manuais são sempre incluídas nos cálculos da métrica de destino.
-
Para evitar um comportamento inesperado de escalabilidade, certifique-se de que a configuração do Auto Scaling considere todas as instâncias de leitor no cluster.
-
Se um cluster não tiver leitores, a métrica não será calculada e os alarmes da política do Auto Scaling permanecerão inativos. Para que a política do Auto Scaling funcione de forma eficaz, pelo menos um leitor deve estar presente o tempo todo.
Capacidades mínima e máxima
Você pode especificar o número máximo de réplicas do Aurora a serem gerenciadas pelo Application Auto Scaling. Este valor deve ser definido entre 0 – 15, e deve ser igual ou maior que o valor especificado para o número mínimo de réplicas do Aurora.
Você também pode especificar o número mínimo de réplicas do Aurora a serem gerenciadas pelo Application Auto Scaling. Este valor deve ser definido entre 0 – 15, e deve ser igual ou menor que o valor especificado para o número máximo de réplicas do Aurora.
Deve haver pelo menos um leitor na instância de banco de dados do leitor para que o Aurora Auto Scaling funcione. Se o cluster de banco de dados não tiver uma instância do leitor e você definir a capacidade mínima como 0, o Aurora Auto Scaling não funcionará.
nota
A capacidade mínima e máxima são definidas para um cluster de banco de dados Aurora. Os valores especificados se aplicam a todas as políticas associadas a um cluster de banco de dados Aurora.
Desaquecimento
Você pode ajustar a responsividade das políticas de escalabilidade de rastreamento de destino, adicionando desaquecimentos que afetam a escalabilidade de seu cluster de banco de dados Aurora pra mais ou para menos. Um desaquecimento bloqueia solicitações subsequentes de redução ou expansão até o período expirar. Esses blocos retardam as exclusões de réplicas do Aurora em seu cluster de banco de dados Aurora para solicitações de redução e a criação de réplicas do Aurora para solicitações de expansão.
Você pode especificar os seguintes desaquecimentos:
-
A atividade de redução diminui o número de réplicas do Aurora em seu cluster de banco de dados Aurora. Um desaquecimento de redução especifica a quantidade de tempo, em segundos, após a conclusão de uma ação de redução antes que quaisquer outras atividades de redução possam iniciar.
-
A atividade de expansão aumenta o número de réplicas do Aurora em seu cluster de banco de dados Aurora. Um desaquecimento de expansão especifica a quantidade de tempo, em segundos, após a conclusão de uma ação de expansão antes que quaisquer outras atividades de expansão possam iniciar.
nota
Um período de esfriamento de aumento da escala horizontalmente será ignorado se uma solicitação subsequente para aumentar a escala horizontalmente for para um número maior de réplicas do Aurora do que o da primeira solicitação.
Se você não especificar um período de esfriamento de aumento ou redução da escala horizontalmente, o padrão para cada um será de 300 segundos.
Habilitar ou desabilitar atividades de redução
Você pode habilitar ou desabilitar atividades de redução para as políticas. Habilitar atividades de redução permite que as políticas de escalabilidade excluam réplicas do Aurora. Quando as atividades de redução são habilitadas, o desaquecimento de redução na política de escalabilidade aplica-se a atividades de redução. Desabilitar atividades de redução evita que as políticas de escalabilidade excluam réplicas do Aurora.
nota
As atividades de expansão são habilitadas para que a política de escalabilidade possa criar réplicas do Aurora, conforme necessário.
Adicionar, editar ou excluir políticas de ajuste de escala automático
É possível adicionar, editar ou excluir políticas de ajuste de escala automático usando o AWS Management Console, a AWS CLI ou a API do Application Auto Scaling. Para ter mais informações sobre adição, edição ou exclusão de políticas de ajuste de escala automático, consulte as seções a seguir.
IDs de instância de banco de dados e marcação
Quando uma réplica é adicionada pelo Aurora Auto Scaling, seu ID de instância de banco de dados é prefixado por application-autoscaling-, por exemplo, application-autoscaling-61aabbcc-4e2f-4c65-b620-ab7421abc123.
A tag a seguir é adicionada automaticamente à instância de banco de dados. Você pode visualizá-lo na guia Tags da página de detalhes da instância de banco de dados.
| Tag | Valor |
|---|---|
| application-autoscaling:resourceId | cluster:mynewcluster-cluster |
Para ter mais informações sobre Amazon RDS as tags de recurso, consulte Marcar recursos do Amazon Aurora e do Amazon RDS.
Aurora Auto Scaling e Performance Insights
Você pode usar o Performance Insights para monitorar réplicas que foram adicionadas pelo Aurora Auto Scaling da mesma forma que com qualquer instância de banco de dados do leitor do Aurora.
Para ter mais informações sobre como usar o Performance Insights para monitorar clusters de banco de dados do Aurora, consulte Monitorar a carga de banco de dados com o Performance Insights no Amazon Aurora.
