概要
「平均 CPU 使用率が 70% を超えたら、インスタンスを増やしたい」。EC2 Auto Scaling でこれを実現する方法は 1 つではありません。自分で CloudWatch アラームを作ってスケーリングポリシーを呼び出す方法（シンプルスケーリング・ステップスケーリング）と、目標値だけを決めればアラームを Auto Scaling が作ってくれる方法（ターゲット追跡スケーリング）があります。
どちらも「アラームが鳴ったらポリシーが動き、希望する容量が変わる」という同じ仕組みの上に乗っています。違うのは、アラームを誰が作り、どこまで細かく増減を決めるかです。この関係が分かっていれば、Lambda や Step Functions を挟まなくても、アラームから直接スケーリングできることも分かります。
この記事では、3 種類の動的スケーリングポリシーの違いと、CloudWatch アラームとのつながりを整理します。実践では、自分で作ったアラームのアクションにシンプルスケーリングポリシーをつなぎ、アラームの状態を切り替えてスケールアウトすることを確かめます。そのあとターゲット追跡ポリシーを作り、アラームが自動で作られることを見比べます。
クラウドおさる猿山の見張り台でも、「鐘が鳴ったら当番を 1 匹足す」と決めるやり方と、「見張りの疲れ具合を半分に保て」とだけ長老会が決めるやり方があるのでござる。今日はその違いを、手を動かして確かめるでござるよ。
この記事のメリット
- シンプルスケーリング・ステップスケーリング・ターゲット追跡スケーリングの違いと使いどころが分かる
- CloudWatch アラームのアクションからスケーリングポリシーを直接呼び出せることが分かる
- ターゲット追跡では、アラームを Auto Scaling が作成・管理することを確かめられる
- 「ピーク時だけ負荷が上がる」ときに、固定台数や大きなインスタンスではなく、動的スケーリングを選ぶ理由を説明できるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
動的スケーリングの仕組み
動的スケーリングは、CloudWatch のメトリクスに応じて Auto Scaling グループの 希望する容量 を変える仕組みです。最小容量と最大容量の範囲で、希望する容量が増えればインスタンスを起動し、減れば終了します。
希望する容量を変えるのはスケーリングポリシーで、ポリシーを呼び出すのは CloudWatch アラームです。アラームがしきい値を超えて ALARM 状態になると、アラームのアクションに指定したスケーリングポリシーが実行されます。
| つなぎ方 | アラームを作るのは | ポリシーの種類 |
|---|---|---|
| 自分でアラームを作り、そのアクションにポリシーを指定する | 自分 | シンプルスケーリング・ステップスケーリング |
| 目標値を決めてポリシーを作る | Auto Scaling（自動で作成・管理） | ターゲット追跡スケーリング |
アラームのアクションには Auto Scaling のスケーリングポリシーを直接指定できるので、間に Lambda 関数や Step Functions を挟む必要はありません。
3 種類のポリシーの違い
| 項目 | シンプルスケーリング | ステップスケーリング | ターゲット追跡スケーリング |
|---|---|---|---|
| 決めること | アラームと、1 回の増減数 | アラームと、超過の幅ごとの増減数 | メトリクスと目標値（例: 平均 CPU 50%） |
| CloudWatch アラーム | 自分で作り、アクションにポリシーを指定する | 同左 | Auto Scaling が作成・管理する。自分で編集・削除しない |
| 増減の決め方 | アラームが鳴るたびに同じ数だけ増減 | しきい値をどれだけ超えたかで、増減数を段階的に変える | 目標値に近づくように、必要な台数を Auto Scaling が計算する |
| 次のスケーリングまで | スケーリングアクティビティとクールダウン期間（既定 300 秒）が終わるまで、追加のアラームに応答しない | アクティビティの途中でも、追加のアラームに応答する。新しいインスタンスはウォームアップの間、集計から外す | 同左（ウォームアップを使う） |
| 推奨度 | 新しく作るならステップかターゲット追跡が推奨されている | 増減を細かく決めたいとき | 平均 CPU 使用率やターゲットあたりのリクエスト数で増減するなら、まずこれ |
ステップスケーリングのステップは、しきい値からの差で範囲を決めます。たとえばしきい値 70% のアラームに「70〜85% なら 1 台、85% 以上なら 2 台追加」と設定すると、超え方が大きいときほど多く増やせます（コンソールでは範囲を絶対値で、CLI では しきい値からの差で指定します）。
クラウドおさるシンプルは「鐘が鳴ったら 1 匹足して、しばらく様子見」、ステップは「鐘の鳴り方で足す数を変える」、ターゲット追跡は「疲れ具合を半分に保て」とだけ言っておく方式でござる。鐘（アラーム）を誰が吊るすかが、一番の違いでござるな。
ターゲット追跡スケーリング
ターゲット追跡スケーリングでは、メトリクスと目標値を指定するだけで、Auto Scaling がスケールアウト用とスケールイン用の CloudWatch アラームを作ります。アラームの名前は TargetTracking-<グループ名>-AlarmHigh-… と TargetTracking-<グループ名>-AlarmLow-… で始まります。
| 項目 | 内容 |
|---|---|
| 定義済みメトリクス | Auto Scaling グループの平均 CPU 使用率、平均ネットワーク入力・出力、ALB のターゲットあたりのリクエスト数 |
| アラームの管理 | Auto Scaling が作成・管理する。自分で作成・編集・削除しない。ポリシーを削除するとアラームも消える |
| スケールイン | 一時的に無効にでき、スケールアウトだけのポリシーにできる |
| 複数のポリシー | いずれかのポリシーがスケールアウトを求めればスケールアウトする。スケールインは、すべてのポリシーがスケールインできるときだけ |
ALB の裏の Web サーバーで、ピークのときだけ CPU が上がって 503 エラーが増えるような場合、ターゲット追跡で平均 CPU 使用率を目標値に保つと、ピークのときだけ台数が増え、ピークが過ぎれば減ります。台数を常に多くしておく、インスタンスタイプを大きくする、といった方法は、ピーク以外の時間に余分な費用がかかります。
クラウドおさるターゲット追跡が作ったアラームは、見慣れぬ名前でも勝手に消したり、しきい値を書き換えたりしてはならぬのでござる。長老会が吊るした鐘を若猿がいじると、見張りの勘定が狂うのでござるぞ。
実践
Auto Scaling グループ soa-scaling-asg（最小 1・希望 1・最大 3）に、2 つのつなぎ方でスケーリングを設定します。まず、シンプルスケーリングポリシー soa-simple-scale-out と、それを呼び出すアラーム soa-scaling-cpu-high を作ります。実際に CPU に負荷をかける代わりに、CLI でアラームの状態を ALARM に切り替えて、ポリシーが呼ばれてインスタンスが増えることを確かめます。そのあと、ターゲット追跡ポリシー soa-cpu50 を作り、アラームが自動で作られることを見比べます。
前提条件
- リージョン:
ap-northeast-1（東京） - 以下のリソースが作成済みであること
まだ用意していない場合は、「作り方の参考」の記事の手順で作れます。リソース名は、この記事の名前に読み替えてください。
| リソース種別 | リソース名 | 内容 | 作り方の参考 |
|---|---|---|---|
| 起動テンプレート | soa-scaling-template | Amazon Linux 2023・t3.micro | EC2 Auto Scaling で落ちても自動で戻る Web サーバーを作る |
| Auto Scaling グループ | soa-scaling-asg | soa-lab-vpc のパブリックサブネット（1a・1c）。最小 1・希望 1・最大 3。スケーリングポリシーは無し | 同上 ※ロードバランサーとスケーリングポリシーは作らない |
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| スケーリングポリシー（シンプル） | soa-simple-scale-out | 1 台追加する。クールダウン 300 秒 |
| CloudWatch アラーム | soa-scaling-cpu-high | グループの平均 CPU 使用率が 70% を超えたら soa-simple-scale-out を呼ぶ |
| スケーリングポリシー（ターゲット追跡） | soa-cpu50 | 平均 CPU 使用率 50% を目標にする |
| CloudWatch アラーム（自動作成） | TargetTracking-soa-scaling-asg-AlarmHigh-… / …-AlarmLow-… | soa-cpu50 が作る |
手順 1: シンプルスケーリングポリシーを作る
AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。上部のツールバーの CloudShell アイコンをクリックして AWS CloudShell を開き、次のコマンドでシンプルスケーリングポリシーを作ります（コンソールでも、グループの「オートスケーリング」タブの「動的スケーリングポリシーを作成する」でポリシータイプに「シンプルなスケーリング」を選べば作れます。ここでは、アラームを後からつなぐ流れを見やすくするため CLI で作ります）。
aws autoscaling put-scaling-policy \
--auto-scaling-group-name soa-scaling-asg \
--policy-name soa-simple-scale-out \
--policy-type SimpleScaling \
--adjustment-type ChangeInCapacity \
--scaling-adjustment 1 \
--cooldown 300出力に PolicyARN が表示されれば作成できています。この時点では、まだどのアラームからも呼ばれません。
手順 2: アラームを作り、アクションにポリシーを指定する
上部の検索バーに CloudWatch と入力し、「CloudWatch」を選択します。左側ナビゲーションの「アラーム」→「すべてのアラーム」を選択し、「アラームの作成」をクリックします。
「メトリクスの選択」をクリックし、「EC2」→「Auto Scaling グループ別」を選択します。soa-scaling-asg の CPUUtilization にチェックを入れ、「メトリクスの選択」をクリックします。
メトリクスと条件を以下のように設定し、「次へ」をクリックします。
- 統計:
平均 - 期間:
5 分 - しきい値の種類:
静的 - 条件:
より大きい、しきい値70
「アクションの設定」で、「Auto Scaling アクションの追加」をクリックし、以下を設定します（通知が既定で表示されている場合は「削除」で外します）。
- アラーム状態トリガー:
アラーム状態 - リソースタイプ:
EC2 Auto Scaling グループ - グループの選択:
soa-scaling-asg（候補に出るのは、シンプルまたはステップスケーリングのポリシーを持つグループだけです） - アクション:
soa-simple-scale-out (1 インスタンスの追加)が自動で入ることを確認
「次へ」をクリックし、アラーム名に soa-scaling-cpu-high と入力して「次へ」→「アラームの作成」をクリックします。作成直後は「データ不足」で、データが集まると、いまは CPU にほとんど負荷が無いので状態は OK になります。
手順 3: アラームの状態を切り替えてスケールアウトさせる
CloudShell に戻り、アラームの状態を手動で ALARM に切り替えます。
aws cloudwatch set-alarm-state \
--alarm-name soa-scaling-cpu-high \
--state-value ALARM \
--state-reason "test: scale out by simple scaling policy"EC2 のコンソールを開き、左側ナビゲーションの「Auto Scaling」→「Auto Scaling グループ」から soa-scaling-asg を開きます。「アクティビティ」タブの「アクティビティ履歴」に、新しいインスタンスを起動する行が追加されています。原因（説明）の欄に、アラーム soa-scaling-cpu-high が ALARM 状態になってポリシー soa-simple-scale-out が実行され、希望する容量が 1 から 2 に変わったことが記録されています。
アラームは、次の評価で実際のメトリクスに基づいて OK に戻ります。シンプルスケーリングは、このあとクールダウンの 300 秒が終わるまで、追加のアラームに応答しません。
クラウドおさる鐘（アラーム）を鳴らしただけで、当番が 1 匹増えたでござる。間に伝令（Lambda）を立てなくても、アラームのアクションからポリシーを直接呼べるのでござるな。
手順 4: ターゲット追跡ポリシーを作る
soa-scaling-asg の「オートスケーリング」タブを選択します。「動的スケーリングポリシー」に soa-simple-scale-out のカードがあり、ポリシータイプが「シンプルなスケーリング」、「次の場合に、ポリシーを実行」が soa-scaling-cpu-high になっていることを確認します。
「動的スケーリングポリシーを作成する」をクリックし、以下を設定します。
- ポリシータイプ:
ターゲット追跡スケーリング - スケーリングポリシー名:
soa-cpu50 - メトリクスタイプ:
平均 CPU 使用率 - ターゲット値:
50
インスタンスのウォームアップ、「スケールインを無効にしてスケールアウトポリシーのみを作成する」など、その他の項目はデフォルトのままにして、「作成」をクリックします。
ここでは、アラームを選ぶ欄がありません。ターゲット追跡では、アラームを自分で用意しないためです。
手順 5: 自動で作られたアラームを確かめる
「オートスケーリング」タブの「動的スケーリングポリシー」に、soa-simple-scale-out（シンプルスケーリング）と soa-cpu50（ターゲット追跡スケーリング）の 2 つが並んでいることを確認します。
CloudWatch のコンソールに戻り、「アラーム」→「すべてのアラーム」を開きます。検索欄に soa-scaling と入力して絞り込むと、自分で作った soa-scaling-cpu-high のほかに、TargetTracking-soa-scaling-asg-AlarmHigh- と TargetTracking-soa-scaling-asg-AlarmLow- で始まる 2 つのアラームが作られていることが確認できます。
AlarmHigh は平均 CPU 使用率が目標値を上回ったとき、AlarmLow は下回ったときのアラームです。条件の列を見ると、この実践では AlarmHigh が CPUUtilization > 50（3 データポイント）、AlarmLow が CPUUtilization < 45（15 データポイント）でした。スケールイン側はしきい値が少し低く、評価の期間も長く取られているので、増減を繰り返しにくくなっています。負荷の無い状態がしばらく続くと AlarmLow が ALARM になり、手順 3 で 2 台に増えたグループは、最小容量の 1 台へ向けてスケールインします。
クラウドおさる同じ「CPU で増やす」でも、鐘を自分で吊るしたのがシンプル、長老会が勝手に吊るしてくれたのがターゲット追跡でござった。中身は同じアラームとポリシーの組み合わせだと分かると、見通しがよくなるでござるな。
まとめ
| やりたいこと | 選ぶもの |
|---|---|
| 平均 CPU 使用率などを目標値に保ちたい（多くの場合） | ターゲット追跡スケーリング |
| しきい値の超え方に応じて、増減数を段階的に変えたい | ステップスケーリング（自分でアラームを作る） |
| 既存のアラームで 1 段だけ増減したい | ステップスケーリング（ステップ 1 つ）。シンプルスケーリングはクールダウン中に応答しない |
| アラームが鳴ったらスケールアウトしたい | アラームのアクションにスケーリングポリシーを直接指定する。Lambda などは挟まない |
- 動的スケーリングは、CloudWatch アラームがスケーリングポリシーを呼び、ポリシーが希望する容量を変える仕組み
- シンプル・ステップはアラームを自分で作ってアクションにポリシーを指定する。ターゲット追跡はアラームを Auto Scaling が作成・管理する
- シンプルはアクティビティとクールダウンが終わるまで追加のアラームに応答しない。ステップとターゲット追跡はウォームアップを使い、途中でも応答する
- ターゲット追跡のアラーム（
TargetTracking-…-AlarmHigh/AlarmLow）は自分で編集・削除しない - ピーク時だけ負荷が上がるなら、固定台数や大きなインスタンスではなく、動的スケーリングで必要なときだけ増やす
起動に時間がかかるアプリでのウォームアップの設定や、混む時刻に先回りするスケジュール・予測スケーリングは、Auto Scaling のウォームアップとは ── 起動が遅いアプリでインスタンスが増えすぎるのを防ぐ で扱っています。終了するインスタンスで処理を済ませたいときは、Auto Scaling のライフサイクルフックの使い方 ── インスタンスの終了前にデータの退避を済ませる を参照してください。
参照先
- Amazon EC2 Auto Scaling の動的スケーリング – Amazon EC2 Auto Scaling
- Amazon EC2 Auto Scaling のターゲットトラッキングスケーリングポリシー – Amazon EC2 Auto Scaling
- Amazon EC2 Auto Scaling のステップおよび簡易スケーリングポリシー – Amazon EC2 Auto Scaling
- 簡易スケーリングポリシー – Amazon EC2 Auto Scaling
- Amazon CloudWatch でのアラームの使用 – Amazon CloudWatch
