Diminua a latência para aplicações com tempos de inicialização longos usando pools ativos

Um pool ativo é um grupo de instâncias do EC2 pré-inicializadas que permanece ao lado de um grupo do Auto Scaling. Sempre que é necessário aumentar a escala da aplicação na horizontal, o grupo do Auto Scaling pode utilizar o pool ativo para atender à nova capacidade desejada. Isso o ajuda a garantir que as instâncias estejam prontas para começar rapidamente a servir o tráfego das aplicações, acelerando a resposta a um evento de aumento de escala na horizontal. Quando as instâncias deixam o pool ativo, elas passam a contar para a capacidade desejada do grupo. Isso é conhecido como inicialização a quente.

Enquanto as instâncias estão no pool quente, suas políticas de escalabilidade só são dimensionadas se o valor da métrica das instâncias que estão no estado InService for maior que o limite alto de alarme da política da escalabilidade (que é o mesmo que a utilização de destino de uma política de dimensionamento com monitoramento do objetivo).

Por padrão, o tamanho do pool ativo é calculado como a diferença entre a capacidade máxima do grupo do Auto Scaling e a capacidade desejada. Por exemplo, se a capacidade desejada do grupo do Auto Scaling for 6 e a capacidade máxima for 10, o tamanho do pool ativo será 4 quando você configurar o pool ativo pela primeira vez e o pool estiver inicializando.

Para especificar a capacidade máxima do grupo dinâmico separadamente, use a opção de especificação personalizada (MaxGroupPreparedCapacity) e defina um valor personalizado para ela que seja maior do que a capacidade atual do grupo. Se você fornecer um valor personalizado, o tamanho do grupo dinâmico será calculado como a diferença entre o valor personalizado e a capacidade desejada atual do grupo. Por exemplo, se a capacidade desejada do seu grupo do Auto Scaling for 6, se a capacidade máxima for 20 e se o valor personalizado for 8, o tamanho do seu grupo dinâmico será 2 quando você configurar o grupo dinâmico pela primeira vez e o grupo estiver sendo inicializado.

Talvez você só precise usar a opção de especificação personalizada (MaxGroupPreparedCapacity) ao trabalhar com grandes grupos do Auto Scaling para gerenciar os benefícios de custo de ter um grupo dinâmico. Por exemplo, talvez um grupo do Auto Scaling com 1.000 instâncias, uma capacidade máxima de 1.500 (para fornecer capacidade extra durante picos de tráfego de emergência) e um pool ativo de 100 instâncias seja uma estratégia melhor para ajudar você a atingir seus objetivos do que manter 500 instâncias reservadas para uso futuro no pool ativo.

Considere usar a configuração de tamanho mínimo (MinSize) para definir de modo estático o número mínimo de instâncias a serem mantidas no grupo de alta atividade. Não há tamanho mínimo definido por padrão. A configuração MinSize é útil quando você especifica MaxGroupPreparedCapacity para garantir que um número mínimo de instâncias seja mantido no grupo de alta atividade, mesmo quando a capacidade desejada do grupo do Auto Scaling for maior que MaxGroupPreparedCapacity.

Você pode manter as instâncias no pool ativo em um de três estados: Stopped, Running, ou Hibernated. Manter as instâncias no estado Stopped é uma maneira eficaz de minimizar os custos. Com as instâncias interrompidas, você paga apenas pelos volumes usados e pelos endereços IP elásticos anexados às instâncias.

Você também pode manter as instâncias em um estado Hibernated para interromper instâncias sem excluir o conteúdo da memória (RAM). Quando uma instância é hibernada, isso sinaliza ao sistema operacional para salvar o conteúdo da RAM no volume raiz do Amazon EBS. Quando você inicia a instância novamente, o volume raiz é restaurado ao seu estado anterior, e o conteúdo da RAM é recarregado. Enquanto as instâncias estão em hibernação, você paga somente pelos volumes do EBS, incluindo armazenamento para o conteúdo da RAM e os endereços IP elásticos anexados às instâncias.

Também é possível manter instâncias em um estado Running no pool ativo, mas isso é altamente desaconselhável a fim de evitar a geração de cobranças desnecessárias. Quando as instâncias são interrompidas ou hibernadas, você economiza o custo das próprias instâncias. Você paga pelas instâncias somente quando elas são executadas.

Você usa ganchos do ciclo de vida para colocar instâncias em um estado de espera para poder executar ações personalizadas nas instâncias. Ações personalizadas são executadas à medida que as instâncias são iniciadas ou antes de serem terminadas.

Em uma configuração de pool quente, os ganchos do ciclo de vida atrasam a interrupção ou hibernação das instâncias e a colocação em serviço durante um evento de expansão até que concluam a inicialização. Se você adicionar um pool ativo ao seu grupo do Auto Scaling sem um gancho do ciclo de vida, as instâncias que demorarem muito para concluir a inicialização poderão ser interrompidas ou hibernadas e, em seguida, colocadas em serviço durante um evento de aumento de escala na horizontal antes de estarem prontas.

Por padrão, o Amazon EC2 Auto Scaling termina suas instâncias quando seu grupo do Auto Scaling reduz a escala na horizontal. Em seguida, ele inicia novas instâncias no pool ativo para substituir as instâncias que foram terminadas.

Se desejar devolver instâncias ao pool ativo, você poderá especificar uma política de reutilização de instâncias. Isso permite reutilizar instâncias que já estão configuradas para atender ao tráfego de aplicações. Para garantir que seu pool ativo não seja excessivamente provisionado, o Amazon EC2 Auto Scaling pode terminar instâncias no pool ativo para reduzir seu tamanho quando for maior do que o necessário, com base em suas configurações. Ao terminar instâncias no pool ativo, ele usa a política de término padrão para escolher quais instâncias terminar primeiro.