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

この記事では、 Azure App Service で実行されているすべての Windows アプリで使用できるベースライン オペレーティング システムの機能について説明します。 この機能には、診断ログとイベントと共に、ファイル、ネットワーク、レジストリへのアクセスが含まれます。

App Service プランレベル

App Service は、マルチテナント ホスティング環境で顧客アプリを実行します。

• Free レベルと共有レベルにデプロイされたアプリは、共有仮想マシン (VM) 上のワーカー プロセスで実行されます。
• Standard レベルと Premium レベルでデプロイされたアプリは、1 人の顧客に関連付けられているアプリ専用の VM 上で実行されます。

App Service では階層間のシームレスなスケーリング エクスペリエンスがサポートされているため、App Service アプリに適用されるセキュリティ構成は変わりません。 この構成により、App Service プランが 1 つのレベルから別のレベルに切り替わるときに、アプリが突然異なる動作をし、予期しない方法で失敗することがなくなります。

開発フレームワーク

App Service の価格レベルでは、アプリで使用できるコンピューティング リソース (CPU、ディスク ストレージ、メモリ、ネットワーク エグレス) の量が制御されます。 ただし、アプリで使用できるフレームワーク機能の幅は、スケーリングレベルに関係なく変わりません。

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

次のセクションでは、App Service アプリで使用できる一般的な種類のオペレーティング システム機能の概要を示します。

ファイル アクセス

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

ローカル ドライブ

その中核となる App Service は、サービスとしての Azure プラットフォーム (PaaS) インフラストラクチャ上で実行されるサービスです。 その結果、VM に関連付けられているローカル ドライブは、Azure で実行されている任意の worker ロールで使用できるドライブの種類と同じです。 これには次のようなものがあります。

• VM のサイズによってサイズが異なるオペレーティング システム ドライブ (%SystemDrive%)。
• App Service が内部的に使用するリソース ドライブ (%ResourceDrive%)。

ベスト プラクティスは、ハードコーディングされたファイル パスではなく、常に環境変数 %SystemDrive% と %ResourceDrive% を使用することです。 これら 2 つの環境変数から返されるルート パスは、時間の経過と同時に d:\ から c:\にシフトしています。 ただし、d:\へのファイル パス参照でハードコードされた古いアプリケーションは、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 共有上の予約済みディレクトリ構造があります。 顧客が特定のデータセンターに複数のアプリを作成している可能性があるため、1 つの顧客サブスクリプションに属するすべてのディレクトリが同じ UNC 共有に作成されます。

Azure サービスの動作方法により、UNC 共有をホストする特定の VM は時間の経過と同時に変化します。 UNC 共有は、Azure 操作の通常の過程で起動または停止されると、異なる VM によってマウントされます。 このため、アプリでは、UNC ファイル パス内のマシン情報が時間の経過と同時に安定するというハードコーディングされた前提を決して行わないようにする必要があります。 代わりに、App Service が提供する便利な偽の絶対パスを使用する必要があります。

偽の絶対パスは、独自のアプリを参照するための移植可能な方法です。 これは、どのアプリまたはユーザーにも固有ではありません。 %HOME%\siteを使用すると、転送ごとに新しい絶対パスを構成しなくても、共有ファイルをアプリからアプリに転送できます。

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

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

システム ドライブでは、App Service はアプリ固有の一時ローカル ストレージ用に %SystemDrive%\local を予約します。 このディレクトリ内のファイルに対する変更は、アプリの再起動の間は永続的 ではありません 。 アプリには、独自の一時ローカル ストレージへの完全な読み取りおよび書き込みアクセス権がありますが、そのストレージはアプリケーション コードによる直接使用を目的としていません。 むしろ、IIS と Web アプリケーション フレームワークに一時ファイル ストレージを提供することが目的です。

App Service では、個々のアプリが過剰な量のローカル ファイル ストレージを消費しないように、アプリごとに %SystemDrive%\local のストレージの量が制限されます。 Free、Shared、Consumption (Azure Functions) レベルの場合、制限は 500 MB です。 次の表に、その他のレベルを示します。

一時 ASP.NET ファイルのディレクトリと IIS 圧縮ファイルのディレクトリは、App Service で一時ローカル ストレージを使用する方法の 2 つの例です。 ASP.NET コンパイル システムは、 %SystemDrive%\local\Temporary ASP.NET Files ディレクトリを一時的なコンパイル キャッシュの場所として使用します。 IIS は、 %SystemDrive%\local\IIS Temporary Compressed Files ディレクトリを使用して、圧縮された応答出力を格納します。 これらの種類のファイルの使用はどちらも (他のファイルと共に) App Service でアプリごとの一時ローカル ストレージに再マップされます。 この再マッピングは、機能が期待どおりに続行されるようにするのに役立ちます。

App Service の各アプリは、 アプリケーション プール ID と呼ばれるランダムで一意の低い特権のワーカー プロセス ID として実行されます。 アプリケーション コードは、オペレーティング システム ドライブへの基本的な読み取り専用アクセスにこの ID を使用します。 このアクセスは、アプリケーション コードが共通のディレクトリ構造を一覧表示し、オペレーティング システム ドライブ上の共通ファイルを読み取ることができることを意味します。 このレベルのアクセスは広いように見えるかもしれませんが、Azure でホストされるサービスで worker ロールをプロビジョニングし、ドライブの内容を読み取ると、同じディレクトリとファイルにアクセスできます。

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

コンテンツ共有 (%HOME%) ディレクトリにはアプリのコンテンツが含まれており、アプリケーション コードはそれに書き込むことができます。 アプリが複数のインスタンスで実行されている場合、 %HOME% ディレクトリはすべてのインスタンス間で共有され、すべてのインスタンスに同じディレクトリが表示されます。 たとえば、アプリがアップロードしたファイルを %HOME% ディレクトリに保存した場合、それらのファイルはすべてのインスタンスですぐに使用できます。

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

ネットワーク アクセス

アプリケーション コードでは、TCP/IP および UDP ベースのプロトコルを使用して、外部サービスを公開するインターネットアクセス可能なエンドポイントへの送信ネットワーク接続を行うことができます。 アプリでは、Azure SQL Database への HTTPS 接続を確立するなどして、これらの同じプロトコルを使用して Azure 内のサービスに接続できます。

また、アプリが 1 つのローカル ループバック接続を確立し、そのローカル ループバック ソケットでアプリをリッスンさせる機能も制限されています。 この機能により、機能の一部としてローカル ループバック ソケットをリッスンするアプリが有効になります。 各アプリにはプライベート ループバック接続があります。 あるアプリは、別のアプリが確立したローカル ループバック ソケットをリッスンできません。

名前付きパイプは、アプリをまとめて実行するプロセス間のプロセス間通信のメカニズムとしてもサポートされています。 たとえば、IIS FastCGI モジュールは、名前付きパイプを使用して、PHP ページを実行する個々のプロセスを調整します。

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

前に説明したように、アプリはランダムなアプリケーション プール ID を使用して、低い特権のワーカー プロセス内で実行されます。 アプリケーション コードは、ワーカー プロセスに関連付けられているメモリ領域と、CGI プロセスまたはその他のアプリケーションが生成する可能性のある子プロセスにアクセスできます。 ただし、同じ VM 上にある場合でも、あるアプリは別のアプリのメモリまたはデータにアクセスできません。

アプリは、サポートされている Web 開発フレームワークで記述されたスクリプトまたはページを実行できます。 App Service では、より制限されたモードに Web フレームワークの設定は構成されません。 たとえば、App Service で実行 ASP.NET アプリは、より制限された信頼モードではなく、完全信頼で実行されます。 従来の ASP と ASP.NET の両方を含む Web フレームワークは、Windows オペレーティング システムに既定で登録されているインプロセス COM コンポーネント (ActiveX データ オブジェクトなど) を呼び出すことができます。 Web フレームワークでは、アウトプロセス COM コンポーネントを呼び出すことはできません。

アプリは、任意のコードを生成して実行したり、コマンド シェルを開いたり、PowerShell スクリプトを実行したりできます。 ただし、実行可能プログラムとスクリプトは、引き続き親アプリケーション プールに付与される特権に制限されます。 たとえば、アプリは、送信 HTTP 呼び出しを行う実行可能プログラムを生成できますが、その実行可能プログラムは、そのネットワーク アダプターから VM の IP アドレスのバインドを解除しようとすることはできません。 低い特権のコードに対して送信ネットワーク呼び出しを行うことができますが、VM でネットワーク設定を再構成するには管理者特権が必要です。

診断ログとイベント

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

たとえば、アプリによって生成された W3C HTTP ログは、次のいずれかを使用できます。

• アプリ用に作成したネットワーク共有の場所にあるログディレクトリ内で。
• ストレージへの W3C ログ記録を設定した場合は、BLOB ストレージで。

後者のオプションを使用すると、アプリはネットワーク共有に関連付けられているファイル ストレージの制限を超えることなく、大量のログを収集できます。

同様に、.NET アプリからのリアルタイム診断情報は、.NET トレースと診断インフラストラクチャを介してログに記録できます。 その後、トレース情報をアプリのネットワーク共有または BLOB ストレージの場所に書き込むことができます。

アプリで使用できない診断ログとトレースの領域は、Windows Event Tracing for Windows (ETW) イベントと一般的な Windows イベント ログ (システム、アプリケーション、セキュリティ イベント ログなど) です。 ETW トレース情報は、適切なアクセス制御リストを使用してマシン全体で表示できる可能性があるため、ETW イベントへの読み取りアクセスと書き込みアクセスはブロックされます。 ETW イベントと一般的な Windows イベント ログの読み取りと書き込みの API 呼び出しは機能しているように見えるかもしれませんが、実際には、アプリケーション コードはこのイベント データにアクセスできなくなります。

レジストリ アクセス

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

ユーザーごとのレジストリ キーへのアクセスを含め、レジストリへの書き込みアクセスがブロックされます。 アプリの観点からは、アプリは VM 間で移行できるため、Azure 環境内のレジストリへの書き込みアクセスに依存することはできません。 アプリが依存できる永続的な書き込み可能ストレージは、App Service UNC 共有に格納されているアプリごとのコンテンツ ディレクトリ構造だけです。

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

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

関連コンテンツ

App Service の実行環境に関する最新情報については、「Azure App Service サンドボックス」を参照してください。 App Service 開発チームは、このページを保持します。