本記事は Microsoft Learn の「Azure App Service プランを構成する」というモジュールをまとめたものである。
Azure App Service プランを実装する
Azure App Service では、アプリは App Service プラン上で実行される。プランは Web アプリ用のコンピューティングリソースのセットを定義し、従来のサーバーファームに似ている。1つまたは複数のアプリを同じプラン上で実行可能。
App Service プランについて知っておくべきこと
- App Service プラン作成時、指定リージョン用のコンピューティングリソースが作成される
- プラン内のすべてのアプリは、そのリソース上で実行される
-
設定内容
- オペレーティングシステム: Linux または Windows
- リージョン: 米国西部、インド中部、北ヨーロッパなど
- 価格レベル: 選択OSに応じて利用可能な App Service 機能と料金を決定
- VMインスタンス数: 現在の範囲は3～30
- VMインスタンスサイズ: CPU、メモリ、リモートストレージで定義
- 既存プランに十分なリソースがあれば、新しいアプリを追加可能
App Service プランを使用する際の考慮事項
Azure App Service プランでアプリを実行・スケーリングする際のポイントを確認する。
- コスト削減: 複数のアプリを同じプランに配置すると、共有リソースへの支払いを節約可能
- 1つのプランで複数アプリ: 仮想マシンインスタンスを共有して構成・保守を簡素化、リソースと容量は慎重に管理
- プランの容量確認: 新しいアプリを追加する前にリソース要件を評価し、プランの残容量を確認
-
アプリの分離が必要な場合:
- リソース消費が多いアプリ
- 他のアプリと別にスケーリングする必要がある場合
- 別リージョンのリソースが必要な場合
Azure App Service プランの価格を決定する
Azure App Service プランの価格レベルは、利用可能な機能と料金を決定する。例として、Free、Shared、Basic、Standard、Premium、PremiumV2、PremiumV3、Isolated、IsolatedV2 がある。
App Service プランでアプリケーションを実行およびスケーリングする方法
Azure App Service プランはアプリケーションのスケール単位であり、価格レベルに応じて実行・スケーリング方法が変わる。固定インスタンス数の場合、プラン内のすべてのアプリが同じインスタンスで実行される。自動スケーリング設定がある場合、プラン内のすべてのアプリが一緒にスケールアウトされる。
-
共有コンピューティング (Free、Shared)
- 他の顧客のアプリと同じ Azure VM 上で実行
- 各アプリに CPU クォータを割り当て、スケールアウト不可
- 開発・テスト用途向け
-
専用コンピューティング (Basic、Standard、Premium、PremiumV2、PremiumV3)
- 専用 Azure VM 上で実行
- 同じプラン内のアプリのみでコンピューティングリソースを共有
- レベルが高いほど、スケールアウト可能な VM インスタンス数が多い
-
Isolated / IsolatedV2
- 専用の Azure 仮想ネットワーク上で専用 VM が実行
- コンピューティングとネットワークの分離が可能
- 最大のスケールアウト機能を提供
| 機能 | Free F1 | Basic B1 | Standard S1 | Premium P1V3 |
|---|---|---|---|---|
| 使用用途 | 開発・テスト | 開発・テスト | 運用ワークロード | 強化スケール・高パフォーマンス |
| ステージングスロット | なし | なし | 5 | 20 |
| 自動スケール | なし | 手動 | ルール | ルール・エラスティック |
| インスタンス数上限 | なし | 3 | 10 | 30 |
| 毎日のバックアップ | なし | なし | 10 | 50 |
Free および Shared
Free と Shared プランは、他のアプリと同じ Azure VM 上で稼働する基本レベルで、開発・テスト向け。SLA はなく、アプリ単位で課金される。
Basic
Basic プランは、低トラフィックで高度な自動スケールやトラフィック管理が不要なアプリ向け。料金はインスタンスのサイズと数に基づき、組み込みのネットワーク負荷分散でトラフィックが自動分散される。Linux 環境では Web App for Containers をサポート。
Standard
Standard プランは運用ワークロード向けで、料金はインスタンスのサイズと数に基づく。組み込みのネットワーク負荷分散でインスタンス間のトラフィックを自動分散し、自動スケールで需要に応じてインスタンス数を調整可能。Linux 環境では Web App for Containers をサポート。
Premium
Premium プランは運用アプリ向けに強化パフォーマンスを提供。Premium v2 では高速プロセッサ、SSD ストレージ、メモリ対コア比が Standard の 2 倍の Dv2 VM を提供。インスタンス数とスケール上限が増え、Standard の高度機能も利用可能。第 1 世代 Premium も引き続き利用可。
Isolated
Isolated プランは仮想ネットワーク上で動作するミッションクリティカル向け。専用の Azure データセンター環境（App Service Environment）でアプリを実行し、高速プロセッサ、SSD、メモリ対コア比が Standard の 2 倍の Dv2 VM を提供。最大 100 インスタンスまでスケール可能で、需要に応じてさらに拡張可能。
実行するタスク: App Service プランを選択する
App Service プランは Azure portal で確認可能。ハードウェア（CPU、メモリ、スケーリング可能なインスタンス数）や機能（バックアップ、ステージングスロット、ゾーン冗長性）に基づいて選択。
- Azure portal で App Service プランを検索して選択する
- 新しい App Service プランを作成する
- 利用可能なプランを表示するには、[ 価格プランを確認する ] を選択する
Azure App Service をスケールアップおよびスケールアウトする
App Service プランとアプリのスケーリングには「スケールアップ」と「スケールアウト」の 2 種類があり、手動または自動で行う場合は「自動スケーリング」と呼ばれる。
Azure App Service のスケーリングについて知っておくべきこと
- スケールアップ: CPU、メモリ、ディスク容量を増加。専用 VM、カスタムドメインと証明書、ステージングスロット、自動スケールなどの拡張機能を追加可能。価格レベル変更でスケールアップ。
- スケールアウト: アプリを実行する VM インスタンス数を増加。価格レベルに応じて最大 30 インスタンスまで。Isolated 環境では最大 100 インスタンスまで。手動または自動で構成可能。
- 自動スケーリング: 定義済みの規則やスケジュールに基づき、スケールアウトのインスタンス数を自動で増減。
- App Service プランの価格レベル変更により、いつでもスケールアップ・スケールダウン可能。
Azure App Service スケーリングを使用する際の考慮事項
- プランレベルを手動で調整可能。低価格レベルで開始し、必要に応じてスケールアップして機能を追加。不要になったらスケールダウンしてコスト削減
- スケールアップの例: Free → Shared（カスタム DNS）→ Basic（SSL バインディング）→ Standard（ステージング環境）→ 同レベルのより大きな VM サイズ（CPU、メモリ、ストレージ増加）
- スケールダウンは逆順で実施可能。容量や機能が不要になった場合にコスト節約
- 自動スケールを使用して、高スループット時にユーザーにサービスを提供し、負荷低下時にコストを削減。ルールとユーザー設定に基づきスケール調整
- スケール設定変更時に再デプロイ不要。コード変更も不要で、数秒で適用。変更はプラン内の全アプリに影響
- App Service アプリが依存する Azure SQL Database や Azure Storage などのリソースも個別にスケーリング可能。App Service プランではこれらは管理されない
Azure App Service 自動スケーリングを構成する
自動スケーリングにより、アプリケーションの負荷に応じてリソースを動的に増減させられる。 負荷が増えればリソースを追加し、使用されていないリソースは削除してコストを節約できる。
自動スケーリングについて知っておくべきこと
-
自動スケーリングでは、最小・最大インスタンス数をルールと条件で指定
-
アプリケーションが条件を満たすと、仮想マシンインスタンス数が自動で調整される
-
条件が満たされると1つ以上のスケーリングアクションがトリガーされる
-
スケールイン・スケールアウトの判断は、自動スケーリングエンジンで設定されたプロファイルに基づく
-
自動スケーリングルールには、トリガーとスケール操作（イン・アウト）が含まれる
-
トリガーはメトリックベースまたは時間ベースで設定可能
- メトリックベース: CPU使用率、平均応答時間、リクエスト数などの負荷に応じてスケーリング
- 時間ベース（スケジュールベース）: 負荷パターンに合わせて事前にスケーリング
-
自動スケーリングエンジンでは通知設定を使用
- 条件が満たされた際にメールやWebhookで通知可能
自動スケーリングを構成するときに考慮すべきこと
- 最小インスタンス数: 負荷がなくてもアプリが常に実行されるように設定
- 最大インスタンス数: 時間単位のコスト上限を制限するために設定
- スケールマージン: 最大値と最小値の差に十分な余裕を持たせ、自動スケーリングが円滑に動作するようにする
-
スケールルールの組み合わせ:
- スケールアウトルール: 負荷増加時にインスタンス追加
- スケールインルール: 負荷減少時に不要なコストを削減
- メトリック統計: 平均・最小・最大・合計など、適切な統計を選択してルールに反映
- 既定のインスタンス数: メトリックが利用できない場合の安全な初期値として設定
- 通知: 自動スケーリングイベント発生時にメールやWebhookで通知し、負荷変化に対する認識を維持