この記事の目的
スケーリングポリシーについて簡単に学ぶ
オンデマンドリソースとプロビジョンドリソース
スケーリングポリシーの前に、オンデマンドとプロビジョンドの違いについて、簡単にまとめます。
モデルをデプロイする際は、要件に応じてリソースを選択する必要があります。（たとえばEC2については、オンデマンドで動かすのか、リザーブドで動かすのか、といった選択肢があります。）
| オンデマンドリソース | プロビジョンドリソース | |
|---|---|---|
| リソース提供 | 必要な時に使わせてもらう | 事前に予約して確保しておく |
| 料金 | 従量課金（使ったら使っただけかかる） | 固定料金（あらかじめ決まった額を支払う） |
| 柔軟性 | 必要な分だけ確保できるので高い | あらかじめ予約しておくので、低い |
| ユースケース | 短期的または需要の予測が難しい場合 | 長期的または需要が安定している場合 |
| コスト効率 | 短期利用なら良い | 長期利用なら良い |
| パフォーマンス | 不測の事態には対応できない恐れがある | 事前に予約しておくので安定 |
スケーリングポリシーについて
クラウド文化にはスケーリングがつきものです。（偏見）
AWS では主に AutoScaling を使用してスケーリングを管理しますが、その手法についてもいくつかあるので簡単にまとめます。
手動スケーリング
管理者が手動でポチポチ増やす。
動的スケーリング
-
ターゲット追跡スケーリング
- メトリクス (CPU使用率など) が目標の値へ近づくようにスケールイン、もしくはスケールアウトする。CPU使用率が90%以下を保てるようにインスタンス台数を調整する、みたいな設定ができる
-
ステップスケーリング
- メトリクスに基づいてスケールイン、もしくはスケールアウトする。CPU使用率が90%を超えたらインスタンスを1台ふやす、みたいな設定ができる
-
シンプルスケーリング
- 条件が満たされると、1回だけアクションを実行する。CPU使用率が90%を超えたらインスタンスを1台ふやす、という条件を定めたら、それが1回だけ実行される。古いポリシー
スケジューリングスケジューリング
決められたタイミングでインスタンスの台数を増減する。たとえば、金曜日の夜はトラフィックが増加するので、金曜日の18時になったらインスタンスを3台増加する、みたいな設定ができる。
予測スケーリング
過去24時間以上最長14日間のメトリクスを参考に、トラフィックを予測してスケーリングポリシーを作成する。
SageMaker のエンドポイントについても、ほぼ同様のスケーリングが用意されています。