AWS Auto Scalingをちゃんと理解したかった話

インフラ触り始めた頃、「Auto Scalingってなんか自動でサーバー増えるやつでしょ」くらいの理解でなんとなく設定してたんですけど、最近ちゃんと向き合う機会があって、改めて整理してみました。

意外と知らなかったこととか、「あー、そういうことだったのか」ってなったことがけっこうあったので、まとめておこうかなと思います。

Auto Scalingって何者？

一言で言うと、アプリの負荷に応じてサーバーを自動的に増やしたり減らしたりする仕組みです。

EC2インスタンスを管理する「EC2 Auto Scaling」が一番よく使われますが、ECSやDynamoDB、Auroraなど他のサービスにも使える「Application Auto Scaling」ってものもあって、それらをまとめて管理できる「AWS Auto Scaling」という統合サービスもあります。最初この3つの名前に混乱したんですが、普通にEC2を使う場合はEC2 Auto Scalingだけ知ってれば大体なんとかなります。

構成としてはだいたいこんな感じで使うことが多いです。

Internet
    ↓
[ALB / NLB]
    ↓
[Auto Scaling Group]
  ├── EC2 (AZ-a)
  ├── EC2 (AZ-b)
  └── EC2 (AZ-c)  ← 負荷増加時に自動追加

ALBの後ろにAuto Scaling Group（ASG）を置いて、インスタンスが増えたら自動的にロードバランサーに追加、減ったら外す、みたいな動きをしてくれます。これが地味に便利で、手動でEC2追加してターゲットグループに登録して……みたいな作業が全部自動になります。

スケーリングポリシーの種類が意外と多い

これが一番「ちゃんと知らなかったな」と思ったところで、スケーリングの戦略がいくつかあります。

ターゲット追跡スケーリングは一番シンプルで、「CPU使用率を50%にキープしてくれ」と目標値を設定すると、それを維持するようにAWSが勝手に計算してスケールしてくれます。自分でアラームを細かく設定しなくていいので、最初はこれを使うのが無難です。

ステップスケーリングは「CPU60%超えたら1台追加、80%超えたら3台追加」みたいに、閾値に応じてスケール量を段階的に変えられます。負荷の急増に対してより素早く対応したい場合に使いますが、設定がやや複雑です。

スケジュールスケーリングは時間帯で事前にスケールしておく方法。「毎日9時に最小台数を5台に増やす」とか「週末は2台に絞る」みたいな使い方ができます。アクセスパターンが読める場合はこれを組み合わせると効率がいいです。

予測スケーリングが個人的にいちばん「へー」ってなったやつで、過去のトラフィックデータをMLで分析して、ピーク前に事前にスケールアウトしておいてくれます。リアクティブ（反応的）じゃなくプロアクティブ（先手を打つ）に動いてくれるので、急激な負荷増加でインスタンスが起動する前に捌けなくなる問題を緩和できます。

クールダウンとウォームアップ、ちゃんと区別できてた？

正直ここはなんとなくで理解してたので改めて整理しました。

クールダウン期間は、スケーリングが発動した後、次のスケーリングアクションまで待つ時間のことです。デフォルトは300秒（5分）。これがないと、インスタンスが起動しきる前にアラームが反応してまたスケールアウト……みたいなことが起きます。

ウォームアップ期間は、新しく起動したインスタンスがメトリクスの計算に含まれるまでの時間です。起動直後のインスタンスはまだリクエストを受け切れてない状態なので、それをスケーリングの判断から除外するための仕組みです。

この2つを混同してたんですが、「クールダウン＝スケーリング後の待機」「ウォームアップ＝新インスタンスが安定するまでの猶予」と覚えると整理しやすいです。

Lifecycle Hookが便利そう

あんまり使ったことなかったんですが、スケールアウト・スケールイン時にカスタム処理を挟める仕組みで、知っておくと役立つ場面があります。

例えばスケールイン（インスタンス削除）時に、いきなりTerminateするんじゃなくて「まず処理中のリクエストを全部捌いてから落とす」とか、「ログをS3に退避してから落とす」みたいなことができます。本番環境だと突然インスタンスが消えると困るケースがあるので、Lifecycle Hookで猶予時間を設けておくのがつらかった経験から学んだことです。

コスト最適化との組み合わせが面白い

スポットインスタンスとAuto Scalingを組み合わせると、コストをかなり下げられます。オンデマンド価格の最大90%オフで使えるスポットインスタンスをASGに混在させる「混合インスタンスポリシー」という設定があって、「常時起動のベース台数はオンデマンド、追加分はスポット」みたいな構成ができます。

スポットインスタンスは突然終了される可能性があるので全台スポットにするのはリスクですが、Lifecycle Hookと組み合わせて終了通知を受け取って安全に処理を移行するとか、工夫次第でかなりいい感じにできます。

Auto Scalingは「とりあえず設定しとく」から「意図を持って設計する」ものだなぁと改めて思いました。ターゲット追跡だけじゃなくて、スケジュールや予測スケーリングを組み合わせると、コストと可用性のバランスがめっちゃ良くなるので、まだ試してない方はぜひ触ってみてください。

これはclaude codeで生成しました。

らしいです。自我を持ってて面白いですね。