LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

需要連動のオートスケーリングとは

オートスケーリングとは、アクセス数や処理負荷といった需要の変化に応じて、サーバーやコンテナの数（またはリソース量）を自動で増減させる仕組みです。Amazon EC2 Auto Scalingでは、Auto Scaling groupと呼ぶインスタンスの集合に最小・希望・上限の容量を設定し、スケーリングポリシーに基づいて需要の増減に応じたインスタンスの起動・終了を自動化します^*1。需要が高まった時間帯だけ台数を増やし、落ち着いた時間帯には減らすことで、常時ピーク時の台数を保有し続ける過剰プロビジョニングを避ける設計です。

ここで扱う「需要連動のコスト最適化」は、個別サービスの単価削減（インスタンスタイプの見直しや購入形態の変更など）や、コスト異常検知の仕組みとは別の論点です。単価削減は「同じ量をより安く買う」取り組みであり、コスト異常検知は「想定外の支出を早期に発見する」取り組みです。これに対しオートスケーリングは「必要な量だけ動かす」設計であり、需要が変動するワークロードに対して過不足のないリソース量を自動で保つことで、コストと可用性の両方を成立させる考え方です。

クラウドの従量課金モデルでは、稼働させた分だけ費用が発生します。ピーク時に合わせて固定台数を用意すると、閑散期には使われないリソースの費用がそのまま無駄になります。逆に少なめの台数で固定すると、繁忙期にレスポンス低下やエラー増加といった可用性の問題を招きます。オートスケーリングは、この両極端を避け、需要曲線に沿ってリソース量を追随させる仕組みだと理解しておくとよいでしょう。

EC2 Auto Scalingのスケーリングポリシー

Amazon EC2 Auto Scalingでは、複数のスケーリング方式を組み合わせてAuto Scaling groupの容量を制御します。代表的な方式がターゲット追跡・スケジュール・予測スケーリングの3つです。

ターゲット追跡スケーリングは指標を一定に保つ

ターゲット追跡スケーリングポリシーは、CPU使用率などの指標に目標値を設定し、その値を保つようにインスタンス数を自動調整する仕組みです^*2。AWSはこの動作をサーモスタットが室温を一定に保つ仕組みにたとえています^*2。例えばCPU使用率の目標値を50%に設定すると、指標が目標値を上回れば増強（スケールアウト）、下回れば縮小（スケールイン）が自動で実行されます^*2。目標値は、通常時のトラフィックに対して実際の指標値が目標値と同等かやや低い水準になるよう、余裕を持たせて設定することが推奨されています^*2。複数のターゲット追跡ポリシーを異なる指標で併用することもでき、その場合はいずれかのポリシーがスケールアウトを求めれば増強し、すべてのポリシーがスケールインに同意した場合のみ縮小するという可用性優先の判断がなされます^*2。

スケジュールドスケーリングは予測可能な周期に対応する

スケジュールドスケーリングは、特定の日時に容量（希望・最小・上限）を変更するスケジュールドアクションをあらかじめ設定しておく方式です^*3。例えば週の半ばにアクセスが増え、週末にかけて減少するといった周期的なパターンが分かっている場合、水曜朝に容量を引き上げ、金曜夜に引き下げるアクションを組んでおくことで、ピーク時の可用性と閑散期のコスト抑制を両立できます^*3。cron式による繰り返しスケジュールにも対応しており、スケジュールドスケーリングと動的スケーリングポリシーを併用すれば、スケジュールで設定した容量の範囲内で、その後の需要変化にも自動で追随させられます^*3。

予測スケーリングは過去データから需要を先読みする

予測スケーリングは、過去の負荷データを分析して日次・週次のトラフィックパターンを検出し、将来必要となる容量をあらかじめ予測してAuto Scaling groupの容量を先回りで増強する仕組みです^*4。営業時間帯にアクセスが集中し夜間・週末は低調になるような周期的なトラフィック、バッチ処理のような繰り返し発生する負荷パターン、起動に時間がかかりスケールアウト時の遅延が性能に影響しやすいアプリケーションといったケースに適しているとされています^*4。反応型の動的スケーリングだけに頼る場合と比べて、需要の増加を待たずに容量を用意できるため過剰プロビジョニングの回避にもつながるとAWSは説明しています^*4。

なお、EC2以外のAWSリソース（ECSサービス、DynamoDBテーブル、Auroraレプリカなど）を対象にスケーリングを行う場合は、Application Auto Scalingが用いられます。Application Auto ScalingもEC2 Auto Scalingと同様に、ターゲット追跡・ステップ・スケジュール・予測の4方式でリソースを制御できる仕組みです^*5。複数種類のリソースを横断してまとめてスケーリング方針を管理したい場合は、これらのリソースを対象にしたスケーリングプランという上位の仕組みも用意されています。

KubernetesのHPA・VPA・Cluster Autoscaler

コンテナ基盤であるKubernetesにも、複数のオートスケーリングの仕組みが用意されています。それぞれ「何をスケールするか」が異なるため、役割の違いを理解したうえで組み合わせる必要があります。

HPA（Horizontal Pod Autoscaler）はPod数を自動調整する

Horizontal Pod Autoscaler（HPA）は、CPU使用率などの観測されたメトリクスに基づいて、DeploymentやStatefulSetといったワークロードのレプリカ数（Pod数）を自動的に更新する仕組みです^*6。HPAはコントローラとして一定の同期周期でメトリクスを取得し、対象のPod数を増減させる水平スケーリングを担います^*6。Pod単体のリソース量を変更するのではなく、Podの複製数を増減させる点が特徴です。

VPA（Vertical Pod Autoscaler）はPodのリソース割り当てを調整する

Vertical Pod Autoscaler（VPA）は、Podに割り当てるCPU・メモリのリクエストとリミットを、実際の使用状況に基づいて自動調整する仕組みです^*7。HPAが台数を増減させる水平スケーリングであるのに対し、VPAは個々のPodの器の大きさを調整する垂直スケーリングにあたります^*7。VPAは推奨値を算出するRecommender、実際にリソース設定を更新するUpdater、新規作成されるPodに推奨値を適用するAdmission Controllerという3つのコンポーネントで構成され、更新の適用方法はupdateModeで制御します^*7。動作にはMetrics Serverの導入が前提となります^*7。

Cluster Autoscalerはノード数を調整する基盤側の仕組み

HPAやVPAがワークロード（Podの数や大きさ）を対象にするのに対し、クラスタの基盤そのものをスケーリングする位置づけの仕組みとしてノードのオートスケーリングがあります^*8。これは、リソース不足でPodがスケジュールできない状態が生じた場合などに、ノードの追加・削除を行うものであり、Pod単位のスケーリングとは異なるレイヤーの制御です^*8。HPAでPod数を増やしても、その受け皿となるノードの容量が不足していれば新しいPodは起動できないため、Pod単位のスケーリングとノード単位のスケーリングは両輪で設計する必要があります。

スケールの前提設計

オートスケーリングは、インスタンスやPodを機械的に増減させる仕組みです。増減した先のインスタンスが正しく機能する設計になっていなければ、台数を増やしても需要を処理しきれない、あるいは減らした際にデータが失われるといった問題が生じかねません。導入前に満たしておくべき前提を整理します。

ステートレス設計がスケールアウト・インの土台になる

オートスケーリングを機能させる前提として、アプリケーションはステートレスに設計しておく必要があります。セッション情報や処理中のデータを特定のインスタンス内だけに保持する設計だと、そのインスタンスが終了した際に情報が失われたり、ロードバランサーが別のインスタンスに振り分けた際に処理が継続できなくなったりします。セッション情報は外部のデータストアに保持し、どのインスタンスが応答しても同じ結果を返せる構成にしておくことが、スケールアウト・スケールインを問題なく行うための土台です。

ヘルスチェックで異常インスタンスを検知し入れ替える

Amazon EC2 Auto Scalingは、EC2のヘルスチェックを使ってインスタンスの状態を自動的に監視し、終了または異常と判定されたインスタンスを検知して置き換え、希望する容量を維持します^*1。標準のヘルスチェックに加えて、アプリケーション固有のカスタムヘルスチェックを定義することもでき、自社で定めた判定基準で異常を検知した場合も自動的にインスタンスが置き換えられます^*1。ヘルスチェックの判定基準が甘いと、実際には応答できていないインスタンスがトラフィックを受け続けてしまうため、アプリケーションの正常性を的確に反映する判定条件を設計する必要があります。

ウォームアップとクールダウンで急な増減を制御する

ターゲット追跡スケーリングでは、新しく起動したインスタンスがウォームアップ中とみなされる時間を設定でき、この時間が経過するまでは集計対象のメトリクスに含まれません^*2。ウォームアップ中のインスタンスがある間はスケールインの動作がブロックされる仕組みになっており、スケールアウトを終えたばかりのインスタンスがすぐに終了されてしまう事態を避けています^*2。この値を適切に設定しないと、実際にはまだ処理能力が立ち上がっていないインスタンスを稼働中として扱ってしまい、スケーリングの判断がずれる原因になります。アプリケーションの起動処理やキャッシュのウォームアップにかかる時間を実測したうえで設定することが望ましいでしょう。

コストと可用性のトレードオフ設計

オートスケーリングの設計では、コストを抑えることと可用性を維持することが常にトレードオフの関係にあります。このトレードオフをどこで折り合わせるかが、設計の核心部分です。

最小台数はゼロにできるとは限らない

Auto Scaling groupには最小サイズを設定でき、需要が少ない時間帯でもこの数を下回ることはありません^*1。最小台数を極端に絞り込めばコストは下がりますが、急なアクセス増加が発生した際にスケールアウトが追いつかず、応答遅延やエラーが発生するリスクが高まります。逆に最小台数を高めに設定すれば可用性は安定しますが、閑散期のコストが下がりにくくなります。ALBのリクエスト数のように実際に0の値を計測できる指標を使う場合、トラフィックが途絶えた期間に容量を0までスケールインさせることも可能です^*2。ただし業務システムで常時アクセスが見込まれる場合は、最小台数を0にする設計が適切とは限らず、業務影響を踏まえた水準を個別に検討する必要があります。

上限（上限サイズ）は予算の歯止めとして機能する

Auto Scaling groupの上限サイズは、需要が急増した場合でもこの数を超えて容量が増えないようにする上限です^*1。上限を設定しておかないと、想定外の負荷やスケーリング設定の不備によって際限なくインスタンスが増え続け、コストが跳ね上がる事態につながりかねません。一方で上限を低く設定しすぎると、本来対応できたはずのアクセス増加時にリソース不足で機会損失が生じます。過去の負荷実績とビジネス上の許容コストの両面から、上限は「まで」という形で具体的な数値を決めておく必要があります。

急増対応は複数の方式を重ねて設計する

単一のスケーリング方式だけに頼ると、想定外のパターンの負荷に対応しきれない場合があります。周期的な需要にはスケジュールドスケーリングや予測スケーリングであらかじめ容量を用意しておき、それでも捉えきれない突発的な変動にはターゲット追跡のような動的スケーリングで追随させるというように、複数の方式を重ねて設計するのが実務的なアプローチです^*3*4。スケジュールドスケーリングと動的スケーリングを併用した場合、動的スケーリングはスケジュールで設定された容量の範囲内で調整を行う仕組みになっているため、両者の上限・下限の整合を取っておくことも欠かせません^*3。

外注時に確認すべき設計範囲と引き継ぎの論点

オートスケーリングの設計・実装を外部のベンダーに依頼する場合、スケーリングポリシーの設定だけを納品してもらうと、運用開始後に「なぜこの閾値になっているのか分からない」という状態に陥りがちです。発注前後で確認しておきたい論点を整理します。

内製に必要なもの

オートスケーリングの設計・運用を自社で内製するには、インフラの構成管理に加えて、アプリケーションの負荷特性を理解した設計ができる人材が必要です。ターゲット追跡の指標選定やウォームアップ時間の調整は、インフラの知識だけでなくアプリケーションの起動処理や内部状態を理解していないと適切な値を導けません。単発のインフラ構築経験だけでは、需要パターンの分析からポリシー設計までを一貫して担うのは難しく、負荷試験を含めた検証体制まで社内に持てるかどうかが内製の可否を左右します。

発注先への確認

提案書に「オートスケーリングを導入します」とだけ記載されている場合、どの指標をターゲット追跡の対象にするのか、最小・希望・上限の各容量をどのような根拠で設定するのか、ウォームアップ・クールダウンの時間をどう見積もったのかを具体的に確認する必要があります。Kubernetes環境であれば、HPA・VPA・ノードのオートスケーリングをどう組み合わせる設計なのか、それぞれの役割分担も打ち合わせで質問しておくと、実装の解像度を見極める手がかりになるでしょう。

契約明記

開発・運用を担当する会社が変わる可能性がある場合は、スケーリングポリシーの設定内容とその設定根拠（負荷試験の結果、想定トラフィックのデータなど）を文書として納品物に含めるよう契約段階で明記しておく必要があります。設定値だけを引き継いでも、なぜその値にしたのかという背景が分からなければ、後任の担当者は需要パターンが変化した際に適切な見直しができません。運用フェーズでの閾値見直しの頻度や、負荷急増時の対応体制についても、契約の中で役割分担を明確にしておくことが望ましいでしょう。

オートスケーリングは一度設定して終わりではなく、事業の成長やアプリケーションの改修に合わせて指標や閾値を継続的に見直す運用が前提です。発注時にはこの運用フェーズまで含めた体制を確認しておくことが、長期的なコスト最適化の実効性を左右します。

まとめ：オートスケーリングでコスト最適化を機能させる3つの判断軸

本稿では、クラウドのオートスケーリングを用いた需要連動のコスト最適化について、EC2 Auto Scalingのスケーリングポリシー、KubernetesのHPA・VPA・Cluster Autoscaler、スケールの前提設計、コストと可用性のトレードオフまでの勘所を整理しました。要点を3つに集約すると次の通りです。第一に、ターゲット追跡・スケジュール・予測といった複数のスケーリング方式は得意な負荷パターンが異なるため、自社の需要曲線の特性に合わせて組み合わせる視点が欠かせません。第二に、ステートレス設計やヘルスチェック、ウォームアップ・クールダウンの調整といった前提条件を満たしていなければ、スケーリングの仕組みだけを導入しても機能しません。第三に、最小台数・上限・急増対応の設計はコストと可用性のトレードオフそのものであり、外注する場合も設定根拠と引き継ぎ資料の範囲を発注前に確認する姿勢が、長期的な運用品質を左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：AWS「What is Amazon EC2 Auto Scaling?」https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html
2. *2　出典：AWS「Target tracking scaling policies for Amazon EC2 Auto Scaling」https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html
3. *3　出典：AWS「Scheduled scaling for Amazon EC2 Auto Scaling」https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html
4. *4　出典：AWS「Predictive scaling for Amazon EC2 Auto Scaling」https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html
5. *5　出典：AWS「What is Application Auto Scaling?」https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html
6. *6　出典：Kubernetes「Horizontal Pod Autoscaling」https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
7. *7　出典：Kubernetes「Vertical Pod Autoscaling」https://kubernetes.io/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/
8. *8　出典：Kubernetes「Autoscaling Workloads」https://kubernetes.io/docs/concepts/workloads/autoscaling/

Tweet