Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

AWSとDoiTで築く、止まらない事業基盤

By Karim AmarsiJul 12, 202315 min read

このページはEnglishDeutschEspañolFrançaisItalianoPortuguêsでもご覧いただけます。

デジタル化が加速する現代において、企業はかつてないほどオンラインサービスに依存しています。サービスが停止すれば、事業に深刻な影響が及びかねません。そこで重要になるのが、AWS上でのディザスタリカバリ(DR、災害復旧)という考え方です。ITインフラやデータに被害を及ぼす災害に備え、迅速に立ち直るための取り組みを指します。AWS(Amazon Web Services)は、堅牢かつ柔軟なDR計画のためのフレームワークを提供しており、ダウンタイムを抑え、不測の事態からより早く復旧することを可能にします。

ディザスタリカバリにおける「災害」とは

ディザスタリカバリの文脈における「災害」とは、事業運営に重大な影響を与えるあらゆる事象を指します。洪水や地震といった自然災害をはじめ、サイバー攻撃、停電、さらにはデータ消失やシステム停止を招く人為的ミスまで、その範囲は多岐にわたります。DR計画の目的は、こうした予期しがたい事態を想定し、事業運営への影響を最小限に抑える備えを整えておくことにあります。

AWS責任共有モデル

DRを計画する上で、AWSの責任共有モデルへの理解は欠かせません。AWSはこのモデルに基づいて運営されており、安全でコンプライアンスに則した環境を維持するために、AWSと利用者がそれぞれの役割を分担する仕組みです。

AWSはクラウド「の」セキュリティ、すなわちデータセンターの物理的セキュリティ、グローバルインフラ、ハードウェア、ネットワークに責任を持ちます。一方、利用者はクラウド「内」のセキュリティ、つまりデータ、アプリケーション、OS、IDおよびアクセス管理を担います。AWSが安全な土台を提供し、その上に利用者が自らのworkloadsを構築・運用しながらセキュリティを上乗せしていく、というイメージです。

高可用性とディザスタリカバリの違い

高可用性(HA)とDRは、いずれも包括的なIT戦略に欠かせない要素ですが、似ているようで目的は異なります。

高可用性は、平常運用時に許容できるサービスレベルを維持することを目的とします。個々のコンポーネントに障害が起きてもシステムが利用し続けられるよう設計しておくのがポイントです。たとえばECサイトであれば、HA構成にしておけば、1つのインスタンスがダウンしても負荷が他のインスタンスに分散されるため、サイトはそのまま稼働を続けられます。

一方、DRは、大規模な障害が発生した後にサービスを復旧させることを目的とします。重要なデータ、アプリケーション、インフラを災害後に復旧するための計画をあらかじめ用意しておくのです。先ほどのECサイトが深刻なサイバー攻撃を受けて広範なデータ消失とダウンタイムに見舞われたとすれば、DR計画に従ってデータを復旧し、サイト機能を取り戻していくことになります。

ディザスタリカバリと事業継続のアプローチを比較する

DRと事業継続(BC)は密接に関連しますが、危機管理におけるアプローチの焦点が異なります。

DRはBCの一部です。災害後にシステム、アプリケーション、データを復旧するために必要な技術的プロセスに重点を置きます。先ほどの例で言えば、サイバー攻撃の後にECサイトを復旧し、脆弱性を修正し、サイトを再稼働させるまでの一連の作業がDRにあたります。

これに対し事業継続は、災害の最中も、その後も、不可欠な業務機能を中断させないための包括的な取り組みです。DRが主にITシステムとデータの復旧に焦点を当てるのに対し、BCはその枠を超えて広がります。先ほどのECサイトの例なら、急増する問い合わせに対応するためのコールセンター増強、暫定的な販売手順の整備、状況や復旧見込みに関する顧客への積極的な情報発信などが含まれるでしょう。BCはITに限らず、災害の影響を受け得る事業のあらゆる側面を網羅します。

ディザスタリカバリ戦略

AWSでDRを設計する際、workloadsの特性に応じていくつかの選択肢があります。ここでは代表的な4つの戦略を紹介します。

  1. バックアップ&リストア:DRの古典的なアプローチの1つです。クラウドへ定期的にバックアップを取得し、災害時にはそれを使って失われたデータやアプリケーションを復元します。仕組みがシンプルでコスト効率にも優れ、バックアップが消費するストレージ分の費用しかかかりません。ただし復旧時間は長くなりがちで、データやアプリケーションの規模によっては相応の時間を要します。比較的長い復旧時間が許容できる、重要度の低いアプリケーションに向いた戦略です。
  2. パイロットライト:環境の最小構成を常時クラウドで稼働させておく方式です。「パイロットライト(種火)」となるのは、データベースやアプリケーションサーバーなど、システム稼働に欠かせないコア要素のみ。災害時はそのコアを起点にリソースを一気にプロビジョニングし、システム全体を立ち上げ直します。すでに動いているサービスをスケールアップするだけで済むため、バックアップ&リストアより復旧が速いのが特長です。一方、最小構成とはいえ環境を維持し続けるため、コストはやや高くなります。短い復旧時間が求められる重要なアプリケーションに適しています。
  3. ウォームスタンバイ:完全に機能する環境の縮小版を、常時クラウドで稼働させておくアプローチです。このスタンバイ環境は本番環境のミラーで、いつでも切り替えに対応できる状態で待機しています。必要に応じて本番相当の負荷を捌けるよう、迅速にスケールアップできます。バックアップ&リストアやパイロットライトよりも復旧時間が短く、フルワークロードに合わせてスケールアップするだけで済みます。ただし、スタンバイ環境を常時維持する必要があるため、コストは増加します。
  4. マルチサイト:通常、地理的に異なる複数のリージョンで、アプリケーションとサービスを同時稼働させる戦略です。平常時は全サイトがアクティブで、負荷を分担します。1つのサイトに障害が起きても、他のサイトが稼働を続けるため、サービスは中断しません。最大の強みは、アクティブ–アクティブ構成によりすべてのDR戦略の中で最短の復旧時間を実現できる点です。一方で、複数の完全機能環境を維持するため、コストは最も高くなります。高可用性とゼロダウンタイムが何より重要なミッションクリティカルなアプリケーションで採用されるのが一般的です。

各戦略にはそれぞれ強みがあり、どれを選ぶかはworkloadsの要件によって変わります。判断の鍵を握るのが、目標復旧時点(RPO)と目標復旧時間(RTO)の2つの指標です。

RPOとは、許容できるデータ損失量を時間で表したものです。たとえばRPOが60分のシステムであれば、障害が起きても失われるデータが60分相当に収まるよう、構成とデータをバックアップしておく必要があります。

一方RTOは、災害発生後、事業継続性の途絶による看過できない影響を回避するために、業務プロセスを復旧すべき目標時間のことです。たとえばRTOが120分なら、障害発生から120分以内にシステムとアプリケーションを稼働状態に戻さなければなりません。

RPOとRTOの違いを押さえておくことは重要です。RPOがデータと許容できる損失量に関する指標であるのに対し、RTOはシステムを再稼働させるまでの時間に焦点を当てています。

ここからは、先ほどの4つの主要なDR戦略について、RPOとRTOの観点から整理してみましょう。

  1. バックアップ&リストア
  • RTO:バックアップ&リストアのRTOは、バックアップを復元するのに要する時間に左右されます。バックアップのサイズ、ストレージの速度、復元プロセスの複雑さなどによって変動し、一般的には数時間から数日に及びます。
  • RPO:バックアップ&リストアのRPOは、バックアップ間隔によって決まります。定期的に取得していれば、最後に成功したバックアップから災害発生時点までの時間がRPOとなります。

2. パイロットライト

  • RTO:パイロットライト戦略は、最小構成の環境をあらかじめクラウドで動かしておくことでダウンタイムを最小化します。RTOは比較的短く、環境のスケールアップに要する時間に応じて、数分から数時間程度です。
  • RPO:パイロットライトのRPOは、本番環境からクラウド上の最小環境へのデータレプリケーション頻度によって決まります。状況により異なりますが、通常は数分から数時間以内に収まります。

3. ウォームスタンバイ

  • RTO:ウォームスタンバイではシステムがすでに稼働しているため、パイロットライトよりもRTOが短くなります。スケーリングや同期処理の内容に応じて、通常は数分から数時間の範囲です。
  • RPO:ウォームスタンバイのRPOは、本番環境とクラウド上のスタンバイ環境間のデータレプリケーションまたは同期の頻度で決まります。パイロットライトと同様、通常は数分から数時間以内です。

4. マルチサイト

  • RTO:マルチサイト戦略は、workloadsを複数のサイトまたはAWSリージョンで同時稼働させることで、高可用性と高速なフェイルオーバーを実現します。災害時にはトラフィックが代替サイトへ即座にリダイレクトされるため、RTOは非常に短く、数秒から数分単位で計測されることもあります。
  • RPO:マルチサイトのRPOは、サイト間・リージョン間で用いるデータレプリケーション方式によって決まります。同期レプリケーションを採用していればRPOはほぼゼロに近く、データ損失は最小限に抑えられます。非同期レプリケーションでは多少の遅延が生じ、RPOは数秒から数分の範囲となります。

DR戦略の選択は、RPOとRTOの要件と整合させるのが理想です。コスト、複雑さ、DR要件のバランスをいかに取るかがポイントになります。データ損失(低RPO)と復旧時間(低RTO)を徹底的に小さくする戦略は、複雑かつ高コストになりがちですが、データ損失やダウンタイムが事業に大きなインパクトを与えるworkloadsには欠かせません。逆に重要度の低いworkloadsであれば、RPOやRTOにある程度余裕を持たせた、シンプルでコスト効率の高い戦略でも十分です。

ディザスタリカバリに役立つAWSの主要サービス

AWSは、効率的かつ効果的なDRを支える多彩なサービスを揃えています。ここでは代表的なものを紹介します。

AWS Elastic Disaster Recovery: インフラのレジリエンスを確保するためのソリューションです。インフラ障害やアプリケーション障害など、さまざまなインシデントからの自動復旧を実現します。ブロックレベルの継続的なデータレプリケーションにより、RPOを数秒単位に抑えられるのが特長です。さらに、AWS環境内のコスト効率に優れたステージングエリアへ継続的にデータをレプリケーションするため、リソース消費を効率的に最小化できます。マシン変換とオーケストレーションの自動化により、RTOも数分単位まで短縮可能です。

AWS Backup:AWS Backupは、EBS、RDS、DynamoDB、EFS、AWS Storage Gatewayなど複数のAWSサービスを横断して、バックアップ処理を簡素化・自動化する一元管理サービスです。統合により運用の煩雑さが軽減され、一貫したバックアップが確保されるため、堅牢なDR戦略に大きく寄与します。バックアップの頻度や保持期間を定めたポリシーをまとめたバックアッププランも作成でき、バックアップをさらに自動化してデータ損失リスクを抑えられます。本サービスはRPO・RTO目標の達成にも重要な役割を果たします。定期的にバックアップをスケジューリングすることで許容データ損失量(RPO)を小さくでき、AWS Backupの復元機能を使えばデータ損失後の復旧時間(RTO)も短縮できます。

Amazon S3 クロスリージョンレプリケーション: 異なるAWSリージョンのバケット間で、オブジェクトを自動かつ非同期にコピーする機能です。DRシナリオにおけるクロスリージョンレプリケーション(CRR)の役割は、リージョン規模の障害が起きてもデータの可用性と耐久性を維持することにあります。元のロケーションでの災害の影響を受けない別の地理的場所に、完全に複製されたデータのバックアップを保持することで、これを実現します。

Amazon RDS: クラウド上でリレーショナルデータベースのセットアップ、運用、スケーリングを容易にするサービスです。RDSは自動バックアップ、データベーススナップショット、クロスリージョンリードレプリカに加え、一部のデータベースではDR機能も備えており、災害後にデータベースを迅速に復旧するためのDRに活用できます。

Amazon Route 53: DRの観点で見たRoute 53の最大の特長は、可用性100%のSLA(サービスレベルアグリーメント)です。この保証により、サービスが常に稼働し、アプリケーションのインフラへ信頼性の高いルーティングを提供します。ヘルスチェックとDNSフェイルオーバー機能も、DRに大きく貢献するポイントです。Route 53はヘルスチェックを通じて、アプリケーションとそのコンポーネントの状態を継続的に監視します。特定のAWSリージョンで障害や異常を検知すると、別のリージョンの正常なリソースへ自動的にトラフィックを切り替えます。このDNSレベルのフェイルオーバーにより、リージョン全体がダウンしてもアプリケーションは利用者に提供され続けます。障害の早期検知と迅速な対応を可能にすることで、Route 53のヘルスチェックとDNSフェイルオーバーは堅牢なDR戦略を支え、ダウンタイムを抑えながらアプリケーションの高可用性を維持します。

AWS Glacier: データのアーカイブ向けに設計された低コストのストレージサービスです。DRにおいては、アクセス頻度の低いデータのバックアップを保管するためのコスト効率に優れた選択肢となります。災害発生時にデータを取り出すことは可能ですが、Amazon S3に比べて取り出しに時間がかかる点には注意が必要です。

AWS CloudFormation: AWSクラウド環境におけるリソースのプロビジョニングと管理を自動化できるサービスです。CloudFormationテンプレートを使えば、Infrastructure as Code(IaC)の形でインフラを定義・展開できます。DRの場面では、テンプレートを利用して別リージョンに素早くインフラを再構築でき、復旧時間の短縮と環境間の整合性確保に役立ちます。なお、これらのテンプレート自体もS3クロスリージョンレプリケーションでDR用リージョンへ複製しておき、必要なときに確実にアクセスできるようにしておくことが重要です。

こうした主要サービスを組み合わせてDR戦略に組み込むことで、企業は堅牢かつスケーラブルで最適化された仕組みを整え、災害発生時にも重要なデータとアプリケーションを確実に復旧できるようになります。

プロアクティブなディザスタリカバリテスト

Netflixは2010年代初頭、クラウド移行の取り組みの一環として、レジリエンステストツール「Chaos Monkey」を導入しました。Chaos Monkeyはインスタンスやサービスをランダムに停止させ、潜在的なシステム障害をシミュレートすることで、重大な障害発生時にシステムがどう振る舞うかを把握する貴重な知見をもたらします。このアプローチは、サービス停止を未然に防ぐためにシステム障害を能動的に発見・修正する分野「カオスエンジニアリング」の発展へとつながりました。Chaos Monkeyとカオスエンジニアリングは、システムの反応や復旧プロセスを評価する手段として、DRにおいて重要な役割を担います。障害シナリオを管理されたテスト環境で検証することで、DR計画の弱点や抜け漏れを洗い出し、必要な調整を行えます。当初は複雑さが増すものの、システムの脆弱性を理解してより堅牢なシステムを構築できるようになるため、組織の備えは大きく強化されます。

もう1つのツールであるAWS Fault Injection Simulator(FIS)は、AWSリソースに対して制御された障害注入実験を可能にし、アプリケーションのレジリエンスを高めます。サーバー停止やAPIスロットリングといった障害を意図的に起こし、システムの反応を観察することで、潜在的な弱点に関する洞察を得られます。DRの観点では、FISはシステムの脆弱な部分を特定する助けとなり、開発者がサービス停止を引き起こす前に対処できるよう後押しします。災害を想定した障害注入実験を通じて、チームは管理された条件下で復旧手順を評価・改善でき、その結果としてDR計画はより強固になり、システムのレジリエンスも向上します。実際の災害時にサービスが中断するリスクを大きく減らすことができるのです。

DoiTの知見でディザスタリカバリを最適化

ディザスタリカバリの分野で、DoiTは計画立案とコンサルティングのサービスを提供しています。経験豊富なクラウドアーキテクトのチームが、お客様の事業に合わせた堅牢なDR計画の策定をサポートします。AWSサービスとインフラに関する深い知見をもとに、ベストプラクティス、復旧手順、最適な構成についてご提案し、workloadsのレジリエンス向上をご支援します。

DR計画は、単にバックアップの仕組みを用意することにとどまりません。事業運営を深く分析し、重要なサービスを見極め、許容できる復旧ポイントと復旧時間を定義する作業が伴います。私たちのチームはこのプロセス全体を伴走し、事業継続の目標と整合した包括的なDR戦略の実現をお手伝いします。

計画が想定どおりに機能するか、そして本番でチームが動けるかを確かめるには、定期的なテストが不可欠です。私たちはテストの設計を支援し、潜在的なギャップや改善余地の特定をお手伝いします。万一、DRを発動する局面で問題が起きた場合も、DoiTがしっかりと寄り添います。こうした場面では1分1秒が勝負どころであることを、私たちは十分に理解しています。チームは迅速かつ的確に対応する体制を整えており、サービスの復旧とダウンタイムの最小化を支援します。トラブルシューティングであれ技術面のアドバイスであれ、危機を乗り越えられるよう全力でサポートします。私たちの関与は復旧で終わりません。復旧後には、事象の振り返り、復旧プロセスの有効性の評価、技術的な助言とベストプラクティスの提供までお手伝いします。

DoiTは、お客様の事業継続とレジリエンスを支えるパートナーでありたいと考えています。計画策定とテストから復旧、そしてそこから得られる学びまで、DRのすべての工程に伴走します。

まとめ

ディザスタリカバリは、事業戦略において「あればよい」要素ではなく、想定外の事態に直面したときに継続性を支える不可欠な構成要素です。AWSの強力さと柔軟性を活かせば、ダウンタイムとデータ損失を最小限に抑える堅牢なDR計画を構築でき、災害が起きても素早く事業を再開できます。専門家のコンサルティングを受ければ、システムに潜む脆弱性を見極め、それに見合ったAWSサービスのご提案を受けられます。こうした知見は、時間と労力の節約だけでなく、よくある落とし穴の回避や、より堅牢で効果的なDR計画の実現にもつながります。AWSをDRプラットフォームとして、DoiTを信頼できるパートナーとしてお選びいただくことで、混乱に耐え、継続性を保てるという確かな自信を得ていただけます。私たちは、レジリエンスとセキュリティに優れたクラウド環境でお客様の事業を強化し、潜在的な逆境を、事業のレジリエンスを示す好機へと変えるお手伝いに尽力します。

AWSとDoiTで備えるディザスタリカバリ戦略入門ガイド