スケーリングポリシーでアプリケーション容量を変更する

AWSBeginner
オンラインで実践に進む

はじめに

アプリケーションはサーバーを増やし、後で減らす必要があります。このラボでは 2 つのポリシーを定義し、2 台から 3 台に増やして 2 台に戻します。実際の HTTP 応答と、上下限が追加の増減を防ぐ動作を確認します。

起動テンプレート、Auto Scaling グループ、ALB ヘルスチェックの知識が必要です。新環境には正常な独立した 2 台の 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 の正常ターゲット 2 台を確認します。スケーリングポリシーは容量調整を定義します。ChangeInCapacity は絶対数の変更で、1 は 1 台追加、-1 は 1 台削減です。

2 つの 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 負荷は検証しません。

3 台にスケールアウトする

正のポリシーを実行し、追加サーバーが実際に応答することを確認します。

スケールアウトはインスタンス追加です。ポリシーを実行し、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 3 個が期待値です。グループはテンプレートで新サーバーを起動し、ターゲットに自動登録します。

最大に達した状態で再実行し、容量を確認します。

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 のままで、グループ最大値を超えません。これは台数の制限で、各サーバーのリクエスト数の制限ではありません。

9 回リクエストし、応答 ID を現在の 3 台と比較します。

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、正常ターゲット 3 台を確認し、Send request で全 ID の実際の 200 を観察します。API の資源追加だけでは処理動作を証明できません。

実際に応答する 3 台

例:希望容量は 3 で、追加サーバーが HTTP 200 を返します。実際の ID は異なります。

スケールインして最小容量を維持する

容量を減らし、2 台が利用可能であることを確認します。

スケールインはインスタンス削減です。負のポリシーを実行し、現在のターゲット正常化を待ちます。

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 2 個と terminated 1 台が期待値です。削除対象はグループが選びます。最新サーバーとは限りません。削除済みサーバーはサービス対象に残りません。

最小値で負のポリシーを再実行し、容量を確認します。

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 を維持し、最小値より減りません。6 回リクエストして残ったサーバー群を確認します。

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

AWS View で正常ターゲット 2 台と両 ID の 200 を確認します。終了 ID は新応答に現れません。ここではライフサイクルとルーティングを確認し、ドレイン時間やセッション維持は測定しません。

ポリシーを削除して準備済みサーバー群を残す

提供されたサーバー群を 2 台に戻した後、作成したポリシーを削除します。

両ポリシーを削除し、残りの一覧を確認します。

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 に正常 2 台が表示されることを確認します。

まとめ

正と負の単純ポリシーを定義し、実際に 2 台から 3 台へ増やし 2 台へ戻して上下限を試しました。HTTP 実応答とインスタンス終了を確認し、ポリシーだけを削除して復元したサーバー群を残しました。

設定、明示的実行、指標トリガーの違いを説明できます。チャレンジでは新サーバーに流量が届かない問題をルーティングとヘルスチェックで診断します。