この記事では、Sitecore Managed Cloud – PaaS 2.0環境で、Azure App Serviceのデプロイ スロットを有効化する方法について解説します。
Azure App ServiceにWeb Appをデプロイする際に、Standard、Premium、またはIsolated価格レベルで実行する場合、デフォルトの本番スロットのかわりに独立したデプロイ スロットを使用することができます。
デプロイ スロットはホスト名を持ったライブAppです。Appの内容および構成要素は二つのデプロイ スロット（本番スロットを含む）の間でスワップすることができます。
貴社のManaged Cloud環境に含まれるAzure Servicesの更なる詳細につきましては、以下のKB記事をご参照ください。特に重点が置かれるのは、Premium App ServicesプランでデプロイされたCMサーバーおよびCDサーバーです。
Sitecore Managed Cloud Standard - Sitecore XP 10.3.1以上のバージョン用トポロジーと価格レベルについて（PaaS 2.0）
このページの下記の図では、以下に示す記号を使用して説明します。
- R = Responsible（実行責任者）： タスクを直接実施・完了する責任者です。
- A = Accountable（説明責任者）： 成果物またはタスクの正確かつ完全な完了に対する最終的な責任を負い、作業を実行責任者に委任している責任者です。
- C = Consulted（相談先）： その他の責任者等から相談を受ける有識者（すなわち、内容領域専門家）であり、双方向のコミュニケーションを行う担当者です。
- I = Informed（報告先）： 随時タスクの進捗について（もしくはタスクの完了または成果物についてのみ）報告を受ける担当者です。
以下は、Sitecore Managed Cloud PaaS 2.0環境内のAppデプロイ スロットを有効化する上での大まかな指針となる手順です。
| RACIの説明 |
お客様/パートナー様 |
Sitecore |
| Azure App Serviceデプロイ スロットをリクエスト |
R, A |
C, I |
| Azure App Serviceデプロイ スロットを有効化 |
C, I |
R, A |
| デプロイ スロットのネットワーク セキュリティ アクセスを制限 * |
C, I |
R, A |
| カスタム コード・アプリケーションのデプロイ ** |
R, A |
C, I |
| 追加のデータベースのデプロイ（必要に応じて） *** |
R, A |
C, I |
| Appデプロイ スロットの交換 |
R, A |
C, I |
| Appデプロイ スロットのデプロイのトラブルシューティング |
R, A |
C, I |
* 弊社では、デプロイ スロットが設置され次第、弊社のネットワーク セキュリティ ポリシー（プライベート ネットワークからのトラフィックのみを排他的に許可し、外部のインターネットからのアクセスをブロックする）に一致させるために、「プライベート エンドポイント」を作成する必要があります。一度プライベート エンドポイントが有効化されたら、弊社Web appではアクセス制限を有効化します。これは「pe」サブネットからプライベートIPアドレスを取得し、プライベート ネットワークとハブのエントリー ポイント ソリューションの一つを介したアクセスだけを許可します。
** 新たに作成されたデプロイ スロットは最初は空であることにご注意ください。スロットが有効化されたら、貴社のアプリケーションをデプロイしていただく必要があります。
*** 貴社の必須要件に応じて、追加のデータベースをデプロイする必要がある場合に実施してください。
- モニタリング:
- SitecoreはCMおよびCD App Serviceプランの本番URLのみを監視します。
- App Serviceのバックアップ:
- Sitecore Managed Cloudのカスタム バックアップ スケジュールには「本番」スロットのバックアップのみが含まれます。
- 二番目のデプロイ スロットが昇格・スワップされた場合、デフォルトのバックアップ プロセスが適用され、スロットがバックアップされます。
- 新しいデプロイ スロットが作成された場合に、新しく作成されたスロットの初期バックアップを取得する自動化処理があります。
- データベースのバックアップ:
- 新しく作成されたデータベースは自動的にバックアップされます。ただし、バックアップ タイプとしてGRSを忘れずに選択することが重要です。
- ディザスタ リカバリ:
- DRが有効化される前に新しいデータベースが作成された場合、DRプロテクションの際にDRに含まれます。
- DRが有効化された後で新しいデータベースが作成された場合、自動化メカニズムによって次の6時間以内にDRに含まれます。
レプリケーションは自動化DRメカニズムによって、次の6時間以内に実行される点にご注意ください。
- App Serviceプラン:
- リソースの配分: デプロイ スロットはメインのApp Serviceとリソースを共有します。そのため、スロットを有効化するとリソースの使用量が若干増加し、もしメインのApp Serviceのリソースがすでに逼迫して制約がある場合には、潜在的にパフォーマンスが低下する可能性があります。
- コールド スタート: 各デプロイ スロットは独立した環境を持ち、スロットをスワップしたりスロットにコードを最初にデプロイした際に、環境がウォーム アップするために短時間のコールド スタートによる遅延が生じる可能性があります。これにより、スロットのスワップまたはデプロイの際に、一時的にパフォーマンスが低下する場合があります。
- スケーリングの考慮事項: メインのApp Serviceをスケーリングした場合、デプロイ スロットも全て同じスケールの設定を継承します。設定が適切に管理されていない場合、リソースの割り当てが完全に最適化されず、潜在的なパフォーマンスのボトルネックを生じさせる可能性があります。
- 構成の複雑さ: 複数のデプロイ スロットを管理する場合、設定やメンテナンスの観点から複雑さが増し、設定ミスや適切でないスロットの管理によるパフォーマンスの問題が引き起こされる可能性があります。
これらのパフォーマンスの影響を緩和するには、リソースの使用量をモニタリングすること、スロットの設定を注意深く適切に構成すること、およびスロットのデプロイとスワップをトラフィックの少ない時間帯か、ユーザーへの影響を最小化できる受け入れ可能なダウンタイムの範囲内で実施することが重要です。
- SQL vCore エラスティック プール:
- リソースの共有: プールにより多くのデータベースが追加されるにつれて、利用可能なCPU、メモリ、I/Oリソースがより多くのデータベースに共有されるようになります。プールのリソースが適切にスケーリングされていない場合、ピーク利用時における個別のデータベースのパフォーマンスが低下する可能性があります。
- リソースの競合: 複数のデータベースが著しく多量のCPUまたはI/Oリソースを同時に必要とした場合、プール内でのリソースの競合が増加します。この競合により、パフォーマンスのボトルネックやクエリの実行速度の低下につながる可能性があります。
- リソースの制限: エラスティック プールには一定のリソースの制限があり、データベースを追加するとこれらの制限に早く到達する可能性があります。プールがそれらのリソースの制限に達すると、ア新しいデータベースのリクエストが拒否され、データベース リソースの可用性に影響する場合があります。
- クエリのパフォーマンス: データベース クエリのパフォーマンスが、新しいデータベースによって生成された追加のワークロードに影響される可能性があります。プールのリソースの制限に達すると、クエリの待ち時間が増加し、応答時間が遅延する可能性があります。
これらのパフォーマンスの影響を緩和するには、定期的にエラスティック プール内のリソースの利用状況を監視し、必要に応じてリソースの割り当てを調整することが重要です。
プールをスケール アップ（より多くのリソースを提供）すると、より多くのデータベースが追加されても、プール内のデータベースに引き続き良好なパフォーマンスを維持させることができます。
- Appのデプロイ スロット: デプロイ スロットを有効化する際に追加のコストは発生しません。
- プライベート エンドポイント: プライベート エンドポイントごとに追加のコストが適用されます。更なるご質問や検討事項等がありましたら、貴社を担当するSitecoreアカウント チームにお問い合わせください。