基本に立ち返ろうということで、AWSのAutoScalingの仕様の確認です。前回は、スケーリングポリシーを中心に確認でした。今回は、起動や終了に関わる仕様ということで、猶予期間・ウォームアップ・クールダウン・終了ポリシーなどの解説になります。
前回
AWSのAutoScalingの整理 スケーリングポリシー編 - プログラマでありたい
ヘルスチェックと猶予期間
まず最初にヘルスチェックと猶予期間です。ヘルスチェックは、AutoScalingの管理対象下のインスタンスの動作をチェックして、異常が認められた場合は新しいインスタンスと置き換えられます。
Auto Scaling インスタンスのヘルスステータスは、正常または異常のどちらかです。Auto Scaling グループ内のすべてのインスタンスは正常な状態で起動されます。インスタンスに異常があるという通知を Amazon EC2 Auto Scaling が受け取らない限り、インスタンスは正常であると見なされます。この通知は、Amazon EC2、Elastic Load Balancing (ELB)、カスタムヘルスチェックのうち 1 つ以上のソースから送られる可能性があります。
Amazon EC2 Auto Scaling がインスタンスを異常ありとマークすると、置き換えがスケジュールされます。インスタンスを置き換えない場合は、個々の Auto Scaling グループに対するヘルスチェックプロセスを停止できます。
Auto Scaling インスタンスのヘルスチェック - Amazon EC2 Auto Scaling (日本語)
このヘルスチェックの挙動を理解するために重要になるのが、ヘルスチェック猶予期間です。英語では、Health Check Grace Periodです。AutoScalingが発動してインスタンスが起動されても、インスタンスの起動時間やインスタンス内のプロセスの起動時間があるために、すぐにそのインスタンスが利用可能な状態になる訳ではありません。その間にヘルスチェックでエラーが出続けると困るので、一定期間ヘルスチェックをしないという猶予期間があります。画面コンソールから作った場合の、猶予期間はデフォルトで300秒（5分）です。が、CLIやSDKから作った場合は、なんと0秒です。この辺の差異がある経緯、ちょっと気になりますね。
ヘルスチェックの猶予期間の設定画面をみると、EC2とELBの2つのヘルスチェックがあることに気が付きます。この違いは何なのか、それぞれ見てみましょう。
Amazon EC2 ステータスチェック
まずEC2の方です。こちらは、正式名称がAmazon EC2 ステータスチェックです。その名の通り、EC2インスタンス単体としてのヘルスチェックを行います。AutoScalingのデフォルトのチェックは、こちらです。
Elastic Load Balancing (ELB) ヘルスチェック
Elastic Load Balancing (ELB) ヘルスチェックは、ELBが提供するテストに基づいて判断されます。対象となるものは、ALBとNLBのターゲットグループならびにCLBです。ヘルスチェックの方法は、ELBの種類によって異なります。ALBの場合はアプリケーションレイヤー (HTTP および HTTPS) のヘルスチェックをサポートし、NLBとCLBの場合は、アプリケーションレイヤー (HTTP/HTTPS) とTCPの両方のヘルスチェックをサポートします。インスタンスは正常だけど、ELBから利用するプロセスが異常という場合に、素早く対処したい場合はELBヘルスチェックを利用します。
ELBのヘルスチェックでややこしいのは、ヘルスチェック猶予期間はあくまでAuto Scalingの中だけで完結していることです。つまり、ELBからのヘルスチェックは猶予期間内であってもUnHealthyを返します。アラートがならないようにヘルスチェックをするには、この辺を考える必用があります。
クラスメソッドさんのブログでも同じテーマで課題提起があり、ELB側ではなくAuto Scaling Group側のGroupTerminatingInstancesがお勧めとのことです。
ELB配下でAuto Scalingを構成する場合には、ELB側のUnHealthyHostCountを利用するのではなく、Auto Scaling Groupが持っているGroupTerminatingInstancesメトリクスを利用した監視がオススメとのことです。
EC2 Auto Scaling グループの「ヘルスチェックの猶予期間」を正しく理解する | Developers.IO
スケーリングクールダウンとウォームアップ
ヘルスチェックの猶予期間を理解したのでAutoScalingについては完璧かと思いきや、AutoScalingにはクールダウンとウォームアップという概念があります。こちらも理解しておきましょう。
クールダウン
まずはクールダウンです。正式名称は、スケーリングクールダウンというようです。これはAutoScalingが発動した直後に追加でインスタンスの増減がなされるのを防ぐための設定です。猶予期間と混同されがちですが、猶予期間はヘルスチェックの猶予であり、クールダウンはインスタンスの増減のアクションの発動に対してのパラメータとなります。
ちなみにAWSの説明では、古い設定であり現在ではデフォルトの設定のまま調整しないで済むとバッサリと切り捨てられています。
スケーリングアクティビティが完了してから別のアクティビティが開始されるまでの時間を変更します。時間の長さは、インスタンスのウォームアップ期間、またはその他のアプリケーションニーズに基づいて設定できます。これは古い設定であり、ほとんどの場合において、デフォルトの 300 秒のままとすることができます。クールダウンオプションは、ターゲット追跡スケーリングポリシー、ステップスケーリングポリシー、またはスケジュールされたスケーリングではサポートされていません。
切り捨てられている理由としては、クールダウンは主として簡易スケーリングに対するパラメータとして動いているためです。ステップスケーリングの場合、メトリクスに対して複数の閾値が指定できます。そのためスケーリング動作中に、別の閾値に達した場合にはクールダウンと関係なく反応するようになっています。一方で50%で1台追加で60%で2台追加と設定している場合、50%に反応して1台追加中に60%に達し更に2台追加となると過剰に追加しすぎとなる場合があります。それを抑止するために、ウォームアップという概念があります。
ウォームアップ
ウォームアップは前述のとおり、ほぼステップスケーリングで差分でインスタンスを追加するために追加された機能です。事実、ステップスケーリングの機能が追加された時に、パラメーターとして登場しています。動作のポイントは2つです。CPUの利用率が50%の時に1台追加、70%の時に2台追加というポリシーが設定された場合を例に解説します。
- （インスタンス追加され）ウォームアップ期間中には、そのアラームでのインスタンス追加はされない
- ウォームアップ期間中に次のアラート（70%）が発動した場合、差分の台数が追加される
ウォームアップは、ステップスケーリングとターゲット追跡スケーリングポリシーに対応しています。
その他のAutoScalingのオプション
猶予期間とクールダウン、ウォームアップを理解できれば、AutoScalingのオプションについて、ほぼ理解していると言えるのではないでしょうか。ただ、上記以外にも、まだ幾つかオプションがあります。代表的なのがライフサイクルフックと終了ポリシーです。せっかくなので、この2つについても見ていきましょう。
ライフサイクルフック
ライフサイクルフックは、Auto Scalingグループによるインスタンスの起動時または削除時にインスタンスを一時停止してカスタムアクションを実行する機能です。例えば、起動時にデータを取得してきたり、削除時にログやデータの退避の処理を追加するといった用途で使えます。待機時間はデフォルトで1時間、最大で48時間まで設定できます。ただ48時間必用なケースは、どうしても思い浮かびません。
終了ポリシー
負荷に応じてインスタンスを増やすのをスケールアウトと言います。これに対して、負荷が下がってインスタンスを減らす場合はスケールインといいます。さてAutoScalingでは、スケールインの際に、どのインスタンスを削除するのでしょうか？これを決めるのが、終了ポリシーです。デフォルトの終了ポリシーでは、インスタンスがアベイラビリティーゾーンに均等に配分されるように削除します。２つのAZで2台・3台とインスタンスがある場合、3台あるAZのインスタンスを一つ削除させてAZ間で均等にさせるというような動作になります。それ以外にも、
| 終了ポリシー | 概要 |
|---|---|
| OldestInstance | 最も古いインスタンスを削除 |
| NewestInstance | 最も新しいインスタンスを削除 |
| OldestLaunchConfiguration | 最も古い起動設定のインスタンスを削除 |
| ClosestToNextInstanceHour | 次の課金時間に最も近いインスタンスを削除 |
| Default | |
| OldestLaunchTemplate | 最も古い起動テンプレートを使用するインスタンスを削除 |
| AllocationStrategy | スポットまたはオンデマンドなどのインスタンスタイプの配分戦略に沿って削除 |
ClosestToNextInstanceHourなんかは、出た当初は素敵と思ったのですが、今はEC2のインスタンスの課金単位時間が1時間から1秒に変わりほぼ意味がなくなっていそうです。今だと、どういった挙動になるのは、どこかで実験してみます。1時間という前提を残して動くのではと予想しています。
まとめ
前後2回に渡って整理してきたEc2 AutoScalingの仕様の確認はいかがでしたでしょうか？普段使わない設定も多く、知らない事も多かったのではないでしょうか？AWSの認定試験は、ケースごとにどのような設定をすれば良いのかということを問われます。そのためには、網羅的に仕様を把握しておく必用があり、AutoScalingは特に重要なポイントです。ELBとAutoScalingは一緒に設定することが多く、どれがどちらの仕様か混同して覚えてしまうことが多いです。一度、AutoScalingとELBを別々に学ぶというのは有効だと思います。
次回は、ELBを整理してみようと思います。
AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト
- 作者:NRIネットコム株式会社,佐々木 拓郎,林 晋一郎,金澤 圭
- 発売日: 2019/04/20
- メディア: 単行本
