【ITニュース解説】Four Disaster Recovery (DR) strategies in AWS explained

災害復旧（DR）は、システムが予期せぬ障害や災害に見舞われた際に、その機能を速やかに回復させ、事業の継続を保証するための重要な戦略である。自然災害、大規模なシステム障害、サイバー攻撃など、様々な原因でシステムが停止する可能性があるため、事前に適切なDR戦略を準備しておくことは、現代のITシステム運用において不可欠だ。このDR戦略を考える上で特に重要となる二つの指標がある。それがRTO（Recovery Time Objective：目標復旧時間）とRPO（Recovery Point Objective：目標復旧時点）である。RTOは、システムが停止してから、どのくらいの時間でサービスを復旧させるべきかを示す目標時間だ。RPOは、システム障害が発生した際に、どの時点までのデータが失われることを許容できるかを示す目標時点である。これらのRTOとRPOの目標は、システムの重要度やビジネスへの影響度に応じて決定される。一般的に、RTOとRPOを短くするほど、DR対策にかかるコストは高くなる傾向がある。

AWS（Amazon Web Services）では、これらのRTOとRPOの要件に応じて、様々なDR戦略を選択できる。主要なものとして「Multi-Site（Active-Active）」「Warm Standby」「Pilot Light」「Backup & Restore」の四つが挙げられる。

一つ目の「Multi-Site（Active-Active）」戦略は、最も高度で、ダウンタイムをほぼゼロに抑えることを目的としている。この戦略では、複数の異なる地理的なリージョン（地域）に全く同じ本番環境を同時に構築し、常に両方の環境でサービスを稼働させる。例えば、世界各地で銀行システムを同時に動かし、ユーザーからのアクセスを分散させる。もし特定のリージョンで障害が発生しても、別のリージョンのシステムが即座に全ての処理を引き継ぐため、サービスは中断することなく継続される。このため、RTOとRPOは限りなくゼロに近づけることが可能だ。しかし、複数のリージョンでフルスケールの本番環境を維持する必要があるため、コストは非常に高くなる。株取引プラットフォームや航空券予約システムのように、一時的な停止も許されないミッションクリティカルなアプリケーションに最適な戦略である。

二つ目の「Warm Standby（ウォームスタンバイ）」戦略は、Multi-Siteよりはコストを抑えつつも、比較的迅速な復旧を目指す戦略である。この戦略では、メインの稼働リージョンとは別のリージョンに、縮小版の待機環境を事前に構築しておく。例えば、ECサイトのメインシステムを米国東部に置き、米国西部に最小限のサーバーとデータベースのレプリカ（複製）を動かしておく。メインサイトで障害が発生した場合、この縮小版の環境をスケールアップ（サーバーの台数を増やしたり、スペックを上げたりする）し、フルスケールのサービスを提供できるようにする。これにより、RTOは数分から数時間、RPOも数分程度の比較的短い時間に抑えられる。コストは、完全な本番環境を維持するMulti-Siteよりは低いが、待機リソースを動かし続けるため中程度となる。オンラインストアや社内基幹システムのように、ある程度のダウンタイムは許容できるが、迅速な復旧が求められるアプリケーションに適している。

三つ目の「Pilot Light（パイロットライト）」戦略は、Warm Standbyよりもさらにコストを抑えつつ、ある程度の復旧時間を許容する戦略である。この戦略では、別のリージョンに最低限の、最も重要なリソース（例えばデータベースなど）だけを稼働させておく。いわば「常夜灯」のように常に点けておく部分のみを維持する。メインサイトで障害が発生した際には、この稼働中の重要リソースを基盤として、アプリケーションサーバーやロードバランサーといった他のサービスを迅速に起動・構築し、環境全体を立ち上げる。この方法では、Warm Standbyよりも復旧までに時間がかかり、RTOは数時間から半日、RPOも比較的短い時間を目指せる。常に稼働させるリソースが少ないため、コストは低〜中程度に抑えられる。SaaSのレポートツールやビジネスインテリジェンスダッシュボードなど、コストを重視しつつも、バックアップとリストアよりは速い復旧が必要なアプリケーションに有用である。

四つ目の「Backup & Restore（バックアップとリストア）」戦略は、最もコストを抑えられるが、復旧に最も時間がかかる戦略である。この戦略では、システムのデータのみを定期的にバックアップし、別のストレージサービス（AWSであればAmazon S3など）に保存しておく。本番環境は一つだけ稼働させ、待機環境は用意しない。もしメインサイトで障害が発生した場合、バックアップデータを使って全く新しい環境を一から構築し、そこにデータをリストアしてサービスを復旧させる。例えば、アーカイブされた動画コンテンツをS3に保存しておき、プライマリサイトが失われた場合、バックアップから新しい環境を構築し、コンテンツを復元する。このプロセスには数時間から数日かかることが一般的であり、RTOは長く、RPOもバックアップの頻度によってデータ損失の度合いが変わる。そのため、コストはストレージ料金のみで済むため非常に低い。開発/テスト環境や、頻繁なアクセスを必要としないアーカイブシステム、非ミッションクリティカルなワークロードなど、復旧に時間がかかってもビジネスへの影響が少ない場合に選択される。

これらの四つのDR戦略は、RTO、RPO、コスト、そして複雑性のバランスによって最適なものが選択される。システムの特性、ビジネス要件、そして予算を考慮し、どのDR戦略が最も適切であるかを慎重に判断することが、安定したシステム運用には不可欠である。システムエンジニアを目指す上では、それぞれの戦略がどのような場面で有効であり、どのようなトレードオフが存在するのかを理解しておくことが、今後のキャリアにおいて非常に役立つ知識となるだろう。