はじめにこんにちは、インフラエンジニアのなみきです。これまでは所属企業でブログを書いていましたが、退職に伴い自分のブログを開設しました。改めてよろしくお願いします。さて、今日のお題はみんな大好きEC2 Auto Scalingです。EC2 Auto Scalingでできる自動スケーリングは、大きく分けて3種類あります。動的スケーリング負荷状況に合わせてスケールできるどのメトリクスを基準にするか？増減させるときは何台ずつ増やすか？などスケールの仕様を細かく設定できるスケジュールされたスケーリング（以下「スケジュール」と表記）予定した日時にインスタンス数を増減させる予測スケーリングリソースの使用率などの規則性から、適切なインスタンス数を予測するこれらのスケーリングを組み合わせて利用されている方は多いのではないでしょうか。今回は、「動的スケーリング」と「スケジュール」を組み合わせて利用する際のオススメ設定方法を紹介します。前提知識3種類のパラメータAuto Scaling Groupには、インスタンス数を制御するパラメータが3種類あります。Desired Capacity （希望容量）Minimum Size （最小サイズ）Maximum Size （最大サイズ）起動するインスタンス数は希望容量に依存します。動的スケーリングを利用している場合、希望容量は最小サイズと最大サイズの間で増減します。自動で最小サイズを下回ったり、最大サイズを上回ることはありません。1NOTE: この記事では、説明を分かりやすくするためインスタンスの重み付けには触れず、単純に「サイズ=インスタンス数」として扱います。ご承知おきください。Desired CapacityはMinimumとMaximumの間で増減する一方、スケジュールでは希望容量を指定できるのはもちろん、最小サイズと最大サイズも指定できます。スケジュールでMinimumとMaximumを変化させる例スケジュールの利用シーン多くの場合、Auto Scalingの動的スケーリングは数分間の負荷状況を見てからスケーリングを始めるため、急激な負荷上昇には対応しきれないことがあります。2動的スケーリングあるある: スケールアウトが間に合わないそこで、負荷の高まる時間が予測できる場合は、スケジュールを利用して待ち構えておくことで対応できます。負荷に備えあらかじめスケールアウトしておく前述の通り、スケジュールでは希望容量だけではなく最小サイズと最大サイズも指定できます。「希望容量を変えたいんだから、希望容量を指定すればいいんじゃないの？」と思われるかもしれません。動的スケーリングを使わずスケジュールのみでインスタンス数を増減させている場合は、その通りです。しかし、動的スケーリングとスケジュールを組み合わせて使う場合、思い通りのインスタンス数を維持するために スケジュールでは最小サイズを指定するのがオススメ です。どういうことか、詳しく見ていきましょう。よくある問題と回避策スケジュールで希望容量を増減させるとどのような問題が起こりうるか、そして最小サイズを指定することでどのように問題を回避できるかを紹介します。問題その1: 即座にスケールイン負荷が高まる時間が分かっている場合、時間に余裕を持たせたスケジュールにすることが多いと思います。すなわち、インスタンス数を増やしてから負荷が高まるまで少し時間があるということですが、この間にインスタンス数が減ってしまっては困ります。希望容量の問題スケジュールで希望容量を増やすと、負荷が高まる前に自動スケールインが発生し、狙ったインスタンス数が維持できないという問題が起こり得ます。例えば、12:00に負荷が高くなるシステムにおいて、11:30のスケジュールで希望容量を増やすとします。この30分間は負荷の低い状態が続くため、動的スケーリングによる自動スケールインが発生し、希望容量が減らされる可能性があります。そうなると肝心の12:00にインスタンス数が足りず、パフォーマンス悪化やエラーを起こしてしまいます。即座にスケールインするイメージNOTE: 動的スケーリングの自動スケールインを無効にして勝手に減らないようにする、というのも一つの回避策ですが、後述する問題その2を併せて回避するため自動スケールインは有効にしておく必要があります。最小サイズで解決では、希望容量のかわりに最小サイズを指定するとどうなるでしょうか。スケジュールを以下のように設定します。希望容量: 無指定最小サイズ: 維持したいインスタンス数希望容量を指定せずに最小サイズを指定すると、希望容量は必ず「最小サイズ以上」になります。それより減ることはないので、次のスケジュールで最小サイズを下げるまでインスタンス数が維持されます。最小サイズ指定でスケールインを回避する問題その2: 問答無用でスケールイン負荷に備えてインスタンス数を増やすのとセットで、負荷が落ち着く頃にインスタンス数を減らすのもよくある使い方です。しかし、負荷の高い状態が予想よりも長引いていたらどうなるでしょうか。希望容量の問題スケジュールで希望容量を指定すると、負荷状況によらず問答無用でインスタンス数を変更してしまいます。問答無用でスケールインするイメージ図最小サイズで解決では、希望容量のかわりに最小サイズを指定するとどうなるでしょうか。スケジュールを以下のように設定します。希望容量: 無指定最小サイズ: 平常時の最小インスタンス数希望容量を指定しないことにより、スケールインは動的スケーリングに任せることになります。負荷状況を見た上で「減らして大丈夫」と判断されて初めて減らされるため、適切なインスタンス数を維持できます。負荷に合わせてスケールインするまとめスケジュールで希望容量を指定するのは分かりやすいですが、動的スケーリングと組み合わせた場合、予期せぬ増減が発生することがあります。希望容量を狙った値にするため、ぜひ最小サイズの指定を取り入れてみてください。インスタンスの重み付けや予測スケーリングを利用している場合は例外的に最大サイズを上回ることがありますが、この記事では詳しく説明しません。↩↩

EC2 Auto Scalingで動的スケーリングとスケジュールを組み合わせる