本記事は Microsoft Learn の「Azure App Service でアプリをスケーリングする」というモジュールをまとめたものである。
スケールアウトオプションを確認する
App Service には、従来からある「オートスケール」と、より高度な「自動スケーリング（Automatic Scaling）」の2種類が存在する。
1. オートスケール
ユーザーが「いつ・どうやって」増やすかを細かく決める方式。
- ルールベース：「CPUが70%を超えたら1台増やす」といったルールを自分で作成
- スケジュール可能：「土日だけ増やす」といった予約設定ができる
- 対象：Standard プラン以上
2. 自動スケーリング
プラットフォームが HTTP トラフィック（リクエスト量）に応じて全自動で調整する方式。
- 運用負荷が低い：ルール作成が不要。トラフィックの増減に合わせて自動でインスタンスを管理
- 高性能：「事前ウォーミング（予熱）」されたインスタンスがあるため、急激な負荷増加にも素早く対応
- 対象：Premium V2 / V3 プラン限定
| 要素 | オートスケール | 自動スケーリング |
|---|---|---|
| 判断基準 | 設定したルールやスケジュール | HTTPトラフィック（自動） |
| 即応性 | 低め（ルール判定後に起動） | 高い（待機インスタンスを活用） |
| 管理のしやすさ | 複雑（ルールの調整が必要） | 非常に簡単（ほぼお任せ） |
| アプリごとの上限設定 | 不可 | 可能 |
オートスケーリングとは
自動スケーリングは、アプリの負荷状況（需要）に応じて、稼働するサーバーリソースを自動的に増減させる仕組み。
1. スケーリングの方向
- スケールアウト：サーバーの「台数」を増やす。アクセス急増時に処理能力を分散させる
- スケールイン：余ったサーバーの「台数」を減らす。負荷が下がった際にコストを抑える
※マシンの性能を上げる「スケールアップ」とは異なり、台数の増減で対応するのが特徴
2. トリガー（発動のきっかけ）
以下の要因を評価して自動で実行される。
- メトリックベース：CPU使用率の上昇、メモリ不足、リクエスト数の急増など
- スケジュールベース：特定の日時や、アクセスが増える時間帯にあらかじめ合わせる設定
- 複合条件：「CPU負荷が高く、かつ特定の時間帯である」といった複数の条件の組み合わせ
Azure App Service のオートスケーリング
アプリの負荷（メトリック）をリアルタイムで監視し、システムがダウンする前にリソースを自動調整する機能。
動作の性質
- 台数の調整（スケールアウト/イン）：Web サーバー（インスタンス）の数を増減させることで、急激なワークロードの変化に対応する
- 負荷分散：追加された新しいサーバーに対して、自動的にアクセス（トラフィック）を振り分ける
注意点
- 個別の性能は不変：1台あたりの CPU パワー、メモリ、ストレージ容量といった「スペック」自体を強化するものではない
- 環境の変化への即応：過負荷になる前にリソースを確保し、ユーザーへの応答遅延やサービス停止を防ぐ
オートスケーリングルール
自動スケーリングは、事前に設定した「ルール」に基づいてリソースを増減させる。
ルールの仕組み
- しきい値の設定：「CPU使用率が〇〇%を超えたら増やす（トリガー）」といった基準値を決める
- リソースの解放：負荷が下がった際に、不要になったインスタンスを削除してコストを抑える
設定時の重要ポイント：DoS 攻撃への対策
単にトラフィックが増えたからといって、無条件にスケールアウトするのは危険。
- 無駄なコスト：悪意のある大量アクセス（DoS攻撃）に反応してスケールアウトすると、処理できないリクエストのために多額の費用が発生する
-
推奨される対策：攻撃による異常なアクセスは、スケーリングで処理するのではなく「破棄」すべき
- 前段で攻撃を検出し、フィルタリング（遮断）する仕組み（WAFなど）を併用するのが望ましい
自動スケーリングの検討タイミングと注意点
自動スケーリングは万能ではなく、状況に応じて「手動スケーリング」や「スケールアップ（性能向上）」と使い分ける必要がある。
1. オートスケーリングが効果的なケース
- 予測可能な変動：休暇中やセール期間など、一時的にアクセスが増減する場合
- 可用性の向上：急な負荷でリクエストが拒否されたり、インスタンスがクラッシュしたりするのを防ぎたい場合
2. 自動スケーリングが適さない・注意が必要なケース
- リソース集約型の処理：1つのリクエストでメモリやCPUを使い切るような重い処理（大規模データの解析など）は、台数を増やすより、1台の性能を上げる（スケールアップ）方が効果的
- 長期的な成長：ユーザー数が数ヶ月かけて緩やかに増える場合。自動スケーリングの監視コスト（オーバーヘッド）をかけるより、予測に基づいて手動で台数を増やす方が安上がり
- 初期インスタンス数が少なすぎる場合：1台だけで運用していると、スケーリングが間に合わずダウンタイムが発生するリスクがある。ある程度の予備キャパシティを確保しておくことが重要
Azure App Service の自動スケーリング
複雑なルール設定を省き、トラフィック量に応じてプラットフォームが最適化する機能。
主な特徴とメリット
-
ルール設定が不要：CPUやメモリのしきい値を手動で決める必要がない。HTTPトラフィックに基づいて自動で判断される
-
アプリごとの独立したスケーリング：同じ App Service プラン内に複数のアプリがあっても、それぞれの負荷状況に合わせて個別に台数を調整できる
-
バックエンドの保護：「最大インスタンス数」の上限を設定可能。連携先のデータベースやレガシシステムが処理しきれなくなる（過負荷）のを防げる
仕組みのポイント
- トラフィック監視：Webアプリがリクエストを受け取ると、App Service が負荷をリアルタイムで監視し、必要に応じてインスタンスを追加する
- リソースの効率化：必要に応じてプラン内のリソースを共有しつつ、効率的にスケールアウトを実行する
オートスケーリングの要因を特定する
オートスケールと App Service プラン
オートスケールは、App Service プランの能力に基づいてサーバー台数を増減させる機能。
動作の基本
- インスタンスの追加：スケールアウト時、Azure は App Service プランで指定されたスペック（CPU・メモリ等）と同じサーバーを新しく起動する
- リソースの複製：アプリはその新しいインスタンス上で動作し、負荷が分散される
暴走防止と制限
- インスタンス数の上限：際限なく台数が増えてコストが爆発するのを防ぐため、プランごとに最大インスタンス数の制限がある
- 価格レベルの影響：高額なプラン（Premiumなど）ほど、より多くの台数までスケールアウトできる
- 絶対的な境界：オートスケールの設定でどれほど高い数値を希望しても、プラン自体の制限値を超えることはできない
オートスケールの発動条件
オートスケールをいつ、どのように実行するかは「オートスケール条件」を定義することで制御する。主に2つの手法がある。
1. メトリックベースのスケーリング
システムの状態（数値）を監視して動的に増減させる。
- 指標の例：CPU使用率、ディスクキューの長さ（処理待ち）、待機中のHTTPリクエスト数など
- メリット：予期せぬアクセス急増にもリアルタイムで対応できる
2. スケジュールベースのスケーリング
特定の日時に合わせて、あらかじめ決めた台数に変更する。
- 例：「平日の朝9時に5台に増やす」「週末は1台に減らす」といった指定が可能
- 期間指定：開始日だけでなく終了日も設定でき、期間が終われば自動で元の台数に戻る（スケールイン）
3. 条件の組み合わせと優先順位
より高度な制御のために、これらをミックスして運用できる。
- ハイブリッド構成：「特定の時間帯（スケジュール）かつ、リクエスト数（メトリック）がしきい値を超えた時だけ増やす」といった設定が可能
- 複数ルールの管理：複数の条件を設定した場合、いずれかが合致すればスケーリングが発動する
- 既定（デフォルト）条件：どのスケジュールにも当てはまらない時に適用される「基本の台数」設定。これは常に有効な状態となる
オートスケールのアクションとクールダウン
ルールがしきい値を検知した際、実際に行われる「動作（アクション）」と、その後の「待機時間」の仕組み。
1. アクションの種類
メトリックとしきい値を比較（演算子を使用）し、台数を調整する。
- スケールアウト（増加）：「CPU > 80%」のように比較し、インスタンスを増やす
- スケールイン（減少）：「CPU < 30%」のように比較し、不要なインスタンスを削る
- 設定方法：「1台ずつ増やす」といった相対的な変化だけでなく、「常に5台にする」といった絶対値での指定も可能
2. クールダウン（待機期間）
アクション実行後に設けられる「システムが落ち着くまでの休憩時間」。
- 目的：インスタンスの起動・停止には時間がかかるため、メトリックが安定する前に連続してルールが発動（過剰な増減）するのを防ぐ
-
仕様：
- 期間中は新しいスケールルールはトリガーされない
- 最小時間は5分
オートスケールルールのペアリング
効率的なリソース管理のためには、「増やすルール」と「減らすルール」をセット（ペア）で設定することが重要。
なぜペアが必要か
- コストの最適化：増やす設定しかないと、負荷が下がってもサーバー台数が戻らず、無駄な料金が発生し続ける
- リソースの循環：需要に合わせて台数を出し入れすることで、常に最適なキャパシティを維持できる
設定のイメージ
同じメトリック（例：CPU使用率）に対して、上限と下限の両方にしきい値を設ける。
- スケールアウト（上限）：「CPUが 80% を超えたら、1台増やす」
- スケールイン（下限）：「CPUが 30% を下回ったら、1台減らす」
注意点：チャタリングの防止
- 余裕を持たせる：上限と下限のしきい値を近づけすぎないこと（例：80%で増やして75%で減らす設定はNG）
- 理由：値が少し変動するたびに「増やす・減らす」を繰り返す不安定な状態（チャタリング）を防ぐため
複数ルールの組み合わせと判定ロジック
1つの「自動スケール条件」の中に、異なるメトリック（CPUやリクエスト数など）に基づいた複数のルールを混在させることができる。ただし、「増やす時」と「減らす時」で判定の仕組みが異なる点に注意が必要。
1. スケールアウト（増やす時）の判定：OR条件
複数のルールのうち、どれか1つでもしきい値を超えたら実行される。
- 例：「CPU > 70%」 または 「リクエスト待ち > 10件」
- 理由：システムのパンクを防ぐため、どこか一箇所でも危険信号が出れば即座に増員する「安全優先」の仕組み
2. スケールイン（減らす時）の判定：AND条件
設定したすべてのルールが満たされた時のみ実行される。
- 例：「CPU < 50%」 かつ 「リクエスト待ちが 0件」
- 理由：一方の負荷が下がっても、もう一方が高い場合は、早急に台数を減らすとパンクする恐れがあるため。慎重にリソースを削る「安定優先」の仕組み
注意事項
- 個別に減らしたい場合：「どれか一方が下がったらすぐに減らしたい」という場合は、ルールを同じ条件に入れず、別々の自動スケール条件として定義する必要がある
- デフォルトの挙動：基本的にはこの「慎重なスケールイン」が、サービスの安定性を守るための標準設定となっている
App Service でオートスケールを有効にする
オートスケールの有効化手順
Azure ポータルから App Service プランの設定を変更し、自動スケーリングを開始する手順。
設定画面へのアクセス
- 場所：対象の App Service プランを開き、左メニューの [設定] ＞ [スケールアウト (App Service プラン)] を選択
- 初期状態：既定では「手動スケーリング（特定の台数に固定）」に設定されている
自動化の有効化
- 方法の選択：[スケールアウト方法] セクションで [規則に基づく] を選ぶ
- 構成の開始：[構成] をクリックすると、詳細な設定画面に移動する
- 条件の追加：[カスタム自動スケール] を選択することで、メトリックやスケジュールに基づいた「条件グループ」を定義できるようになる
スケール条件の追加と構成
オートスケールを有効にすると、システムの基本となる「既定の条件」の編集や、特定の状況に応じた「カスタム条件」の追加が可能になる。
条件の種類と優先順位
- カスタム条件：特定のスケジュールやメトリックに基づいて優先的に実行される
- 既定（デフォルト）の条件：他にアクティブな条件がない場合に常に適用される「ベースライン」
設定の構成要素
-
インスタンス数の範囲：
- 最小数：負荷が低くても維持する最低台数
- 最大数：コストやプラン制限（価格レベル）の範囲内で許容する最大台数
- 判定ロジック：「特定の数値（メトリック）に応じて増減」させるか、「決まった台数に固定」するかを選択可能
-
スケジュール（カスタム条件のみ）：
- 特定の日時や曜日にのみ条件を適用できる
- スケジュールがない条件は常にアクティブな状態となる
スケールルールの作成
メトリックベースの条件を設定する際は、「ルールの追加」から具体的な動作を定義する。構成要素は大きく分けて以下の2つ。
1. トリガー（発動条件）
「いつ」アクションを起こすかを指定する。
- メトリックの監視：CPU使用率、メモリ、HTTPリクエスト数などを選択
- しきい値の設定：「80%を超えたら」「10件より多くなったら」といった基準を決める
2. アクション（実行内容）
条件を満たした際に「何をするか」を指定する。
- スケーリングの種類：インスタンスの「追加（スケールアウト）」か「削除（スケールイン）」
- 調整方法：1台ずつ増やす、あるいは特定の台数に変更する、などの動作を選択
オートスケーリングの監視（実行履歴）
設定したルールが実際にどう動作したかは、Azure ポータルのグラフで後から詳細に確認できる。
実行履歴グラフでわかること
台数の推移：時間の経過とともに、インスタンスの数がどのように増減したかを視覚的に追跡可能
- トリガーの特定：どの自動スケール条件（ルール）によってその変更が引き起こされたかが表示される
リソース使用率との関連付け
- 相関分析：[概要] ページにあるメトリック（CPU使用率など）と実行履歴を照らし合わせることで、「負荷が上がったから、狙い通りに台数が増えたか」を検証できる
- チューニング：意図しないタイミングで増減している場合、ルールのしきい値を調整する判断材料になる
オートスケーリングのベスト プラクティスを調べる
オートスケーリングの基本概念
オートスケールは、インスタンス（サーバー）の数を増減させる「水平スケーリング」を管理する仕組み。
1. 台数の制限設定
以下の3つの値をあらかじめ定義する。
- 最小値：維持する最低限の台数
- 最大値：コストやプランの制約による上限
- 既定値：異常時や判定不能時に適用される標準の台数
2. 判定の仕組み
- 常時監視：スケール用のメトリック（CPUなど）を常に読み取り、設定した「しきい値」を超えていないかチェックする
- インスタンス単位の計算：しきい値の判定は、全インスタンスの「平均値」で行われる
- 例：2台稼働時に「CPU > 80%」で増やす設定の場合、2台の平均使用率が80%を超えた時点でスケールアウトが発動する
3. ログと通知
- アクティビティログ：成功・失敗を問わず、すべての履歴が自動で記録される
- アラート通知：ログと連携し、スケーリング発生時にメール、SMS、Webhookなどでリアルタイムに通知を受け取ることが可能
オートスケーリングのベストプラクティス
効果的な運用と「フラッピング（不必要な増減の繰り返し）」を防ぐための重要ポイント。
1. 最大値・最小値に十分なマージンを設ける
- 制限の間で動かす：最小=2、最大=2のように差がないと、オートスケールは機能しない
- 余裕の確保：予期せぬ負荷にも対応できるよう、価格レベルの制限内で幅を持たせる
2. 適切な統計情報の選択
- 基本は「平均」：通常は Average（平均） を使用するのが最も安定する
- 特殊なケース：状況に応じて 最小 最大 合計 を選べるが、意図しない変動に反応しすぎないよう注意が必要
3. しきい値の慎重な設定と「フラッピング」回避
「増やす（Out）」と「減らす（In）」の数値を近づけすぎないのが鉄則。
- フラッピングとは：台数を減らした瞬間に負荷が跳ね上がり、またすぐ増やす……という無限ループに陥ること
- Azureの賢い判定：Azureはスケールイン前に「減らした後の負荷」を予測する。減らした後にすぐしきい値を超える（再スケールが必要になる）と判断した場合、スケールインをスキップする。
-
推奨設定例：
- スケールアウト：CPU 80% 以上
- スケールイン：CPU 60% 以下（これくらい間隔を空けると安定する）
4. 複数ルール設定時のロジックを理解する
1つの条件に複数のメトリック（CPUとメモリなど）を混ぜる場合：
- 増やす時 (OR)：どれか1つでもしきい値を超えれば実行（即応性・安全重視）
- 減らす時 (AND)：設定したすべてのルールが「減らしてOK」な状態にならない限り、実行されない（安定性重視）
5. 安全な「既定（デフォルト）」インスタンス数
- メトリック喪失への備え：監視データが取得できないなどの異常事態に備え、ワークロードを最低限さばける「安全な台数」を既定値にする
6. 通知とログの活用
- アクティビティログ：成功・失敗・メトリック不可など、あらゆる挙動が記録される
- アラート設定：メールのほか、Webhookを使用して自動で管理者に通知したり、他システムと連携したりして、異常を即座に察知できる体制を作る