EC2 Auto Scalingとは
EC2 Auto Scalingを用いることで、アプリケーションの負荷を処理するための適切な数のEC2インスタンスを利用することができる、。Auto Scalingを利用するためには、Auto Scalingグループと呼ばれるEC2インスタンスの集合を定義し、このグループに含まれる最小と最大のインスタンスの数を定義する。また、希望するインスタンス数（Desired capacity）を定義することも可能。また、Auto Scalingグループ内のEC2インスタンスを複数のAZに分散配置することで、地理的な冗長性や安全性を実現できる。
Auto Scalingを用いることで、耐障害性や可用性が向上する。また、必要な数のインスタンスのみ起動されるため安定的なパフォーマンスを低コストで実現することができる。
Auto Scalingグループ内の各EC2インスタンスの負荷に偏りが発生した場合は、古いインスタンスを終了して新しいインスタンスを起動させる。この場合にスムーズに処理が継続されるように、一時的に最大容量に対して10%のマージンが確保される。
ライフサイクル
Auto Scalingのライフサイクルは以下の通り。
Auto Scalingグループはグループ内のインスタンスに対して定期的にヘルスチェックを行なっている。スケールイン/アウトは、手動もしくはスケーリングポリシーやスケジュールに基づき実行される。スケールイン、ヘルスチェックの失敗、Auto Scalingグループからの離脱等が発生した場合には、Auto Scalingグループ内のEC2インスタンスは終了処理が実施される。
Auto Scalingグループ
起動設定
Auto Scalingグループ内のEC2インスタンスは、起動テンプレートもしくは起動設定の設定内容に基づいて起動される。これらには、AMIのIDやインスタンスタイプ、ネットワーク設定、ストレージの設定、オンデマンドインスタンスとスポットインスタンスの配分等が含まれる。また、起動設定は、既に起動済みのインスタンスの属性を使用して作成することも可能である。Auto Scalingグループに関連付けられる起動設定は1つだけであり、グループ作成後に変更することはできない。Auto Scalingグループに関連づける起動設定を変更する場合は、現在の起動設定をコピーした上で新たな起動設定を作成し、これを当該のAuto Scalingグループに紐づける。
ロードバランサとの連携
Auto Scalingで増減したインスタンスに対して適切にトラフィックが分散されるようにするためには、Elastic Load Balancingの受信トラフィックの通信先にAuto Scalingグループを指定する。Auto Scalingのヘルスチェックは、通常EC2のステータスチェックのみであるが、オプションでELBのヘルスチェックを用いてAuto Scalingグループのヘルスチェックを行う設定にすることも可能である。この場合、ELBから送られる定期的なPINGに応答しないなど、ELBのヘルスチェック合格しなかった場合、このインスタンスは異常ありと判定されて他のインスタンスに置き換えられる。
スケーリング
Auto Scalingでは、以下のスケーリング方法を実施可能である。
- 現在のインスタンスレベルの維持
- 手動スケーリング
- スケジュールに基づくスケーリング
- 要求に基づくスケーリング（動的スケーリング）
CloudWatchのメトリクスを利用して複数のスケーリングポリシーを適用することも可能である。例えば、EC2のCPU使用率を指標としたポリシーと、SQSのメッセージ処理に関するメトリクスを指標としたポリシーを同時に適用する、といったような場合である。複数のポリシーが適用となった場合は、より影響を与えるポリシーの実行命令が優先される。
スケジュールされたスケーリング
あらかじめ指定したスケジュールに沿って、スケーリングアクションが実行されるように指定することが可能である。スケーリングアクションが有効になる時間と、最小/最大サイズ、希望するサイズを指定する。このスケジュールは、1回のみ実行することも定期的に実行することもできる。
スケジュールされたスケーリングを作成する場合、ほとんどの場合指定した時刻から数秒以内に実行されるが、最大2分ほど遅れる可能性もあるので留意が必要である。また、複数のスケジュールを同時刻に設定することはできない。
動的スケーリング
動的スケーリングは、以下の方法をサポートしている。
| ポリシー名 | トリガおよび動作 |
|---|---|
| Target tracking scaling | 特定のメトリクスのターゲット値を維持するようにスケーリング |
| Step scaling | 複数のスケーリング調整値をトリガにスケーリング |
| Simple scaling | 1つのスケーリング調整値をトリガにスケーリング |
Simple scaling および Step scaling
トリガに基づいてスケーリングが実行される際には、以下の調整タイプに基づいてスケーリングが実行される。
| 調整タイプ | 動作 |
|---|---|
| ChangeInCapacity | 指定した数だけ増減する |
| ExactCapacity | 指定した数になるように増減する |
| PercentChangeInCapacity | 割合指定する |
また、Step scalingの場合は、新しく起動されたインスタンスがAuto Scalingグループに追加されるまでの待ち時間（ウォームアップ）を指定できる。
SQSに基づくスケーリング
SQSにキューが積み上がり、処理が遅延することがないようにするには、 SQSのデータを読み取り処理を行うEC2をAuto Scalingさせる必要がある。このAuto Scalingを適切にスケーリングさせるためには、 Amazon SQS メトリックスApproximateNumberOfMessagesを用いてキューの長さを測定した上で、1インスタンスあたりの処理能力を計算しどの程度スケーリングさせる必要があるか指定する。
クールダウン
メトリクス値が短期間で増減し、その度にスケーリングが実行されることを防ぐために、クールダウン期間が設けられている。デフォルトのクールダウン値は300秒。クールダウン期間は新たなスケーリングは実行できない。なお、このクールダウンが有効なのは、Simple scalingのみ。
インスタンスの停止
スケールイン時に停止されるインスタンスは以下の条件で決定される。
- インスタンスが最も多いAZ
- 最も古い起動設定またはテンプレートを使用している
- 次の課金開始時間に近いインスタンス
終了時ポリシーはカスタマイズが可能である。また、終了から保護するインスタンスを指定することもできる。
| ポリシー名 | 実行内容 |
|---|---|
| OldestInstance | 最も古いインスタンス |
| NewestInstance | 最も新しいインスタンス |
| OldestLaunchConfiguration | 最も古い起動設定のインスタンス |
| ClosestToNextInstanceHour | 次の課金開始時間に近いインスタンス |
| Default | デフォルト（上記） |
| OldestLaunchTemplate | 最も古い起動テンプレート |
| AllocationStrategy | オンデマンド/スポットの割り当て戦略に合わせて決定 |
ライフサイクルフック
インスタンスの起動時もしくは削除時に一時停止して、カスタムアクションを実行できる機能。ソフトウェア等をインストールできる。
スケーリングプロセスの中断と再開
スケーリングプロセスの1つ以上を停止し、あとで再開できる。
| スケーリングプロセス | 内容 |
|---|---|
| Launch | インスタンスを追加 |
| Terminate | インスタンスを削除 |
| HealthCheck | ヘルスチェック |
| ReplaceUnhealthy | 異常なインスタンスを削除し代替インスタンスを作成 |
| AZRebalance | AZ間のバランスを調整 |
| AlarmNotification | CloudWatchからアラーム通知を受け取る |
| ScheduledActions | スケジュールされたアクションを実施 |
| AddToLoadBalancer | ELBに追加 |
注意事項
Auto Scalingは、バーストトラフィックには対応できない。
