Azure App Service入門 Webアプリのデプロイから料金・スケーリングまで現場で使える実践ガイド

「社内のWebアプリをクラウドに移行したいけど、サーバーの管理はもうやりたくない」

オンプレミスでIISやApache、Nginxを使ってWebアプリケーションを運用してきたエンジニアなら、一度はそう思ったことがあるはずです。OSのパッチ適用、ミドルウェアのバージョン管理、SSL証明書の更新、ロードバランサーの設定。Webアプリを動かすだけなのに、インフラ周りの作業が山ほどあります。

この記事では、Azure App Serviceの基本的な仕組みから、オンプレWebサーバーとの違い、料金モデル、デプロイ方法、スケーリング設計まで、現場のインフラエンジニア目線で解説します。

Azure App Serviceとは？オンプレWebサーバーとの違い

Azure App Serviceは、MicrosoftがAzure上で提供するフルマネージドのWebアプリケーションホスティングサービスです。.NET、Java、Node.js、Python、PHP、Rubyなど主要な言語・フレームワークに対応しており、コードをデプロイするだけでWebアプリが動きます。

オンプレのWebサーバーとの最大の違いは「インフラ層を一切触らなくていい」という点です。

オンプレでIISのアプリケーションプールを調整したり、Nginxのworker_processesを最適化したりした経験がある方なら、App Serviceの「何も設定しなくても動く」感覚に最初は違和感を覚えるかもしれません。しかし、その分アプリケーションのコードに集中できるのがPaaSの価値です。

App Serviceプラン（価格レベル）の選び方

Azure App Serviceの料金は「App Serviceプラン」で決まります。これはオンプレでいう「どのスペックのサーバーを借りるか」に相当します。

1. Free / Shared（開発・テスト向け）

無料で使えるFreeプランと、月額数百円のSharedプランがあります。カスタムドメインやSSLの制約があり、本番運用には使えません。動作確認やプロトタイプ開発に適しています。

2. Basic（小規模本番向け）

専用のコンピューティングリソースが割り当てられます。カスタムドメインとSSLが使えますが、自動スケールには対応していません。トラフィックが安定している社内向けアプリに向いています。

3. Standard（一般的な本番環境）

自動スケール、デプロイスロット（ステージング環境）、毎日のバックアップが使えます。ほとんどの本番Webアプリはこのプランで十分です。

4. Premium（高トラフィック・高パフォーマンス）

より多くのインスタンス数への自動スケール、VNet統合、より高いスペックのインスタンスが利用できます。大規模なB2Cサービスや、VNet経由でバックエンドDBに接続する構成に適しています。

※ 価格は従量課金（Pay-As-You-Go）の目安です。1年/3年のリザーブドインスタンスで最大55%割引になります。

オンプレでWebサーバー1台に月額数万円のハードウェアリース料を払っていたことを考えると、Standard (S1)の約1万円で自動スケール・ステージング環境・自動バックアップが付いてくるのは、コストパフォーマンスとしてかなり優秀です。

App Serviceの作成とデプロイ手順

1. Azureポータルでの作成

Azureポータル（portal.azure.com）にサインインし、以下の手順で進めます。

・「リソースの作成」→ 検索欄に「Web App」と入力 → 「Web アプリ」を選択
・サブスクリプションとリソースグループを選択（なければ新規作成）
・名前を入力（例: myapp-web）。この名前が `myapp-web.azurewebsites.net` のURLになる
・公開方法で「コード」を選択（Dockerコンテナも選択可能）
・ランタイムスタックを選択（例: .NET 8、Node 20 LTS、Python 3.12）
・リージョンで「Japan East（東日本）」を選択
・App Serviceプランを選択（新規作成 or 既存を選択）
・「確認および作成」→「作成」

作成完了まで1〜2分です。オンプレでIISのセットアップにWindows Serverのインストールから始めて半日かかっていた時代とは雲泥の差です。

2. Azure CLIでの作成

# リソースグループの作成
az group create --name myapp-rg --location japaneast

# App Serviceプランの作成（Standard S1）
az appservice plan create \
  --name myapp-plan \
  --resource-group myapp-rg \
  --location japaneast \
  --sku S1 \
  --is-linux

# Web Appの作成（Python 3.12の例）
az webapp create \
  --name myapp-web \
  --resource-group myapp-rg \
  --plan myapp-plan \
  --runtime "PYTHON:3.12"

`–is-linux` を付けるとLinuxベースのApp Serviceが作成されます。.NETやNode.jsはWindows/Linux両対応ですが、PythonやRubyはLinuxのみ対応です。

3. Gitでのデプロイ

App Serviceへのデプロイ方法は複数ありますが、最も手軽なのはローカルGitデプロイです。

# ローカルGitデプロイを有効化
az webapp deployment source config-local-git \
  --name myapp-web \
  --resource-group myapp-rg

# デプロイ用の資格情報を設定
az webapp deployment user set \
  --user-name deploy-user \
  --password 'YourDeployPassword123!'

# ローカルリポジトリにリモートを追加してpush
git remote add azure https://deploy-user@myapp-web.scm.azurewebsites.net/myapp-web.git
git push azure main

`git push` するだけでデプロイが完了します。オンプレでFTPクライアントを開いてファイルを1つずつアップロードしていた頃と比べると、運用効率が段違いです。

本番環境ではGitHub ActionsやAzure DevOpsと連携して、CI/CDパイプラインを構築するのが一般的です。App ServiceはGitHubリポジトリとの直接連携にも対応しており、Azureポータルの「デプロイセンター」から数クリックで設定できます。

デプロイスロットでゼロダウンタイムリリース

App Serviceの「デプロイスロット」は、Standardプラン以上で使える機能です。オンプレでいう「ステージング環境を用意して、本番と切り替える」という運用を、1つのApp Service内で実現できます。

仕組み

デプロイスロットは、本番スロットとは別のURL（例: `myapp-web-staging.azurewebsites.net`）を持つ独立した環境です。ステージングスロットにデプロイして動作確認した後、本番スロットと「スワップ」するだけで、ダウンタイムなしのリリースが完了します。

# ステージングスロットの作成
az webapp deployment slot create \
  --name myapp-web \
  --resource-group myapp-rg \
  --slot staging

# ステージングにデプロイ
git push azure-staging main

# 動作確認後、本番とスワップ
az webapp deployment slot swap \
  --name myapp-web \
  --resource-group myapp-rg \
  --slot staging \
  --target-slot production

スワップはDNSの切り替えではなく、内部的なルーティングの変更で行われるため、切り替えは数秒で完了します。万が一問題があれば、もう一度スワップすればロールバックできます。

オンプレでは「リリース日は深夜作業で、手動でファイルを差し替えて、動作確認して……」という運用が当たり前でした。デプロイスロットを使えば、営業時間中でもリリースできます。

スケーリングの設計

スケールアップ（垂直スケーリング）

App Serviceプランの価格レベルを上位に変更することで、CPUやメモリのスペックを上げられます。オンプレで「サーバーのCPUを交換する」「メモリを増設する」に相当する操作です。

Azureポータルの「スケールアップ」から数クリックで変更でき、数分で反映されます。再起動は発生しますが、ロードバランサーが組み込まれているため、複数インスタンス構成なら無停止で切り替わります。

スケールアウト（水平スケーリング）

インスタンス数を増やすことで処理能力を水平に拡張します。Standardプラン以上では、CPUやメモリの使用率、HTTPキューの長さなどの条件に基づく自動スケールが設定できます。

# 自動スケール設定の例（CPU 70%超で1台追加、30%未満で1台削減）
az monitor autoscale create \
  --resource-group myapp-rg \
  --resource myapp-plan \
  --resource-type Microsoft.Web/serverFarms \
  --name myapp-autoscale \
  --min-count 1 \
  --max-count 5 \
  --count 2

az monitor autoscale rule create \
  --resource-group myapp-rg \
  --autoscale-name myapp-autoscale \
  --condition "CpuPercentage > 70 avg 5m" \
  --scale out 1

az monitor autoscale rule create \
  --resource-group myapp-rg \
  --autoscale-name myapp-autoscale \
  --condition "CpuPercentage < 30 avg 5m" \
  --scale in 1

オンプレで負荷が上がったときに「サーバーを追加発注して、届くまで2週間待って、ラックに設置して……」という対応をしていた方なら、この自動スケールの速度感は革命的に感じるはずです。

ただし注意点があります。アプリケーション側がステートレスに設計されていないと、スケールアウトで問題が起きます。セッション情報をサーバーのメモリに保持している場合、リクエストが別インスタンスに振り分けられるとセッションが失われます。セッション管理はAzure Redis Cacheや外部データベースに移すのが定石です。

よくあるトラブルと対処法

「アプリが起動しない」の確認手順

デプロイ後にアプリが500エラーで動かない場合、まずApp Serviceのログを確認します。

Azureポータルで対象のApp Serviceを開き、「診断とトラブルシューティング」→「アプリケーションログ」を確認してください。スタートアップの失敗原因が記録されています。

よくある原因はランタイムバージョンの不一致です。ローカルではPython 3.11で開発していたのに、App ServiceのランタイムがPython 3.12に設定されていた、というケースです。ポータルの「構成」→「全般設定」でランタイムバージョンを確認してください。

カスタムドメインの設定でつまずく

`myapp-web.azurewebsites.net` ではなく独自ドメインを使う場合、DNSにCNAMEレコードを追加します。

・CNAMEレコード: `www` → `myapp-web.azurewebsites.net`
・TXTレコード（検証用）: `asuid.www` → App Serviceが指定するドメイン検証ID

ネイキッドドメイン（www なし）を使う場合はAレコードの設定が必要です。オンプレでDNSを管理していた方なら手慣れた作業ですが、TXTレコードによるドメイン所有権の検証がAzure固有のステップとして加わります。

環境変数と接続文字列の管理

オンプレではweb.configやappsettings.jsonにDB接続文字列を直接書いていたケースも多いと思います。App Serviceでは「構成」→「アプリケーション設定」から環境変数として設定するのが基本です。

これにより、コードリポジトリに機密情報を含めなくて済みます。さらに、Azure Key Vaultと連携して「Key Vault参照」を使えば、接続文字列をKey Vaultから自動取得する構成も組めます。

# アプリケーション設定の追加（Azure CLI）
az webapp config appsettings set \
  --name myapp-web \
  --resource-group myapp-rg \
  --settings DB_CONNECTION="Server=mydb.database.windows.net;Database=myapp;..."

# Key Vault参照を使う場合
az webapp config appsettings set \
  --name myapp-web \
  --resource-group myapp-rg \
  --settings DB_CONNECTION="@Microsoft.KeyVault(VaultName=myapp-kv;SecretName=db-connection)"

本記事のまとめ

Azure App Serviceは「Webアプリを動かすためのインフラ管理」からエンジニアを解放してくれるサービスです。IISのアプリケーションプール設定やApacheのチューニングに費やしていた時間を、アプリケーション開発に振り向けられます。

まずはFreeプランで既存のアプリをデプロイしてみるのが最も確実な第一歩です。`git push` するだけでWebアプリが公開される体験を、ぜひ実感してみてください。