batchiです。
まわりくどくやってきましたがようやく終わります。
自分でもあまり見返す気がしないくらい遠回りしてきました。
でもユリウスとかいう人が言っていた気がします。
『一番の近道は遠回りだった』
『遠回りこそが俺の最短の道だった』
はい。
[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①
同上②
同上③
同上④
同上⑤
ウォームアップとはなんぞや、という部分を書きます。
7.ウォームアップ
参照するドキュメントは以下のあたり。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-scaling-simple-step.html#as-step-scaling-warmup
そして2017年7月現在書いてあることは以下がすべてです。
ステップスケーリングポリシーでは、新しく起動されたインスタンスのウォームアップにかかる秒数を指定できます。その指定されたウォームアップ期間が終了するまで、インスタンスは Auto Scaling グループの集合メトリクスの対象になりません。
スケールアウト時、Auto Scaling はグループの現在の容量の一部としてウォームアップ中のインスタンスは対象にしません。したがって、複数のアラーム超過によってもステップ調整値の範囲は変わらず、1 つのスケーリングアクティビティという結果になります。これにより、必要以上の数のインスタンスが追加されることがなくなります。先ほどのセクションの例で、新しいインスタンスのウォームアップの最中に、メトリクスが 60 になり、さらに 62 になったとします。現在の容量がまだ 10 であるため、Auto Scaling は 1 インスタンス（10 インスタンスの 10%）を追加する必要がありますが、グループの必要な容量はすでに 11 インスタンスなので、Auto Scaling は必要な容量をさらに増やしません。ただし、新しいインスタンスのウォームアップの最中にメトリクスが 70 になった場合、Auto Scaling は 3 インスタンス（10 インスタンスの 30%）を追加する必要がありますが、グループの必要な容量はすでに 11 なので、Auto Scaling は 2 つのインスタンスのみを追加し、新しい必要な容量は 13 インスタンスになります。
スケールイン時、Auto Scaling はグループの現在の容量の一部として終了中のインスタンスを対象にします。したがって、Auto Scaling グループから必要以上の数のインスタンスが削除されることがなくなります。
スケールアウトアクティビティの進行中、スケールインアクティビティを開始することはできません。
ちょっと飲み込むのに時間がかかりそうですね。
とはいえ、上記で少し色を薄くしている部分は例が書いてあるだけです。
それを除くと、大したことは書かれていないことがわかります。
#第④回と同じく、ここでも以下の呼称を用いることにします。
・「希望する容量」「必要な容量」…『Desired Capacity』
・「現在の容量」…『Current Capacity』
スケールアウト/スケールイン共通
・ウォームアップが完了するまでAuto Scalingグループの「Current Capacity」は変動しない
スケールアウトの場合
・ウォームアップが完了するまでスケール対象のインスタンスは集合メトリクスの対象とならない
・スケールアウトアクティビティ中にスケールインアクティビティは開始されない
7.1.ウォームアップ挙動の例
ドキュメントに従い数字を用いた例を見ていきます。
以下のスケールアウトポリシーが設定されている前提で考えます。
・Current Capacityは10（台）
・Auto Scalingグループ配下のインスタンスからメトリクス値を集約する
・集約メトリクス値が以下の値をとった場合に以下アクションを行う
（ステップ1）60以上70未満の場合、10%分の台数を増加させる
（ステップ2）70以上の場合、30%分の台数を増加させる
このステップではスケーリング調整タイプとして
「PercentChangeInCapacity」が指定されています。
PercentChangeInCapacityで基準となる値は、
「変更前のDesired Capacity」というか、「Current Capacity」です。
そして、一区切りのウォームアップの期間内に、下記の値を順番に取った場合を考えます。
・60（ステップ1に該当）
・62（ステップ1に該当）
・70（ステップ2に該当）
| 値が60の時 | 値が62の時 | 値が70の時 | |
| Current Capacity | 10 | 10※1 | 10※1 |
| Desired Capacity | 11 （10台の10%増加)） |
11 （10台の10%増加)） |
13 （10台の30%増加)） |
※1…ウォームアップ中は増加しないため10のまま
ウォームアップという概念が存在しない場合を考えます。
| 値が60の時 | 値が62の時 | 値が70の時 | |
| Current Capacity | 10 | 11 | 12 |
| Desired Capacity | 11 （10台の10%増加)） |
12 （11台の10%増加※2)） |
15 （12台の30%増加※2)） |
※2…小数点切り捨て
スケールアウトにより1台増加しても、
すぐさま負荷の分散先として機能するわけではありません。
インスタンスが立ち上がって、
OS、サービスが立ち上がって、
ELB配下に組み込まれて、
負荷の分散先として機能するまでの時間。
その時間をウォームアップとして設定しておくことによって、
過剰なインスタンスのスケールを防ぐことができます。
おわりに：結局クールダウンとウォームアップの違いって？
長々とやってきましたが、結局は以下のような違いと捉えています。
例のごとくスケールアップの場合のみを例とします。
スケールインの場合は適宜読み替えてください。
クールダウンの場合
・手動スケーリングもしくはシンプルスケーリングポリシーに対応
・Desired Capacityの増加にあわせて待機無しでCurrent Capacityが増加
・スケールしたインスタンスは集約メトリクスの対象となる
・クールダウン中のアラート検知をトリガーとしたスケーリングは実施しない
ウォームアップの場合
・ステップスケーリングポリシーに対応
・Desired Capacityの増加後、ウォームアップ期間分待機してからCurrent Capacityが増加
・スケールしたインスタンスはウォームアップ完了まで集約メトリクスの対象とならない
・ウォームアップ中のアラート検知は変更前のCurrent Capacityを基準に判断される
というわけでクールダウンとウォームアップの違いについてでした。
書いてる最中（2017年7月）に、
動的スケーリングのポリシーの種類が増えたときはどうしようかと思いましたが、
いったん見ないことにすると決めました。
・シンプルスケーリングポリシー
・ステップスケーリングポリシー
・ターゲットトラッキングポリシー New!
追って新しいポリシーを確認します。
ひとまず以上です。
