ディザスター リカバリーとは
災害は、アプリケーションの設計の高可用性部分によって軽減できる程度を超えて、大規模で長期的な影響を生じさせる 1 つの大きな事象です。 ディザスター リカバリー (DR) とは、自然災害やデプロイの失敗など、ダウンタイムやデータ損失につながる影響の大きいイベントから復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。
復旧目標
完全な DR プランでは、アプリケーションが実装するプロセスごとに次の重要なビジネス要件を指定する必要があります。
回復ポイントの目標 (RPO)は、データ損失が許容される最大継続時間です。 RPO は、"30 分のデータ" や "4 時間のデータ" など、ボリュームではなく時間単位で測定されます。RPO は、データの盗難ではなく、データ損失の制限と回復に関するものです。
目標復旧時間 (RTO) は、ダウンタイムが許容される最大継続時間です。この場合の "ダウンタイム" は仕様によって定義されます。 たとえば、災害時に許容されるダウンタイムの継続時間が 8 時間の場合、RTO は 8 時間です。
アプリケーションで実装される主要なプロセスまたはワークフローごとに個別の RPO と RTO の値が必要です。このためには、ディザスター シナリオのリスクと考えられる復旧戦略を調べます。 RPO と RTO を指定するプロセスにより、固有のビジネス上の懸念事項 (コスト、影響、データ損失など) の結果として、アプリケーションの DR 要件が効果的に作成されます。
ディザスター リカバリーの設計
ディザスター リカバリーは自動機能ではなく、設計、構築、テストを行う必要があります。 確実な DR 戦略をサポートするには、最初から DR を念頭に置いてアプリケーションを構築する必要があります。 Azure では、アプリを作成するときに DR をサポートするのに役立つサービス、機能、ガイダンスが用意されています。 DR をサポートするために何をする必要があるかを理解するには、まず回復性に対する共同責任モデルを理解する必要があります。 詳細については、「回復性に対する共同責任」を参照してください。
データの復旧
災害発生時にデータを復元する主な方法として、バックアップとレプリケーションの 2 つがあります。
バックアップは、データを特定の時点に復元します。 バックアップを使用すると、データを Microsoft Azure クラウドにバックアップして復旧するためのシンプルかつ安全でコスト効率の高いソリューションを提供できます。 Azure Backup を使用して、復旧で使用するための有効期間が長い読み取り専用データ スナップショットを作成します。
データ レプリケーションは、データ損失を最小限に抑えながら、複数のデータ ストア レプリカにライブ データのリアルタイムまたは準リアルタイムのコピーを作成します。 レプリケーションの目標は、アプリケーションの応答性を維持しながら、できるだけ短い待機時間でレプリカを同期し続けることです。 ほとんどのフル機能のデータベース システムやその他のデータ ストレージ製品およびサービスには、それらの機能およびパフォーマンス要件を満たすために、何らかの種類のレプリケーションが、緊密に統合された機能として含まれています。 この一例として、geo 冗長ストレージ (GRS) が挙げられます。
レプリケーション設計が異なれば、データの整合性、パフォーマンス、コストの優先順位も異なります。
アクティブ レプリケーションでは、複数のレプリカで同時に更新を行う必要があり、スループットの代償として整合性が保証されます。
パッシブ レプリケーションではバックグラウンドで同期が行われるので、レプリケーションによってアプリケーションのパフォーマンスが制約されることはありませんが、RPO は増加します。
アクティブ/アクティブまたはマルチマスター レプリケーションでは複数のレプリカを同時に使用できるため、負荷分散が可能になりますが、データの整合性は複雑になります。
アクティブ/パッシブ レプリケーションでは、フェールオーバー中にのみライブで使用するためにレプリカが予約されます。
Note
フル機能を備えたデータベース システムや他のデータ ストレージ製品およびサービスの大半には、機能およびパフォーマンスの要件を満たすために、geo 冗長ストレージ (GRS) などの何らかの種類のレプリケーションが含まれています。
回復性のあるアプリケーションの構築
災害のシナリオでは、ネットワーク接続の問題、データセンターの停止、仮想マシン (VM) の損傷、またはソフトウェア デプロイの破損に関する損害など、原因はさまざまですが、結果的にダウンタイムも発生するのが一般的です。 ほとんどの場合、アプリケーションの復旧は、稼働している別のデプロイへのフェールオーバーを伴います。 その結果、大規模な災害が発生した場合、別の Azure リージョンでプロセスを復旧することが必要になることがあります。 追加の考慮事項としては、復旧場所、レプリケートされた環境の数、これらの環境を維持する方法などがあります。
アプリケーションの設計に応じて、いくつかの異なる戦略と、Azure Site Recovery などの Azure 機能を使用して、災害後のプロセス復旧に対するアプリケーションのサポートを向上できます。
サービス固有のディザスター リカバリー機能
Azure App Service などの Azure サービスとしてのプラットフォーム (PaaS) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されています。 一部のシナリオでは、サービス固有の機能を使用して高速リカバリがサポートされます。 たとえば、Azure SQL Server では、別のリージョンにサービスを迅速に復元するための geo レプリケーションがサポートされます。 Azure App Service にはバックアップと復元の機能があり、ドキュメントには、Azure Traffic Manager を使用してセカンダリ リージョンにトラフィックをルーティングするためのガイダンスが含まれています。