조정 정책으로 앱 용량 변경하기

소개

앱은 때때로 서버를 늘리고 나중에 줄여야 합니다. 두 정책을 정의해 실제 서버군을 두 대에서 세 대로 늘린 후 두 대로 돌립니다. 실제 HTTP 응답과 용량 한계가 추가 변경을 막는 동작을 확인합니다.

시작 템플릿, Auto Scaling 그룹 및 ALB 상태 검사를 알아야 합니다. 새 환경에는 독립적인 정상 두 인스턴스 그룹 application-fleet, 템플릿, 네트워크와 ALB가 있습니다. 이전 리소스는 재사용하지 않습니다.

자격증 관련성

SAA-C03 Domain 2 및 **SOA-C03 Domain 2**의 용량 설정, 조정 동작 및 ALB 통합을 입문 수준으로 실습합니다.

조정 정책 정의

제공된 서버군을 살펴보고 용량을 바꾸지 않은 채 정책을 만듭니다.

작업 디렉터리에서 초기 용량을 조회합니다.

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"

최소 2, 원하는 2, 최대 3 및 AWS View의 정상 대상 두 개가 예상됩니다. 조정 정책은 용량 변경을 정의합니다. ChangeInCapacity는 절대 수량을 바꾸며 1은 한 대 추가, -1은 한 대 감소입니다.

두 SimpleScaling 정책을 만듭니다. 쿨다운은 보통 이전 동작이 안정된 후 다음 경보 동작을 허용합니다. 여기서는 30초를 저장합니다.

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}'

정책 생성은 실행이 아닙니다. 여기서는 --no-honor-cooldown으로 명시적 호출해 제어된 전환을 봅니다. 쿨다운 시간 적용이나 CloudWatch 경보는 시연하지 않습니다. 운영 환경에서 지표 정책은 경보를 사용하고 대상 추적은 목표값을 따릅니다. 자동 피드백이나 CPU 부하는 검사하지 않습니다.

세 대로 확장

양의 정책을 실행하고 추가 서버가 실제 요청을 처리하는지 확인합니다.

스케일 아웃은 인스턴스 추가입니다. 정책을 실행하고 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}'

원하는 용량 3과 현재 ID 세 개가 예상됩니다. 그룹은 템플릿으로 새 서버를 시작하고 자동 등록합니다.

최대값에서 같은 정책을 다시 실행하고 용량을 조회합니다.

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}'

용량은 3을 유지하며 최대값을 넘지 않습니다. 이는 서버 수 제한이며 서버당 요청 수 제한은 아닙니다.

아홉 요청을 보내 응답 ID를 현재 세 인스턴스와 비교합니다.

for request in 1 2 3 4 5 6 7 8 9; do
  curl --config client.conf -sS "http://$LB_DNS/health"
  echo
done

AWS View에서 원하는 3, 정상 대상 세 개와 Send request를 통한 전체 ID의 실제 200 응답을 확인합니다. API의 리소스 추가만으로 트래픽 처리를 증명할 수 없습니다.

예: 원하는 용량은 세 대이며 추가 서버가 HTTP 200을 반환합니다. 실제 ID는 다릅니다.

축소하고 최소값 유지

용량을 줄이고 앱 서버 두 대가 계속 사용 가능한지 확인합니다.

스케일 인은 인스턴스 감소입니다. 음의 정책을 실행하고 현재 대상이 정상일 때까지 기다립니다.

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}'

현재 ID 두 개와 terminated 한 대가 예상됩니다. 그룹이 제거할 대상을 선택하므로 가장 새 서버라고 가정하지 않습니다. 제거된 서버는 활성 대상에 남지 않아야 합니다.

최소값에서 음의 정책을 다시 실행하고 용량을 조회합니다.

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}'

원하는 용량은 2를 유지하며 최소값 아래로 내려가지 않습니다. 여섯 요청으로 남은 서버군을 확인합니다.

for request in 1 2 3 4 5 6; do
  curl --config client.conf -sS "http://$LB_DNS/health"
  echo
done

AWS View에서 정상 대상 두 개와 두 현재 ID의 200 응답을 확인합니다. 종료 ID는 새 응답에 나오지 않습니다. 라이프사이클과 라우팅을 검사하며 드레이닝 시간이나 세션 보존은 측정하지 않습니다.

정책을 삭제하고 준비된 서버군 유지

제공된 서버군을 두 대로 복원한 후 정책을 삭제합니다.

두 정책을 삭제하고 남은 목록을 확인합니다.

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}'

정책 목록은 [], 그룹은 최소 2, 원하는 2, 최대 3이어야 합니다. 정책 삭제는 기존 서버를 종료하지 않습니다. 그룹, 템플릿, ALB 및 네트워크를 유지하고 AWS View의 정상 두 대를 확인합니다.

요약

양과 음의 단순 정책으로 실제 두 대를 세 대로 늘리고 두 대로 줄이며 두 한계를 확인했습니다. 실제 HTTP 응답과 인스턴스 종료를 검증하고 정책을 삭제해 복원된 서버군을 유지했습니다.

설정, 명시적 실행 및 지표 트리거를 구분할 수 있습니다. 챌린지에서는 라우팅과 상태 진단으로 새 서버에 트래픽이 오지 않는 문제를 해결합니다.