Auto Scalingで自動スケーリングを実現する

前回の記事では、ELB（Elastic Load Balancing）による負荷分散について解説しました。本記事では、EC2 Auto Scalingを使用した自動スケーリングについて解説します。Auto Scalingグループの概念、起動テンプレートの設定、各種スケーリングポリシーの使い分けを理解し、負荷に応じて自動的にスケールする高可用性なシステムを構築できるようになりましょう。

Amazon EC2 Auto Scalingとは

Amazon EC2 Auto Scalingは、EC2インスタンスの数を自動的に増減させるサービスです。トラフィックの変動やシステム負荷に応じて適切な数のインスタンスを維持し、可用性の向上とコスト最適化を両立します。

Auto Scalingの主な特徴

Auto Scalingには以下の特徴があります。

なぜAuto Scalingが必要か

Webアプリケーションのトラフィックは時間帯や曜日、イベントによって大きく変動します。

graph TB
    subgraph "固定台数構成の問題"
        direction TB
        Fixed[EC2 3台固定]
        Fixed --> Problem1[ピーク時に<br/>処理しきれない]
        Fixed --> Problem2[閑散時に<br/>リソースの無駄]
    end

graph TB
    subgraph "Auto Scaling構成のメリット"
        direction TB
        ASG[Auto Scaling<br/>グループ]
        ASG --> Peak[ピーク時<br/>5台に自動増加]
        ASG --> Normal[通常時<br/>3台を維持]
        ASG --> Offpeak[閑散時<br/>2台に自動削減]
    end

Auto Scalingを導入することで、以下のメリットが得られます。

• 可用性の向上: 負荷増大時に自動でスケールアウトし、サービスを安定稼働
• 耐障害性: インスタンス障害時に自動で代替インスタンスを起動
• コスト削減: 閑散時にスケールインし、不要なリソースコストを削減
• 運用負荷軽減: 手動でのインスタンス増減作業が不要

Auto Scalingの構成要素

Auto Scalingは、以下の3つの主要コンポーネントで構成されます。

graph TB
    subgraph "Auto Scalingの構成要素"
        LT[起動テンプレート<br/>Launch Template] --> ASG[Auto Scalingグループ<br/>ASG]
        ASG --> Policy[スケーリングポリシー]
        
        LT --> |インスタンスの設定<br/>AMI、インスタンスタイプ等| ASG
        ASG --> |インスタンスの管理<br/>最小/最大/希望容量| EC2[EC2インスタンス群]
        Policy --> |スケーリングの条件<br/>いつ増減するか| ASG
    end

起動テンプレート（Launch Template）

起動テンプレートは、Auto Scalingグループが新しいインスタンスを起動する際の設定を定義します。

Auto Scalingグループ（ASG）

Auto Scalingグループは、インスタンスの集合を管理する論理的なグループです。

スケーリングポリシー

スケーリングポリシーは、いつ、どのようにインスタンス数を変更するかを定義します。

起動テンプレートの作成

起動テンプレートは、Auto Scalingグループでインスタンスを起動する際の設計図となります。

起動テンプレートと起動設定の違い

以前は「起動設定（Launch Configuration）」も使用されていましたが、現在は起動テンプレートの使用が推奨されています。

起動テンプレートの作成手順

EC2コンソールから「起動テンプレート」→「起動テンプレートを作成」を選択します。

ユーザーデータの設定例

ユーザーデータを使用して、インスタンス起動時に自動的にWebサーバーをセットアップできます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

#!/bin/bash
# システムの更新
dnf update -y

# Webサーバーのインストール
dnf install -y nginx

# アプリケーションコードの取得
aws s3 cp s3://my-app-bucket/app.tar.gz /var/www/html/
cd /var/www/html && tar -xzf app.tar.gz

# Webサーバーの起動
systemctl enable nginx
systemctl start nginx

# CloudWatch Agentのインストールと設定
dnf install -y amazon-cloudwatch-agent
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -s \
  -c ssm:AmazonCloudWatch-linux-config

起動テンプレートのバージョン管理

起動テンプレートはバージョン管理が可能です。設定変更時は新しいバージョンを作成します。

Auto Scalingグループでは、使用するバージョンを以下のように指定できます。

• Latest: 常に最新バージョンを使用
• Default: デフォルトに設定されたバージョンを使用
• 特定のバージョン番号: 明示的にバージョンを指定

Auto Scalingグループの作成

Auto Scalingグループは、EC2インスタンスの集合を管理する中心的なコンポーネントです。

Auto Scalingグループの作成手順

EC2コンソールから「Auto Scalingグループ」→「Auto Scalingグループの作成」を選択します。

ステップ1: 起動テンプレートの選択

ステップ2: インスタンス起動オプション

複数のサブネット（AZ）を選択することで、高可用性を実現できます。

graph TB
    subgraph "マルチAZ構成"
        ASG[Auto Scaling<br/>グループ]
        subgraph "AZ-a"
            EC2A[EC2-A1]
            EC2B[EC2-A2]
        end
        subgraph "AZ-c"
            EC2C[EC2-C1]
            EC2D[EC2-C2]
        end
        ASG --> EC2A
        ASG --> EC2B
        ASG --> EC2C
        ASG --> EC2D
    end

ステップ3: ロードバランサーの連携

ELBと連携することで、新しく起動したインスタンスが自動的にターゲットグループに登録されます。

ステップ4: グループサイズとスケーリング

graph LR
    subgraph "容量設定の考え方"
        Min[最小容量: 2] --> Desired[希望容量: 4] --> Max[最大容量: 10]
    end

ヘルスチェックの設定

Auto Scalingグループは、インスタンスの正常性を監視し、異常なインスタンスを自動的に置き換えます。

猶予期間が短すぎると、アプリケーションの起動が完了する前にインスタンスが異常と判定され、無限ループに陥る可能性があります。

インスタンス配分戦略

Auto Scalingグループは、AZへのインスタンス配分を自動的に行います。

graph TB
    subgraph "AZ間の均等配分"
        ASG2[ASG<br/>希望容量: 4]
        ASG2 --> AZa[AZ-a: 2台]
        ASG2 --> AZc[AZ-c: 2台]
    end

1つのAZに障害が発生した場合、残りのAZでインスタンスを起動し、希望容量を維持します。

スケーリングポリシー

スケーリングポリシーは、Auto Scalingグループがいつ、どのようにスケールするかを定義します。

ターゲット追跡スケーリングポリシー

ターゲット追跡スケーリングは、指定したメトリクスを目標値に維持するようにインスタンス数を調整します。最も推奨されるスケーリング方式です。

graph TB
    subgraph "ターゲット追跡の動作"
        CW[CloudWatch<br/>CPU使用率] --> Check{CPU > 50%?}
        Check -->|はい| ScaleOut[スケールアウト]
        Check -->|いいえ| Check2{CPU < 50%?}
        Check2 -->|はい| ScaleIn[スケールイン]
        Check2 -->|いいえ| Keep[現状維持]
    end

ターゲット追跡スケーリングポリシーの設定例を示します。

ターゲット追跡の特徴

• CloudWatchアラームを自動的に作成・管理
• スケールアウトとスケールインの両方を自動で実行
• 複数のターゲット追跡ポリシーを組み合わせ可能

ステップスケーリングポリシー

ステップスケーリングは、メトリクスの値に応じて段階的にインスタンス数を調整します。

graph TB
    subgraph "ステップスケーリングの動作"
        CW2[CloudWatch<br/>CPU使用率] --> Step1{40-60%}
        Step1 -->|該当| Action1[変更なし]
        CW2 --> Step2{60-80%}
        Step2 -->|該当| Action2[+2台追加]
        CW2 --> Step3{80%以上}
        Step3 -->|該当| Action3[+4台追加]
    end

ステップスケーリングの設定例（スケールアウト）を示します。

ステップスケーリングの設定例（スケールイン）を示します。

ステップスケーリングの特徴

• 細かい制御が可能
• CloudWatchアラームを手動で作成する必要がある
• スケールアウトとスケールインを別々に定義

シンプルスケーリングポリシー

シンプルスケーリングは、CloudWatchアラームに基づいて単一のスケーリングアクションを実行します。

シンプルスケーリングの制限

シンプルスケーリングには「クールダウン期間」があり、スケーリングアクション実行後は次のスケーリングまで待機が必要です。そのため、急激な負荷変動への対応が遅れる可能性があります。

graph LR
    subgraph "シンプルスケーリングのクールダウン"
        Scale1[スケールアウト] --> Cool[クールダウン<br/>300秒] --> Next[次の評価]
    end

新規の構成では、シンプルスケーリングよりもターゲット追跡スケーリングを推奨します。

スケーリングポリシーの比較

スケジュールされたスケーリング

スケジュールされたスケーリングは、予測可能な負荷変動に対応するために、特定の時間にインスタンス数を変更します。

ユースケース

graph TB
    subgraph "日次パターンの例"
        Morning[朝 9時<br/>スケールアウト<br/>最小: 4台]
        Evening[夜 21時<br/>スケールイン<br/>最小: 2台]
        Morning --> Daytime[日中は高負荷]
        Evening --> Nighttime[夜間は低負荷]
    end

スケジュールされたスケーリングが有効なシナリオを示します。

• 日次パターン: 業務時間帯は高負荷、夜間は低負荷
• 週次パターン: 平日は高負荷、週末は低負荷
• イベント対応: 計画されたキャンペーンやセール期間
• バッチ処理: 定期的なバッチ処理の実行時間帯

スケジュールの設定

Cron式の書式は以下のとおりです。

分 時 日 月 曜日

スケジュールスケーリングとポリシーの組み合わせ

スケジュールスケーリングと動的スケーリングポリシーを組み合わせることで、より効果的なスケーリングが実現できます。

graph TB
    subgraph "組み合わせ戦略"
        Schedule[スケジュールスケーリング<br/>9時: 最小4台に変更]
        Target[ターゲット追跡ポリシー<br/>CPU 50%を維持]
        Schedule --> Base[ベースラインを確保]
        Target --> Dynamic[負荷に応じて調整]
        Base --> Combined[効果的なスケーリング]
        Dynamic --> Combined
    end

この組み合わせにより、以下のメリットが得られます。

• 予測可能な負荷増加に事前対応（スケジュール）
• 予測外の負荷変動にも自動対応（ターゲット追跡）

予測スケーリング

予測スケーリングは、過去のトラフィックパターンを機械学習で分析し、将来の負荷を予測してスケーリングを行います。

予測スケーリングの仕組み

graph LR
    subgraph "予測スケーリングの流れ"
        History[過去14日間の<br/>メトリクス] --> ML[機械学習<br/>モデル]
        ML --> Forecast[48時間先の<br/>負荷予測]
        Forecast --> Action[事前に<br/>スケールアウト]
    end

予測スケーリングの利点

• 先回りのスケーリング: 負荷増加前にインスタンスを準備
• ウォームアップ時間の考慮: インスタンスの起動時間を考慮した事前対応
• 定期的なパターンへの対応: 日次・週次の負荷パターンを自動学習

予測スケーリングを有効にするには、少なくとも1日分の履歴データが必要です。より正確な予測には、2週間以上の履歴データが推奨されます。

インスタンスのウォームアップとクールダウン

スケーリング時のインスタンスの準備期間について理解することが重要です。

ウォームアップ期間

ウォームアップ期間は、新しく起動したインスタンスがメトリクスに含まれるまでの待機時間です。

graph LR
    subgraph "ウォームアップの必要性"
        Launch[インスタンス起動] --> Boot[OS起動<br/>30秒]
        Boot --> App[アプリ起動<br/>60秒]
        App --> Ready[サービス開始<br/>30秒]
        Ready --> Metrics[メトリクス安定<br/>60秒]
    end

ウォームアップ期間中のインスタンスは、スケーリングの判断に使用されるメトリクスから除外されます。これにより、起動直後の不安定な状態がスケーリング判断に影響を与えることを防ぎます。

クールダウン期間（シンプルスケーリング）

クールダウン期間は、シンプルスケーリングポリシーにおいて、スケーリングアクション後に次のスケーリングを待機する時間です。

ターゲット追跡スケーリングとステップスケーリングでは、クールダウンの代わりにウォームアップ期間が使用されます。

インスタンスの終了ポリシー

スケールイン時に、どのインスタンスを終了するかを決定するポリシーです。

終了ポリシーの種類

デフォルト終了ポリシーの順序

デフォルトの終了ポリシーは、以下の順序で適用されます。

graph TB
    subgraph "デフォルト終了ポリシーの順序"
        Step1[1. AZのバランスを確認<br/>インスタンスが多いAZを選択]
        Step2[2. 古い起動設定/テンプレートを選択]
        Step3[3. 次の課金時間に近いインスタンスを選択]
        Step4[4. ランダムに選択]
        Step1 --> Step2 --> Step3 --> Step4
    end

スケールイン保護

特定のインスタンスをスケールインから保護することができます。

保護されたインスタンスは、以下の場合でも終了されません。

• スケールインアクション
• 最大インスタンス数の削減
• インスタンスの更新

ただし、以下の場合は終了されます。

• 手動終了
• ヘルスチェック失敗
• スポットインスタンスの中断

ライフサイクルフック

ライフサイクルフックは、インスタンスの起動または終了時にカスタムアクションを実行するための仕組みです。

ライフサイクルフックの用途

graph TB
    subgraph "起動時のライフサイクルフック"
        Launch2[インスタンス起動] --> Pending[Pending:Wait]
        Pending --> Custom[カスタムアクション<br/>- 設定ファイル取得<br/>- ヘルスチェック確認<br/>- アプリ起動確認]
        Custom --> Complete[CONTINUE]
        Complete --> InService[InService]
    end

graph TB
    subgraph "終了時のライフサイクルフック"
        Term[終了開始] --> TermWait[Terminating:Wait]
        TermWait --> Custom2[カスタムアクション<br/>- ログの退避<br/>- セッションの移行<br/>- 登録解除処理]
        Custom2 --> Complete2[CONTINUE]
        Complete2 --> Terminated[Terminated]
    end

ライフサイクルフックの設定

ライフサイクルフックとの連携サービス

インスタンスの更新

Auto Scalingグループ内のインスタンスを新しい設定で更新する方法を説明します。

インスタンスの更新方法

インスタンスの更新（ローリングアップデート）

インスタンスの更新機能を使用すると、ダウンタイムを最小限に抑えながらインスタンスを更新できます。

graph LR
    subgraph "ローリングアップデートの流れ"
        Start[更新開始] --> New1[新インスタンス1起動]
        New1 --> Health1[ヘルスチェック]
        Health1 --> Old1[旧インスタンス1終了]
        Old1 --> New2[新インスタンス2起動]
        New2 --> Repeat[繰り返し...]
        Repeat --> Complete3[完了]
    end

Auto ScalingとELBの連携設定

Auto ScalingとELBを連携させることで、トラフィックの自動分散と自動スケーリングを実現します。

連携の仕組み

graph TB
    subgraph "Auto Scaling + ELB連携"
        Internet[インターネット] --> ALB[ALB]
        ALB --> TG[ターゲットグループ]
        TG --> ASG3[Auto Scalingグループ]
        
        ASG3 -->|新規起動| New[新インスタンス]
        New -->|自動登録| TG
        
        ASG3 -->|終了| Old[終了インスタンス]
        Old -->|自動登録解除| TG
        
        CloudWatch2[CloudWatch] -->|スケーリング判断| ASG3
    end

連携時の設定ポイント

Connection Draining

インスタンスの終了時、既存の接続を適切に処理するためにConnection Draining（登録解除の遅延）を設定します。

graph LR
    subgraph "Connection Drainingの流れ"
        Terminate[スケールイン開始] --> Draining[Draining状態<br/>新規リクエスト停止]
        Draining --> Wait[既存接続の完了待ち<br/>最大300秒]
        Wait --> Complete4[インスタンス終了]
    end

Auto Scalingのベストプラクティス

Auto Scalingを効果的に活用するためのベストプラクティスを紹介します。

容量設計

スケーリングポリシー

高可用性

graph TB
    subgraph "高可用性構成の推奨"
        ASG4[Auto Scalingグループ]
        ASG4 --> AZ1[AZ-a: 2台以上]
        ASG4 --> AZ2[AZ-c: 2台以上]
        ASG4 --> AZ3[AZ-d: 2台以上]
    end

コスト最適化

まとめ

本記事では、Amazon EC2 Auto Scalingの基本概念から、起動テンプレート、Auto Scalingグループ、各種スケーリングポリシーまでを解説しました。

重要なポイントをまとめます。

• Auto Scalingの目的: 可用性向上、コスト最適化、運用負荷軽減を実現
• 起動テンプレート: インスタンス設定の設計図、バージョン管理が可能
• Auto Scalingグループ: 最小/最大/希望容量でインスタンス数を制御
• ターゲット追跡スケーリング: 最も推奨されるスケーリング方式
• スケジュールスケーリング: 予測可能な負荷変動に事前対応
• ELB連携: ヘルスチェックと自動登録/登録解除で高可用性を実現

Auto ScalingとELBを組み合わせることで、負荷に応じて自動的にスケールする高可用性なシステムを構築できます。次回の記事では、CloudWatchによるAWSリソースの監視について解説します。

参考リンク

• Amazon EC2 Auto Scaling とは - AWS ドキュメント
• Auto Scaling グループ - AWS ドキュメント
• 起動テンプレート - AWS ドキュメント
• ターゲット追跡スケーリングポリシー - AWS ドキュメント
• スケジュールされたスケーリング - AWS ドキュメント
• Amazon EC2 Auto Scaling の料金