Open6
Auto Scaling ターゲット追跡ポリシー VS ステップスケーリングポリシー
techno.koki概要
ターゲット追跡ポリシー
閾値に設定したメトリクスを保つようにタスクを自動増減してくれる。
AWS マネージドで比較的ラクに導入できそう。
- 規定のメトリクス（CPU、メモリ）を閾値に指定
- 閾値を維持するように、タスク数を自動増減
- メトリクスが大きいほど、多くのタスクを追加する
- タスク数自動増減には、Cloud Watch アラームが使用される
- Cloud Watch アラームは、Auto Scaling 作成時に、同時に自動作成される
- ステップスケーリングのように、細かい段階ごとの定義が不要
ステップスケーリングポリシー
閾値を段階的に設定して、各段階毎に異なるタスク数の増減を設定できる。
適切な設定をするのが簡単じゃない。
- 閾値の段階毎に、増減するタスク数などを指定可能
- ターゲット追跡よりもユーザーが細かく指定できる、みたいな印象
- クールダウンの他に、ウオームアップが使える
- スケーリング中に次のスケーリング指示が来た場合、後者の指示数のスケーリングを適用
techno.kokiステップスケーリングのメリット
- 閾値毎にスケーリングポリシーを設定できるので、「閾値負荷80%」のような急激な負荷増大が来た場合には、タスクを10個追加する、のような柔軟な追加が可能
参考
techno.kokiスケーリングメトリクスが、スケーラブルなターゲットのキャパシティに比例してスケールする使用率メトリクスである場合には、
ターゲット追跡スケーリングポリシーを使うのが良い
参考
techno.koki緩やかなアクセス増減に対するスケールには、ターゲット追跡が向いている
急激なアクセス増減には、段階追跡が向いている
といえる、らしい
参考
techno.koki色々と試行錯誤している記事
参考
techno.kokiAmazon ECS サービスの Auto Scaling は Application Auto Scaling ステップスケーリングポリシーの使用をサポートしていますが、代わりにターゲット追跡ポリシーを使用することをお勧めします。たとえば、CPU 使用率が特定のレベルを下回ったまたは上回ったときにサービスをスケーリングする場合は、Amazon ECS によって提供される CPU 使用率メトリクスに基づいてターゲット追跡スケーリングポリシーを作成します。