オートスケールの「振動」を防ぐ: AWS のポリシー選び（Target Tracking / Step / Simple / Scheduled）と Kubernetes HPA の tolerance
普段は Target Tracking、急な跳ね上がりには Step、決まったピークには Scheduled。どれを選んでも、Cooldown・Warm-up（HPA なら tolerance と安定化ウィンドウ）を短くしすぎると増減を繰り返す。
どんなときに使う？
- Auto Scaling グループや ECS サービスのスケーリングポリシーをどれにするか迷っている
- 台数（Pod 数）が数分おきに増えたり減ったりして落ち着かない
- HPA の目標値（例: CPU 60%）を変えたのに、思ったほど反応しない／反応しすぎる
AWS: 4 つのポリシーの使い分け（@dkfj の整理）
| ポリシー | 向いている場面 | 一言メモ |
|---|---|---|
| Target Tracking | ほとんどの通常負荷 | 「CPU 50% を保つ」のように目標値だけ決める。最近の推奨 |
| Step Scaling | 急激な負荷変化 | 「閾値をどれだけ超えたか」で増やす台数を段階的に変えられるので、大きなスパイクに一気に追いつける |
| Simple Scaling | 古い構成・単純な用途 | 1 回動くと Cooldown が終わるまで次の調整をしない。反応が遅い |
| Scheduled Scaling | 時刻が決まったピーク | 朝 9 時・セール開始など、来ると分かっている負荷を先回りで確保 |
組み合わせることも多い（例: 平常時は Target Tracking、既知のピークは Scheduled で最低台数を上げておく）。
振動（フラッピング）の原因は時間設計
- Warm-up（インスタンスのウォームアップ）: 新しいインスタンスが起動してメトリクスが安定するまでの時間。短すぎると「まだ負荷を受け持てていない新入り」を数に入れずに負荷が高いと判断し、さらに追加してしまう → 増えすぎて今度は縮小
- Cooldown: Simple Scaling で、スケール後に次の調整を待つ時間。短すぎると同じスパイクに何度も反応する
- 目安は「起動〜ヘルスチェック合格〜メトリクスに反映」までの実測時間。アプリの起動が遅い（JVM・大きなコンテナ）ほど長くする
Kubernetes HPA: tolerance も閾値の一部
HPA は 望ましいレプリカ数 = ceil(現在数 × 現在値 / 目標値) で計算するが、比率が 1.0 に近いあいだは何もしない。この「近い」の幅が tolerance（既定 0.1 = ±10%）。
- 目標 CPU 60% なら、およそ 54%〜66% の間は増減しない。閾値を変えるときは、この不感帯も一緒に考える（@matsuu がメルカリの Elasticsearch の記事に付けたコメントの要点）
- Kubernetes 1.33 から HPA ごとに設定でき、1.37 で安定版になった。スケールアップとダウンで別の値にできる
yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
behavior:
scaleUp:
tolerance: 0.05 # 目標の 5% 超えで増やし始める（早めに反応）
scaleDown:
tolerance: 0.15 # 15% 下回るまで減らさない（減らしすぎ防止）
stabilizationWindowSeconds: 300 # 既定。直近 5 分の推奨値の最大を採用して緩やかに減らす- クラスター全体の既定は kube-controller-manager の
--horizontal-pod-autoscaler-toleranceで変える（API からは変えられない） - スケールダウンの安定化ウィンドウは既定 300 秒、スケールアップは 0 秒（すぐ増やす）。AWS の Cooldown に相当する考え方
注意点
- tolerance を小さくするほど反応は早くなるが、メトリクスの揺れでも動くようになる。小さくするなら安定化ウィンドウやスケーリングポリシー（何秒で何 Pod まで）で上限をかける
- 起動直後の Pod は CPU を一時的に多く使うことがある。HPA は
--horizontal-pod-autoscaler-cpu-initialization-period（既定 5 分）の間、準備中の Pod の CPU を割り引いて扱う - AWS 側の詳細な既定値はサービス（EC2 Auto Scaling / ECS / Application Auto Scaling）で異なるので、各ドキュメントで確認する
出典
- @dkfj · 2026-10-18
- @matsuu · 2026-10-18
- メルカリエンジニアリング「Elasticsearch の Autoscaling を改善する: scale-out の高速化と HPA tolerance の調整」: engineering.mercari.com
- Kubernetes ドキュメント「Horizontal Pod Autoscaling」: kubernetes.io