AWSのITコストを削減 Simpline

選ばれ続けること

 

エンジニアブログ

ホーム - エンジニアブログ - 2017年6月

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する④

2017.06.23

batchiです。
だいぶいい感じにまわりくどくなってきました。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①
[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する②
[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する③

スケーリング調整タイプとステップ調整値とはなんぞや、
というところまできました。

参照するドキュメントは以下のあたりです。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-scaling-simple-step.html#as-scaling-adjustment

5.スケーリング調整タイプ


ドキュメントの言葉を借りると以下の通り。
ステップスケーリングまたは簡易スケーリングポリシーが実行されると、ポリシーで指定したスケーリング調整値を使用して Auto Scaling グループの現在の容量が変更されます。スケーリング調整では、グループの容量が最大グループサイズより大きい容量にも、最小グループサイズよりも小さい容量にも変更されることはありません。

微妙にわかりづらいですね。

簡単に言えばスケーリング調整タイプとは、
容量の変更の仕方を指定するものです。

「◯台増やす(減らす)」か、
「◯台にする」か、
「◯%分台数増やす(減らす)」か が選べます。

ここでいう「◯」がスケーリング調整値と呼ばれるものです。

ちなみに、AutoScalingグループでは以下の容量を指定する必要があります。
グループサイズとも呼びます。

・希望
・最小
・最大

ここで指定した「最大」を超える台数に調整されることも、
「最小」を下回る台数に調整されることもない、と書かれています。

5.1.現在の容量と希望する容量


スケーリング調整タイプによってグループの「現在の容量」を変更できることはわかりました。

では具体的に「現在の容量」をどう変更するかというと、
「希望する容量」を変更することによって実現します。

「希望する容量」とは、グループサイズにおける「希望」のことです。
ドキュメントによっては「必要な容量」と訳されていたりします。

めんどくさいので「Desired Capacity」に統一することにします。
「現在の容量」は「Current Capacity」に統一します。

Current Capacityはコンソール画面で「インスタンス」と表記されている部分です。
英語だと「Instances」ですね。

autoscaling

基本的にDesired CapacityとCurrent Capacityは同一の値を取ります。
スケーリング動作が生じた時のみ以下の流れで調整が入ります。

・スケーリング調整タイプによってDesired Capacityが変更される
・Desired CapacityとCurrent Capacityの差異を埋めるべくCurrent Capacityが変更される

そしてまたDesired CapacityとCurrent Capacityが同一の値を取ることになります。

Desired Capacityは「最大」を超えないし「最小」を下回らない、
というのを改めて覚えておきましょう。

5.2.スケーリング調整タイプ詳細


スケーリング調整タイプは3種類あります。

それぞれ台数を増加させることも減少させることもあるわけですが、
表記が冗長になるので、以下では「増加させる場合」のみを例にとって書きます。
「減少させる」に読み替え可能です。
5.2.1.ChangeInCapacity

「◯台増やす」のパターンです。
スケーリング調整値として、増やしたいインスタンスの台数を指定します。
Desired Capacityがその台数分増加します。
5.2.2.ExactCapacity

「◯台にする」のパターンです。
スケーリング調整値として、稼働させたいインスタンスの台数を指定します。
Desired Capacityがその値に変更されます。
5.2.3.PercentChangeInCapacity

「◯%分台数増やす」のパターンです。
スケーリング調整値として、増やしたいインスタンスの割合(%)を指定します。
Desired Capacityが以下のように増加します。

・変更前のDesired Capacity(整数) × スケーリング調整値(%)を計算する
 ・結果が整数の場合…その値をDesired Capacityに追加
 ・結果が0と1の間の場合…1をDesired Capacityに追加
 ・結果が1以上で小数点を持つ場合…小数点を切り捨てた値をDesired Capacityに追加

オプションとして、「最低限この台数は追加したい」という値
(MinAdjustmentMagnitude)を指定可能です。

計算結果がMinAdjustmentMagnitudeより小さかった場合、
MinAdjustmentMagnitudeによって上書きされます。

*

今回もまわりくどく記したため、
ステップ調整値について書くスペースが無くなりました。

というわけで次回に持ち越しです。
以上です。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する③

2017.06.09

batchiです。

前回までの投稿でスケーリングプランの種類と、クールダウンの種類を抑えました。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①
[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する②

やっぱりこういうのは表で一覧化しないと捉えづらいよね、ということで、
各スケーリングプランとクールダウン/ウォームアップの対応をまとめます。

3.スケーリングプランごとのクールダウン/ウォームアップ


◯…適用される
×…適用されない







































スケーリングプラン デフォルトのクールダウン スケーリング固有のクールダウン ウォームアップ
インスタンス数の維持 × × ×
手動スケーリング × オーバーライド可能 ×
スケジュールに基づくスケーリング × × ×
シンプルスケーリングポリシーによる動的スケーリング オーバーライド可能 ×
ステップスケーリングポリシーによる動的スケーリング × ×

はい、こういった形となりました。
これでもう2度と迷うことがないですね。

こうなってくると、もはや気になるのは
シンプルスケーリングポリシーとステップスケーリングポリシーの違いだけですね。

4.シンプルスケーリングポリシーとステップスケーリングポリシー


どちらも動的スケーリングで用いられるポリシーです。

簡単に言えば、
シンプルスケーリングポリシーは「一回こっきり」、
ステップスケーリングポリシーは「細かく刻める」という違いがあります。
例)
シンプル:平均CPU使用率が80%以上で2台追加
ステップ:平均CPU使用率60%以上で1台、80%以上でもう1台追加


かつてはシンプルスケーリングポリシーしか存在しておらず、
ステップスケーリングポリシーは相対的に新しい概念となります。

「<メトリクス>が◯◯以上で△台追加(削除)」というくくりをステップと表現しますが、
ステップが1つの場合であってもステップスケーリングポリシーを用いることが推奨されています。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-scaling-simple-step.html
ステップ調整値が 1 つであっても、ステップスケーリングポリシーを使用することをお勧めします。このポリシーは、スケーリングアクティビティまたはヘルスチェック交換の最中でも、アラームを継続的に評価し、グループをロックしないためです。

冷やすよりは温める時代になってきたということですね。

4.1.スケーリング調整タイプとステップ調整値


シンプルスケーリングポリシーとステップスケーリングポリシーの違いは、
「一回こっきり」か「細かく刻める」かと書きました。

これをもう少し掘っていくと、
「ステップスケーリングポリシーのみステップ調整値という概念がある」
というところに行き着きます。

このステップ調整値という概念を理解するためには、
先にスケーリング調整タイプという概念の理解が必要です。

スケーリング調整タイプは、
シンプルスケーリングポリシーでも
ステップスケーリングポリシーでもあてはまる概念です。

さっそくスケーリング調整タイプについて学んでいこう、
というところで次回に持ち越しです。

やり方がまわりくどいですね。
こちらからは以上です。