はじめに
Auto Scalingにいくつか種類があるのを知らなかったのでまとめてみたいと思います。。
概要
安定した予測可能なパフォーマンスを可能な限り低コストで維持するためにアプリケーションをモニタリングし、容量を自動で調整するサービスのこと。
コスト最適化のために、需要に基づいてインスタンスを追加及び削除を行う
⇒閾値の設定をちゃんとすればサーバーダウンを起こすことなくスケーリングを行ってくれる
- 単一の直感的なインターフェイスで複数のAWSリソースに対するターゲット使用率レベルを設定することができる
- 異なるAWSリソースのグループが需要の変化に対応する方法を自動化するスケーリングプランを構築することができる
- アプリケーションの継続的な監視と最適なパフォーマンスレベルを維持する
- 需要の増加に応じて、リソースの容量を自動的に増加させる
実行時の挙動
実行されるとAZに適切に分散されるようにインスタンス数が調整される。最も少ないAZでインスタンスを起動し、起動に失敗した場合成功するまで別AZで起動を行う
・もしアンバランスが発生したら??
AZ間でインスタンス数の不均衡があった場合、原因となるインスタンスを停止し、リソースが不足していたAZに新規インスタンスを起動するといった再分散の調整が行われる。
古いインスタンスを終了する前に新しいインスタンスを起動することで、パフォーマンス低下を防ぐ。最大容量に近づくと再分散処理が遅くなってしまい、完全に停止する可能性がある。これを回避するために一時的に10%または+1の容量を追加し最大容量を増やす。
Auto Scalingの種類
Application Auto Scaling
EC2以外の個々のAWSサービスの自動的にスケーリングする。
- Auroraレプリカ
- DynamoDBテーブルとグローバルセカンダリインデックス
- ECS(Elastic Container Service)サービス
- ElastiCache for Redisクラスター
- EMRクラスター
- Neptuneクラスター
- スポットフリートリクエスト
など
スケーリングの種類
手動スケーリング
Auto Scalingグループのサイズの希望する容量を手動で変更しスケーリングする
動的スケーリング
トラフィックの変化に応じてスケーリングする方法で以下3種類が存在する
簡易スケーリング
EC2 Auto Scalingのみ使用可能が、基本的に推奨されていない方法。1つのメトリクスに対して1種類だけの調整値に基づいてスケーリングする。
ステップスケーリング
利用可能:EC2 AutoScaling,Applicaton Auto Scaling
複数のスケーリングの調整の値(ステップ調整値)に基づいてスケーリングする方法。例えば、CPU使用率が50%以下になったら1台減らす、60%以上なら1台追加など。
ターゲット追跡スケーリング
利用可能:EC2 AutoScaling,Applicaton Auto Scaling
メトリクスおよびターゲットの値を決めると、その値を維持しようとスケーリングする方法。例えば、CPU使用率が60%に維持するようにEC2をスケーリングするなど。
予測スケーリング
利用可能:EC2 AutoScalingのみ
トラフックの増減する規則的なパターンがあるときに利用する。日時や週次などの特定の期間になったらスケーリングする。例えば、毎週月曜日13時になったら2台追加するなど
スケジュールスケーリング
利用可能:EC2 AutoScaling,Applicaton Auto Scaling
一度限り、もしくは定期的なスケジュールを指定可能。
キャパシティ制限
-
Desired capacity(希望するキャパシティ)
Auto Scalingグループ作成時の初期キャパシティを表す。希望するキャパシティに指定された数のインスタンスを起動。スケーリングポリシーまたはスケジュールされたアクションがアタッチされていない限り、このインスタンス数が維持される。
数値を変更することで手動でスケーリングさせることも可能 -
Minimum capacity(最小キャパシティ)
最小グループサイズを表す。設定されている限り、希望するキャパシティを最小サイズ制限よりも小さくすることはできない。 -
Maximum capacity(最大キャパシティ)
最大グループサイズを表す。設定されている限り、希望するキャパシティを最大サイズ制限よりも大きくすることできない。
ウォームアップとクールダウン
-
クールダウン
Auto Scalingが発動した直後、インスタンスの増減がされることを防ぐ設定。現在では簡易スケーリングのための設定として使用され、それ以外のスケーリングポリシーではデフォルト設定(300秒)のままで問題なし。
ステップスケーリングの場合、しきい値に達した場合クールダウンと関係なく反応する
クールダウン期間中は前のスケーリングタスクを完了させる前にインスタンスを停止させない
・クールダウン以外の例外
- クールダウン中mスケジュールされた時間に開始されるか、ターゲット追跡またはステップスケーリングポリシーによりスケーリングアクティビティが開始されると、クールダウン終了待たずにそれらが実行される。
- インスタンスが正常でなくなった場合、EC2 Auto Scalingはクールダウンの完了を待つことなく異常のあるインスタンスに置き換わる
-
ウォームアップ
新しいインスタンスを段階的に差分で追加するための機能。サービス開始できるようになるまでに何秒要するのかを設定する。デフォルトで300秒が設定されている。
ライフサイクルフック
Auto Scalingグループによるインスタンスの起動時または削除時にインスタンスを一時停止してカスタムアクションを実行することが出来る。
ヘルスチェック
Auto Scalingによって起動されたインスタンスに対して定期的に行われている。
サービス | 内容 |
---|---|
EC2タイプ | ステータスがrunning以外の場合、またはシステムステータスがimpairedの場合に異常と判断する。デフォルト時に有効化になっている |
ELBタイプ | インスタンスのステータスチェックとELBのヘルスチェックからインスタンスの状態を判断する。チェックを行うにはEC2タイプから変更しなければならない |
Termination Policy
Auto Scalingでスケールインが発生したときに、どのインスタンスを終了させるかを決めるもの。「どのインスタンスを残し、どのインスタンスを消すか」は、スケールアウト・スケールインの利用目的によって異なる。
項目名 | 内容 |
---|---|
Oldest Instance | もっとも古いインスタンスから順番に終了 |
Newest Instance | 最も新しい起動時刻のインスタンスから終了 |
Oldest Launch Configuration | 最も古い起動設定により起動しているインスタンスから終了 |
Close To Next Instance Hour | 次の課金が始まるタイミングが最も近いインスタンスから終了 |
デフォルト状態の場合は、下記の図の流れで終了するインスタンスが選ばれる
参考