はじめに
DR対策（Disaster Recovery：災害復旧）とは、 災害が発生した場合に、迅速にシステムを復旧させるための対策・体制を指します。 具体的な災害としては、地震・台風などの自然災害や、不正アクセスによるシステム障害などが想定されます。
自然災害や不正アクセス等によるシステム障害のリスクが高まっている現在、 DR対策はクラウド環境構築における基本となりつつあります。
ここではAWSにおけるDR対策の基本パターンを紹介いたします。
AWSプラクティス案
出典：Amazon Web Servicesブログ 組織事業継続性が求められる基幹システムの DR 戦略
1. バックアップリストア方式
概要
定期的にデータのバックアップを取り、障害が発生した場合に別のリージョンにバックアップからリストアして復旧する方式。
メリット
- コストが低い
バックアップのみを保持するため、常時稼働するインフラが必要ない。
ストレージやデータ転送にかかるコストがメインとなる。 - 複雑さが少ない
システム全体の稼働を二重に維持する必要がないため、システム運用がシンプル。 - 簡単な管理
アクティブなシステムが1つだけで、バックアップ管理が容易。
デメリット
- 復旧に時間がかかる
障害が発生してからバックアップからリストアし、システムを再構築するまでに時間がかかる。 - ダウンタイムが長くなる
障害が発生してからリストア完了までシステムが停止しているため、ダウンタイムが長くなる可能性が高い。 - データの損失リスク
バックアップのタイミング次第では、直前のデータが失われる可能性がある（RPOが長くなる）。
2．パイロットライト方式
概要
メインとなるリージョンでインフラが稼働しており、別リージョンには最低限のインフラ（特にデータベースや重要なサービス）だけを用意しておく方式。 障害発生時には、別リージョンのリソースを拡張して本格的なサービス運用に切り替える。
メリット
- コストが低い
別リージョンに最小限のリソースしか稼働させないため、マルチサイトやウォームスタンバイよりもコストが低い。 - 復旧が比較的速い
重要なシステムやデータベースは常に準備されているため、バックアップリストアよりも速く復旧できる。 - ダウンタイムがある程度短縮
バックアップリストアに比べると、必要なリソースをすぐにスケールアウトできるため、復旧にかかる時間が短縮される。
デメリット
- 一部の手動操作が必要
フル稼働させるために手動でリソースをスケールアップする作業が必要で、完全に自動化しない場合、多少の運用作業が発生する。 - 短いが、ダウンタイムが発生
パイロットライト方式でも、障害時にリソースを拡張するまでの短期間のダウンタイムが発生する。 - 運用の複雑さ
フェイルオーバー時にリソースの拡張やデプロイを適切に行うための運用が必要。
3．ウォームスタンバイ方式
概要
メインとなるリージョンで通常運用を行い、別リージョンには本番環境に近い状態でリソースを一部稼働させておく方式。 別リージョン側では最小限のスケールでサービスが動いているため、障害時にはすぐにリソースをフル稼働させて本番環境に切り替える。
メリット
- 復旧が迅速
パイロットライト方式よりも多くのリソースが既に稼働しているため、すぐにリソースをスケールアップして切り替えることが可能。復旧時間が短くなる。 - ダウンタイムが短い
リソースは常時稼働しているため、ダウンタイムが短く抑えられる。 - コストと可用性のバランス
完全なマルチサイト方式ほど高コストではないが、バックアップリストアやパイロットライトよりも速い復旧が可能で、可用性の確保が容易。
デメリット
- コストが中程度
リソースを一部稼働させているため、パイロットライトやバックアップリストアよりもコストがかかる。ただし、完全なホットスタンバイ（マルチサイト）よりは低コスト。 - 運用の複雑さ
スタンバイ中のリソースを適切に維持し、障害時にスムーズにスケールアップできるようにする必要があるため、一定の運用管理が求められる。
4．マルチサイト（ホットスタンバイ）方式
概要
メインとなるリージョンと別リージョンの両方にシステムを配置し、片方が障害を起こした際にはもう一方に即時切り替える方式。
メリット
- ダウンタイムが最小限
片方のリージョンがダウンした際に、もう片方に即座に切り替えることができ、ダウンタイムがほぼ発生しない（フェイルオーバーが速い）。 - 即時復旧
システムは常に両方のリージョンで稼働しているため、サービスの可用性が高く、復旧時間がほとんどかからない。 - データの即時同期
通常はリアルタイムでデータが複製されるため、データの損失リスクがほとんどない（RPOが短い）。
デメリット
- コストが高い
両リージョンでインフラを稼働させるため、二重のコストがかかる。特に計算リソースやデータの複製にかかる費用が増大する。 - 運用が複雑
両方のリージョンでシステムが動いているため、システムの管理が複雑になり、インフラやネットワーク設定、データベースの同期に細心の注意が必要。 - 複雑なフェイルオーバー設定
自動フェイルオーバーの設定や、データの整合性維持が難しい場合がある。
まとめ
各パターンの比較まとめです。
ダウンタイムやリスクの少なさ、復旧の速さに比例してコストや運用の複雑さが上がるため、障害発生時の影響度に応じたパターンの採用が重要です。
以上、よろしくお願いいたします。
