Introdução
Uma aplicação pode precisar de mais servidores e depois menos. Você definirá duas políticas, ampliará a frota de dois para três e voltará a dois. Verificará HTTP real e como os limites impedem novas alterações.
Você deve conhecer modelos, grupos Auto Scaling e verificações ALB. Este ambiente novo fornece o grupo independente íntegro application-fleet de duas instâncias, modelo, rede e balanceador. Nenhum recurso anterior é reutilizado.
Relação com certificações
Prática introdutória de SAA-C03 Domain 2 e SOA-C03 Domain 2: capacidade Auto Scaling, ações de escalabilidade e integração ALB.
Definir políticas
Você examinará a frota e criará políticas sem alterar capacidade.
Entre no diretório e consulte a capacidade inicial:
cd /home/labex/project
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Max:MaxSize,Instances:Instances[].InstanceId}'
TG_ARN=$(aws elbv2 \
describe-target-groups \
--names application-targets \
--query 'TargetGroups[0].TargetGroupArn' \
--output text)
LB_DNS=$(aws elbv2 \
describe-load-balancers \
--names application-alb \
--query 'LoadBalancers[0].DNSName' \
--output text)
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
Espere mínimo 2, desejado 2, máximo 3 e dois destinos íntegros em AWS View. Uma política de escalabilidade define o ajuste. ChangeInCapacity altera uma quantidade absoluta: 1 adiciona um servidor; -1 remove um.
Crie duas políticas SimpleScaling. O cooldown normalmente permite estabilizar uma ação antes de outra acionada por alarme. Armazene 30 segundos:
aws autoscaling \
put-scaling-policy \
--auto-scaling-group-name application-fleet \
--policy-name add-one-server \
--policy-type SimpleScaling \
--adjustment-type ChangeInCapacity \
--scaling-adjustment 1 \
--cooldown 30
aws autoscaling \
put-scaling-policy \
--auto-scaling-group-name application-fleet \
--policy-name remove-one-server \
--policy-type SimpleScaling \
--adjustment-type ChangeInCapacity \
--scaling-adjustment -1 \
--cooldown 30
aws autoscaling \
describe-policies \
--auto-scaling-group-name application-fleet \
--query 'ScalingPolicies[].{Name:PolicyName,Type:PolicyType,Adjustment:ScalingAdjustment,Cooldown:Cooldown}'
Criar políticas não as executa. Aqui usamos --no-honor-cooldown para transições controladas. Não demonstramos aplicação temporal do cooldown nem alarmes CloudWatch. Em produção, políticas por métricas usam alarmes; target tracking segue um valor alvo. Não testamos realimentação automática nem carga CPU.
Ampliar para três servidores
Você executará a política positiva e verificará respostas reais do novo servidor.
Scale-out adiciona instâncias. Execute a política e aguarde ALB:
aws autoscaling \
execute-policy \
--auto-scaling-group-name application-fleet \
--policy-name add-one-server \
--no-honor-cooldown
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Desired:DesiredCapacity,Max:MaxSize,Instances:Instances[].InstanceId}'
Espere capacidade 3 e três IDs atuais. O grupo usa o modelo para o novo servidor e o registra automaticamente.
Execute a mesma política novamente no máximo e consulte capacidade:
aws autoscaling \
execute-policy \
--auto-scaling-group-name application-fleet \
--policy-name add-one-server \
--no-honor-cooldown
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Desired:DesiredCapacity,Max:MaxSize,Instances:Instances[].InstanceId}'
A capacidade permanece 3; o ajuste não ultrapassa o máximo do grupo. O limite controla servidores, não solicitações por servidor.
Envie nove solicitações e compare os IDs com os três servidores atuais:
for request in 1 2 3 4 5 6 7 8 9; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Abra AWS View. Confirme desejado 3, três destinos íntegros e respostas reais 200 de todos com Send request. Uma nova entrada na API não comprova atendimento ao tráfego.
Exemplo: capacidade desejada três e o servidor adicional retorna HTTP 200. Seus IDs serão diferentes.
Reduzir e preservar o mínimo
Você reduzirá capacidade e confirmará dois servidores disponíveis.
Scale-in remove instâncias. Execute a política negativa e aguarde destinos íntegros:
aws autoscaling \
execute-policy \
--auto-scaling-group-name application-fleet \
--policy-name remove-one-server \
--no-honor-cooldown
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Instances:Instances[].InstanceId}'
aws ec2 \
describe-instances \
--filters "Name=tag:aws:autoscaling:groupName,Values=application-fleet" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'
Espere dois IDs atuais e uma instância terminated. O grupo escolhe o servidor removido; não presuma que sempre é o mais novo. Ele não deve continuar no conjunto ativo de destinos.
Execute a política negativa novamente no mínimo e consulte capacidade:
aws autoscaling \
execute-policy \
--auto-scaling-group-name application-fleet \
--policy-name remove-one-server \
--no-honor-cooldown
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Instances:Instances[].InstanceId}'
O desejado permanece 2; a política não reduz abaixo do mínimo. Envie seis solicitações para testar a frota restante:
for request in 1 2 3 4 5 6; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Em AWS View, confirme dois destinos íntegros e respostas 200 dos IDs atuais. O ID terminado não deve aparecer em novas respostas. Testamos ciclo de vida e roteamento, sem medir drenagem nem preservação de sessões.
Remover políticas e manter a frota
Você removerá as políticas após restaurar a frota fornecida a dois servidores.
Exclua ambas as políticas e examine o inventário restante:
aws autoscaling \
delete-policy \
--auto-scaling-group-name application-fleet \
--policy-name add-one-server
aws autoscaling \
delete-policy \
--auto-scaling-group-name application-fleet \
--policy-name remove-one-server
aws autoscaling \
describe-policies \
--auto-scaling-group-name application-fleet \
--query 'ScalingPolicies[].PolicyName'
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Max:MaxSize}'
A lista deve ser [] e o grupo mínimo 2, desejado 2, máximo 3. Excluir políticas não termina servidores existentes. Preserve grupo, modelo, ALB e rede; AWS View deve mostrar dois servidores íntegros.
Resumo
Você definiu políticas simples positivas e negativas, observou expansão real de dois para três e redução para dois, e testou limites. Verificou HTTP real e terminação nativa, depois removeu políticas mantendo a frota restaurada.
Você distingue configuração, execução explícita e acionamento por métricas. O desafio aplica diagnóstico de roteamento e integridade a um novo servidor sem tráfego.
