Azure App Service におけるオペレーティング システムの機能

  • [アーティクル]

この記事では、 Azure App Service上で動作するすべての Windows アプリが利用できる基本的なオペレーティング システムの機能について説明します。 これらの機能には、ファイル アクセス、ネットワーク アクセス、レジストリ アクセス、診断ログ、イベントがあります。

Note

App Service の Linux アプリは、独自のコンテナーで実行されます。 コンテナーへのルート アクセス権はありますが、ホスト オペレーティング システムへのアクセスは許可されていません。 同様に、Windows コンテナーで実行されるアプリではコンテナーへの管理アクセスが可能ですが、ホスト オペレーティング システムにはアクセスできません。

App Service プランの階層

App Service は、マルチテナント ホスティング環境で顧客のアプリを実行します。 Free レベルと Shared レベルでデプロイされたアプリは、共有仮想マシン上のワーカー プロセスで実行されます。一方、Standard レベルと Premium レベルでデプロイされたアプリは、単一の顧客に関連付けられたアプリ専用の仮想マシン上で実行されます。

Note

App Service の Free および Shared (プレビュー) サービス プランは、他の App Service アプリと同じ Azure 仮想マシンで稼働する基本レベルです。 一部のアプリは他のお客様に属する場合もあります。 このレベルは、開発とテストのみでの使用を対象としています。

App Service はどのレベルでもシームレスにスケーリングされるので、App Service アプリのセキュリティ構成は選択するレベルに左右されません。 これにより、App Service プランを別のレベルに切り替えたときにアプリの動作が突然変わって予期しないエラーが発生することはありません。

開発フレームワーク

アプリで使用できるコンピューティング リソース (CPU、ディスク ストレージ、メモリ、ネットワーク送信) は、App Service の価格レベルによって異なります。 ただし、アプリで使用できるフレームワーク機能の幅はどのスケーリング レベルでも変わりません。

App Service では、ASP.NET、クラシック ASP、Node.js、PHP、Python などのさまざまな開発フレームワークをサポートしています。 セキュリティ構成を標準化して単純にするために、App Service アプリでは通常、各種の開発フレームワークが既定の設定で実行されます。 プラットフォームで指定されるフレームワークとランタイム コンポーネントは、セキュリティとコンプライアンスの要件を満たすように、定期的に更新されます。このような理由により、特定のマイナー バージョンやパッチ バージョンは保証していません。必要に応じて、お客様のターゲット メジャー バージョンをお勧めします。

この後の各セクションでは、App Service アプリで使用できる汎用オペレーティング システム機能について概説します。

ファイル アクセス

App Service には、ローカル ドライブやネットワーク ドライブなど、さまざまなドライブが存在します。

ローカル ドライブ

根本的に、App Service は、Azure PaaS (Platform as a Service) インフラストラクチャ上で動作するサービスです。 したがって、仮想マシンに "接続" されるローカル ドライブは、Azure 上の worker ロールで使用するドライブと同じ種類です。 これには次のものが含まれます

  • オペレーティング システム ドライブ (%SystemDrive%)。このサイズは、VM のサイズによって変わります。
  • リソース ドライブ (%ResourceDrive%) は、App Service で内部的に使用されます。

ベスト プラクティスは、ハードコーディングされたファイル パスではなく、常に環境変数 %SystemDrive% と %ResourceDrive% を使用することです。 これら 2 つの環境変数から返されるルート パスは、時間の経過とともに d:\ から c:\ にシフトしています。 ただし、d:\ へのファイル パス参照でハードコーディングされた古いアプリケーションは引き続き機能します。これは、App Service プラットフォームが d:\ を自動的に再マップして代わりに c:\ を指すようにするためです。 前述のように、ファイル パスを作成するときは常に環境変数を使用し、既定のルート ファイル パスに対するプラットフォームの変更に関する混乱を避けることを強くお勧めします。

アプリケーションの成長に伴い、ディスク使用率を監視することが重要です。 ディスク クォータに達すると、アプリケーションに悪影響が及ぶ可能性があります。 次に例を示します。

  • ディスク上の領域が不足していることを示すエラーがアプリからスローされることがあります。
  • ブラウザーで Kudu コンソールにアクセスするときにディスク エラーが表示されることがあります。
  • Azure DevOps または Visual Studio からのデプロイが失敗することがあります (ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk))。
  • アプリのパフォーマンスが低下することがあります。

ネットワーク ドライブ (UNC 共有)

アプリのデプロイとメンテナンスを容易にする App Service の特長の 1 つは、すべてのコンテンツ共有が一連の UNC 共有に保存されることです。 このモデルは、複数の負荷分散サーバーを配したオンプレミス Web ホスティング環境で使用される共通のコンテンツ ストレージ パターンに対応します。

App Service 内には、各データ センターに作成された複数の UNC 共有があります。 データ センターごとに、すべての顧客のユーザーコンテンツの割合が各 UNC 共有に反映されます。 顧客のサブスクリプションごとに、データ センター内の UNC 共有上にディレクトリ構造が確保されます。 顧客が特定のデータ センター内に複数のアプリを作成している場合は、その顧客サブスクリプションに属するすべてのディレクトリが同じ UNC 共有上に作成されます。

Azure サービスの性質上、UNC 共有をホストする仮想マシンはその時々で変わります。 通常の Azure 運用で個々の仮想マシンが起動または停止するたびに、それらに UNC 共有が確実にマウントされます。 したがって、UNC ファイル パスのマシン情報が常に変わらないことを前提としてアプリをハードコーディングしないでください。 代わりに、App Service に用意されている便利な "偽" の絶対パス %HOME%\site を使用してください。 この "偽" の絶対パスを使用すれば、アプリとユーザーが変わっても常に目的のアプリを表すことができます。 %HOME%\site を使用することで、共有ファイルを別のアプリへ移動するたびに新しい絶対パスを構成する必要がなくなります。

アプリに付与されるファイル アクセスの種類

アプリ内の %HOME% ディレクトリは、そのアプリ専用の Azure Storage 内のコンテンツ共有にマップされ、そのサイズは価格レベルで定義されます。 これには、コンテンツ、エラー、診断のログ用のディレクトリや、ソース管理によって作成された以前のバージョンのアプリのディレクトリなどが含まれることがあります。 これらのディレクトリは、読み取りおよび書き込みアクセスのために、実行時にアプリのアプリケーション コードで使用可能です。 ファイルはローカルに保存されないので、アプリの再起動後も保持されます。

システム ドライブでは、%SystemDrive%\local は App Service によってアプリ固有の一時ローカル ストレージ用に予約されます。 このディレクトリ内のファイルに対する変更は、アプリの再起動後に保持 "されません"。 アプリはこの一時的なローカル ストレージに自由に読み取り/書き込みアクセスできますが、アプリケーション コードからの直接アクセスは本来の使用方法ではありません。 このストレージの目的は、IIS および Web アプリケーション フレームワークに一時的なファイル ストレージを提供することです。 さらに、App Service では、各アプリの %SystemDrive%\local でのストレージ容量も制限されます。これは、個々アプリでローカル ファイル ストレージが過度に消費されるのを防ぐためです。 Free、Shared、Consumption (Azure Functions) レベルでは、制限は 500 MB です。 その他のレベルについては、次の表を参照してください。

SKU ローカル ファイル ストレージ
B1/S1/P1 11GB
B2/S2/P2 15 GB
B3/S3/P3 58 GB
P0v3 11GB
P1v2/P1v3/P1mv3/Isolated1/Isolated1v2 21 GB
P2v2/P2v3/P2mv3/Isolated2/Isolated2v2 61 GB
P3v2/P3v3/P3mv3/Isolated3/Isolated3v2 140 GB
Isolated4v2 276 GB
P4mv3 280 GB
Isolated5v2 552 GB
P5mv3 560 GB
Isolated6v2 1104 GB

App Service での一時的なローカル ストレージの使用例として、ASP.NET 一時ファイルのディレクトリと IIS 圧縮ファイルのディレクトリがあります。 ASP.NET コンパイル システムでは、%SystemDrive%\local\Temporary ASP.NET Files ディレクトリをコンパイルの一時的なキャッシュ場所として使用します。 IIS では、%SystemDrive%\local\IIS Temporary Compressed Files ディレクトリを使用して圧縮済みの応答出力を保存します。 これらはいずれも、App Service ではアプリごとの一時的なローカル ストレージに再マッピングされます。 この再マッピングにより、引き続き適切に機能させることができます。

App Service の各アプリは、"アプリケーション プール ID" と呼ばれる、ランダムな一意の低特権ワーカー プロセス ID として実行されます。詳細については、IIS の「アプリケーション プール ID」のドキュメントを参照してください。 アプリケーション コードでは、オペレーティング システム ドライブへの基本的な読み取り専用のアクセスにこの ID を使用します。 つまり、アプリケーション コードは、オペレーティング システム ドライブ上の共通ディレクトリ構造を参照し、共通ファイルを読み取ることができます。 少々広範なアクセス レベルに思えるかもしれませんが、Azure ホステッド サービスに worker ロールをプロビジョニングしてドライブ コンテンツを読み取る場合も、同じディレクトリとファイルにアクセスできます。

複数のインスタンス間でのファイル アクセス

コンテンツ共有 (%HOME%) ディレクトリにはアプリのコンテンツが含まれ、アプリケーション コードからの書き込みが可能です。 アプリが複数のインスタンスで実行される場合、%HOME% ディレクトリはすべてのインスタンスで共有されるため、すべてのインスタンスで同じディレクトリが参照されます。 そのため、たとえば、アップロードされたファイルがアプリによって %HOME% ディレクトリに保存されると、それらのファイルはすぐにすべてのインスタンスから利用できるようになります。

一時ローカル ストレージ (%SystemDrive%\local) ディレクトリはインスタンス間で共有されません。どちらもアプリとその Kudu アプリの間で共有されません。

ネットワーク アクセス

アプリケーション コードは、TCP/IP ベースと UDP ベースのプロトコルを使用してインターネットに接続し、外部サービスを公開しているエンドポイントにアクセスできます。 アプリでは、同じプロトコルを使用して Azure 内のサービスにも接続できます。たとえば、SQL Database への HTTPS 接続を確立できます。

アプリでローカル ループバック接続を確立し、そのローカル ループバック ソケットでリッスンするための機能も限定的に用意されています。 主な目的は、アプリ機能の一環として、ローカル ループバック ソケットでリッスンできるようにすることです。 各アプリに "プライベート" ループバック接続が表示されます。 アプリ "A" は、アプリ "B" によって確立されたローカル ループバック ソケットをリッスンできません。

1 つのアプリの実行に複数のプロセスがかかわっている場合、それらのプロセスが互いに通信する手段 (プロセス間通信: IPC) として、名前付きパイプもサポートされています。 たとえば、IIS FastCGI モジュールは、名前付きパイプを利用して PHP ページを実行する複数のプロセスを調整します。

コードの実行、プロセス、メモリ

既に説明したように、アプリは、ランダムなアプリケーション プール ID を使用して低特権のワーカー プロセス内で実行されます。 アプリケーション コードは、ネットワーク プロセス、および CGI プロセスや他のアプリケーションが生成する子プロセスに関連付けられたメモリ空間にアクセスできます。 ただし、あるアプリから別のアプリのメモリやデータには、たとえそれが同じ仮想マシン上に配置されていたとしても、アクセスすることはできません。

アプリは、サポート対象の Web 開発フレームワークで記述されたスクリプトやページを実行できます。 App Service では、Web フレームワークの設定がより限定的なモードに構成されることはありません。 たとえば、App Service 上で動作する ASP.NET アプリは、限定的な信頼モードではなく "完全信頼" で実行されます。 Web フレームワークでは、クラシック ASP と ASP.NET も含めて、Windows オペレーティング システムに既定で登録されている ADO (ActiveX Data オブジェクト) などのインプロセス COM コンポーネントを呼び出すことができます (アウトプロセス COM コンポーネントは対象外)。

アプリは任意のコードを生成して実行できます。 アプリは、コマンド シェルの生成や PowerShell スクリプトの実行などは許容されます。 ただし、アプリで任意のコードとプロセスを生成できる場合でも、実行可能なプログラムやスクリプトは、親アプリケーション プールに与えられる特権に制限されます。 たとえば、アプリは外部への HTTP 呼び出しを行う実行可能ファイルを生成できますが、その実行可能ファイルは、仮想マシンの IP アドレスを NIC から解除することはできません。 外部へのネットワーク呼び出しは低権限のコードでも実行できますが、仮想マシンのネットワーク設定を再構成するには管理者権限が必要です。

診断ログとイベント

一部のアプリは、ログ情報というデータ セットにアクセスします。 App Service で実行されるコードが使用できるログ情報には、診断ログがあります。これは、アプリによって生成され、アプリから簡単にアクセスすることもできるログ情報です。

たとえば、アクティブなアプリによって生成される W3C HTTP ログは、そのアプリ用に作成されたネットワーク共有場所にあるログ ディレクトリか、顧客がストレージへの W3C ログを設定している場合は Blob Storage に格納されます。 Blob Storage を使用すると、ネットワーク共有のファイル ストレージ制限を気にすることなく大量のログを収集できます。

同様に、.NET のトレース/診断インフラストラクチャを使用すれば、.NET アプリの診断情報をリアルタイムに記録できます。その際、トレース情報をアプリのネットワーク共有に書き込むか、Blob Storage に書き込むかを選択できます。

アプリが使用できない診断情報ログとトレースの領域は、Windows ETW イベントと一般的な Windows イベント ログ (システム ログ、アプリケーション ログ、セキュリティ イベント ログなど) です。 (適切な ACL があれば) マシン上で ETW トレース情報を参照できるので、ETW イベントへの読み取りアクセスと書き込みアクセスがブロックされます。 アプリの開発時には、ETW イベントや一般的な Windows イベント ログを読み書きする API 呼び出しが機能するように見えるかもしれませんが、これは、App Service がそのように見せかけているにすぎません。 実際には、アプリケーション コードはこれらのイベント データにアクセスできません。

レジストリ アクセス

アプリは、それが実行されている仮想マシンの多くのレジストリ (すべてではありません) に読み取り専用でアクセスできます。 つまり、実際には、アプリは、ローカルの Users グループへの読み取り専用アクセスを許可するレジストリ キーにアクセスできることになります。 現在、読み取りアクセスまたは書き込みアクセスがサポートされていないレジストリ領域の 1 つに、HKEY_CURRENT_USER ハイブがあります。

レジストリへの書き込みアクセスはブロックされます。ユーザーごとのレジストリ キーにも一切アクセスできません。 Azure 環境の場合、アプリが他の仮想マシンへ移行される可能性があるので、レジストリへの書き込みアクセスを前提にしてコードを開発しないでください。 アプリで利用できる唯一の書き込み可能な永続ストレージは、App Service の UNC 共有に格納されるアプリ別のコンテンツ ディレクトリ構造です。

リモート デスクトップ アクセス

App Service では、VM インスタンスへのリモート デスクトップ アクセスは提供されません。

詳細情報

Azure App Service サンドボックス - App Service の実行環境に関する最新の情報。 このページは、App Service の開発チームによって直接管理されます。