はじめに
アプリケーションはサーバーを増やし、後で減らす必要があります。このラボでは 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 で、追加サーバーが 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 実応答とインスタンス終了を確認し、ポリシーだけを削除して復元したサーバー群を残しました。
設定、明示的実行、指標トリガーの違いを説明できます。チャレンジでは新サーバーに流量が届かない問題をルーティングとヘルスチェックで診断します。



