Azure アプリ サービスのオペレーティング システム機能

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

App Service プランの階層

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

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

開発フレームワーク

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

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

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

ファイル アクセス

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

ローカル ドライブ

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

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

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

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

• ディスクに十分な領域がないことを示すエラーがアプリによってスローされる場合があります。
• 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 共有をホストする特定の仮想マシンは時間の経過と同時に変化します。 UNC 共有は、Azure 操作の通常の過程で起動または停止されると、異なる仮想マシンによってマウントされます。 したがって、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 です。 次の表に、その他のレベルを示します。

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

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

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

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

ネットワーク アクセス

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

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

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

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

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

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

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

診断ログとイベント

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

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

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

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

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

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

レジストリ アクセス

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

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

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

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

詳細情報

App Service の実行環境に関する最新情報については、Azure アプリ Service サンドボックスを参照してください。 App Service 開発チームメインこのページが含まれています。