解説

Sitecore Managed Cloud Standardは、Microsoft Azureのプラットフォーム上における技術とサービスの組み合わせにより成り立っています。Managed Cloud Standardはさまざまな最適化が可能な本質的にオープンな製品であり、お客様ごとの実装パターンに合わせて開始時のトポロジー（Sitecore Managed Cloud Standardのトポロジーおよび価格レベル）を適用させることができます。
本記事では、弊社が多くのManaged Cloud Standard関連のプロジェクトに携わった経験の中から、それらのプロジェクトを成功に導いたベスト プラクティスをいくつかご紹介します。
ただし、これらのご提案は正式なSLAを通じてSitecoreからサポートされているものではない点にご注意ください。Managed Cloudの公式サポートの範囲は、Sitecore Managed Cloud Standard - オンデマンド リクエストのサービス一覧およびSitecore Managed Cloud Standard - モニタリング メトリクスで定義されています。
本記事でご説明する内容は（Sitecoreの公式サポートとは別に、）Microsoft Azureの機能を特定のSitecoreのシナリオに合うよう調整する場合の対応方法のご提案事項となります。

ご提案内容は、具体的には以下の6つの要素に関係しています。

1. SQLデータベース
   
   • Azure SQLデータベースの定期的な正常性ルーチン
   • バックアップ（Azure SQLデータベース バックアップ計画依頼フォームをご参照ください）
2. App Service
   
   • Azureの「ローカル キャッシュ」機能の有効化
   • Asp.Netの「アプリケーションの初期化（Application Initialization）」機能の有効化
   • Azureのプロアクティブ自動復旧（Auto-Heal）の無効化
   • ASP.Netの「fcnMode」の無効化
   • 動的キャッシュの無効化
   • Sitecoreアプリケーションのセキュリティ強化（セキュリティ ガイドをご参照ください）
   • Sitecoreアプリケーションのキャッシュ チューニング（推奨される初期キャッシュ値をご参照ください）
   • バックアップ（Azure App Service バックアップ計画依頼フォームをご参照ください）
3. App Service プラン
   
   • デフォルトのトポロジーは開始点である
   • Microsoftは予告なしにアップデートを実施する可能性がある
   • S3Azure App Service プランの検討：P2V3対S3
   • Basic App Service プランの利用は推奨しません
4. Application Insight
   
   • ロギングのメカニズムとしてのApplication Insight
   • Application Insightにおけるデータ ストレージの「日次制限」
5. Azureのネットワーク
   
   • CMのIP制限を考慮し、PingチェックのためにApplication InsightsのIPレンジに注意する
   • Webアプリケーション ファイアウォール（WAF）を本番前に設定する                
6. リソース グループ
   
   • Azureのリソースを「タグ」で識別できる

ご提案

• • Azure SQLデータベースの定期的な正常性ルーチン
    IaaSにおける従来のMicrosoft SQLサーバーでは、データベースの定期的なアップデートおよびデータベースの最適化を完了させるために、定期的なメンテナンス プランが不可欠です。これに関する詳細情報については、メンテナンス プランをご参照ください。Azure SQLでは、メンテナンス プランのような機能がありませんので、特別な手順を実施して、Azure SQLで定期的なインデックスの断片化の解消と、内部的な再編成を実施していただく必要があります。Sitecore Managed Cloudチームは、Azure Automationをベースとしたこのための標準的なソリューションを提供しています。これは「Set up SQL Maintenance Plan」と呼ばれるServiceNowのサービス リクエストとして、サービス カタログからご利用いただけます。

• • Azureの「ローカル キャッシュ」機能の有効化
    ローカル キャッシュ機能は、Microsoft Azure App Serviceの機能であり、Sitecoreの機能ではありません。しかし、Sitecore Managed Cloudの実装の中には、Sitecoreの再起動速度を向上させるために、ローカル キャッシュを使用しているものがあります。
    Microsoft Azureプラットフォームがアップデートを実行する際に、Azure App Serviceが一時的に停止してしまう場合、ローカル キャッシュは関連するダウンタイム時間を短縮することができます。この機能は、実装用のファイルをローカルのAzure App Serviceホストで利用できるようにします。そのため、サービス再起動後に実装のファイルをメインとなる場所からApp Serviceを運用するホストに時間をかけてコピーしなくとも、ローカル キャッシュのファイルをすぐに利用できるようになります。ローカル キャッシュの容量はデフォルトで300MBに制限されていますが、最大2GBまで増やすことができます（ローカル キャッシュ機能をご参照ください）。
    ただし、コピーされたファイルがローカル キャッシュの容量を超える場合、App Serviceはローカル キャッシュを警告なく無視し、リモート ファイル共有から読み取ることにご注意ください。したがって、このご提案事項の一環として、Sitecore実装のディスク上のファイル量およびサイズを減少させる必要がある可能性があります。もしソリューションに大量のファイルがあり、2GBの上限に達している場合、以下の標準的な手順の実施を検討していただくことをお薦めいたします。
    
    1. プロジェクトでコンテンツ テストによるスクリーンショットとスクリプトの書き込み機能を使用していない場合、無効化します。これを無効にするには、ContentTesting.GenerateScreenshotsの設定の値をnoneに変更します。
    2. ContentTesting.PhantomJS.RemoveAbandonedJS設定を有効にして、古いスクリプト ファイルが即時に削除されるようにすることも可能です。
    3. 「Azure App Serviceでのアプリの診断ログの有効化」に記載されている通り、ファイル システムへのアプリケーション ロギングを無効化します。
    4. tempフォルダおよびApp_Dataフォルダに保存されているファイルの有効期限の時間を短縮します。これを実施するには、設定の<agent type="Sitecore.Tasks.CleanupAgent" method="Run" interval="06:00:00">ノード下一式フォルダの maxAge 値を変更します。
    5. Azureのフォールバック アペンダーを無効にします。 これを最も簡単な方法で実施するには、\App_Config\Sitecore\ExperienceContentManagement.Administration
       \Sitecore.ExperienceContentManagement.Administration.configファイルを開き、「logDisabled4net」ノードを削除します。

• • Asp.Net「アプリケーションの初期化(Application Initialization)」機能を有効化する
    

    「Application Initialization」は、Azure App Servicesで利用可能なIIS機能であり、Sitecore特有の機能ではありません。いくつかのManaged Cloudの実装は初回使用前に、<applicationInitialization>機能を使用してAzureのApp Serviceをウォームアップする場合があります。この機能を使うと、新しいインスタンスがトラフィックを受信する前に適切にウォームアップされるため、自動スケールアウト時に有用な場合があります。この機能を有効化するには、ウォームアップのページおよび関連のプロパティに指定しているweb.configにAppInitializationセクションを追加します： 

    <system.webServer>
    <applicationInitialization doAppInitAfterRestart="true">
    <add initializationPage="/default.aspx" hostName="myhost"/>
    </applicationInitialization>
    </system.webServer>

    詳細情報については、アプリケーション初期化をご参照ください。また、以下のリンクに参考となるSitecore向けのご提案が掲載されていますのでご参照ください：
    Sitecore App Service Warm-Up Demystified

• • Azure自動復旧(Auto-Heal)の無効化
    

    Azure App Serviceには、自動復旧(Auto-Heal)という機能が搭載されています。これは、Azureのランタイムが、システムがビジーすぎる状態であったり、正常な状態でないと判断した場合に、システムをプロアクティブに再起動させるためのものです。ひとつのApp Serviceが90%以上のメモリ使用量で30秒間動作した場合、Azureランタイムが介入し、App Serviceを再起動させます。Azure App Serviceではこれが望ましい場合もありますが、Sitecoreの実装によっては、容量の限界（高メモリ使用量）に近い状態で動作している場合、Azureの自動復旧機能を無効にするとサイトの可用性が向上し、ワークロードが重くてもサイトを中断せずに動作させることができるようになる場合があります。
    
    自動復旧を無効にするには、以下を実施してください。

    1. Azure App Serviceの「Diagnose and Solve Problem（問題の診断と解決）」に移動します。
    2. 「Diagnostic Tools（診断ツール）」の自動復旧のオプションを選択します。
    3. プロアクティブ自動復旧のタブに「オフ」をクリックします。
     

 

• • ASP.Netの「fcnMode」を無効にする

    FcnMode機能が有効化された状態で、特定のファイル（.dllや.config）が変更されると、Web Appが再起動されます。 この機能を有効化することによって、予期されないApp Poolの再起動が発生する可能性があります。例えば、アプリケーションのロジックでファイルを高速に変更する場合や、サブディレクトリが多数存在するディレクトリ構造で、それぞれにFcnModeの監視が必要な場合などに、この現象が見受けられることがあります。その予防策として、 実装でFcnModeを無効にすることが可能です。チューニングに関する情報については、以下の記事をご参照ください：
    https://doc.sitecore.com/xp/en/developers/100/managed-cloud/recommendations--sitecore-tuning-in-azure.html（英語版）

    これを無効化すべきか判断できない場合は、新規のお問い合わせを作成してサポートにご連絡ください。サポートとのやり取りを通じて、現在直面している問題をよりよく理解し、この機能を無効にする必要性があるかをより詳しく把握することができます。

• • Dynamic Cacheを無効にする

    Dynamicキャッシュは、ローカル キャッシュと似たものです。しかし、これはサイト全体をApp Serviceのホストにキャッシュする代わりに、リクエストされたファイルのみをキャッシュします。これはSitecoreではなく、Azure App Service製品で提供されている機能です。そもそもファイルがキャッシュされるのは、App Serviceのアプリケーション ファイルが、複数のインスタンスにスケールできる機能がサポートされている単一の場所に保存され、すべてのインスタンスが同じコンテンツを指すようにするためです。これは、「d:\home」ディレクトリをファイル サーバーへのシンボリック リンクにすることで実現します。「d:\local」 は実際にインスタンス上にあり、キャッシュが保存される場所となります。一部のAzure App Serviceでは、リモート ファイル共有からサイトのコンテンツを要求したときに遅延（レイテンシー）が発生する場合がありますが、ほとんどの場合これは起こりません。
    
    「Azure Web Appsを使用している場合にSitecore XPが不安定になる」の記事の「解決策１」に従って、「WEBSITE_DYNAMIC_CACHE」を「0」に変更し、この機能を無効化していただくことをお薦めします。

• • Azure App Service プランの検討

    Managed Cloud環境をスケールしようとするお客様は、おそらくAzureの価格レベルを「S3」と「P2v2」のどちらにするか検討することになります。本記事の執筆時点では、Microsoft Azureでのこれら2つのレベルの価格は同じですが、P2v2が提供する2コアよりもS3が提供する4コアが必要な場合を除き、一般的にはP2v2レベルの方の性能が優れています。要件はアプリケーションによって異なるため、プロジェクトごとにテストして判断する必要がありますが、Managed Cloudのお客様は、S3よりもP2V2を選択するのが一般的です。なぜなら、Premium v2シリーズは、同じコストでより高度な仕様のコンポーネントをサポートしており、それがしばしばSitecoreパフォーマンスの向上につながるためです。

• • Azure Blobストレージのアプリケーション ログ記録の保存

    Sitecore Managed Cloudのインスタンスのパフォーマンスに影響を与えるため、SitecoreアプリケーションのログをAzure Blobストレージに保存することは推奨されないことにご注意ください。詳細情報については「Azure App Serviceのアプリケーション ログ (Blob)の設定とWebサイトのパフォーマンスについて」の記事をご参照ください。このデータの収集および保存には、Azure Application Insightsを使用することをお薦めします。

• • Application Insightsのデータ ストレージの「日次制限」
    

    Sitecore Managed Cloudのデプロイは、Azure Application Insightsを使用してアプリケーションの診断情報と関連するテレメトリーを収集します。Application Insightsで収集したデータはすべて有料なため、1日に保存するデータ容量の制限が設定されています。デフォルトでほとんどのお客様のシナリオでは1日あたり0.33GBに制限されています（この制限は「日次制限(Daily Cap)」と呼ばれます）。本番アプリケーションでは、1日あたり0.33GBを超える診断データを生成することがしばしばあるため、貴重なデータの損失を防ぐために、お客様特定の実装に適した値に日次制限を増加させることをお勧めします。正確な値は、状況によって異なりますが、実際のManaged Cloudの実装では、1日の上限を5GBから10GBの間に設定することが多いようです。なお、追加のデータを保存すると、プロジェクトにかかるAzureのコストが増加することに注意してください。

• • IP制限
    

    エンドポイントにアクセスできるIPアドレスを指定することで、Sitecore Managed Cloudの環境の主要コンポーネントであるAzure App Serviceへのアクセス権を制御することができます。これは、Azure App Serviceの「Networking」設定で実施します。これに関する詳細情報につきましては、Microsoftドキュメントの「Azure App Serviceのアクセス制限を設定する」記事をご参照ください。なお、もしManaged Cloudのお客様が特定のIPにしかリソースへのアクセスを付与しない場合、Azure App Serviceのエンドポイントのヘルス チェックを阻害する可能性がある点にご注意ください。Application Insightsのヘルス チェックは、Sitecore Managed Cloudのチームが、システムの可用性を監視するための重要な手段の1つであり、これらのチェックが接続できない場合、Managed CloudのサポートのSLAに影響を与えることになります。監視のメトリックスに関する情報については、「Sitecore Managed Cloud Standard - モニタリング メトリクス」の記事をご参照ください。
    Managed Cloudのサービス範囲（Sitecore Managed Cloud スタンダード– サービスの概要と付属するオペレーション）によると、監視サービスに対するアプリケーションの可用性を確保することは、お客様の責任で実施していただく内容となっています。Application Insightsの監視で使用されるIPアドレスは、Application InsightsおよびLog Analyticsで使用されるIPアドレスの記事の「可用性テスト」節で確認することができます。Sitecore Managed Cloudで使用される場所は、オーストラリア東部、ヨーロッパ北部、東南アジア、米西部および米中部となります。これらのIP制限に関するサポートが必要な場合、カスタマー サクセス マネージャー（CSM）またはサポート ポータル（サポート ポータルの使用方法）を通じて、弊社にお問い合わせください。

• • Webアプリケーション ファイアウォール（WAF）を本番前にセットアップする
    

    Sitecore Managed Cloudチームは、お客様の環境でWAFのセットアップおよびインテグレーションを実施します。これは、Sitecore Managed Cloud Standard - オンデマンド リクエストのサービス一覧で提供されているサービスの一部です。 弊社のこれまでの経験上、DNSの伝搬遅延やその他のネットワークの問題のおそれがあるため、WAFの実装は、Sitecore Managed Cloud環境の本番開始前に完了させることが最善であると考えられます。実際のプロジェクトでは、WAF導入後にすべての接続の変更をテストし、かつ慎重に評価するために十分な時間が必要であるため、プロジェクトのライフ サイクルの早い段階で取り込むことをお勧めします。

• Azureのリソースを「タグ」で識別できる
  

  Microsoft Azureは、リソースを認識する方法として、「タグ」をサポートしています。これに関連するMicrosoftの資料として、「タグを使用して Azure リソースと整理階層を整理する」の記事をご参照ください。Managed Cloudのお客様には、環境のメタデータを通知するために、Azureリソース グループにタグをつけていただくことをお薦めいたします。Azure Portalでのタグは、以下の例のように表示されます。