batchiです。
[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①
全6回の無駄に長丁場の記事を書いている最中に、
しれっと新しい動的スケーリングのポリシーが追加されていました。
– 新機能 – EC2 Auto Scalingのターゲットトラッキングポリシー –
https://aws.amazon.com/jp/blogs/news/new-target-tracking-policies-for-ec2-auto-scaling/
ひとまず前回時点では見て見ぬふりをして書き上げたので、
見て見ぬふりをしたツケをこれから払います。
ターゲットトラッキング(追跡)ポリシーとは
簡単に言えば、以下のような挙動です。
・メトリクスを指定する(平均CPU使用率、平均ネットワークI/Oなど)
・メトリクスに対するターゲット値を指定する(60%、5,000byteなど)
・ターゲット値からぶれないようにうまいこと勝手にスケーリングしてくれる
こんな感じです。動的スケーリングの設定としてはかなり簡素化されましたね。
ドキュメントとしては以下を参照しましょう。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-scaling-target-tracking.html
補足として下記のようなトピックがあります。
・指定可能なメトリクスは以下の通り
・事前定義されたメトリクス
- ターゲット別のALBリクエスト数
- CPUの平均使用率
- 平均ネットワーク入力(バイト)
- 平均ネットワーク出力(バイト)
・カスタマイズされたメトリクス
- (どうやって設定するんだろう??)
・オプションでスケールインを無効にすることが可能
・ウォームアップの期間を指定する必要あり
・ポリシー作成時にCloud Watchアラームが自動的に作成される
・メトリクスの値を取得する間隔は1分を推奨
[改訂版]スケーリングプランごとのクールダウン/ウォームアップ
ターゲットトラッキングポリシーでは、
クールダウンの概念ではなくウォームアップの概念が適用されます。
以前私は「ウォームアップはステップスケーリングポリシーだけ」
と謳っていたのですが、修正を余儀なくされました。
というわけで以下の表の通り。
◯…適用される
×…適用されない
スケーリングプラン | デフォルトのクールダウン | スケーリング固有のクールダウン | ウォームアップ |
インスタンス数の維持 | × | × | × |
手動スケーリング | × | オーバーライド可能 | × |
スケジュールに基づくスケーリング | × | × | × |
シンプルスケーリングポリシーによる動的スケーリング | ◯ | オーバーライド可能 | × |
ステップスケーリングポリシーによる動的スケーリング | × | × | ◯ |
ターゲットトラッキングポリシーによる動的スケーリング | × | × | ◯ |
ウォームアップの考え方自体は、
ステップスケーリングポリシーの時と変わりありません。
(良かった。)
ターゲットの追跡スケーリングポリシーでは、新しく起動されたインスタンスのウォームアップにかかる秒数を指定できます。その指定されたウォームアップ期間が終了するまで、インスタンスは Auto Scaling グループの集合メトリクスの対象になりません。
スケールアウト時、Auto Scaling はグループの現在の容量の一部としてウォームアップ中のインスタンスは対象にしません。これにより、必要以上の数のインスタンスが追加されることがなくなります。
スケールイン時、Auto Scaling はグループの現在の容量の一部として終了中のインスタンスを対象にします。したがって、Auto Scaling グループから必要以上の数のインスタンスが削除されることがなくなります。
スケールアウトアクティビティの進行中、スケールインアクティビティを開始することはできません。
ターゲットトラッキングポリシーの実装
さわりの部分だけ紹介します。
Auto Scalingグループのコンソール画面で「ポリシーの追加」を選択すると、
ターゲットトラッキングポリシーの作成画面が開きます。
(他のポリシーを作成したい場合は画面下部から切り替える)
・名前(ポリシー名)
・メトリクスタイプ
・ターゲット値
・ウォームアップの長さ
・スケールインの無効化の有無の指定
上記を指定するだけで完了です。簡単。
ポリシーを作成すると、自動的にCloudwatchアラームが作成されます。
今回の例ではターゲット値として「50」を指定しましたが、
スケールアウトを担うアラームと、スケールインを担うアラームが以下の設定で作成されました。
・1分間の平均CPU使用率が50を超える期間が3回連続で検出された場合スケールアウト
・1分間の平均CPU使用率が45を下回る期間が15回連続で検出された場合スケールイン
具体的にスケールする台数は、Cloudwatchアラームからは確認できません。
よしなにやってくれるので、気にする必要がない部分ですね。
自動的に作成されたアラームは、
ユーザー側では編集も削除もできません。
削除したいときは、ポリシー削除すれば連動して削除されます。
ちなみに、ポリシー作成時に「スケールインの無効化」を有効化していると、
スケールインを担うアラームは作成されません。
というわけでターゲットトラッキングポリシーの紹介でした。
◯◯台という部分をユーザーが握れないので、
ターゲットの値を適切に設定する必要があるポリシーですね。
実際に動かしてみて、適切なターゲットの値を算出するのが良さそうです。
こちらからは以上です。