AWSマルチリージョンでディザスタリカバリ（DR）を実現する

DR（ディザスタリカバリ）とは？

近年、ITシステムは様々な生活場面で必要不可欠なものになっています。製造業などでは、発注や生産管理のシステムが停止すると製品の生産に影響が出てしまいます。また、QRコードなどの決済システムが動かなくなると、多くの店舗や利用者に影響が出てしまいます。システム障害は人為的な原因だけでなく、災害などでデータセンターが被災したり、広域的な停電が発生しても生じます。

これらのようなシステム障害や災害によるシステム停止においてもビジネスが継続できるように作成しておく計画のことを、BCP(事業継続計画)といいます。災害や大規模なシステム障害が発生しても事業活動の中断を最小限に抑えることが目的です。

特に、システムにおいて、災害発生時にシステムやデータを迅速に復旧・復元し、事業の中断を最小限に抑えるための計画やアプローチのことを、DR（ディザスタリカバリ）といいます。本記事では、DRの確認ポイントや、AWSにおけるシステムDRの実現方法について解説していきます。

DRサイト導入前に確認すべきポイント

DRサイトの導入の前に確認すべきことは、システムの特性と指標を整理することです。

整理すべきシステムの特性とは？

システムの特性とは、業務の重要度やユーザー数など、システムが停止した際のリスクを考えるうえで重要な特性です。

• 一般ユーザー向けか社内向けか…例えば、eコマースサイトやオンラインバンキングサービスなど。これらのシステムは、多数の外部ユーザーがアクセスし、利用頻度や利用時間が広範にわたるため、ダウンタイムが直接収益や信頼に影響します。一方で、社内向けシステムは利用時間が限られているケースがあります。
• 基幹システムかサポートシステムか…金融機関のトランザクションシステムや病院の電子カルテシステムなど、いわゆる基幹システムと呼ばれるものは停止時のリスクが非常に大きいと考えられます。一方で社内のイントラネットなどは閲覧ができなくても大きな社会的影響がありません。
• 法規制・コンプライアンス…金融業や医療業界など、特定の規制に準拠する必要がある場合。例えば、データの保全や復旧に関する規制が厳しい業界では、DR計画にこれらの要件を組み込む必要があります。

リスク評価したあとは、適切な指標を設定する必要があります。以下に、DRを考える上での主要な指標について説明します。

AWSを活用したDR対策で安心、安全を設計するスタイルズのAWS移行サービスはこちら→

RTO（Recovery Time Objective）とは

RTOはRecovery Time Objectiveの略で、目標復旧時間のことです。具体的には、重要な機能が中断され復旧までにかかる時間を示します。この間はシステムが利用できなくなるため、業務をシステムに頼る度合いが大きい企業はRTOが長くなるほど大きな打撃を受けるでしょう。一方、システムが中断されても事業の継続にあまり支障がないケースもあります。つまり、RTOの値がゼロに近いほどシステムの復旧時の許容時間が短くなります。早期に復旧が実現すると企業の利益へのダメージを最小限に抑えられるだけでなく、企業の社会的責任を遂行でき、顧客や市場からの信頼獲得にもつなげられるでしょう。

RPO（Recovery Point Objective）とは

Recovery Point Objective（RPO）は、日本語では目標復旧時点と訳せます。インシデント（企業にとって好ましくないできごと）の後に、過去のどの時点のデータを復旧させるかを表す指標です。「データの復旧ができなくてもどれだけの時間または日数が許容されるか」を示す指標と言い換えられるでしょう。事業内容や活動状況によってRPOの値の重要度が変わります。例えば、取引のためのデータ通信が頻繁に行われている企業では、システムが停止した後の1時間でもデータが消えれば多くの価値を失うことになるでしょう。反対に、データの取引がほとんど行われない企業では、3日前のデータを復旧すれば問題ない場合があります。

RLO（Recovery Level Objective）とは

Recovery Level Objective（RLO）は、災害やシステム障害後にシステムやサービスが復旧する際のサービスレベルを指します。RLOは、復旧後のシステム性能や機能の最低基準を定義し、通常の運用レベルに完全に戻るまでの一時的な目標を設定します。RLOの設定により、段階的な復旧プロセスを計画し、完全な復旧までの間に必要な最低限のサービスを確保することができます。

AWSにおけるディザスタリカバリ

AWS（Amazon Web Services）は、リージョンやAZ（アベイラビリティゾーン）など、複数の地域（リージョン）・データセンター（AZ）にまたがってシステムを構築できるインフラストラクチャを提供しています。リージョンやAZを組み合わせて利用することで、システムのDRサイト構築を簡単に進めることができます。AWSでは、DR戦略として4つの主要な方式が提案されています。これらの方式は、コスト、復旧時間、データ保護のレベルに応じて選択されます。それぞれの方法について、解説していきます。

AWSにおける手法１（バックアップとリストア）

Backup & Restoreは、最も基本的なDR戦略です。この方式では、定期的にデータやシステムのバックアップをAWSに保存し、災害発生時にそれらをリストア（復元）することを目的としています。低コストで実装可能ですが、リストアに時間がかかるため、復旧時間（RTO）はどうしても長くなります。また、バックアップ間隔によってはデータ損失量（RPO）も大きくなる可能性があります。コスト重視の小規模ビジネスやサポートシステムなどに適しています。

AWSにおける手法２（パイロットライト）

パイロットライト方式では、小規模にデータベースを立ち上げておくなど、主要なシステムの最重要な構成要素だけをAWS上で常に稼働させておき、その他のリソースは災害発生時など、必要時に立ち上げます。例えば、データベースのデータだけをリアルタイムに同期させておき、災害発生時にはWeb/APサーバーも立ち上げるといった内容です。これにより、災害発生時に迅速にシステムを完全稼働状態にすることが可能です。最低限のリソースのみを常時稼働させるため、コストは比較的抑えられますが、Backup & Restoreよりはコストがかかります。主要な構成要素が常に稼働しているため、リストアよりも早い復旧が可能です。ダウンタイムは極力避けたいが、フルスタンバイのコストを避けたいシステムに適しています。

AWSにおける手法３（ウォームスタンバイ）

ウォームスタンバイはパイロットライト方式に似ていますが、すべての構成要素を小規模に縮小版としてAWS上で常に稼働させておき、災害発生時には切り替えてフルキャパシティでの稼働を目指す方式です。中〜高程度、縮小版システムの維持にコストがかかりますが、マルチサイトよりは低コストとなります。縮小版システムが稼働しているため、RTO/RPOは低く抑えることができます。ダウンタイムは許容されないが、完全なマルチサイトほどのコストはかけられないシステムに適しています。

AWSにおける手法４（ホットサイト/マルチサイト）

マルチサイト方式は、複数のAWSリージョンにわたってシステム全体を常に稼働させる方式です。災害発生時には、フェイルオーバーによって影響を受けないサイトに迅速に切り替えることができます。コスト効率は一番悪いですが、RTO/RPOはほとんどないと考えて問題ありません。完全にミッションクリティカルなシステムや、極めて短いダウンタイムが要求される業務に適しています。

DR対策に絶対必要なことは

DRサイトは設計や初期構築よりも運用が何よりも大切です。実際に、DRが発動するときはシステム構築中ではなく運用中になるためです。具体的に必要な項目は以下のとおりです。

継続的なテストや訓練

いざというときに迅速に切り替えができるように、定期的に手順の確認やテストが必要です。また、切り替え手順だけでなく、切り替えの判断や切り戻しのタイミングの確認といった、本番さながらの体制で行うことが何よりも重要です。

人手を極力排除する

災害発生時には切り替えを行う人が出社できなかったり、システムを操作できなかったり、といった事態も考慮しておく必要があります。そのようなケースに備え、DRの切り替え手順は極力自動化（コード化）をしておく必要があります。

監視を行う

大規模なシステム障害や災害によるシステムの使用不可な状態が発生していても、関係者が気づけないと初動が遅れてしまいます。AWS CloudWatchやAWS Personal Health Dashboardなどで、状態の監視を行うようにしましょう。

AWSを活用したDR対策で安心、安全を設計するスタイルズのAWS移行サービスはこちら→

まとめ

AWSでは、リージョンやAZなどを組み合わせて災害や大規模システム障害に強いシステムを簡単に構築することができます。ただ、システムのDRをコスト効率よく、適切に実現するためには、システムの特性の整理を行った後、RTO/RPO/RLOといったそれぞれの指標に合わせて、DRの方式を選択していく必要があります。また、DRサイトを構築した後も、適切な運用を行っていくことが何よりも重要です。会社のシステムにおいて、どのようなDRの方式を選択すればいいのか、またどのような運用を行っていけばいいのかは、専業のベンダーに相談してみてもいいでしょう。