1. PaaS 2.0の災害復旧

DR 2.0の回復ポイント目標および回復時間目標

Version:
日本語翻訳に関する免責事項

このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。

本番環境の障害からDR環境での運用復帰までの時間は、フェイルオーバープロセス開始のリクエストを作成するかどうかに依存します。フェイルオーバー前に故障やイベントの調査に費やす時間は、運用復帰のタイミングを遅らせます。このトピックでは、DR 2.0のフェイルオーバープロセスに関わるリカバリーポイント目標(RPO)および復旧時間目標(RTO)について説明します。

リカバリーポイント目標(RPO)

サービスの種類

リカバリーポイントの目的

Azure SQL フェイルオーバーグループ

~5秒

Azure App Serviceはバックアップと復元を計画します

3時間

Azure Redisキャッシュ(セカンダリージョンで再構築)

該当なし

Sitecoreの設定と自動化

3時間

バックアップとリストアを用いるSolr as a Service(サービスとしてのソリューション)

3時間

技術復旧時間目標(RTO)

サービスの種類

技術復旧時間目標

Azure SQLフェイルオーバーグループ

10分

Azure App Service plans backup

10分

Azure Redis Cache *

30分

Sitecoreの設定と自動化

10分

バックアップとリストアを用いるSolr as a Service(サービスとしてのソリューション)

10分

* Azure Redisキャッシュのスケーリングアップは約30分かかります。この間、Azure Redis Cacheサービスへのアクセスが断続的に行われる場合があります。 MicrosoftのAzure Redisスケーリングに関するドキュメントをご参照ください。

!注技術RTOの価値は、Sitecoreプラットフォームの復元にかかる時間のみを考慮しています。顧客やパートナーが手動でフェイルオーバーの許可を得る試みやカスタマイズの検証を試みるなど、手作業が必要な場合、実効的なRTOは延長されます。

プラットフォームおよびウェブサイトの回復時間目標(RTO)

以下に記載するRTO値は、DRフェイルオーバープロセスを開始するために顧客の承認が必要です。

バックアップ技術

責任ある所有者

技術復旧時間目標

Sitecore CMサーバーアクセスとサービスの利用可能性

Sitecore

1時間

Sitecore CDサーバーのアクセスとサービスの利用可能性

Sitecore

1時間

ウェブサイトへのアクセスと入手可能性

顧客/パートナー

顧客依存の活動で、カスタムアプリケーション接続文字列やサードパーティ接続の検証が必要です。

!注RTOは大規模なコンテンツデータベースにかかる大幅な時間のため、xDBインデックスの再構築はカバーしません。分析インデックスの再構築が行われない場合、これはEXMのようにリストに依存する機能にのみ影響し、ランタイムサイトには影響しないはずです。

この記事を改善するための提案がある場合は、 お知らせください!