Azure App Serviceのスケール・運用・監視｜自動スケール・スロットスワップ・App Insights・KQL

Azure

App Serviceにアプリをデプロイし、設定・ネットワーク・認証まで整えたら、最後の関門は「本番でちゃんと動かし続ける」ことです。アクセスが増えても落ちない、デプロイでサービスを止めない、異常にすぐ気づける——ここまでできて、はじめて”実務レベル”です。

スケールアップとスケールアウトの違い、監視の入り口（App Insightsとログ）…このへんが一番あいまい…

シリーズ最終回のこの記事では、App Serviceの「スケール・運用・監視」を整理します。読み終えたときに、次の6つを説明・実践できるようになることをゴールにします。

  • スケールアップ（垂直）を構成できる
  • スケールアウト（自動スケール）を構成できる
  • デプロイスロットのスワップ（無停止デプロイ）ができる
  • ヘルスチェック／Always Onを理解している
  • Application Insightsで監視できる
  • 診断ログをLog Analyticsに送れる

各セクションの最後に「これが説明できればOK」の自己チェックを置いています。デプロイ手順は第2回、スロットの概念もそこで触れています。

スケールアップ（垂直）を構成する

まずスケールの2種類を、しっかり区別することから始めましょう。ここは混同しやすいので、図で押さえます。

【スケールアップ（垂直）】＝1台を強くする
   SKUを上げる： B1 → P1v3
   ┌────┐        ┌────────┐
   │ 小 │   →    │   大    │  CPU/メモリUP
   └────┘        └────────┘

【スケールアウト（水平）】＝台数を増やす
   インスタンス数を増やす： 1台 → 3台
   ┌────┐        ┌────┐┌────┐┌────┐
   │ 1台 │   →    │ 1台 ││ 2台 ││ 3台 │
   └────┘        └────┘└────┘└────┘

スケールアップ（垂直スケール）は、App Service PlanのSKU（価格レベル）を上げて、1インスタンスあたりの性能を強くする方法です。「今のプランだとメモリが足りない」「Standard以上の機能が欲しい」といったときに使います。第1回で学んだ価格レベルを上げる操作そのものです。

# App Service PlanのSKUを変更（スケールアップ）
az appservice plan update \
  --resource-group rg-appservice \
  --name plan-appservice \
  --sku P1V3

【ここが説明できればOK①】
App Service PlanのSKUを変更してスケールアップ（垂直スケール）が反映されることを確認できれば、このチェックはクリアです。

スケールアウト（自動スケール）を構成する

スケールアウト（水平スケール）は、インスタンスの”台数”を増やして、負荷を分散する方法です。特に強力なのが自動スケール（Autoscale）で、CPU使用率などのメトリックに応じて台数を自動で増減できます（Standard以上で利用可能）。

「1台を強く＝アップ」「台数を増やす＝アウト」。まずこの2語の区別が最重要！

典型的なルールは「CPU使用率が70%を超えたら1台追加、30%を下回ったら1台削減」といったもの。昼のピーク時だけ台数を増やし、夜は減らす——という運用が自動でできます。設定はApp Service Planに対して行います。

# 自動スケール設定を作成（最小1・最大5台）
az monitor autoscale create \
  --resource-group rg-appservice \
  --resource plan-appservice \
  --resource-type Microsoft.Web/serverfarms \
  --name autoscale-appservice \
  --min-count 1 --max-count 5 --count 1

# CPU 70%超で+1台するルールを追加
az monitor autoscale rule create \
  --resource-group rg-appservice \
  --autoscale-name autoscale-appservice \
  --condition "CpuPercentage > 70 avg 5m" \
  --scale out 1

【ここが説明できればOK②】
CPU使用率などのメトリックに基づく自動スケールアウトルールを設定し、インスタンスの増減を確認できれば、このチェックはクリアです。

デプロイスロットのスワップ（無停止デプロイ）

第2回で概念を紹介したデプロイスロットを、実際に運用する場面です。stagingスロットで新バージョンを検証し、本番とスワップ（入れ替え）することで、ダウンタイムなしのデプロイを実現します。

# ① stagingスロットを作成
az webapp deployment slot create \
  --resource-group rg-appservice \
  --name my-webapp-001 --slot staging

# （②stagingに新バージョンをデプロイ→動作確認）

# ③ staging と production をスワップ（無停止）
az webapp deployment slot swap \
  --resource-group rg-appservice \
  --name my-webapp-001 \
  --slot staging --target-slot production

スワップの巧妙な点は、スワップ前にstaging側を”予熱（ウォームアップ）”してから切り替えることです。これにより、切り替えた瞬間に「初回アクセスが遅い」という問題を避けられます。万一新バージョンに問題があっても、もう一度スワップすれば即座に旧バージョンへ切り戻せるのも安心材料です。

【ここが説明できればOK③】
stagingスロットを本番にスワップし、ダウンタイムなしで新バージョンへ切り替わることを確認できれば、このチェックはクリアです。

ヘルスチェック／Always On

安定運用を支える2つの機能を押さえましょう。どちらも設定は簡単ですが、効果は大きいです。

  • ヘルスチェック（Health check）：指定したパス（例 /health）を定期的に確認し、応答しない不健全なインスタンスを自動的にロードバランスから除外する。複数インスタンス運用時に、”死んだ1台”にリクエストが流れるのを防ぐ。
  • Always On：既定では一定時間アクセスがないとアプリがアンロード（アイドル停止）され、次のアクセスで起動に時間がかかる。Always Onを有効にすると常時稼働し、”コールドスタート”を防ぐ（Basic以上で利用可）。

「たまにアクセスすると最初だけ極端に遅い」という現象は、Always Onがオフでアイドル停止しているのが原因のことが多いです。本番運用ではAlways Onを有効に、複数台構成ではヘルスチェックを設定——これが定石です。

【ここが説明できればOK④】
「ヘルスチェックパスによる不健全インスタンスの除外」と「Always Onによるアイドル停止防止」の役割を説明できれば、このチェックはクリアです。

Application Insightsで監視する

「動いているか」だけでなく「どう動いているか」を可視化するのがApplication Insights（App Insights）です。Azure Monitorの一部で、App Serviceと統合されています。

有効化すると、次のようなテレメトリ（計測データ）が自動で収集・可視化されます。

  • 要求数（リクエスト数）と応答時間（どのページが遅いか）
  • 失敗率・例外（どのエラーが何回発生しているか、スタックトレース付き）
  • 依存関係（DB・外部API呼び出しの所要時間）、ライブメトリック（リアルタイム監視）

多くのランタイムでは、ポータルからApp Insightsを有効化するだけで（コード改修なしの自動計装で）主要なテレメトリが取れ始めます。「本番の遅い箇所・エラーの温床を特定する」入り口として、まず有効化しておきたい機能です。

【ここが説明できればOK⑤】
Application Insightsを有効化し、要求数・応答時間・例外などのテレメトリを確認できれば、このチェックはクリアです。

診断ログをLog Analyticsに送る

最後は、ログを1か所に集約してクエリで分析する仕組みです。App Serviceの診断設定（Diagnostic settings）を使い、各種ログ／メトリックを Log Analyticsワークスペース に送ります。

# 診断設定でログ/メトリックをLog Analyticsへ送る
az monitor diagnostic-settings create \
  --resource "<App ServiceのリソースID>" \
  --name diag-to-law \
  --workspace "<Log AnalyticsワークスペースのリソースID>" \
  --logs '[{"category":"AppServiceHTTPLogs","enabled":true}]'

集約したログは、KQL（Kusto Query Language）で自在に照会できます。たとえば「直近1時間の5xxエラーを多い順に集計」するなら、こんなクエリになります。

// 直近1時間の5xxエラーをURLごとに集計
AppServiceHTTPLogs
| where TimeGenerated > ago(1h)
| where ScStatus >= 500
| summarize count() by CsUriStem
| order by count_ desc

App Insights（テレメトリの可視化）とLog Analytics（ログの集約＋KQL分析）を組み合わせると、「異常に気づく→原因を掘り下げる」という監視のサイクルが回せます。まずは診断設定でログをLog Analyticsに集める——ここが監視の土台です。

【ここが説明できればOK⑥】
診断設定でApp Serviceのログ／メトリックをLog Analyticsワークスペースに送り、KQLで照会できれば、このチェックはクリアです。

まとめ：シリーズ全6回の総まとめ

最終回のポイントを振り返りましょう。

  • スケールアップ（垂直）＝1台を強く／スケールアウト（水平）＝台数を増やす。自動スケールでメトリック連動
  • スロットスワップで無停止デプロイ＆即時ロールバック
  • ヘルスチェック＋Always Onで安定稼働
  • App Insightsでテレメトリ可視化、診断設定→Log Analytics（KQL）でログ分析

そしてこの記事で、App Serviceシリーズ全6回が完結です。①概要 → ②デプロイ → ③設定 → ④ネットワーク → ⑤認証・ID → ⑥スケール・運用。この6ステップを一通りたどれば、App Serviceを「作れる」だけでなく、実務で安全に運用できる水準に到達しています。お疲れさまでした！

あわせて読みたい（App Serviceシリーズ）

タイトルとURLをコピーしました