Desired Capacity で頭が混乱したときのための記事
はじめに
この記事では、Desired Capacity と Desired Capacity の理解に必要な周辺知識のみ紹介しております。
AutoScaling全体の概要を把握したい場合は、以下のスライドを見るのが一番良いかと思います。
おなじみBlackbeltのスライドなのですが、この回は特に分かりやすいです。
この記事では、AutoScalingの中でもDesired Capacityについて整理して解説していきます。
※記事中の間違いはご指摘頂けると嬉しいです！！
Desired Capacityとは？
EC2 Auto Scalingグループを作成する際に、min, max, Desired Capacityを設定します。
まず、微妙に間違った理解と正しい理解を最初に紹介します。
微妙に間違った理解
- min： インスタンス数の最小。
- max： インスタンス数の最大。
- Desired Capacity： 起動したいインスタンス数。値は不変。
正しい理解
- min： Desired Capacityの最小。
- max： Desired Capacityの最大。
- Desired Capacity： 起動したいインスタンス数。静的スケーリング以外では可変である。
このままでは何も説明になっていないので、実際の動きと共に理解するために、最初は静的スケーリングと動的スケーリングの違いから説明していきます。
※以降『Auto Scaling』は、EC2 Auto Scalingのことを指します。（AWS Auto Scaling や Application Auto Scalingがあるので、念のため注意書き）
スケーリングの概念：静的スケーリングと動的スケーリング
Auto Scaling のスケーリングの方法には、大きく分けて二つの方式があります。
動的スケーリングにも複数種類がありますが、今回の記事では割愛します。
- 静的スケーリング
- 動的スケーリング
静的スケーリング
静的スケーリングは、非常に単純です。
Auto Scalingといえば、CPU利用率やネットワークのIN/OUT数を元にEC2インスタンスの数を自動で増減させることを思い浮かべます。
ところが、静的スケーリングは、常にインスタンス数が一定数になるように保つだけです。
そして、この「一定のインスタンス数」がDesired Capacityによって定義されます。
ハンズオンや『試してみた系の記事』ではよく目にしますが、おそらく一般的なワークロードではあまり使われないのではないでしょうか（ここは完全に実践を伴わない推測です）。
動きを図とグラフで整理しておきます。
図
グラフ
動的スケーリング
動的スケーリングは、インスタンス数を自動で増減させるものです。
CPU利用率やネットワークのIN/OUT数を考慮して、インスタンス数を増減させます。
このとき、インスタンス数の増減は、Desired Capacityの増減によって実現されます。
さらに、可変であるDesired Capacityの値は min より小さくならず、 max より大きくなりません。
動きを図とグラフで整理しておきます。
図
グラフ
静的スケーリングではDesired Capacityは不変、動的スケーリングではDesired Capacityは可変となります。
また、min, maxの値が意味を持つのは動的スケーリングにおいてです。静的スケーリングではDesired Capacityの値が変わらないので、ほとんど意味がありません。
静的スケーリングを先に調べて動的スケーリングを後から調べると、Desired Capacityへの理解が混乱する可能性があるので気を付けたいですね。
ポイント： 静的スケーリングではmaxとminは考えなくてよい
maxとminはDesired Capacityの取り得る値です。
静的スケーリングではDesired Capacityは増減しないので、maxとminの値は無視していいということになります。
もちろん、最初の設定時に、『min <= Desired Capacity <= max』に値を設定する必要はありますが動作中は考えなくて良いです。
ポイント： 動的スケーリングで設定するDesired Capacityは『最初に立ち上げるインスタンス数』
Auto Scalingグループを作成する際に必須で設定が必要なDesired Capacityですが、動的スケーリングでは初期値としての設定になります。
例えば、CPU使用率を判断基準に設定したAuto Scalingグループにおいて、初期にDesired Capacityを3に設定しておいても、平均CPU使用率が閾値を超えていたらDesired Capacityはすぐに4に変わります。
この意味で、動的スケーリングにおけるDesired Capacityは初期に立ち上げるインスタンス数を定義しているだけになります。
動的スケーリングで実際の動きを確認
さて、動的スケーリングについての説明があっているか、動作を確認しました。
ここで検証したいことを、整理しておきましょう。以下の2点です。
まず、以下の設定のAuto Scalingグループを作成しました。
- サイズの設定
- min: 1
- max: 3
- Desired Capacity: 2
- 動的スケーリングポリシー
- グループの平均CPU使用率が30%より大きいならインスタンスを 1 追加
- グループの平均CPU使用率が30%以下ならインスタンスを 1 終了
スケーリングポリシーをマネジメントコンソールで見ると、こんな感じです。
※普通はCPU利用率の閾値を80%とか50%とか高めに設定しますが、今回は負荷をかけるのが面倒なので低めに設定しました。
そして、今までの説明の正しさを確認するために、以下の流れが本当に起こるか確認していきます。
手順と仮説
AutoScalingグループを作成
↓
動的スケーリングポリシーを設定
↓
CPU利用率は0に近いのでDesired Capacityが 1 に設定されてグループのインスタンス数が 1 になる
↓
インスタンスに負荷を掛けて平均CPU利用率を30%より大きくする
↓
Desired Capacityが 2 に設定されてグループのインスタンス数が 2 になる
↓
さらにインスタンスに負荷を掛けて平均CPU利用率を30%より大きくする
↓
Desired Capacityが 3 に設定されてグループのインスタンス数が 3 になる
負荷をかける方法はこちらの記事[1]を参考にしてstressツールで行いました。
詳細は割愛しますが、インストールコマンドだけ置いておきます。
sudo amazon-linux-extras install epel -y
sudo yum install stress -y
さて、実際にどうなったかを見ていきます。
実際の手順と結果
手順
AutoScalingグループを作成
↓
動的スケーリングポリシーを設定
↓
インスタンスに負荷を掛けて平均CPU利用率を30%より大きくする
↓
さらにインスタンスに負荷を掛けて平均CPU利用率を30%より大きくする
↓
負荷をかけるのを停止して何もしないようにし、CPU利用率を30%以下にする
結果
CloudWatchのメトリクスで確認しました。
結論から言うと、想定通りの動きになっています。
まず、Desired Capacityの変動を見ていきましょう。画像が小さくて申し訳ないですが、拡大して見ていただけると幸いです。
おまけに、Desired Capacityと稼働インスタンス数を置いておきます。
確認したかった以下の仮説を検証できました。
なぜ Desired Capacity は理解しづらいのか？
まず、初期設定にポイントがあると思います。
Auto Scalingグループを作成する際に、min, max, Desired Capacityを設定します。この時に、これら3つが不変であるという認識が生まれやすく、「動的スケーリングではDesired Capacityは可変である」ということに気づきにくくなります。
次に、静的スケーリング、動的スケーリングの概念です。
Desired Capacityの意味合いが静的スケーリングと動的スケーリングで大きく変わってしまうので、先にスケーリングの概念を理解する必要があります。Desired Capacityだけでは理解が進みません。
また、検索すると静的スケーリングでハンズオンをしている記事や動的スケーリングの説明をしている記事などがごちゃごちゃに出てくるので、混乱する要因になるかと思います。
1つの記事の中で動的スケーリングのパターンを解説した後に、簡単にできる静的スケーリングのハンズオンをしているような記事も目にしたので、そこで混乱するかもしれません。
AWSの基本的なサービスですが、簡単に理解できないので腐らず地道に頑張りたいです。
今回得られたこと
個人的に得られたことを書いていきます。
- Auto Scalingグループの作成方法や起動テンプレートまわりの知識
- Desired Capacity の詳細
- 動的スケーリング、静的スケーリングの概念の理解
- 強制的にCPUに負荷を掛ける方法
- ステップスケーリングポリシーの設定まわり
- CloudWatchメトリクスの見方
検証にてAuto Scalingグループの作成や起動テンプレートの作成が出来たのは良かったです。
また別の記事で、Desired Capacity以外の知識についても取り上げたいです。例えば、スケーリングポリシーやライフサイクルフックなど。
今回失ったもの
- 300円くらいのお金
- 時間
AutoScalingでは複数のインスタンスを起動するので、お金がかかってしまいますね。
また、今回記事に書いたところ以外で何度も試していたので、思ったよりも掛かっていました。
実際に掛かるお金は大したことないですが、何か試すたびに怯えている現状をどうにかしたいですね。
自分個人のAWSアカウントでハンズオンを行っていると、値段について慎重にしらべることになるので、その意味では個人のアカウントでやる意味があるかと思います。
とはいえ、本音を言えば、常識の範囲内で自由に使えるAWSアカウントを会社側で用意してくれると嬉しいですね。
最後に
また、AWSの気になった細かいポイントについて記事を作っていきます！
Discussion