オートスケーリング講座

この講座では、AWSのAuto Scalingについて学びます。

• 固定台数構成の問題点（機会損失・余剰コスト・手動復旧）
• Auto Scalingの仕組みと3つの機能（スケールアウト・スケールイン・自動復旧）
• 水平スケーリングと垂直スケーリングの違い
• 起動テンプレートの作成方法
• Auto Scalingグループの設定
• スケーリングポリシーの種類（ターゲット追跡・スケジュール・予測）

1. 現状の問題点

ELBを使って複数サーバへの負荷分散を行いましたが、この構成にはまだ問題があります。

1.1 需要拡大時の機会損失

まず1つ目は、需要が拡大した場合の機会損失が生じる恐れがあるという点です。

Webシステムを始めとして、一般向けに使用されているシステムのアクセス数は常に変動しています。ある程度の予測はできるとしても、キャンペーンやSNSでの拡散などによる突発的な需要までは、完全に予測することはできません。

そうした際、あらかじめ用意した固定のサーバ台数では処理しきれなくなる可能性があります。 その結果、パフォーマンスの低下やシステムダウンが発生し、せっかくアクセスしてくれたユーザを逃してしまうことになります。これは、重要なビジネスチャンスの損失に直結します。

1.2 余剰リソースのコスト

続いて2つ目は、コストの無駄が生じる点です。

システムダウンを防ぐために、あらかじめ需要の増加を見越してサーバを増やしておいたとします。しかし、万が一予想よりもアクセスが少なかった場合、増やした分のサーバ費用がそのままコストとしてのしかかってきます。

また、システムのアクセスは1日中一定ではありません。早朝や夜間など需要が低下する時間帯であっても、ピーク時に合わせた台数を稼働させ続けることになり、無駄な課金が発生してしまいます。

つまり、需要を高く見積もりすぎた結果、必要以上のリソースを抱える「オーバースペック」な状態に陥ってしまうおそれがあります。

1.3 障害発生時の手動運用の負荷

前述の通り、ELBにはヘルスチェック機能があり、応答のない故障したサーバを自動で切り離すことは可能です。これにより、システム全体の完全停止という最悪のシナリオは回避できます。

しかし、切り離された分だけ稼働するサーバの台数が減ってしまうため、残ったサーバへの負荷が急増し、パフォーマンスが低下するリスクが残ります。

元の正常な状態（台数）に戻すためには、エンジニアが手動で新しいサーバを起動し、設定し直さなければなりません。いつ発生するかわからない障害に対し、常に人手でリカバリしなければならない点は、運用面でも精神面でも大きな負担となります。

2. Auto Scalingとは

これらの問題点を解決するのがAuto Scalingです。システムの負荷状況にあわせて、サーバの台数を自動的に増減させる仕組みです。あらかじめ設定したルール（例：「CPU使用率が70%を超えた場合」など）に基づき、AWS側で常に監視し、必要に応じてリソースをコントロールします。

Auto Scalingによるスケールアウトの流れを以下に示します。

flowchart LR
    CW["CloudWatch<br>（監視）"] -- "しきい値超過を検知" --> ASG["Auto Scaling Group"]
    ASG -- "スケールアウト指示" --> LT["起動テンプレート"]
    LT -- "EC2を作成" --> EC2["新規EC2インスタンス"]
    EC2 -- "自動登録" --> ELB["ELB<br>（ロードバランサー）"]

Auto Scalingが行うコントロールには、主に以下の3種類があります。

2.1 スケールアウト（拡張）

サーバの負荷が増加した場合に、自動的に新しいサーバを追加して処理能力を拡張します。 これにより、突発的なアクセス増加が発生した場合でもパフォーマンスを維持できるため、ビジネスの機会を失わずに済みます。なお、予算を超えないよう、極端にサーバ台数を増やしすぎないための「上限」を設けることも可能です。

2.2 スケールイン（縮小）

サーバへのアクセスが落ち着き、リソースに余剰が出てきた場合に、不要なサーバを自動的に停止・削除する仕組みです。 これにより、使っていないサーバが稼働し続ける無駄を防ぎ、コストを最小限に抑えます。なお、必要以上にサーバが減らされることを防ぐため、一般的には最低限維持する「下限台数」を設定します。

2.3 自動復旧

Auto Scalingが管理しているサーバが障害などで応答しなくなった場合、ヘルスチェックによりそれを検知します。そして、問題のあるサーバを自動的に破棄し、代わりに新しい健康なサーバを起動して入れ替えます。 万が一の障害時でもシステムが自動で復旧するため、エンジニアの時間的・精神的な負荷を大幅に軽減できます。

このように、Auto Scalingを利用することで、人の手を介さずに**「必要な時に、必要な分だけ」**のリソースを用意することが可能になります。これこそが、クラウド（AWS）を利用する最大のメリットの一つと言えます。

3. スケーリングの2つのアプローチ

システムのリソース（処理能力）を拡張することを「スケーリング」と呼び、水平スケーリングと垂直スケーリングの2種類があります。

水平スケーリングと垂直スケーリングの違いを以下に示します。

graph TD
    subgraph horizontal["水平スケーリング（台数を増やす）"]
        direction LR
        H1["EC2"] ~~~ H2["EC2"] ~~~ H3["EC2<br>（追加）"]
    end

    subgraph vertical["垂直スケーリング（性能を上げる）"]
        direction LR
        V1["EC2<br>small"] -- "スケールアップ" --> V2["EC2<br>large"]
    end

3.1 水平スケーリング

サーバの台数を増減させることで処理能力を調整する方法です。

一般的に、EC2や後述するECSといったコンピュートリソースのスケーリングはこの手法で行われます。また、後の講座で解説するRDSにおいても、読み取り専用の複製を作成する際にはこの水平スケーリングのアプローチが採用されます。

この方法の最大の利点は、理論上はサーバの台数を増やせば増やすほど性能を向上させることができ、上限がほぼないという点です。さらに、稼働中のサーバを停止させることなく新しいサーバの追加や削除が可能であるため、サービスを継続したまま拡張できるという大きなメリットがあります。

注意点として、複数のサーバ間でデータや処理の整合性を保つための設計が必要となりますが、ロードバランサーであるELBを併用することで、トラフィックを適切に分散し、これらの課題を概ね解決することができます。

3.2 垂直スケーリング

サーバ自体のスペック（性能）を変更することでスケーリングを行う方法です。CPUやメモリを増強して、サーバの器を大きくするイメージです。

例えばデータベースであるRDSの場合、データの書き込み処理を行うマスターデータベースを複数台に分散させると整合性の管理が非常に複雑になるため、通常は1台のサーバの性能を上げる垂直スケーリングが採用されます。

この手法のメリットは、システム構成をシンプルに保てる点にあります。

一方でデメリットとしては、物理的なスペックの上限が存在することに加え、スペック変更の際には再起動が必要になるケースが多く、メンテナンス時にシステムの一時停止や、停止させないための高度な工夫が求められる点が挙げられます。

4. EC2 Auto Scalingの特徴

Auto Scalingの特徴について解説します。

4.1 Auto Scaling Group

Auto Scaling Groupとは

Auto Scalingグループとは、主にEC2インスタンスの数を自動で増減させる管理機能のことです。あらかじめシステムの維持に必要な最小台数と、負荷が高まった際の最大台数を設定しておくことで、その範囲内で自動的に台数調整を行ってくれます。

具体的な動作としては、どのようなサーバを立ち上げるかという構成内容を「起動テンプレート」で定義し、どのような基準で増減させるかというルールを「スケーリングポリシー」で設定することで、運用の自動化を実現します。

ELBとの関連

Auto Scalingグループは単独でも機能しますが、WebシステムなどではELBと組み合わせて使用するのが一般的です。

両者を関連付けることで、Auto Scalingによって新しく起動したサーバが、自動的にELBの通信の宛先として登録されるようになります。これにより、システム全体の入口であるELBが、増減するサーバに対して即座に負荷分散を行えるようになります。

マルチAZ

Auto Scalingグループは、複数のアベイラビリティゾーン（AZ）にまたがった配置が可能です。設定時に複数のAZを指定しておけば、サーバの台数を増やす際に、特定のAZに偏らないよう自動的にバランスを取りながら配置してくれます。

これにより、一つのAZに障害が発生してもシステム全体が停止しない、耐障害性の高い構成を維持することができます。

4.2 起動テンプレートの作成

起動テンプレートは、オートスケーリングで起動するEC2インスタンスの「設定情報」をテンプレート化したものです。

オートスケーリングで新しいサーバが起動した際、OS等の環境が整っていなければサービスを提供できません。そのため、アプリが即座に動作するよう定義した「起動テンプレート」を用意し、それに従って起動するように設定します。

起動テンプレートでは、「AMI」「インスタンスタイプ」「キーペア」「セキュリティグループ」など、EC2インスタンス起動時に必要な項目はすべて設定できます。

サブネットはテンプレート内で指定せずにおくことで、オートスケーリンググループ側の設定に従い、マルチAZへ適切に分散配置されるようになります。

また、ミドルウェアやアプリケーションのセットアップ方法については、主に2つのアプローチがあります。

• 事前に必要な環境を構築済みの「カスタムAMI」を用意し、それを指定する方法です。これにより、起動直後からアプリケーションが動作可能な状態を作れます。
• 「ユーザデータ」を利用する方法です。これはインスタンス起動時にシェルスクリプトを実行する機能で、起動プロセスの中でミドルウェア等をインストール・設定させることができます。

4.3 スケーリングポリシー

スケーリングポリシーとは、オートスケーリングにおいて、どのような条件やタイミングでサーバの台数を調整するかを定義したルールのことです。Auto Scaling Groupでは、システムの特性や要件に合わせていくつかのポリシーを使い分けることができますが、ここでは主要な3つの方式について解説します。

ターゲット追跡スケーリング

まず、最も標準的で頻繁に利用されるのがターゲット追跡スケーリングです。これは、特定のメトリクス（CPU使用率やメモリ使用率など）があらかじめ設定した目標値を維持するように、自動的に台数を調整する方法です。

例えば「CPU使用率を常に70%前後に保つ」といった設定を行うことで、負荷が高まった際にはサーバを追加し、逆に負荷が落ち着いてきたら不要なサーバを削除してもとの台数に戻します。これにより、必要なパフォーマンスを維持しながらコストを最適化することが可能です。

スケジューリングポリシー

次に、スケジュールに基づくスケーリングについて説明します。これは、予測可能なトラフィック変動に合わせて、特定の日時にサーバ数を自動的に増減させるポリシーです。

例えば、毎週決まった曜日や時間にアクセスが急増することがわかっている場合、そのタイミングに合わせて事前にサーバ台数を増やしておくことができます。

また、テスト環境や社内システムなどで、「業務時間中の朝8時から夜20時までのみ稼働させ、夜間は0台にして停止する」といった運用を行うことで、コスト削減にも役立ちます。

予測スケーリング

これは、AWSの機械学習モデルが過去のトラフィック変動パターンを学習し、将来の需要を予測して事前にスケーリングを行う機能です。 例えば、「毎朝9時に急激にアクセスが増える」という傾向を学習していれば、ターゲット追跡スケーリングが反応するよりも前に、あらかじめサーバを増やしておくことができます。通常はターゲット追跡スケーリングと組み合わせて使用し、予測不能なスパイクと予測可能な変動の両方に対応する構成が推奨されています。

ステップスケーリング

最後に、ステップスケーリングです。これはターゲット追跡スケーリングよりもさらに詳細な制御が必要な場合に適しており、負荷のレベルに応じて段階的にアクションを設定する方法です。

例えば「CPU使用率が60%を超えたら1台追加、さらに80%を超えたら2台追加する」というように、しきい値ごとに異なる台数の増減を細かく定義できます。

設定の手順はやや複雑になりますが、急激な負荷変動に対して、より柔軟で意図した通りの挙動をさせたい場合に有効です。

4.4 Auto Scalingの挙動制御

スケーリングポリシーと合わせて、Auto Scalingの挙動をより詳細にコントロールするための設定がいくつかあります。ここでは代表的な2つの機能を紹介します。

クールダウン期間（振動の防止）

スケーリング実行後、次のアクションを開始するまでに一定の待機時間を設ける設定です。

サーバが起動してから負荷を受け入れられるようになるまでにはタイムラグがあります。この期間を設けずに判定を続けると、効果が出る前に追加のアクション（インスタンスの追加や削除）が行われ、サーバが増えすぎたり減りすぎたりする「スラッシング（振動）」が起きてしまいます。

これを防ぐために、通常は数分間のクールダウン期間が設けられています。

終了ポリシー（削除対象の選択）

スケールイン（縮小）の際、複数あるサーバのうち「どのサーバを優先して削除するか」を決めるルールです。

デフォルトでは、アベイラビリティゾーンのバランスを保ちつつ、「最も古い起動設定のサーバ」や「課金時間の区切りが近いサーバ」などを自動的に判断して削除します。

特定のサーバを残したい場合などは、このポリシーをカスタマイズすることが可能です。

5. 主なユースケース

Auto Scalingは、需要の変動に対応しながらコスト最適化を実現するために活用されます。以下に代表的なユースケースを紹介します。

5.1 ECサイトのピーク対応

セール期間やテレビ放映後など、アクセスが急増するタイミングに合わせてサーバ台数を自動的に増加させ、アクセスが落ち着いたら元の台数に戻します。これにより、機会損失を防ぎながら通常時のコストを抑えることができます。

5.2 業務システムの時間帯対応

スケジュールベースのスケーリングを活用して、業務時間中はサーバ台数を増やし、夜間や休日は最小限に抑える運用が可能です。開発環境であれば、夜間は0台にして完全に停止させることでコストを大幅に削減できます。

5.3 自動復旧による運用負荷軽減

ヘルスチェックと連携することで、障害が発生したサーバを自動的に検知して新しいサーバに置き換えます。これにより、深夜や休日の障害対応から解放され、運用担当者の負担を大幅に軽減できます。

6. 設計のポイント

Auto Scalingを設計する際の主要な検討項目を以下にまとめます。

7. まとめ

この講座では、Auto Scalingについて学びました。

• Auto Scalingは、システムの負荷に応じてサーバ台数を自動的に増減させる仕組み
• スケールアウトで負荷増加時にサーバを追加し、スケールインで負荷低下時にサーバを削減する
• 水平スケーリングは台数を増減、垂直スケーリングはスペックを変更する方式
• Auto Scaling GroupでEC2インスタンスの台数管理を行う
• 起動テンプレートで新規起動するインスタンスの設定を定義する
• スケーリングポリシーで台数調整の条件を設定する（ターゲット追跡、スケジュール、予測、ステップ）
• ELBと組み合わせることで、新規インスタンスが自動的に負荷分散の対象となる
• マルチAZ構成により、耐障害性の高いシステムを構築できる