Azure App Service のローカル キャッシュ

Azure App Service コンテンツは Azure Storage に格納され、永続的なコンテンツ共有として公開されます。 この設計はさまざまなアプリで動作し、次の属性があります。

• コンテンツは、アプリの複数の仮想マシン (VM) インスタンス間で共有されます。
• コンテンツは永続的であり、実行中のアプリで変更できます。
• ログ ファイルと診断データ ファイルは、同じ共有コンテンツ フォルダーの下にあります。
• 新しいコンテンツを発行すると、コンテンツ フォルダーが直接更新されます。 ソース管理マネージャー (SCM、Kudu とも呼ばれます) Web サイトと実行中のアプリを使用して、同じコンテンツをすぐに表示できます。 ただし、一部のテクノロジ (ASP.NET など) では、最新のコンテンツを読み込む特定のファイル変更でアプリの再起動が開始される場合があります。

多くのアプリではこれらの機能を 1 つ以上使用していますが、一部のアプリでは、高可用性で実行できる高パフォーマンスの読み取り専用コンテンツ ストアが必要です。 このようなアプリは、VM インスタンス上のローカル キャッシュに対して実行することでメリットを得ることができます。

Azure App Service のローカル キャッシュ機能は、コンテンツの Web ロール ビューを提供します。 このコンテンツは、サイトの起動時に非同期的に作成されるストレージ コンテンツの書き込み/破棄キャッシュです。 キャッシュの準備ができたら、サイトはキャッシュされたコンテンツに対して実行するように切り替えます。

ローカル キャッシュで実行されているアプリには、次のような利点があります。

• Azure Storage のコンテンツへのアクセスに関連する待機時間には影響しません。
• 読み取り専用コピーはローカルにキャッシュされるため、ストレージへの接続に関する問題は影響しません。
• ストレージ共有の変更によるアプリの再起動が少なくなります。

ローカル キャッシュが App Service の動作を変更する方法

ローカル キャッシュを構成すると、次の変更が行われます。

• D:\home は、アプリの起動時に VM インスタンスに作成されるローカル キャッシュを指すようになりました。 D:\local は、VM 固有の一時的なストレージを指し続けます。

• ローカル キャッシュには、共有コンテンツ ストアの /site フォルダーと /siteextensions フォルダーの 1 回限りのコピーが含まれています。 これらのフォルダーはそれぞれ、 D:\home\site と D:\home\siteextensionsにあります。 これらのファイルは、アプリの起動時にローカル キャッシュにコピーされます。

  これら 2 つのフォルダーのサイズは、既定では 1 GB に制限されていますが、2 GB に増やすことができます。 キャッシュ サイズが大きくなると、キャッシュの読み込みに時間がかかります。 ローカル キャッシュの上限を 2 GB に増やし、コピーしたファイルがこの最大サイズを超えた場合、App Service はローカル キャッシュを無視し、リモート ファイル共有から読み取ります。

  重要

  コピーしたファイルがローカル キャッシュに対して定義されているサイズ制限を超えた場合、または制限が定義されていない場合、デプロイとスワップの操作がエラーで失敗する可能性があります。 詳細については、この記事で後述する サイズ制限に関する FAQ を参照してください。

• ローカル キャッシュは読み取り/書き込みです。 ただし、アプリが VM 間を移動したり再起動したりすると、変更は破棄されます。 ミッション クリティカルなデータを格納するためにローカル キャッシュを使用しないでください。

• D:\home\LogFiles と D:\home\Data はログファイルとアプリデータを含んでいます。 これらのフォルダーは、VM インスタンスにローカルに格納され、共有コンテンツ ストアに定期的にコピーされます。 アプリはこれらのフォルダーに書き込むことでログ ファイルとデータを保持できますが、コピー プロセスはベスト エフォートです。 VM インスタンスが突然応答を停止すると、ログ ファイルとデータが失われる可能性があります。

• ベスト エフォート コピーは ログ ストリーミングに影響します。 ストリーミング されたログでは、最大 1 分の遅延が観察される場合があります。

• 共有コンテンツ ストアでは、ローカル キャッシュを使用するアプリの LogFiles と Data のフォルダー構造が変更されます。 一意の識別子とタイムスタンプで構成される名前のサブフォルダーがあります。 各サブフォルダーは、アプリが実行されている VM インスタンスまたは実行中の VM インスタンスに対応します。

• D:\home内の他のフォルダーはローカル キャッシュに残り、共有コンテンツ ストアにはコピーされません。

• サポートされている方法を使用してアプリケーションをデプロイメントすると、耐久性のある共有コンテンツ ストアに直接発行されます。 ローカル キャッシュ内の D:\home\site フォルダーと D:\home\siteextensions フォルダーを更新するには、アプリを再起動する必要があります。 シームレスなライフ サイクルについては、この記事の後半の ベスト プラクティスに関するセクション を参照してください。

• SCM サイトの既定のコンテンツ ビューには、引き続き共有コンテンツ ストアが反映されます。

ローカル キャッシュを有効にする方法

ローカル キャッシュは、予約済みアプリ設定の組み合わせを使用して構成します。 これらのアプリ設定は、次のいずれかの方法を使用して設定できます。

Azure portal を使用してローカル キャッシュを構成する

このアプリ設定 ( WEBSITE_LOCAL_CACHE_OPTION = Always) を追加して、Web アプリごとにローカル キャッシュを有効にします。

Azure Resource Manager を使用してローカル キャッシュを構成する

{
    "apiVersion": "2015-08-01",
    "type": "config",
    "name": "appsettings",
    "dependsOn": [
        "[resourceId('Microsoft.Web/sites/', variables('siteName'))]"
    ],

    "properties": {
        "WEBSITE_LOCAL_CACHE_OPTION": "Always",
        "WEBSITE_LOCAL_CACHE_SIZEINMB": "1000"
    }
}

ローカル キャッシュのサイズ設定を変更する

既定では、ローカル キャッシュ サイズは 1 GB です。 このサイズには、コンテンツ ストアからコピーされた /site フォルダーと /siteextensions フォルダーが含まれます。 また、ローカルで生成されたログとデータ フォルダーも含まれます。

この制限を引き上げるには、アプリ設定の WEBSITE_LOCAL_CACHE_SIZEINMBを使用します。 アプリごとに最大 2 GB (2,000 MB) のサイズを増やすことができます。 キャッシュ サイズを大きくすると、キャッシュを読み込む時間が長くなる点に注意してください。

ローカル キャッシュを使用するためのベスト プラクティス

ステージング環境機能と組み合わせてローカル キャッシュを使用することをお勧めします。

次のプロセスは、ローカル キャッシュを使用するためのベスト プラクティスを表しています。

1. 値が WEBSITE_LOCAL_CACHE_OPTION の固定のアプリケーション設定 Always を 運用 スロットに追加します。 WEBSITE_LOCAL_CACHE_SIZEINMB を使用している場合は、さらにその設定を運用スロットの固定設定としてマークします。

2. ステージング スロットを作成し、そこに公開します。 通常は、ローカル キャッシュを使用するようにステージング スロットを設定しません。これにより、運用スロットにローカル キャッシュの利点を提供しながら、シームレスなビルド/デプロイ/テスト ライフ サイクルを実現できます。

3. ステージング スロットでサイトをテストします。

4. 準備ができたら、ステージング スロットと運用スロットの間で スワップ操作 を実行します。

固定設定はスロットに関連付けられます。 ステージング スロットが運用環境にスワップされると、ローカル キャッシュのアプリ設定が継承されます。 新しくスワップされた運用スロットは、数分後にローカル キャッシュに対して実行され、スロット ウォームアップ中にウォームアップされます。 スワップが完了すると、本番スロットはローカル キャッシュに対して動作します。

よく寄せられる質問

ローカル キャッシュのサイズ制限を超えた場合はどうなりますか?

コピーしたファイルがローカル キャッシュのサイズ制限を超えると、アプリはリモート共有からの読み取りに戻ります。 次の表に詳細を示します。

アプリがローカル キャッシュのメリットを得られるかどうかを確認するにはどうすればよいですか?

ローカル キャッシュは、次のすべての条件が適用される場合に適しています。

• アプリには、高パフォーマンスで信頼性の高いコンテンツ ストアが必要です。
• アプリでは、実行時に重要なデータを書き込むためのコンテンツ ストアは使用されません。
• 合計サイズは 2 GB 未満です。

/siteフォルダーと/siteextensions フォルダーの合計サイズを確認するには、サイト拡張機能の Azure Web Apps Disk Usage を使用します。

サイトがローカル キャッシュの使用に切り替えたかどうかを確認するにはどうすればよいですか?

ステージング環境でローカル キャッシュを使用している場合、ローカル キャッシュがウォームアップされるまでスワップ操作は完了しません。 サイトがローカル キャッシュに対して実行されていることを確認するには、ワーカー プロセス環境変数 WEBSITE_LOCALCACHE_READY確認します。 複数のインスタンスでこの変数を検査するには、 ワーカー プロセス環境変数の Kudu 命令を参照してください。

アプリに新しく発行された変更が反映されないのはなぜですか?

アプリでローカル キャッシュを使用する場合は、サイトを再起動して最新の変更を読み込む必要があります。 変更を運用環境サイトに直接発行しない場合は、 ベスト プラクティスに関する前のセクションで説明したように、デプロイ スロットの使用を検討してください。

ログはどこにありますか?

ローカル キャッシュを使用している場合、ログ フォルダーとデータ フォルダーの構造が若干変わります。 サブフォルダーは、一意の VM 識別子とタイム スタンプで名前が付けられたフォルダーの下に入れ子になりました。 これらの各フォルダーは、アプリが実行されている VM インスタンスまたは実行中の VM インスタンスに対応します。

ローカル キャッシュを有効にしてアプリを再起動する理由

ローカル キャッシュは、ストレージ関連のアプリの再起動を防ぐのに役立ちます。 ただし、VM 上の計画されたインフラストラクチャのアップグレード中も、アプリが再起動する可能性があります。 全体として、ローカル キャッシュが有効になっている再起動の数は少なくなります。

ローカル キャッシュは、より高速なローカル ドライブにコピーされるディレクトリを除外しますか?

コピー プロセス中に、 repository という名前のフォルダーはすべて除外されます。 この動作は、サイト コンテンツに、日常的な操作に必要のないソース管理リポジトリが含まれているシナリオで役立ちます。

サイト管理操作後にローカル キャッシュ ログをフラッシュするにはどうすればよいですか?

ローカル キャッシュ ログをフラッシュするには、アプリを停止して再起動します。 このアクションにより、前のキャッシュがクリアされます。

ローカル キャッシュが有効になっている場合、再起動後に以前にデプロイされたファイルが App Service に表示されるのはなぜですか?

以前に展開したファイルが再起動後に再び表示される場合は、アプリ設定 WEBSITE_DISABLE_SCM_SEPARATION=trueが存在するかどうかを確認します。 この設定を追加すると、Kudu 経由のデプロイは永続的ストレージではなくローカル VM に書き込まれます。 このような状況を回避するには、 前述のベスト プラクティス に従い、ローカル キャッシュが有効になっていないステージング スロットへのデプロイを実行します。

関連コンテンツ

• Azure App Service の環境変数とアプリ設定