AWSのITコストを削減 Simpline

選ばれ続けること

 

エンジニアブログ

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

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

2017.05.26

batchiです。

前回はスケーリングプランの種類についておさえました。
[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①

それぞれのスケーリングポリシーに関わるクールダウン/ウォームアップを整理する前に、
クールダウンの中にも種類があるよ、というところから始まります。

2.クールダウンの種類


参照するのはこのあたりです。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/Cooldown.html

クールダウンとは、簡単に言えば、
過剰にスケールさせないために設ける待機時間です。

例えば、「負荷が高まってきたので1台追加した」となっても、
その1台がすぐに負荷の分散先として機能してくれるわけではありません。

インスタンスが作成されて、そのOS上でサービスが起動して…
となるまでは、負荷は高いままとなります。

そこの時間を踏まえないと、1台追加して「まだ負荷高い!もう1台追加しなくては!」となり、
さらなる1台もすぐには準備が整わないので「さらにもう1台!」となり、
すべての追加分のインスタンスが準備万端となったころには
過剰な台数が稼働している…となりかねません。

それを避けるためにクールダウンがあります。

クールダウンには、以下の2種類があります。

・デフォルトのクールダウン
・スケーリング固有のクールダウン

2.1.デフォルトのクールダウン


AutoScalingグループ作成時に設定する項目です。
ここをブランクにすることはできません。

よって、すべてのAutoScalingグループは、
1つの「デフォルトのクールダウン」の値を持ちます。

「デフォルトのクールダウン」のデフォルト値は300秒です。ややこしいですね。

「デフォルトの」っていうことはデフォルトでないクールダウンもあるわけでして、
それが次に説明する「スケーリング固有のクールダウン」です。

2.2.スケーリング固有のクールダウン


特定のスケーリングプランを取る時に、
デフォルトのクールダウンの値を上書き(オーバーライド)することができます。

デフォルトのクールダウンはAutoScalingグループに対して設定していましたが、
スケーリング固有のクールダウンはスケーリングプランごとに設定します。
(具体的には、シンプルスケーリングポリシーか、手動スケーリングアクション)

スケーリング固有のクールダウンは、
オプション的な位置づけで、指定は必須ではありません。

指定しなかった場合はデフォルトのクールダウンの値が採用されることになるんですね、
と理解したくなりますが、少しだけ違います。
スケーリングプランによります。

はじめに「特定のスケーリングプラン」と書きましたが、
スケーリング固有のクールダウンが関わるのは、
「手動スケーリング」か「シンプルスケーリングポリシーによる動的スケーリング」のどちらかです。

2.2.1.手動スケーリングの場合


ここでスケーリング固有のクールダウンを指定しないと、
クールダウンそのものが無視されます。

デフォルトのクールダウンは手動スケーリングにサポートされていないためです。

スケーリング固有のクールダウンを指定した時のみ、
クールダウン期間分の待機が実施されます。

#この場合も「オーバーライド」というのが正しいのか不明です。
#CLIによる手動スケーリングの時だけしかスケーリング固有のクールダウンを指定出来ない気がします。

2.2.2.シンプルスケーリングポリシーによる動的スケーリング


ここでは、スケーリング固有のクールダウンを指定しない場合、
デフォルトのクールダウンの値が採用されます。
これは分かりやすいですね。

スケーリング固有のクールダウンを指定すればそちらが採用される、
すなわちオーバーライド、というのも分かりやすいです。

* * * *

クールダウンの種類が判明しましたので、
次回はそれを踏まえてスケーリングプランごとの
「デフォルトのクールダウン/スケーリング固有のクールダウン/ウォームアップ」の関連を整理したいと思います。

進み方がまわりくどいですね。
こちらからは以上です。

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

2017.05.12


2017年7月に新たなポリシーが追加されたので、若干事情が変わりました。
[Auto Scaling]いつのまにか増えていたターゲットトラッキングポリシーを理解する





batchiです。

Auto Scalingをいじっていると、クールダウンという言葉をよく目にします。
それとは別に、ウォームアップという言葉もあります。

え?何が違うの?
冷やしたらいいのか温めたらいいのかどちらですか?

…と、なった時に一度調べたのですが、
久しぶりに思い出そうとしたらまったく思い出せなかったので、
改めて調べて記します。

結論のようなもの


・冷やすのと温めるのは同時にはできません
・冷やすか温めるかはスケーリングプランないしポリシーによって決定されます
・温める機会があるのはステップスケーリングポリシーを選択したときだけです
・デフォルトのクールダウンって何、と思ったらメインルートテーブルを思い出そう
・温める動作の意味が分からなかったらdesired capacityとcurrent capacityを意識しよう

この結論に至るまで、まわりくどく寄り道をして記していきます。

1.スケーリングプラン


「Auto Scalingによってインスタンスが増えます減ります」という動作を、
どのように実現しましょうか、という方法(プラン)は、いくつか種類があります。

参考にするドキュメントは以下のあたりです。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/scaling_plan.html#scaling_typesof

1.1.インスタンス数の維持


指定したインスタンス数を維持しようとするスケーリング動作です。
この「インスタンス数」にカウントされるのは、正常なインスタンスだけです。

なので、インスタンスに異常が検知された場合には、
そのインスタンスを削除し、
新たな正常なインスタンスを起動することでインスタンス数を維持します。

何をもって異常とするかは、ヘルスチェックの設定によります。
デフォルトでは、EC2インスタンスのステータスのみを評価します。
 
******長い脱線開始*****

EC2インスタンスのステータスってどこのこと指してます?
ドキュメントを見ましょう。

インスタンスステータスが running 以外の状態の場合、またはシステムステータスが impaired である場合は、Auto Scaling はインスタンスを異常ありと見なし、代わりのインスタンスを起動します。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-maintain-instance-levels.html#determine-instance-health


こういったドキュメントとかコンソール画面の日本語は、
ひっかかりやすいのでうっかりすると間違いそうですね。

まず「インスタンスステータス」とは、
マネジメントコンソールで「インスタンスの状態」と表示されている部分のことです。

'running'と記載があるのでイメージはしやすいですね。

running以外は異常ありとみなすので、
うっかり「停止」を押して「stopping」状態になると、瞬く間に削除されます。

次に「システムステータス」とは何を表しているか。

「2/2のチェックに合格しました」でおなじみのステータスチェック。
内訳を見ると以下の2つがある。

①システムステータスのチェック
②インスタンスステータスのチェック

※②で「インスタンスステータス」という言葉が出てくるのが紛らわしいですが、
'running'とか表示される「インスタンスの状態」とは別物です。

「システムステータス」って要は①のことでしょ、と思っていたら、違いました。
①②の結果によって「システムステータス」が決定される、でした。

ステータスチェックは 1 分ごとに実行され、それぞれ成功または失敗のステータスを返します。すべてのチェックが成功すると、インスタンス全体のステータスが OK になります。1つ以上のチェックが失敗すると、全体のステータスが impaired になります。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html?icmpid=docs_ec2_console


①②両方とも成功するとシステムステータスは「OK」になる。
①②いずれかが失敗するとシステムステータスは「impaired」になる。

そういうことでした。

同じことを言っててもドキュメントやコンソール画面で言い回しが違ったりするので、
惑わされず「ここでいうこれは何を指してるんだろう」というのを正確に読み取るのは大事ですね。

******長い脱線終了*****
 
ここまで述べたEC2のステータスに加えて、
ELBによるヘルスチェックの結果もAuto Scalingグループによる評価対象に加えることができます。
(Inservice/OutOfserviceと表示されるアレです)

このスケーリングプランを利用して、
障害が発生しても自動回復させよう、という試みを俗にAuto healingと言いますね。

1.2.手動スケーリング


手動で稼働させる台数を指定し、スケールアウトないしスケールインを実施します。
Auto Scalingなのに手動で操作するんですか?という質問はやめましょう。
自動車の自動運転だってまだ実現してないじゃないですか。

1.3.スケジュールに基づくスケーリング


スケジュールとインスタンス数を設定しておけば、
自分の代わりに小人が手動スケーリングを行ってくれるイメージです。

スケジュール指定で自動でやるか人力でやるかの違いだけです。
一度きりでも繰り返しでも設定もできます。

1.4.動的なスケーリング


どの「きっかけ」に基いて、
「どのような内容で」スケーリングを実施するかを予め設定しておくことで、
負荷状況に合わせたスケーリングが実現できます。

「きっかけ」になりうるのは以下の2つ。
・メトリクス(Cloudwatchアラームによる監視)
・Amazon SQS

「どのような内容で」というのは「スケーリングポリシー」によって定義します。
スケーリングポリシーは以下の2種類があります。

・シンプルスケーリングポリシー
・ステップスケーリングポリシー

冒頭で述べましたが、ウォームアップが関わってくるのは、
後者のステップスケーリングポリシーだけです。

1.スケーリングプランで様々なスケーリング方法が出てきましたが、
一番最後の「動的なスケーリングでステップスケーリングポリシーを使う」場合のみ、
ウォームアップが関わってきます。

じゃあそれ以外はクールダウンが関わってくるんですね、
というとそういうわけではなく、
クールダウンすら関わってこない場合と、
クールダウンの中でも種類があってこのクールダウンだけ…というのもあるので、
それは次回まわりくどく説明します。

以上です。