やるきげんきなみき

Web系インフラエンジニアのTips集

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

はじめに

こんにちは、インフラエンジニアのなみきです。 これまでは所属企業でブログを書いていましたが、退職に伴い自分のブログを開設しました。 改めてよろしくお願いします。

さて、今日のお題はみんな大好きEC2 Auto Scalingです。

EC2 Auto Scalingでできる自動スケーリングは、大きく分けて3種類あります。

これらのスケーリングを組み合わせて利用されている方は多いのではないでしょうか。

今回は、「動的スケーリング」と「スケジュール」を組み合わせて利用する際のオススメ設定方法を紹介します。

前提知識

3種類のパラメータ

Auto Scaling Groupには、インスタンス数を制御するパラメータが3種類あります。

  • Desired Capacity (希望容量)
  • Minimum Size (最小サイズ)
  • Maximum Size (最大サイズ)

起動するインスタンス数は希望容量に依存します。 動的スケーリングを利用している場合、希望容量は最小サイズと最大サイズの間で増減します。 自動で最小サイズを下回ったり、最大サイズを上回ることはありません。1

NOTE: この記事では、説明を分かりやすくするためインスタンスの重み付けには触れず、単純に「サイズ=インスタンス数」として扱います。ご承知おきください。

Desired CapacityはMinimumとMaximumの間で増減する

一方、スケジュールでは希望容量を指定できるのはもちろん、最小サイズと最大サイズも指定できます。

スケジュールでMinimumとMaximumを変化させる例

スケジュールの利用シーン

多くの場合、Auto Scalingの動的スケーリングは数分間の負荷状況を見てからスケーリングを始めるため、急激な負荷上昇には対応しきれないことがあります。2

動的スケーリングあるある: スケールアウトが間に合わない

そこで、負荷の高まる時間が予測できる場合は、スケジュールを利用して待ち構えておくことで対応できます。

負荷に備えあらかじめスケールアウトしておく

前述の通り、スケジュールでは希望容量だけではなく最小サイズと最大サイズも指定できます。

「希望容量を変えたいんだから、希望容量を指定すればいいんじゃないの?」と思われるかもしれません。 動的スケーリングを使わずスケジュールのみでインスタンス数を増減させている場合は、その通りです。

しかし、動的スケーリングとスケジュールを組み合わせて使う場合、思い通りのインスタンス数を維持するために スケジュールでは最小サイズを指定するのがオススメ です。

どういうことか、詳しく見ていきましょう。

よくある問題と回避策

スケジュールで希望容量を増減させるとどのような問題が起こりうるか、そして最小サイズを指定することでどのように問題を回避できるかを紹介します。

問題その1: 即座にスケールイン

負荷が高まる時間が分かっている場合、時間に余裕を持たせたスケジュールにすることが多いと思います。 すなわち、インスタンス数を増やしてから負荷が高まるまで少し時間があるということですが、この間にインスタンス数が減ってしまっては困ります。

希望容量の問題

スケジュールで希望容量を増やすと、負荷が高まる前に自動スケールインが発生し、狙ったインスタンス数が維持できないという問題が起こり得ます。

例えば、12:00に負荷が高くなるシステムにおいて、11:30のスケジュールで希望容量を増やすとします。 この30分間は負荷の低い状態が続くため、動的スケーリングによる自動スケールインが発生し、希望容量が減らされる可能性があります。 そうなると肝心の12:00にインスタンス数が足りず、パフォーマンス悪化やエラーを起こしてしまいます。

即座にスケールインするイメージ

NOTE: 動的スケーリングの自動スケールインを無効にして勝手に減らないようにする、というのも一つの回避策ですが、後述する問題その2を併せて回避するため自動スケールインは有効にしておく必要があります。

最小サイズで解決

では、希望容量のかわりに最小サイズを指定するとどうなるでしょうか。 スケジュールを以下のように設定します。

希望容量を指定せずに最小サイズを指定すると、希望容量は必ず「最小サイズ以上」になります。 それより減ることはないので、次のスケジュールで最小サイズを下げるまでインスタンス数が維持されます。

最小サイズ指定でスケールインを回避する

問題その2: 問答無用でスケールイン

負荷に備えてインスタンス数を増やすのとセットで、負荷が落ち着く頃にインスタンス数を減らすのもよくある使い方です。 しかし、負荷の高い状態が予想よりも長引いていたらどうなるでしょうか。

希望容量の問題

スケジュールで希望容量を指定すると、負荷状況によらず問答無用でインスタンス数を変更してしまいます。

問答無用でスケールインするイメージ図

最小サイズで解決

では、希望容量のかわりに最小サイズを指定するとどうなるでしょうか。 スケジュールを以下のように設定します。

希望容量を指定しないことにより、スケールインは動的スケーリングに任せることになります。 負荷状況を見た上で「減らして大丈夫」と判断されて初めて減らされるため、適切なインスタンス数を維持できます。

負荷に合わせてスケールインする

まとめ

スケジュールで希望容量を指定するのは分かりやすいですが、動的スケーリングと組み合わせた場合、予期せぬ増減が発生することがあります。 希望容量を狙った値にするため、ぜひ最小サイズの指定を取り入れてみてください。


  1. インスタンスの重み付けや予測スケーリングを利用している場合は例外的に最大サイズを上回ることがありますが、この記事では詳しく説明しません。
  2. メトリクスの1ポイントだけ見てスケーリングさせることも設定上は可能ですが、実際の運用ではトレンドを外れた値が突発的に発生することもあるので、そのような設定は現実的ではありません。