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 つのステップ調整値のみ、下限を null (負の無限大) にすることができます。下限が負のステップ調整値がある場合は、下限が null のステップ調整値が必要です。
- 1 つのステップ調整値のみ、上限を null (正の無限大) にすることができます。上限が正のステップ調整値がある場合は、上限が null のステップ調整値が必要です。
- 同じステップ調整値で上限と下限を null にすることはできません。
- メトリクス値が超過しきい値を上回っている場合、下限にその値を含み、上限には含みません。メトリクス値が超過しきい値を下回っている場合、下限にその値を含まず、上限に含みます。
やっぱり文字だけだとよくわからないので、図で見ることにします。
上記の例では、以下のようなポリシーになっています。
・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」を下限に入れた場合でも、
「負の無限大」を下限とするステップが自動的に追加されます。
ルール4
4.同じステップ調整値で上限と下限を null にすることはできません。
「同じステップ調整値」というよりは
「同じスケーリングポリシー」と捉えるのが正しいと思っています。
基準となる値に対して、相対的に「正となる値」と「負となる値」を
同じポリシーに入力することはできません。
※スケールアップの場合は下限が「基準となる値」以上、
スケールインの場合は上限が「基準となる値」以下である必要があるため。
ルール5
メトリクス値が超過しきい値を上回っている場合、下限にその値を含み、上限には含みません。メトリクス値が超過しきい値を下回っている場合、下限にその値を含まず、上限に含みます。
スケールアウトの場合：<下限>は「～以上」で<上限>は「～より小さい」で考える
スケールインの場合：<上限>は「～以下」で<下限>は「～より大きい」で考える
というだけの話です。
先程の例で言えば、
（ステップ1）55以上で77より小さい場合、11台追加する
（ステップ2）77以上で88より小さい場合、22台追加する
（ステップ3）88以上の場合、33台追加する
評価された値が「77」であった場合、
ステップ1ではなくステップ2のアクションが取られる、ということです。
だいぶまわりくどくやってきましたが、
流石にそろそろ終わります。
次にようやく「ウォームアップってどういう挙動？」というのを書きます。
以上です。
