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.スケーリングプランで様々なスケーリング方法が出てきましたが、
一番最後の「動的なスケーリングでステップスケーリングポリシーを使う」場合のみ、
ウォームアップが関わってきます。
じゃあそれ以外はクールダウンが関わってくるんですね、
というとそういうわけではなく、
クールダウンすら関わってこない場合と、
クールダウンの中でも種類があってこのクールダウンだけ…というのもあるので、
それは次回まわりくどく説明します。
以上です。
