※本記事に紹介されている提案は、Sitecore公式のSLAでのサポート対象外となりますので、ご了承ください。
Managed Cloudの公式サポート範囲は、サービス カタログ（Sitecore Managed Cloud Standard -オンデマンド リクエストのサービス一覧）および監視の処理（Sitecore Managed Cloud Standard - モニタリング メトリクス）で定義されています。本記事では、Sitecoreの公式サポートとは別に、Microsoft Azureの機能を特定のSitecoreのシナリオに合うように調節する方法についてのご提案を説明します。
Sitecore Managed Cloud Standardは、Microsoft Azureのプラットフォーム上に構築されています。つまり、Azure App Servicesが、ほとんどのソリューションの基本的な構成要素となっています。Microsoftは、App Servicesの基盤となるAzureプラットフォームに対して、プラットフォーム インフラ全体の信頼性、パフォーマンス、およびセキュリティを向上させるために、定期的なアップデートを実施しています。
しかし、Microsoftはこれらのアップデートについて、事前の通知や作業時間帯のスケジュールなどを提供していません（これは、Azure App ServicesとPaaS（Platform as a Service）モデルにおける管理プロセスの一部です）。
これらのアップデートのほとんどは、Webアプリケーションに影響を与えないように実施されますが、一方でこれらのアップデートによって、Azure App Serviceが時折再起動される場合があります。この場合、SitecoreはApp Serviceの再初期化を完了させる必要があるため、一時的にアプリケーションが利用不可能となる可能性があります。なお、Azure App Servicesの基盤となるプラットフォームのSLAは99.95%であり、一般的には、この記事で説明するプラットフォームのアップデートがSLAに違反することはありません。
※App Service上で実行されるSitecoreアプリケーションは、Sitecoreアプリケーションの起動ルーチンのため、可用性がわずかに長く中断される可能性があります。
以下の節では、弊社が携わってきた多くのManaged Cloud Standardプロジェクトの中から、Azureプラットフォームのアップデートに伴う可用性の懸念への対処に成功した経験に基づく、プロジェクトのベストプラクティスについてご紹介します。
より早く再起動を実施する
再起動をより早く完了させる方法として、以下の3つの具体的な解決策があります。
アプリケーションの初期化
アプリケーションの初期化はAzure App Servicesで利用可能なIISの機能であり、Sitecore固有の機能ではありません。Managed Cloudの実装の中には、この機能を使用して、初回の使用前にAzure上のApp Serviceをウォームアップするものがあります。この機能を用いると、新しいインスタンスがトラフィックを受信する前に適切にウォームアップされるので、自動スケールアウトの際に有用です。web.configにAppInitializationのセクションを追加し、ウォームアップのページおよび関連するプロパティを指定することができます。
<system.webServer>
<applicationInitialization doAppInitAfterRestart="true">
<add initializationPage="/default.aspx" hostName="myhost"/>
</applicationInitialization>
</system.webServer>
この機能に関する詳細情報につきましては、「アプリケーションの初期化」または「アプリケーションの初期化で特定のページをウォームアップする」（英語） をご参照ください。また「Sitecore App Service Warm-Up Demystified（Sitecore App Serviceウォームアップの解明）」（英語）には、Sitecoreに特化した提案内容が記載されています。
Azure App Serviceの「ローカル キャッシュ」
ローカル キャッシュの機能（Azure App Serviceのローカル キャッシュの概要）は、Microsoft AzureのApp Serviceが提供するものであり、Sitecoreの機能ではありません。しかし、Sitecore Managed Cloudの実装の中には、Sitecoreの再起動速度を向上させるために、ローカル キャッシュを使用しているものがあります。Microsoft AzureプラットフォームがAzure App Serviceの一時的な中断を引き起こすアップデートを実施する際、ローカル キャッシュは関連するダウンタイム期間を短縮することができます。この機能は、サービスの再起動後に中央の場所から実装のファイルをApp Serviceを動かしているホストからコピーする代わりに、ローカル キャッシュのファイルを直ちに利用できるようにすることで、実装のファイルをローカルのAzure App Serviceホストで利用できるようにします（コピーには時間がかかる場合があるためです）。
ローカル キャッシュの容量はデフォルトで300MBに制限されていますが、最大2GBまで増加させることができます（Azure App Serviceのローカル キャッシュの概要をご参照ください）。コピーされたファイルがローカル キャッシュの容量を超えた場合、App Serviceはローカル キャッシュを警告なしで無視し、リモート ファイル共有からの読み込みを実施します。従って、Sitecore実装のディスクのファイル数および容量を減らすことが、解決策の1つとなります。
ソリューションに大量のファイルがあり、（ローカル キャッシュの容量を）最大2GBまで増加させたくない場合は、以下の標準的な手順の実施をご検討いただくことをお薦めします。
Dynamic Cache
Dynamic Cacheはローカル キャッシュと似ていますが、App Serviceホストでサイト全体をキャッシュすることなく、要求されたファイルのみキャッシュするようにします。これは、Azure App Service製品が提供する機能であり、Sitecoreが提供する機能ではありません。まずファイルがキャッシュされるのは、App Serviceのアプリケーション ファイルを複数インスタンスにスケールすることができる単一の場所に格納しつつ、それら全てが同じコンテンツを指すようにするためです。
これは、d:\homeディレクトリをファイル サーバーへのシンボリック リンクとして設定し、実際にインスタンスに存在するd:\localを、キャッシュを格納する場所に設定することで実現されます。一部のAzure App Serviceでは、リモート ファイル共有からコンテンツを要求する際、遅延がみられることがありますが、ほとんどの場合は遅延は発生しません。
この機能を無効にするには、「Azure Web Appsを使用している場合にSitecore XPが不安定になる」に記載されている解決策1に従って、WEBSITE_DYNAMIC_CACHEを「0」に設定することをお薦めします。