Azureを学ぶ Azure App Serviceを試す

本記事は Microsoft Learn の「Azure App Serviceを試す」というモジュールをまとめたものである。

Azure App Service を調べる

WebアプリやAPIの公開・運用を効率化するフルマネージドなプラットフォーム（PaaS）。インフラ管理の複雑さを排除し、開発者が「コードを書くこと」と「迅速な機能リリース」に専念できる環境を提供する。

特徴とメリット

• インフラ管理の不要化：サーバーの構築・保守・スケーリングが自動化されるため、運用負荷が大幅に軽減される
• 幅広い技術スタックへの対応：.NET、Java、Node.js、Python、PHPなど、主要な言語を網羅。WindowsとLinuxのいずれの環境も選択可能
• 高い柔軟性：標準的なランタイムだけでなく、カスタムコンテナー（Docker等）のデプロイにも対応。実行環境を自由にカスタマイズできる制御権を確保できる

組み込みの自動スケールのサポート

Azure App Serviceは、負荷に応じてリソースを自動調整する機能を標準装備している。調整方法は以下の2種類。

• スケールアップ・ダウン（性能の変更）：CPUやメモリなどの「マシンのパワー」を強化・縮小する
• スケールアウト・イン（台数の変更）：稼働する「サーバーの台数」を増やして負荷を分散、または減らして撤収する

コンテナのサポート

Azure App Serviceは、コンテナー化したWebアプリをOS問わず実行できる。

• 自由なデプロイ：Windows・Linuxの両OSに対応。Azure Container RegistryやDocker Hubからイメージを取得可能
• 高度な構成：Windowsコンテナーや、Docker Composeによるマルチコンテナー構成をサポート

CI/CD のサポート

Azure App Serviceは、コードの変更を自動で反映するCI/CD環境を標準提供している。

• 多様なソース連携：GitHub、Bitbucket、Azure DevOps、ローカルGitなどと簡単に接続可能
• 自動同期：リポジトリへコードをプッシュするだけで、App Serviceが自動で変更を検知・適用する
• コンテナー対応：Docker HubやAzure Container Registryと連携し、コンテナーイメージの自動更新もサポート

デプロイスロット

Standardプラン以上では、本番環境とは別の「デプロイ スロット」を利用できる。

• 検証環境の構築：本番と同じ設定の別環境へ先にデプロイし、動作確認を行える
• スワップ機能：ボタン一つで本番環境と中身を入れ替え可能
• リスク低減：事前検証済みのアプリを本番へ反映させるため、リリース時のダウンタイムや事故を最小限に抑えられる

App Service on Linux

Linux環境でのネイティブ実行と、カスタムコンテナーの両方をサポートしている。

• 手軽なデプロイ：.NET Core、Java、Node.js、Python、PHP用の組み込みイメージが用意されており、コードをアップロードするだけで即座に稼働する
• 高いカスタマイズ性：組み込みイメージで対応できない特殊なランタイムが必要な場合、独自のカスタムコンテナーを利用できる
• 最新環境の維持：言語やフレームワークは定期的にアップデートされる。最新の対応状況は Azure CLI (az webapp list-runtimes) から確認可能

App Service Environment

App Service Environment は、高いセキュリティと独立性を備えた、専用の実行環境を提供する機能。

• 完全な隔離：他のユーザーとインフラを共有しない、顧客専用のネットワーク・コンピューティング環境を構築できる
• 高度なセキュリティ：仮想ネットワーク（VNet）内に展開されるため、ネットワークトラフィックの制御や分離を厳格に行える
• 専用リソース：サポートインフラを含め、1人の顧客がリソースを独占して利用できる

Azure App Service プランを調べる

App Service上で動くアプリは、必ず「App Service プラン」というリソースの枠組みの中で実行される。

• プランの定義要素：OS（Windows/Linux）、実行リージョン、サーバー（VM）のサイズと台数を決定する
• リソース共有：同一プラン内であれば、複数のアプリで一つのコンピューティングリソースを共有して動かすことが可能

価格レベルの種類
価格レベルによって、機能とコスト、独立性が決まる。

• 共有コンピューティング（Free, Shared）：他ユーザーとVMを共有する低コスト層。リソース制限があり、スケールアウト不可
• 専用コンピューティング（Basic 〜 Premium）：自分専用のVMを確保。同じプラン内のアプリのみが同居し、高い処理能力とスケールアウトが可能
• Isolated（IsolatedV2）：専用の仮想ネットワーク上で稼働。ネットワークレベルで完全に分離された最高水準のセキュリティと拡張性を持つ

アプリの実行方法とスケーリング方法

App Service プランは、アプリを動かすための「最小の単位（スケールユニット）」として機能する。

• リソースの共有：同じプランに属するすべてのアプリ、デプロイ スロット、Webジョブは、同一のVMインスタンス上でリソースを共有して動作する
• 一斉スケーリング：プランのインスタンス数を増減させると、そのプラン内のすべてのアプリが同時にスケールアウト・インする
• オーバーヘッドの考慮：診断ログの出力やバックアップの実行も同じVMのCPU・メモリを消費するため、これらを加味したリソース設計が必要
• 無料・共有レベルの制約：FreeおよびSharedレベルは共有VMを利用するため、スケールアウト（台数増加）には対応していない

アプリのパフォーマンス最適化とコスト管理

アプリの負荷や要求レベルに応じて、App Service プランを柔軟に変更・再編できる。

• プランの変更（スケールアップ/ダウン）：価格レベルを切り替えるだけで、いつでもCPUやメモリ、利用可能な機能を拡張・縮小できる
• コストの最適化：負荷の低い複数のアプリを一つのプランに集約することで、コンピューティングリソースを共有し、コストを抑えられる
• プランの分離（パフォーマンス優先）：特定のアプリが重い、個別にオートスケールさせたい、あるいは別リージョンで動かしたい場合は、そのアプリを独立した新しいプランへ移動させる

App Service にデプロイする

各チームの要件に合わせて、自動と手動の両デプロイ方式を柔軟に選択・実装できる。

自動デプロイ

迅速な機能提供とバグ修正を実現するため、主要なソース管理システムと連携した自動デプロイが可能。

• Azure DevOps：ビルドからテスト、リリースまで一貫したパイプラインを構築できる
• GitHub：リポジトリの特定ブランチへプッシュするだけで、変更を自動反映する
• Bitbucket：標準対応しているが、より親和性が高いのは上記2種

手動デプロイ

自動化パイプラインを介さず、直接コードをプッシュする手段として以下が提供されている。

• Git：App Serviceをリモートリポジトリとして登録し、直接プッシュしてデプロイする
• CLI (az webapp up)：コマンド一つでアプリの新規作成からパッケージ化、デプロイまでを一括実行する
• Zipデプロイ：アプリファイルをZIP形式にまとめ、HTTP経由（curl等）で転送する
• FTP/S：従来のファイル転送プロトコルを利用して、サーバー上のディレクトリへ直接配置する

デプロイスロットの使用

Standardプラン以上では、デプロイ スロットを活用したダウンタイムのない更新が可能。

• ステージング環境の利用：本番とは別のスロットにデプロイし、事前に動作確認を行える
• スワップ機能：本番とステージングを入れ替える際、事前にインスタンスが起動（ウォームアップ）されるため、切り替え時の停止時間をゼロにできる

複数環境への継続的デプロイ

ブランチ戦略に合わせた効率的な検証フローを構築できる。

• ブランチ別デプロイ：テスト（Test）、品質保証（QA）、ステージングなどの各ブランチを、対応する専用スロットに自動配備する
• スムーズな検証：関係者が常に最新の検証環境へアクセスできるため、テストとレビューが迅速化する

コンテナーの継続的デプロイ

コンテナー更新時は、スロット活用と適切なタグ管理でダウンタイムと混乱を防ぐ。

• スロットの活用：直接本番を更新せず、ステージングスロットへデプロイしてスワップすることで無停止更新を実現する
• 一意なタグ付け：latest タグの使用は避け、コミットIDやタイムスタンプで識別可能にする。これによりデバッグやバージョン追跡が容易になる
• 自動更新フロー：イメージをレジストリへプッシュし、Webアプリ側の指定タグを更新する。タグ更新を検知してサイトは自動再起動し、新イメージをプルする

サイドカーコンテナーの活用

Linuxベースのカスタムコンテナーにおいて、メインアプリを補助する「サイドカー」を最大9つまで追加できる。

• 機能の分離：監視、ログ収集、設定管理、ネットワークサービスなどの補助機能を、メインのコードを汚さずに別コンテナーとして実行可能
• 疎結合な設計：メインアプリと密接に連携しつつ、各サービスの独立性を保てる
• 設定方法：Azureポータルの「デプロイ センター（Deployment Center）」から簡単に追加・管理できる

App Service の認証と認可について詳しく知る

App Service は認証・認可機能を内蔵しており、Web アプリや API においてコードをほとんど書かずにユーザー認証やデータアクセス制御を実装できる。

組み込み認証を利用する利点

App Serviceにはプラットフォームレベルで認証機能が統合されており、独自実装の手間を大幅に削減できる。

• 開発効率の向上：IDプロバイダーとの連携が標準提供されているため、セキュリティの実装時間を削り、アプリ本来の機能開発に専念できる
• 専門知識が不要：言語やSDK、高度なセキュリティ知識に関わらず、設定のみで認証機能を導入可能
• 多様なプロバイダー：Microsoft Entra ID、Google、Facebook、Xなどの主要なログイン手段を容易に統合できる
• 柔軟な選択肢：より高度な制御が必要な場合は、既存フレームワークのセキュリティ機能や自作ユーティリティとの併用・切り替えも可能

IDプロバイダーとの連携

App Service はフェデレーション認証を採用しており、外部プロバイダーがユーザーID管理と認証フローを代行する。

• 標準対応プロバイダー：Microsoft Entra ID、Google、Facebook、X、GitHub、Apple、OpenID Connectが利用可能
• 専用エンドポイント：各プロバイダーに対応した専用URL（例: /.auth/login/google）が用意されており、これを利用して認証・トークン検証を行う
• 自由な組み合わせ：複数のサインインオプションを同時に提供することも可能

認証・認可の仕組み

App Service の認証機能は、アプリ本体と同じ VM 上で動作するプラットフォーム・ミドルウェアとして提供される。

• リクエストの遮断：すべての HTTP 要求は、アプリに届く前にこのモジュールを通過し、認証と認可が行われる
• ミドルウェアの役割：ユーザーの認証と、各プロバイダーが発行する OAuth トークンの検証・保存・更新
  • 認証セッションの管理
  • ユーザー情報を HTTP ヘッダーに挿入し、アプリ側へ受け渡し
• コード不要：アプリケーションコードとは独立して動作するため、言語や SDK に依存せず、設定ファイルや Azure Resource Manager から構成できる

2つの認証フロー

認証方式は、プロバイダーのSDKを使用するかどうかで「サーバー主導」と「クライアント主導」の2つに分かれる。

• サーバー主導フロー（SDKなし）

  • 対象：主にブラウザアプリ
  • 仕組み：App Serviceがログインページへのリダイレクトやサインイン処理を代行する
  • 結果：認証後はブラウザのCookieでセッションを管理

• クライアント主導フロー（SDKあり）

  • 対象：REST API、モバイルアプリ、JSクライアントなど
  • 仕組み：アプリ側でプロバイダーのSDKを使いログインし、取得したトークンをApp Serviceに送信して検証する
  • 結果：App Serviceが独自のトークンを発行し、以降は X-ZUMO-AUTH ヘッダーで認証を行う

認証手順の比較

項目	サーバー主導 (SDKなし)	クライアント主導 (SDKあり)
サインイン	指定URLへリダイレクト	SDKで直接ログイン
検証	自動でコールバック処理	トークンをApp ServiceへPOST
認証確立	セッション認証Cookieを発行	認証トークンを返却

未認証リクエストへの対応

Azure portalの設定により、認証されていないユーザーからのアクセスに対する動作を制御できる。

• 未認証アクセスを許可（コードに委任）
  • 挙動：ログインなしでアプリにアクセス可能
  • 用途：匿名ユーザー向けのページを表示したり、複数のログインプロバイダーをアプリ側で提示したりする場合に利用
  • 特徴：認証済みの場合のみ、HTTPヘッダーにユーザー情報が追加される
• 認証を強制（アクセス拒否）
  • 挙動：未認証リクエストを遮断し、ログインを促す
  • ブラウザ：設定したプロバイダーのログインページ（/.auth/login/<provider>）へ自動リダイレクト
  • モバイル/API：HTTP 401 Unauthorized を返却
  • カスタム：常に 401 や 403 Forbidden を返すよう構成することも可能

トークン ストア

App Serviceには、認証によって取得したトークンを安全に保管・管理する「トークン ストア」が内蔵されている。

• リポジトリ機能：WebアプリやAPIのユーザーごとに紐付けられた認証トークンを自動で保持する
• 即時利用：いずれかのIDプロバイダーで認証を有効化すれば、追加設定なしでそのまま利用可能
• 活用場面：保管されたトークンを使用し、ユーザーに代わってプロバイダーのリソース（Graph APIなど）へアクセスできる

トークンストアは組み込みの認証機能を使用している場合にのみ利用可能であり、トークンには環境変数または HTTP ヘッダーを介してアクセスできる

認証・認可のデバッグ

アプリケーションログを有効化することで、認証に関する詳細な動作を追跡できる。

• ログの統合：認証・認可のトレース情報がアプリケーションログファイル内に直接記録される
• トラブルシューティング：予期しないログイン失敗や権限エラーが発生した際、ログを参照するだけで原因の特定が可能
• 利便性：認証専用のツールを使わず、既存のログ出力の仕組みでデバッグを完結できる

App Service のネットワーク構成

既定ではインターネットに公開されており、外部エンドポイントへのアクセスも可能。セキュリティ要件に応じて、トラフィックを制御する必要がある。

2つのデプロイ形態

• マルチテナント（パブリック）
  • SKU：Free, Shared, Basic, Standard, Premium (V2/V3)
  • 特徴：共有インフラ上でホストされる一般的な構成
• シングルテナント (ASE: App Service Environment)
  • SKU：Isolated
  • 特徴：ユーザー専用の仮想ネットワーク（VNet）内で直接実行。高度な分離とセキュリティが必要な場合に適している

マルチテナント App Service のネットワーク構造

App Serviceは「フロントエンド（リクエスト処理）」と「ワーカー（アプリ実行）」からなる分散システム。複数の顧客がインフラを共有するため、アプリを直接社内ネットワーク等に接続することはできない。

その代わりに、「受信（イン入り）」と「送信（アウト）」のそれぞれに対して独立した制御機能が提供される。

主要なネットワーク機能

方向	主な機能	用途
受信 (Inbound)	アクセス制限	特定のIPアドレスのみ許可
	プライベート エンドポイント	VNet内からのみアクセス可能にする
	アプリ割り当てアドレス	専用のIPアドレスを割り当てる
送信 (Outbound)	VNet 統合	VNet内のリソースや外部へ安全に接続
	ハイブリッド接続	外部のオンプレミス等へ中継接続

受信制御のユースケース

• IPベースのSSL：「アプリ割り当てアドレス」で専用IPを使用
• 特定の接続元に限定：「アクセス制限」で特定のIP範囲以外を遮断
• セキュアな受信：「プライベート エンドポイント」によりインターネットに公開せず運用

App Service の既定の動作とホスト構造

App Serviceは「スケールユニット」という単位で多数の顧客を収容しており、プラン（SKU）によってアプリが動く「ワーカー（サーバー実体）」の専有度が異なる。

プランごとのワーカー共有状況

• Free / Shared：他の顧客と同じワーカー（マルチテナントワーカー）上でアプリが実行される
• Basic 以上：ワーカーは特定の顧客（自社）の「App Service プラン」専用となる
• Standard 以上：同じプラン内の全アプリが、同一のワーカー上でリソースを共有して動作する
  • スケールアウト（インスタンス増設）時：プラン内の全アプリが、新しいワーカーへセットでコピー（レプリケート）される

送信（アウトバウンド）IPアドレスの仕組み

アプリから外部へ接続する際に使われるIPアドレスは、プランの「仮想マシン（VM）ファミリ」によって決まる。

• VMファミリとアドレスの関係
  • Free/Shared/Basic/Standard/Premium は同じVMファミリを共有
  • PremiumV2 や PremiumV3 はそれぞれ異なるVMファミリを使用
  • プラン（SKU）のランクを変更（例：StandardからPremiumV3へ）すると、送信IPアドレスも変化する
• 共有の仕組み
  • 送信IPは固定の1つではなく、複数のアドレス候補（セット）から選ばれる
  • これらのアドレスは、同じVMファミリを利用している他ユーザーのアプリとも共有される
• IPの確認方法
  • outboundIpAddresses：アプリが現在使用しているIPリスト
  • possibleOutboundIpAddresses：スケールユニット全体でアプリが使用する可能性のある全IPリスト（将来的な増設等を含む）

送信元IPが複数ある理由は、通信の渋滞（ポート枯渇）を防ぐための負荷分散、障害時に別の経路で通信を継続する冗長性の確保、そしてアプリ増設時に即座に通信できるよう予備のIPを確保しておくためである。

送信 IP アドレスの確認方法

アプリが外部への通信で使用するIPアドレスは、Azure portal または Azure CLI（コマンド）で確認できる。

1. Azure portal で確認する

• アプリのメニューから [プロパティ] を選択
• [送信 IP アドレス] 欄に表示される

2. コマンド (Azure CLI) で確認する

アプリが現在使用しているIPリスト

az webapp show \
    --resource-group <group_name> \
    --name <app_name> \
    --query outboundIpAddresses \
    --output tsv

スケールユニット全体でアプリが使用する可能性のある全IPリスト

az webapp show \
    --resource-group <group_name> \
    --name <app_name> \
    --query possibleOutboundIpAddresses \
    --output tsv

演習：コンテナー化されたアプリを Azure App Service にデプロイする

web app リソースの作成

• Azure portal に移動
• App Services から作成を選択
  
• 基本情報を入力
  
• コンテナ情報を入力
  
• 作成を押す