Auto Scaling はなぜスケールアウトは速く、スケールインは慎重なのか - 非対称な判断ロジックの設計意図
EC2 Auto Scaling がスケールアウトを即座に実行する一方でスケールインに冷却期間を設ける非対称な設計の理由、フラッピング防止の仕組み、ターゲット追跡スケーリングの内部ロジックを解説します。
スケールアウトとスケールインの非対称性
EC2Auto Scaling のデフォルト設定では、スケールアウト (インスタンスの追加) の冷却期間は 0 秒 (即座に実行)、スケールイン (インスタンスの削除) の冷却期間は 300 秒 (5 分) です。この非対称な設定には明確な設計意図があります。スケールアウトが遅れると、ユーザーに直接影響します。トラフィックが急増しているのにインスタンスが追加されなければ、レスポンスタイムが悪化し、最悪の場合はサービスがダウンします。したがって、スケールアウトは可能な限り速く実行すべきです。一方、スケールインが速すぎると、フラッピング (頻繁なスケールアウトとスケールインの繰り返し) が発生します。トラフィックが一時的に減少してインスタンスを削除した直後に、再びトラフィックが増加してインスタンスを追加する、という無駄なサイクルが繰り返されます。インスタンスの起動には数分かかるため、フラッピングはパフォーマンスの劣化とコストの増加を同時に引き起こします。
冷却期間 (Cooldown) の仕組み
冷却期間は、スケーリングアクションが実行された後、次のスケーリングアクションを抑制する時間です。スケールアウトの冷却期間中は、追加のスケールアウトは抑制されますが、スケールインは実行できます。逆に、スケールイン冷却期間中は、追加のスケールインは抑制されますが、スケールアウトは実行できます。この設計により、「スケールアウトが必要なのにスケールイン冷却期間中だから実行できない」という事態は発生しません。冷却期間の最適値は、ワークロードの特性によって異なります。EC2 インスタンスの起動から ELB のヘルスチェックに合格するまでの時間が 3 分であれば、スケールアウトの冷却期間は 3 分以上に設定すべきです。冷却期間が短すぎると、新しいインスタンスがまだトラフィックを処理していない段階で「まだ足りない」と判断され、過剰なスケールアウトが発生します。ターゲット追跡スケーリングポリシーを使用する場合、冷却期間は自動的に管理されるため、手動での設定は不要です。
ターゲット追跡スケーリングの内部ロジック
ターゲット追跡スケーリング (Target Tracking Scaling) は、指定したメトリクスのターゲット値を維持するようにインスタンス数を自動調整する最も推奨されるスケーリングポリシーです。たとえば、CPU 使用率のターゲットを 50% に設定すると、Auto Scaling は CPU 使用率が 50% を維持するようにインスタンス数を増減します。内部的には、ターゲット追跡スケーリングは PID コントローラー (比例・積分・微分制御) に似たアルゴリズムで動作しています。現在のメトリクス値とターゲット値の差 (偏差) に基づいて、必要なインスタンス数を計算します。偏差が大きいほど、一度に追加・削除するインスタンス数が多くなります。ターゲット追跡スケーリングの重要な特性は、スケールアウトとスケールインで異なるアラームを内部的に作成することです。スケールアウトアラームは 3 分間の評価期間で 3 回連続して閾値を超えた場合に発火し、スケールインアラームは 15 分間の評価期間で 15 回連続して閾値を下回った場合に発火します。この非対称な評価期間が、「速いスケールアウト、慎重なスケールイン」を実現しています。
スケールインで削除されるインスタンスの選択ロジック
スケールインが実行される際、どのインスタンスが削除されるかは、デフォルトの終了ポリシーに従って決定されます。デフォルトのロジックは 3 段階です。第 1 に、インスタンスが最も多い AZ を選択します。これにより、AZ 間のインスタンス数のバランスが維持されます。第 2 に、その AZ 内で最も古い起動設定 (Launch Configuration) または起動テンプレート (Launch Template) を使用しているインスタンスを選択します。これにより、古い設定のインスタンスが優先的に削除され、新しい設定への移行が促進されます。第 3 に、同じ起動設定のインスタンスが複数ある場合、次の課金時間に最も近いインスタンスを選択します。EC2 の 1 秒課金が導入された現在、この基準の実質的な意味は薄れていますが、ロジックとしては残っています。カスタム終了ポリシーを設定することも可能です。NewestInstance (最新のインスタンスを削除)、OldestInstance (最古のインスタンスを削除)、ClosestToNextInstanceHour (次の課金時間に最も近いインスタンスを削除) などのポリシーを選択できます。
予測スケーリング - 過去のパターンから未来を予測する
2021 年に導入された予測スケーリング (Predictive Scaling) は、過去 14 日間のトラフィックパターンを機械学習で分析し、将来のトラフィックを予測してインスタンスを事前にプロビジョニングする機能です。たとえば、毎朝 9 時にトラフィックが急増するパターンがある場合、予測スケーリングは 8:50 頃からインスタンスを追加し始め、9 時のトラフィック急増に備えます。リアクティブなスケーリング (トラフィックが増えてからインスタンスを追加) では、インスタンスの起動と ELB への登録に数分かかるため、トラフィック急増の初期にパフォーマンスが劣化します。予測スケーリングはこのギャップを埋めます。予測スケーリングは、ターゲット追跡スケーリングと併用することが推奨されます。予測スケーリングが「予想されるベースライン」を事前にプロビジョニングし、ターゲット追跡スケーリングが「予想外の変動」に対応する、という役割分担です。予測スケーリングの予測精度は、トラフィックパターンの規則性に依存します。毎日同じパターンを繰り返すワークロードでは高い精度が得られますが、不規則なトラフィックパターンでは予測が外れることがあります。スケーリング設計のパターンを体系的に学ぶには、専門書籍 (Amazon)が参考になります。