EC2 Auto Scalingを簡単に実践

Auto Scalingとは、サーバーの負荷やその他の条件に基づいて、クラウドサーバーの数を自動で増減させる機能のこと。システムに負荷がかかると自動でサーバーを増やし、高負荷時でも安定運用を実現する。また、負荷が少ないときにはサーバーを減らすことで、余計なコストを抑えることができる。まさにクラウドの真価といえる機能。

今回は、こうした負荷分散技術の一環として、AWSのEC2 Auto Scalingを簡単に構築し、実践してみる。なお、VPCやロードバランサーは前回すでに構築済みのため、今回はその後編となる。

https://zenn.dev/ayatakaa_chan/articles/2a37d4fe3ca109

1. Launch Template（起動テンプレート）の作成

1. AWSマネジメントコンソールで「EC2」→「起動テンプレート」を選択
2. 「起動テンプレートの作成」

• 名前：MyWebLaunchTemplate
• AMI：Amazon Linux 2
• インスタンスタイプ：t2.micro
• ネットワーク：MyALBVPC（VPC名）
• セキュリティグループ：WebSG
• その他はデフォルトでOK

3. 「起動テンプレートの作成」

2. Auto Scaling Group（ASG）の作成

1. サービス検索で「Auto Scaling」→「Auto Scaling グループ」を選択
2. 「Auto Scaling グループの作成」

• 名前：MyWebASG
• 起動テンプレート：先ほど作成したMyWebLaunchTemplate
• VPC：MyALBVPC
• サブネット：WebSubnet1, WebSubnet2を選択
• 「ロードバランシング」→
  • 「既存のロードバランサーを使用」→MyALBを選択
  • 「ターゲットグループ」→MyTargetGroupを選択

3. 「グループサイズとスケーリングポリシー」

• デフォルトでは
  • 最小：2
  • 最大：4
  • 希望：2
    （この例では最小・最大・希望いずれも2でもOK）
• スケーリングポリシー
  • 今回は「手動」でも良いが、CPU使用率ベースの自動スケーリングも選択できる

4. その他はデフォルトで「作成」

ちなみに、もっとも低コストで最低限の可用性を確保するには、Auto Scalingグループの最小・最大キャパシティを1に設定することで、インスタンス数を常に1に固定できる。この設定でも、異常なインスタンスがあれば自動で置き換えられ、1台稼働の状態が維持される（ただし可用性は落ちる）。

3. ASGの動作確認

• ASGが自動でEC2インスタンスを2台起動し、ALB配下のターゲットグループに登録される
• 片方のEC2を停止/削除しても、自動で新しいインスタンスが追加される
• ALBのDNSにアクセスし、Webページが表示されることを確認

2台のEC2インスタンスのうち1つを停止させたことで、新しいインスタンスが生成された

※補足：スケールイン時のセッション維持について
インスタンスがスケールインで削除されると、ローカルに保持していたセッション情報（ログイン状態やカート情報など）も一緒に失われる。セッションを安定して維持するには、セッション情報をインスタンス間で共有する仕組みが必要。
代表的な選択肢として、Amazon DynamoDBやAmazon ElastiCacheがある。DynamoDBはマルチAZ対応かつ高耐久で永続保存に向いており、ElastiCache（特にRedis型）は高速な読み書きができ、永続化やマルチAZ構成も可能。
なお、ElastiCacheのMemcached型は簡易な一時キャッシュには適しているが、永続化されず、障害時にデータが失われる点に注意。

4. スケールアウト／スケールインを試してみる

• Auto Scaling Groupの「グループサイズ」を手動で増減
  例えば「最小:3、希望:3」にすると3台自動起動
  「最小:1、希望:1」にすれば台数も自動で減る

• 「スケーリングポリシー」を「CPU使用率が70%を超えたら増やす」などに設定してみるのも面白い

グループサイズはスピンボタンで簡単に増減できる

グループサイズを最初2から3に上げたことで、インスタンスが2つから3つに増えた

なお、画面下にあるライフサイクルフックとは、スケーリング発生時のEC2インスタンスの起動または終了のタイミングで任意の処理を実行できる機能。たとえば、スケールアウト時に初期化スクリプトを走らせたり、スケールイン時にログを収集・退避する処理を組み込める。

また、スケールインが発生したときにどのインスタンスが終了対象になるかは、「終了ポリシー」で制御できる。デフォルトでは「もっとも古く起動されたインスタンス」が対象になる。特定のインスタンスをスケールインから保護したい場合は、「インスタンスの保護」を有効にする必要がある。

以上でAuto Scalingの実践は終了。Auto Scalingの仕組みを取り入れることで、システムの可用性とコスト効率を両立した柔軟なインフラ運用が実現できる。今後はスケーリングのトリガーや通知設定、Auto Scalingと連携する他のAWSサービスとの統合など、より実践的な活用にも挑戦していきたい。