Auto ScalingとSelf-Healing

ゴール

伸縮性と自己修復の基本動作は既習です。

ここでは、Amazon EC2 Auto Scalingを1つの制御系として見ます。

最小キャパシティ
        │
        ▼
希望するキャパシティ
        │
        ▼
最大キャパシティ

に対して、

負荷・スケジュール
↓
スケーリング制御
↓
希望するキャパシティを変更

する処理と、

異常判定
↓
置き換え制御
↓
現在の希望するキャパシティを回復

する処理を区別します。

さらに、

ヘルスチェック猶予期間
デフォルトのインスタンスウォームアップ
インスタンスメンテナンスポリシー

が、この制御へどのように影響するかを判断します。

1. Auto Scaling グループの中心状態は「希望するキャパシティ」

Auto Scaling グループでは、次の3つを区別します。

例えば、

最小 = 2
希望 = 4
最大 = 10

なら、

通常状態
↓
4のキャパシティを維持

することが基本です。

希望するキャパシティは、

2以上
10以下

の範囲で変更されます。

スケーリング条件がない状態では希望するキャパシティを維持し、インスタンスが予期せず終了した場合などにも代替インスタンスを起動してその値へ戻そうとします。

2. 「希望するキャパシティを変える制御」と「戻す制御」を分ける

同じように新しいインスタンスが起動していても、制御目的は異なります。

スケーリング

希望 = 4
↓
負荷増加
↓
スケーリングポリシー
↓
希望 = 6

基準となる希望するキャパシティそのものを変更しています。

異常インスタンスの置き換え

希望 = 4
↓
1台が異常
↓
置き換え
↓
正常なキャパシティを4へ回復

こちらでは、通常、

希望 = 4

という目標値を維持したまま、その目標を満たす構成員を入れ替えます。

ただし、置き換え中にスケーリングポリシーやスケジュールされたアクションで希望するキャパシティ自体が変更される場合があります。

その場合は、

置き換え開始時の希望値

へ固定して戻すのではなく、

現在の希望するキャパシティ

を基準に制御されます。

3. 最小・最大キャパシティはスケーリング可能範囲を制限する

例えば、

最小 = 2
希望 = 4
最大 = 4

で高負荷になったとします。

スケーリングポリシーが、

さらにキャパシティが必要

と判断しても、

希望するキャパシティ
→ 最大4まで

という制約があります。

逆に、

最小 = 2

なら、スケールインによって希望するキャパシティを1へ下げることはできません。

つまり、

スケーリングポリシー

だけではなく、

最小キャパシティ
+
最大キャパシティ

まで含めて伸縮可能範囲を判断します。

4. 可用性上必要な下限を最小キャパシティへ反映する

マルチAZ構成で、

低負荷時でも
複数の正常インスタンスを維持したい

という要件があるとします。

それにもかかわらず、

最小キャパシティ = 1

なら、負荷低下時には希望するキャパシティが1まで縮小する可能性があります。

したがって最小キャパシティは、

どこまでコストを削減できるか

だけではなく、

平常時・低負荷時にも
最低限どのキャパシティを残す必要があるか

から決めます。

5. スケーリングポリシーは「希望するキャパシティをどう変えるか」を決める

スケーリング方式は、負荷特性に合わせて選びます。

例えば、

毎週月曜日 09:00
必ず処理量が増える

なら、既知の時刻に合わせたスケジュールされたスケーリングを評価できます。

一方、

毎週似た需要パターンがある
↓
履歴から将来需要を予測したい

なら、予測スケーリングが候補になります。

6. ターゲット追跡ではキャパシティと関係するメトリクスを選ぶ

ターゲット追跡では、

キャパシティを増やす
↓
1台あたりの負荷が下がる

という関係を持つメトリクスが扱いやすくなります。

例えば、

平均CPU使用率
ALBRequestCountPerTarget

などです。

一方、

グループ全体の総リクエスト数

のように、

インスタンス数を増やしても
メトリクス自体がほぼ変わらない

ものは、ターゲット追跡の制御対象として適切でない場合があります。

判断軸は、

キャパシティを増減したとき
メトリクスが期待した方向へ変化するか

です。

7. 正常性判定とキャパシティ変更は別の入力を持つ

Auto Scaling グループは、

負荷を見る制御

と、

インスタンスが正常かを見る制御

を同時に持つことができます。

例えば、

CPU使用率上昇
↓
希望するキャパシティを増加

している最中に、

別のインスタンス
↓
ヘルスチェック失敗
↓
置き換え

が発生することもあります。

つまり、

スケーリング中だから
置き換えは停止する

とは限りません。

8. ヘルスチェック猶予期間は「異常判定が早すぎる」問題を調整する

新しいインスタンスがInServiceになっても、

アプリケーション起動
↓
依存先への接続
↓
リクエスト受付可能

まで時間が必要な場合があります。

例えばElastic Load Balancingのヘルスチェックが、アプリケーション初期化中の新規インスタンスをまだ利用不可と判断しているとします。

この段階でAmazon EC2 Auto Scalingがその結果を基にすぐ終了させると、

まだ初期化中
↓
ヘルスチェック失敗
↓
終了
↓
新しいインスタンス起動
↓
再び準備完了前に終了

となる可能性があります。

ヘルスチェック猶予期間は、このような起動直後の追加ヘルスチェックによる早すぎる終了を防ぐために利用します。

ただし、すべての異常判定を停止する期間ではありません。

EC2インスタンスが
running状態ではなくなる
↓
Amazon EC2 Auto Scalingが検出
↓
猶予期間中でも
Unhealthyとして置き換え対象

になります。

したがって、

猶予期間
=
どの異常でも無視する時間

とは考えません。

また、猶予期間を長くしすぎると、本当に利用できないインスタンスへの対応開始も遅くなるため、アプリケーションが準備完了になるまでの時間に合わせて設定します。

9. デフォルトのインスタンスウォームアップは「新キャパシティをいつ準備完了として扱うか」

新しいインスタンスが、

InService

になった直後でも、

アプリケーション初期化中
キャッシュ準備中
十分な処理能力をまだ出せない

ことがあります。

デフォルトのインスタンスウォームアップを設定すると、動的スケーリングでは初期化を終えていない新規インスタンスがCloudWatchメトリクスへ与える影響を抑えられます。

また、インスタンスメンテナンスポリシーを使用する場合には、新しいインスタンスがウォームアップを完了する前に正常キャパシティとして扱うことを防ぐためにも利用されます。

10. 猶予期間とウォームアップを分けて判断する

問題文で、

アプリケーション初期化中なのに
Elastic Load Balancingのヘルスチェック失敗で終了される

なら、ヘルスチェック猶予期間を考えます。

一方、

起動直後のインスタンスを
十分なキャパシティとして早く数えすぎる

ことが問題なら、デフォルトのインスタンスウォームアップを考えます。

11. インスタンスメンテナンスポリシーは置き換え中のキャパシティ範囲を制御する

インスタンスを置き換える際、

先に旧インスタンスを終了

すると、一時的に利用可能なキャパシティが減ります。

逆に、

先に新インスタンスを起動

すると、一時的に希望するキャパシティを超えることがあります。

インスタンスメンテナンスポリシーでは、

最小正常率
最大正常率

を使って、置き換え中に維持・許容するキャパシティ範囲を制御します。

最小正常率

希望するキャパシティに対して、

InService
+
正常
+
利用準備完了

でなければならないキャパシティの下限を表します。

例えば、

最小正常率 = 90%

なら、

置き換え中も
希望するキャパシティの90%相当を
正常かつ利用準備完了の状態で維持

することを基準にします。

最大正常率

希望するキャパシティに対して、

InServiceかつ正常
または
Pending

で存在できるキャパシティの上限を表します。

したがって、

最大正常率
=
正常なInServiceインスタンスだけを数える割合

ではありません。

新しいインスタンスを先に起動する場合などに、

置き換え中に
一時的にどこまで
キャパシティ増加を許容するか

を制御します。

12. 希望するキャパシティと置き換え可能範囲は別

例えば、

希望するキャパシティ = 10
最小正常率 = 90%
最大正常率 = 120%

なら、置き換え処理中は、

正常かつ利用準備完了の下限
→ 9相当

InServiceかつ正常
またはPendingを含む上側
→ 12相当

という範囲を基準に置き換えを進められます。

しかし最終的な目標は、

希望するキャパシティ = 10

です。

つまり、

最大正常率120%
=
希望するキャパシティを12へ変更

ではありません。

あくまで、

置き換え中に許容する
一時的なキャパシティ上限

です。

13. スケーリングとインスタンス置き換えは並行して動作できる

例えば最初に、

最小 = 4
希望 = 8
最大 = 16

だったとします。

インスタンス置き換え中に負荷が増え、

スケーリングポリシー
↓
希望するキャパシティ
8 → 12

となる場合があります。

インスタンスメンテナンスポリシーは、

希望するキャパシティを固定する仕組み

ではありません。

現在の希望するキャパシティを基準に
置き換え時のキャパシティ範囲を制御する

仕組みです。

そのため置き換え中でも、スケーリングポリシーやスケジュールされたアクションによって、設定された最小・最大キャパシティの範囲内で希望するキャパシティが変わる場合があります。

14. シナリオ：どの設定を見るべきかを分解する

状況

最小 = 4
希望 = 8
最大 = 12

のAuto Scaling グループがあります。

次の3つが発生しました。

① 高負荷になった

② 新規インスタンスは
   起動から3分間はリクエストを処理できない

③ インスタンス置き換え中も
   可用性をできるだけ落としたくない

判断

① 高負荷

スケーリングポリシー
+
最大キャパシティ

を確認します。

② 初期化時間

ヘルスチェック猶予期間
+
デフォルトのインスタンスウォームアップ

について、異常判定とキャパシティ評価のどちらを調整する必要があるか判断します。

③ 置き換え中の可用性

インスタンスメンテナンスポリシー
↓
最小正常率
最大正常率

を確認します。

このように、

Auto Scalingの問題

と一括りにせず、

何の制御値が
どの状態を決めているか

へ分解します。

15. 混同ポイント

16. SAP-C02での判断フロー

Auto Scaling グループの問題
↓
何が変化した？
│
├─ 需要
│   ↓
│   希望するキャパシティを変える制御
│   ↓
│   スケーリングポリシー
│   またはスケジュールされたアクション
│   ↓
│   最小・最大キャパシティの範囲内か
│
└─ インスタンスの正常性 / 置き換え
    ↓
    現在の希望するキャパシティを
    正常インスタンスで満たす
    ↓
    起動直後の追加ヘルスチェックによる
    早すぎる異常終了が問題？
    → ヘルスチェック猶予期間
    ↓
    新キャパシティの準備完了判定が問題？
    → デフォルトのインスタンスウォームアップ
    ↓
    置き換え中に維持・許容する
    キャパシティ範囲が問題？
    → インスタンスメンテナンスポリシー

最後に
↓
これらが並行動作した場合でも
可用性要件を満たせるか

まとめ

Amazon EC2 Auto Scalingでは、

最小キャパシティ
希望するキャパシティ
最大キャパシティ

が制御状態の中心です。

スケーリング
→ 希望するキャパシティを変える

のに対し、

異常置き換え
→ 現在の希望するキャパシティを満たし直す

という違いがあります。

さらに、

ヘルスチェック猶予期間
→ 起動直後の追加ヘルスチェックによる
   早すぎる終了を抑える

デフォルトのインスタンスウォームアップ
→ 新キャパシティを準備完了として扱う時期を制御

インスタンスメンテナンスポリシー
→ 置き換え中に維持・許容する
   キャパシティ範囲を制御

します。

SAP-C02では個別機能名だけでなく、どの設定がAuto Scaling グループのどの状態を変えるのかを判断します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional 試験ガイド（SAP-C02）
• Amazon EC2 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 — インスタンスメンテナンスポリシー