災害復旧について理解する

ディザスタリカバリサービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。その影響は、高可用性設計の処理能力を超えている。（DR）とは、予期せぬ障害発生後、1つまたは複数のワークロードを別の IBM Cloud リージョンで稼働可能な状態に戻すプロセスです。高可用性は災害復旧とは異なる。

ITワークロードを設計・構築する場合、高可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。（HA）を維持することに重点が置かれることが多い。 HAとは、単一障害点を排除してワークロードが生き残れるように設計するプロセスであり、インフラストラクチャの障害によって引き起こされる停止を回避することができる。

災害は違う。災害は、ワークロードを高可用性にしようと試みたにもかかわらず、ダウンする原因となる。クラウドワークロードを設計・導入する際には、災害によってそのワークロードがどのような影響を受ける可能性があるか、またどのように復旧できるかを検討する必要があります。災害発生時には、復旧プロセスの一環として、 IBM Cloud がインフラの復旧など、講じるべき措置がある場合があります。また、データの復元など、あなた自身でも行うべき手順があるかもしれません。設定データなどが含まれることが多いデータについて、バックアップが確実に作成され、復元可能な状態にあることを確認する必要があります。

最悪の災害は広範囲に影響を及ぼすため、被災したワークロードはまったく別の地域で復旧する必要があるかもしれない。

災害復旧とは何か？

第2の地域への回復を説明するために、あるシナリオを考えてみよう。通常、顧客は IBM Cloud us-south マルチゾーン・リージョンでワークロードを実行する。その後、大規模な災害が発生し、 us-south 地域全体が影響を受け、停電が長期化する。このような場合、 us-south 、通常運転に戻すには、停電の規模にもよるが、数時間、数日、あるいは数ヶ月かかるかもしれない。影響を受けたクラウドのワークロードがビジネス・オペレーションにとって重要なものである場合、長時間のダウンタイムが発生すると、ワークロードをリカバリして第2のリージョン（ IBM Cloud ）で実行するしか選択肢がなくなる。

このような状況は通常、自然災害や地域的・国家的緊急事態など、特定の地理的地域に影響を及ぼす広範な問題に起因する。このような災害が起こる可能性は低い。通常、 IBM Cloud のMZRアーキテクチャはゾーン障害に対して十分な保護機能を提供しており、マルチゾーン地域全体が障害に陥る可能性は低いと言えます。MZR上に展開されるサービスに対する IBM Cloud のサービスレベル契約（SLA）は、通常 99.99 ％となっており、これは年間で 52.5 分強の予期せぬダウンタイムに相当します。詳細は IBM Cloud サービス・レベル・アグリーメントを参照。

しかし、災害によって重要なワークロードが稼働している地域が破壊される可能性は残っている。災害による長時間のダウンタイムを避けたいのであれば、ディザスタリカバリプランを準備しておくこと。

RTOとRPO

回復時間の目標災害復旧計画において、災害後にビジネスプロセスが復旧するまでの時間。 (RTO）と（RPO）は、多くの場合、災害復旧計画の出発点となる2つのポイントである。リカバリーポイントの目標災害復旧計画において、データが復旧するまでの時間は、復旧時点から災害発生時点までを秒、分、時間で測定した時間である。次の図は、RTOとRPOがどのように単純化された停電タイムラインに適合するかを説明している。

停電が発生した場合、企業は災害を宣言し、災害復旧計画を実行に移すかどうか、またそのタイミングを決定しなければならない。災害を宣言した後、RTOの時間が始まる。 RTOとは、サービスを使用可能な状態に復旧させるのにかかる時間のこと。プランは、多くのワークロードをカバーする包括的なRTOと、各ワークロードをカバーする個別のRTOを持つことができる。 RTOは、分、時間、日などの時間単位で表される。

RPOとは、サービスが復元される時点のことで、通常は最後のバックアップの時点である。データ破損から復旧する場合、破損が発生する前の時点への早期RPOが望ましい。複数のワークロードが相互接続されている場合、各システムが同じ時点に買い戻されることが重要である。 RPOは、障害発生時点、データ損失ゼロ時点、最終バックアップ時点、またはその中間で表される。 RPOの制約には、技術的実現可能性と導入コストが含まれる。停電はエンドユーザーにサービスが復旧するまで続く。

多くの環境では、ワークロードのタイプが混在しており、基本的にクリティカルなものもあれば、それほどクリティカルでないものもある。複雑な環境では、あるワークロードが動作するために別のワークロードを必要とするような、他のワークロードへの依存関係が多い場合もある。これらの側面は、個々のワークロードに対するRTOとRPOの目標設定に貢献する。ワークロードの復旧順序を考慮した復旧計画のタイムラインを作成する。タイムラインは、ビジネスにおけるワークロードの重要性、リソース要件、複雑さ、依存関係を考慮しなければならない。

以下の表は、参考例としてアプリケーション分類ごとのRPO/RTOの例を示している。実際のRPO/RTOや業務分類は各組織によって異なる。

ビジネス・アプリケーション・クラスに基づくRTO/RPO値の例
ビジネス・アプリケーション・クラス	RPO	RTO
プラチナ（常時点灯）	0	ほぼゼロ
ゴールド（ほぼ常時点灯）	<= 15分	<=1時間
シルバー（高可用性）	<=1時間	4～8時間
ブロンズ（中程度の空き状況）	<=8時間	<=24時間

DRの維持にはコストがかかる。次の図は、典型的なDRコスト曲線を示している。 RTOとRPOの目標がゼロに近ければ近いほど、必要なソリューションのコストは大きくなる。 RTOやRPOが数時間、さらには数日単位になるにつれて、関連コストは削減される。 RTOとRPOの目標が最も厳しいワークロードは、保護に最もコストがかかり、最もビジネスクリティカルである。

災害への備え

DR戦略を定義するアプローチは体系的である必要があり、アプリケーションまたはワークロードと、それらが使用するクラウド・サービスのタイプから始める必要がある。すべてのワークロードに対して単一のRTO/RPO目標を設定したくなるが、現実には、各ビジネス・ワークロードは独立しており、独自のRTOおよびRPO要件を持っている。多くの顧客は一連の作業負荷クラスを使用しており、各クラスには一定のRPO/RTOが設定されている。

各ビジネス・ワークロードは、一連のクラウド・リソースを使用する。 DRの要件を理解し、文書化し、本番環境にリリースする前に実装しなければならない。そもそもDRソリューションを念頭に置いてワークロードを設計するよりも、DRソリューションを「後付け」する方が難しい。

災害復旧戦略

DRソリューションには多くの選択肢がある。さまざまなオプションは、以下の4つの大きなカテゴリーに分類される：

ゼロフットプリント: ゼロ・フットプリントでは、アプリケーション・スタック全体が1つの場所でアクティブになり、別の場所でアプリケーション・スタックをリカバリすることができるが、そこではまったく何も構築されない。実際には、すべてのバックアップがリカバリのために2番目の場所で利用可能であることを確認してください。災害が発生した場合、バックアップが適用される前に、すべてのサービスが、できればTerraformテンプレートなどから、一からプロビジョニングされる。ゼロフットプリントは最もコストのかからない戦略である。サービスはゼロからプロビジョニングされるため、RTOとRPOの目標が少なくとも数時間に及ぶ場合にのみ適している。
基本スタンバイ: 基本的なスタンバイ・オプションは、アプリケーション・スタック全体をある場所でアクティブに保ち、別のアプリケーション・スタックは別の場所にデプロイされるがシャットダウンされた状態に保つ。プライマリ・ロケーションで長時間の障害が発生した場合、アプリケーション・スタックはセカンド・ロケーションで起動され、バックアップがリカバリされる。このモデルを使用するワークロードのインスタンス化とリカバリには、数時間のリカバリ時間がかかることが予想される。ワークロードの可用性が重要で、RTOの目標が数時間未満の場合、このアプローチは最適ではない。
最小限の操作: 最小限の操作とは、アプリケーション・スタック全体はプライマリ・ロケーションとバックアップ・ロケーションの両方でアクティブであるが、ユーザー・トランザクションはプライマリ・ロケーションのみで処理されることを意味する。データベース・レプリケーションやディスク・レプリケーションのようなデータ・レプリケーションは、バックアップの場所を同期しておく。プライマリサイトが長期間利用できない場合、すべてのクライアントトランザクションはバックアップサイトにルーティングされる。このアプローチは、分単位で測定できるRPOとRTOを提供する。最小限の運用は、二重展開のため、アクティブ/パッシブオプションよりも高くつく。例えば、スタンバイ資産を使用してスケーラビリティーとスループットを向上させることはできないため、リソースが浪費されます。
Active/Active: Active/Activeは、両方のロケーションがアクティブであることを意味し、クライアントのトランザクションは、「ラウンドロビン」や「地理的に最も近い」など、事前に定義されたポリシーに従って両方のリージョンに分配される。あるサイトに障害が発生した場合、他のサイトはすべてのクライアントにサービスを提供できなければならない。この構成では、RPO と RTO の両方をゼロに近い値にすることができます。オートスケーリングの使用は、現在の負荷に基づいて十分なリソースが利用可能であることを保証するための鍵となる。あるリージョンに障害が発生した場合、残りのリージョンは全負荷を処理するために迅速にスケールしなければならない。 2つのサイトにまたがるデータは、レプリケーション・メカニズムによって継続的に同期される。データの破損や損失が災害の根本的な原因である場合、レプリケーションのためにこのアプローチだけに頼るのは問題がある。このような災害を解決するには、やはり、破損または紛失していないデータを含むバックアップを復元することに頼る。

さまざまなシナリオを想定したデザイン

災害にはさまざまな形があり、その対策にはさまざまなテクニックが必要だ。完全な地域停止から回復する手段は、データ破損から回復する方法とは異なる。優れた設計は、単一のシナリオだけを考慮するのではなく、複数の潜在的な故障からの回復を提供するさまざまなシナリオを考慮する。

災害が発生した場合の復旧に必要なものをよく検討すること。すべてのワークロードが必要なのか、それともコア・アプリケーションのサブセットだけが必要なのか修復の順番はありますか？ワークロード間のデータの一貫性は重要か？劣化した状態で働くことは可能ですか？可能だとしたら、どのくらいの期間ですか？

これらの質問は、技術的なものと同じくらいビジネス上の問題である。事業を機能させ、その結果を理解した上で残存リスクを受け入れ、許容できる最小限の回復とは何かについて、明確な見解を持たなければならない。技術的ソリューションの計画は、ビジネス要件と手を携えて行わなければならず、その両方が災害復旧計画に盛り込まれていなければならない。詳しくは、災害復旧の計画を参照。

サービス固有の文書を読む

各 IBM Cloud サービスは個別に文書化され、その製品に固有の BCDR 要件のセクションが含まれる。利用する各サービスのガイダンスを確認し、それに従ってください。トピックへの具体的なリンクの探し方については、高可用性とディザスタリカバリに関するサービス・ドキュメントを参照してください。