AWSのITコストを削減 Simpline

選ばれ続けること

 

エンジニアブログ

ホーム - エンジニアブログ - 2017年7月

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する(終)

2017.07.21

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!

追って新しいポリシーを確認します。
ひとまず以上です。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する⑤

2017.07.07

batchiです。
まわりくどさがかなり煮詰まってきました。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①
同上②
同上③
同上④

スケーリング調整タイプの説明が終わったので、
ステップ調整値とはなんぞや、というところからです。

参照するドキュメントは以下のあたり。

http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-scaling-simple-step.html#as-scaling-steps

スケーリング調整タイプは、
シンプルスケーリングポリシーでも
ステップスケーリングポリシーでもあてはまる概念でした。

ステップ調整値はステップスケーリングポリシー独自の概念です。

6.ステップ調整値


ステップ調整値とはなんぞや。
ドキュメントによれば以下の通りです。
ステップスケーリングポリシーを作成するときは、アラーム超過のサイズに基づいてスケールできるようにする 1 つ以上のステップ調整値を追加します。各ステップ調整値には、スケーリング調整タイプに基づいて、メトリクス値の下限、メトリクス値の上限、スケールする量を指定します。

ドキュメントで文字だけを追っていると読む気が失せてくるので、
実際にポリシーの設定画面で確認します。

ステップ調整値

↑この赤枠で囲ったものがステップ調整値です。
この例ではステップを2段階で設定しています。

スケーリング調整タイプ

↑ちなみに青枠で囲っているのが前回の記事で記載した「スケーリング調整タイプ」です。
この例では「5.2.1ChangeInCapacity」を指定しています。

「5.2.2.ExactCapacity」を指定したい場合は、
「追加」としているところを「設定」に変更します。

「5.2.3.PercentChangeInCapacity」を指定したい場合は、
「インスタンス」しているところを「%(グループ中)」に変更します。

6.1.ステップ調整値のルール


ステップ調整値には以下のルールがあります。

  1. ステップ調整値の範囲に重複や間隔があってはなりません。

  2. 1 つのステップ調整値のみ、下限を null (負の無限大) にすることができます。下限が負のステップ調整値がある場合は、下限が null のステップ調整値が必要です。

  3. 1 つのステップ調整値のみ、上限を null (正の無限大) にすることができます。上限が正のステップ調整値がある場合は、上限が null のステップ調整値が必要です。

  4. 同じステップ調整値で上限と下限を null にすることはできません。

  5. メトリクス値が超過しきい値を上回っている場合、下限にその値を含み、上限には含みません。メトリクス値が超過しきい値を下回っている場合、下限にその値を含まず、上限に含みます。


やっぱり文字だけだとよくわからないので、図で見ることにします。

ステップ調整値ルール

上記の例では、以下のようなポリシーになっています。

・cloudwatchアラーム「test-alarm」の値をトリガーとしてスケーリングする
・「test-alarm」はAuto Scalingグループ配下のインスタンスのCPU使用率(%)を集約した値を検出している
・「test-alarm」は300秒ごとの平均の値を評価する
・「test-alarm」により評価された値が以下の条件にあてはまった場合、ステップに応じたアクションをとる
 ・55以上で77より小さい場合、11台追加する
 ・77以上で88より小さい場合、22台追加する
 ・88以上の場合、33台追加する

それを踏まえて各ルールを見ていきます。

ルール1

1.ステップ調整値の範囲に重複や間隔があってはなりません。

以下のような設定はできません、という意味です。

(ステップ1)55以上で77より小さい場合、11台追加する
(ステップ2)74以上で88より小さい場合、22台追加する ←ステップ1と重複している
(ステップ3)90以上の場合、33台追加する ←ステップ2と間隔がある

マネジメントコンソールで設定する場合、
上限を入力すると自動的に次のステップの下限が入力されるので、
そもそもこのルールに違反する設定のしようがありません。

ルール2,3


2.1 つのステップ調整値のみ、下限を null (負の無限大) にすることができます。下限が負のステップ調整値がある場合は、下限が null のステップ調整値が必要です。
3.1 つのステップ調整値のみ、上限を null (正の無限大) にすることができます。上限が正のステップ調整値がある場合は、上限が null のステップ調整値が必要です。


先述の例で言うと、(ステップ2)の上限として正の数字である「88」を指定した時点で、
自動的に「正の無限大」を上限とするステップが追加されます。

簡単に言えば、そういうことです。

ここでいう「正負」は基準となる値に対する相対的なものだと捉えるといいでしょう。
(上の例では「55」が基準となる値)

スケールインポリシーで、絶対値としては正の数である「33」を下限に入れた場合でも、
「負の無限大」を下限とするステップが自動的に追加されます。

ステップ調整値ルール2

ルール4


4.同じステップ調整値で上限と下限を null にすることはできません。

「同じステップ調整値」というよりは
「同じスケーリングポリシー」と捉えるのが正しいと思っています。

基準となる値に対して、相対的に「正となる値」と「負となる値」を
同じポリシーに入力することはできません。

※スケールアップの場合は下限が「基準となる値」以上、
 スケールインの場合は上限が「基準となる値」以下である必要があるため。

ルール5

メトリクス値が超過しきい値を上回っている場合、下限にその値を含み、上限には含みません。メトリクス値が超過しきい値を下回っている場合、下限にその値を含まず、上限に含みます。


スケールアウトの場合:<下限>は「~以上」で<上限>は「~より小さい」で考える
スケールインの場合:<上限>は「~以下」で<下限>は「~より大きい」で考える

というだけの話です。

先程の例で言えば、

(ステップ1)55以上で77より小さい場合、11台追加する
(ステップ2)77以上で88より小さい場合、22台追加する
(ステップ3)88以上の場合、33台追加する

評価された値が「77」であった場合、
ステップ1ではなくステップ2のアクションが取られる、ということです。




だいぶまわりくどくやってきましたが、
流石にそろそろ終わります。

次にようやく「ウォームアップってどういう挙動?」というのを書きます。
以上です。