Azure App Service

解決する課題

• Web アプリや API をすぐ公開したいが、サーバーや OS の構築・パッチ適用に手間をかけたくない
• 言語ランタイム（.NET・Java・Node.js・Python・PHP など）やコンテナをそのまま動かしたい
• HTTPS・独自ドメイン・証明書・スケールといった定番の運用機能を最初から欲しい
• リリース時のダウンタイムをなくし、問題時にすぐ戻したい
• インフラよりもアプリのコードに集中したい（IaaS の仮想マシンを自分で運用したくない）

主要概念と用語

• App Service プラン: アプリが動くコンピューティングの器。価格レベル（Tier）と規模（インスタンス数）を決め、課金の単位になる。同一プラン内に複数のアプリを同居できる
• Web App（アプリ本体）: 実際に公開される単位。コードまたはコンテナをデプロイする
• 価格レベル（Tier）: Free / Shared から、Basic・Standard・Premium、隔離された Isolated まで段階がある。上位ほどスケール上限・機能・分離が強化される
• デプロイスロット: 本番とは別のステージング環境。検証後に本番と入れ替え（スワップ）できる
• スワップ: スロット同士を入れ替える操作。事前ウォームアップにより無停止リリースと即時ロールバックを実現する
• スケールアップ / スケールアウト: 価格レベルを上げて1台を強くするのがスケールアップ、インスタンス数を増やすのがスケールアウト
• App Service for Containers: 独自の Docker イメージをそのまま実行する形態
• WebJobs / 継続的デプロイ: バックグラウンド処理の実行や、GitHub などからの自動デプロイ

仕様・制限・クォータ

• OS は Windows と Linux から選べる。対応する言語ランタイムやコンテナ実行は OS により差がある
• 無料・共有レベルは検証用で、独自ドメインや常時稼働などに制約がある。本番では Basic 以上を選ぶのが一般的
• 自動スケールやスロット数の上限は価格レベルに依存する。上位レベルほどインスタンス数とスロット数を多く確保できる
• リージョンやサブスクリプションごとに利用できるインスタンス数などのクォータがあり、必要に応じて引き上げ申請が可能
• 具体的な台数・サイズ・スロット数は価格レベルとリージョンで変わるため、最新の公式情報で確認すること

内部の仕組み

App Service は、利用者から見えない共有または専用のワーカー群の上でアプリを実行するマネージド基盤です。利用者は App Service プランで価格レベルとインスタンス数だけを宣言し、OS のパッチ適用・ロードバランサ・ヘルスチェック・スケールはプラットフォーム側が担います。

受信リクエストはプラットフォームのフロントエンド（ロードバランサ）を経由して、プラン内の各ワーカーインスタンスに分散されます。スケールアウトすると同じアプリが複数インスタンスで動くため、アプリはステートレスに設計し、セッションやファイルはアプリ外（データベースや Blob、Redis など）へ逃がすのが前提になります。

デプロイスロットは、同一プラン上に別ホスト名を持つ並行環境として用意されます。スワップ時は新スロットを事前にウォームアップしてからルーティングを切り替えるため、利用者への影響を抑えてリリースできます。問題があれば再度スワップして元に戻せます。

設計パターン / ベストプラクティス

• アプリはステートレスに保ち、状態は外部（DB・Blob・Redis）へ。スケールアウトしても整合するようにする
• リリースはデプロイスロット経由で行い、スワップで無停止反映・即時ロールバックを可能にする
• 接続文字列やキーはアプリ設定や Key Vault 参照で注入し、コードに埋め込まない
• 負荷に応じて**自動スケール（メトリックやスケジュール）**を設定し、過剰な常時インスタンスを避ける
• 仮想ネットワーク統合やプライベートエンドポイントで、バックエンド（DB など）への通信を閉域化する

運用・監視

• Application Insights を有効化し、要求数・応答時間・例外・依存関係を可視化する（分散トレースに対応）
• プラットフォームのメトリクスとログは Azure Monitor / Log Analytics に集約し、アラートを設定する
• デプロイ直後に不調なら、まずスワップで元のスロットへ戻すことを第一の対応にする
• 起動失敗時は、ログストリームやコンソールでアプリのスタートアップログ・ランタイムのバージョン整合を確認する
• ヘルスチェック機能で異常インスタンスを自動的にローテーションから外す

コスト

• 課金は基本的に **App Service プラン（価格レベル × インスタンス数 × 稼働時間）**に対して発生する。アプリの数ではなくプランが単位
• 同一プランに複数アプリを同居させればコストを共有できるが、リソースの取り合いに注意する
• 検証用途では Free / Shared、本番では Basic 以上を選ぶ。Premium は性能・スケール・スロットが強化される
• インスタンスを増やしたままにせず、自動スケールで需要に合わせるとコスト効率が上がる
• 具体的な料金は価格レベル・リージョン・OS で変動するため、断定せず公式の料金ページで見積もる

セキュリティ

• マネージド ID をアプリに付与し、Key Vault やデータベースへ資格情報なしでアクセスする（AWS の IAM ロール相当）
• 認証・認可は組み込みの認証機能（Easy Auth）で Entra ID や各種 ID プロバイダと連携でき、アプリ側の実装を減らせる
• HTTPS を必須化し、独自ドメインにはマネージド証明書などで TLS を提供する
• プライベートエンドポイント / 仮想ネットワーク統合で受信・送信の経路を閉域化する
• シークレットはアプリ設定の Key Vault 参照で注入し、コードや構成ファイルへの平文埋め込みを避ける

Well-Architected の観点

• 運用上の優秀性: デプロイスロットと継続的デプロイで、リリースの自動化と無停止反映・ロールバックを標準化できる。OS パッチやスケールはプラットフォームに委譲される
• 信頼性: 複数インスタンスへの分散とヘルスチェックで可用性を高め、ステートレス設計で水平スケールに耐える
• パフォーマンス効率: 自動スケールで需要に追従し、価格レベルのスケールアップで単体性能も調整できる
• コスト最適化: プラン単位の課金を理解し、同居・自動スケール・適切なレベル選択で無駄を抑える
• セキュリティ: マネージド ID・Key Vault・閉域ネットワーク・組み込み認証で、資格情報の露出と攻撃面を減らす

試験で問われるポイント

関連サービス・比較

App Service で OS レベルの制御が必要なら仮想マシン（IaaS）、逆にリクエスト単位で課金してアイドル時の費用を止めたいならAzure Functions のようなサーバーレスを検討します。コンテナを本格運用するなら Container Apps / AKS も比較対象になります。

ハンズオン / CLI例

# リソースグループと App Service プランを作成（Linux・Basic レベル）
az group create --name demo-rg --location japaneast
az appservice plan create \
  --name demo-plan \
  --resource-group demo-rg \
  --location japaneast \
  --is-linux \
  --sku B1

# Web アプリを作成（Node ランタイムの例）
az webapp create \
  --name demo-web-unique-name \
  --resource-group demo-rg \
  --plan demo-plan \
  --runtime "NODE:20-lts"

# ステージング用のデプロイスロットを作成
az webapp deployment slot create \
  --name demo-web-unique-name \
  --resource-group demo-rg \
  --slot staging

# 検証後、ステージングを本番へスワップ（無停止リリース）
az webapp deployment slot swap \
  --name demo-web-unique-name \
  --resource-group demo-rg \
  --slot staging \
  --target-slot production

# 公開 URL を確認
az webapp show \
  --name demo-web-unique-name \
  --resource-group demo-rg \
  --query defaultHostName -o tsv