Auto Scalingの段階スケーリングポリシーについて
オートスケーリングの種類
オートスケーリング機能は、アプリケーションの安定的な「性能を維持」し「費用を抑える」ような、自動的なサーバー運用を実現する上で重要な機能です。オートスケーリングには、いくつかの種類があります。
- 手動スケーリング：例）今からインスタンスを4台にする
- スケジュールに基づくスケーリング：例）午前6時にインスタンスを2台増やす
- 動的スケーリング：例）CPU90%になったらインスタンスを1台増やす
- 固定数維持：例）障害が発生してもインスタンスを4台を維持する
今回は、動的スケーリングの新機能である、「段階スケーリング」についてご紹介したいと思います。
段階スケーリングポリシー（Step Scaling Policies）
段階スケーリングポリシーは、CloudWatchメトリクスから得られる値（CPU使用率やSQSキューサイズなど）の閾値を超えて発せられるアラームに対して、値ベースでスケーリングアクションを個別設定できる機能です。例えば、CPU使用率50%を閾値としてアラームが飛ぶとします。この時、報告されてくる値は、50%でも99%でも動作は同じでした。ですから、急激に上がる負荷に対してのんびりインスタンスを追加（クールダウンはデフォルトで300秒）するか、ちょっとだけCPU使用率上がってても沢山インスタンス追加するという、実際のビジネスにあまりフィットしないことがありました。そこで、50%なら1台追加、60%なら2台追加、70%なら3台追加といった具合に、閾値を超えてアラームから報告される値によってスケールする台数を指定できるようになりました。
これらの方法は、以前もポリシーとアラームをたくさん設定すれば同様に実現できていたと思いますが、1つのアラームと1つのポリシーでまとめて実現できるようになっていることがポイントです。
ちなみに複数アラームと複数ポリシーで高速オートスケーリングを実現した記事は以下ですのでご参考までに。
Amazon SQSとCloudWatchによる高速AutoScaling
やってみる
実際にやってみましょう。
起動コンフィグ（Launch Configuration）の作成
起動するインスタンスの情報について作成します。
インスタンスタイプの指定やセキュリティグループ等の設定を行います。
続いて、起動コンフィグを使うオートスケーリンググループの作成です。
オートスケーリンググループ（Auto Scaling Group）の作成
名前を設定して、初期の起動台数の設定をします。
台数固定か条件に合わせてスケーリングするか指定します。
今回は、スケーリングの設定をしましょう。
初期表示から段階スケーリングポリシーの設定になっていますね。
アラーム（Alarm）の作成
新規にアラームを作成します。ここでは、複数のアラームを作成せずに、1つだけ閾値の低いアラームを作成します。今回は50%としました。
段階スケーリングポリシー（Step Scaling Policies）の作成
今回の大事なポイントです。この例では、CPU使用率の平均が非常に高い場合には負荷を下げるために積極的にインスタンスを追加しています。例えば平均80%を超えていたら8台追加する設定です。
ちなみに、追加の単位は、「台数」の他に、「割合」を指定することもできます。例えば平均80%を超えていたら100%追加（2倍に）する設定です。
画面から簡単に設定することができましたね！
ちなみに、コマンドラインから作成したポリシーを確認すると、段階部分の数字が絶対値ではなく相対値になっていましたので注意が必要ですね。PolicyTypeの値がStepScalingになっているのがポイントです。
$ aws autoscaling describe-policies
{
"ScalingPolicies": [
{
"PolicyName": "Increase Group Size",
"MetricAggregationType": "Average",
"AutoScalingGroupName": "MyScalingGroup1",
"PolicyARN": "arn:aws:autoscaling:ap-northeast-1:XXXXXXXXXXXX:scalingPolicy:cc32145d-9a47-4ba3-85b2-0021YYYYYYYY:autoScalingGroupName/MyScalingGroup1:policyName/Increase Group Size",
"PolicyType": "StepScaling",
"StepAdjustments": [
{
"ScalingAdjustment": 1,
"MetricIntervalLowerBound": 0.0,
"MetricIntervalUpperBound": 10.0
},
{
"ScalingAdjustment": 2,
"MetricIntervalLowerBound": 10.0,
"MetricIntervalUpperBound": 20.0
},
{
"ScalingAdjustment": 4,
"MetricIntervalLowerBound": 20.0,
"MetricIntervalUpperBound": 30.0
},
{
"ScalingAdjustment": 8,
"MetricIntervalLowerBound": 30.0
}
],
"AdjustmentType": "ChangeInCapacity",
"Alarms": [
{
"AlarmName": "awsec2-MyScalingGroup1-CPU-Utilization",
"AlarmARN": "arn:aws:cloudwatch:ap-northeast-1:XXXXXXXXXXXX:alarm:awsec2-MyScalingGroup1-CPU-Utilization"
}
]
}
]
}
クールダウン（Cooldown）とウォームアップ（Warmup）について
オートスケーリングの動作を考える上で、以前からクールダウンというものがありました。これは、アラームによってスケーリングポリシーから指定されたコンフィグを使ったインスタンスの起動指示がいきますが、インスタンスのブートストラップなどの処理によって数分掛かることがあります。この数分を待たずに次の起動指示が来てしまいますと、次々と新しいインスタンスが立ち上がってしまいます。そこで、クールダウン期間を設定することで起動指示直後の待ち時間を設けています。デフォルトで300秒が設定されています。これにより、アラームが連続して何度も起こったとしても、クールダウン期間中はポリシーが動き出しません。
一方で、ウォームアップは、段階スケーリングポリシーの機能追加に合わせて追加されたパラメータです。指定されたウォームアップ期間が切れるまで、起動指示されたインスタンスは、オートスケーリンググループのメトリクス情報としてカウントされません。ちょっと分かりづらいと思いますので例を挙げます。スケーリングポリシー(+1台追加)によってインスタンス起動処理が起こるとします。このインスタンス起動開始から完了までの間（負荷が分散されていない）に、次のスケーリングポリシー(+4台追加)が動き出したとします。さて、最新の負荷状況を考えると、+4台のみにしたいところですが、2度のスケーリングポリシーによって、5台（+1台+4台）の起動台数になってしまっては困ります。これを防止するのがウォームアップです。一言で言うと「段階的に差分でインスタンスを追加」です。デフォルトで300秒が設定されています。
以下は、クールダウンとウォームアップのイメージ図です。
ライフサイクルフック
ちなみに、オートスケーリンググループのライフサイクルフックという機能があります。これは、インスタンスが起動完了後、オートスケーリンググループに追加される前に「待ち状態（Wait）」にして、何かしらアプリケーション処理を実行させることができます。例えば、データベースからメモリにマスタデータをロードするなどが考えられます。このライフサイクルフックが終わったタイミングで、クールダウン期間のカウントが開始されます。
まとめ
今回は、オートスケーリングの新機能である、段階スケーリングポリシーについてご紹介しました。今までは非常に高い閾値を設定して1回だけインスタンス数を増やす設定をしている方も多かったのではと思います。この場合、既にアプリケーションの動作が不安定になっていたり、1回の追加では間に合わなかったりしたこともあったのではないでしょうか。今回の機能追加によって、低い閾値を設定しつつも、実際の負荷に合わせて段階的にインスタンスを追加することができるようになり、より安定的なシステム全体の運用につながるのではと思いました。クールダウン、ウォームアップ、ライフサイクルフックあたりを押さえておきましょう！
![【Security Hub修復手順】 [Autoscaling.5] Auto Scaling グループの起動設定を使用して起動した Amazon EC2 インスタンスは、パブリック IP アドレスを含みません](https://images.ctfassets.net/ct0aopd36mqt/wp-refcat-img-cea52bc8a6ec5cad9021b38df4a08b9e/24c76ee7c1ae7aa7f9676a59c77f8702/aws-security-hub)
