LASSIC Media らしくメディア
クラウドのDR(災害復旧)構成を外注構築
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- クラウドDR(災害復旧)構成は、RTO(目標復旧時間)とRPO(目標復旧時点)に応じてバックアップ＆リストア・パイロットライト・ウォームスタンバイ・マルチサイトから方式を選びます。
- AWS・Azure・Google Cloudは、リージョン間レプリケーションとフェイルオーバー/フェイルバックの仕組みを公式に用意しています。
- 構成の複雑さとコストは方式によって変わるため、内製と外注の判断軸を整理しておく必要があります。
目次
- クラウドDR(災害復旧)構成とは、RTO/RPOに応じて復旧環境を選ぶ仕組み
- RTO(目標復旧時間)とRPO(目標復旧時点)——復旧の速さと許容できるデータ損失を決める指標
- バックアップ＆リストア・パイロットライト・ウォームスタンバイ・マルチサイト——4つのDR方式
- リージョン間レプリケーションの仕組み——非同期複製で複数リージョンにデータを持たせる
- フェイルオーバーとフェイルバック——切替の判断と復旧後に戻す手順
- DR訓練を定期的に実施する——想定した復旧経路が機能しない事態を防ぐ
- 内製と外注の分かれ目——構成の複雑さと運用体制の工数で判断する
- まとめ：クラウドDR構成で押さえる3つの判断軸
- よくある質問
クラウドDR(災害復旧)構成とは、RTO/RPOに応じて復旧環境を選ぶ仕組み
クラウドDR(災害復旧)構成とは、RTO(目標復旧時間)とRPO(目標復旧時点)に応じて復旧環境を用意する構成です*1。方式はバックアップ＆リストア・パイロットライト・ウォームスタンバイ・マルチサイトの4種類に分かれます*1。方式が変わればコストと復旧の速さも変わるため、要件に応じた選択が欠かせません。
AWSは自社のホワイトペーパーで、クラウド上のディザスタリカバリ戦略を大きく4つに区分しています*1。低コスト・低複雑性のバックアップ手法から、複数のアクティブリージョンを使う手法まで、段階的な選択肢として整理されている点が特徴です*1。
どの方式を選ぶかは、想定する災害の範囲によっても変わってきます。単一データセンターの障害であれば、バックアップ＆リストアで足りる場合もあります*1。リージョン規模の障害や規制対応が必要な場合は、パイロットライト以降の方式を検討することになります*1。
RTO(目標復旧時間)とRPO(目標復旧時点)——復旧の速さと許容できるデータ損失を決める指標
RTOとは、災害発生からシステムが復旧して利用可能になるまでに許容できる時間の上限を指す指標です*2。一方のRPOは、災害発生時に許容できるデータ損失の範囲を、時間の長さの上限で示す指標です*2。
RTOが4時間であれば、4時間以内に業務を復旧させる必要があるという意味になります。RPOが1時間であれば、直前1時間分のデータ損失までは許容するという意味です*2。この2つの数値は、事業への影響度から逆算して設定します。
RTOとRPOを短く設定するほど、常時稼働させるリソースが増え、運用コストと構成の複雑さも増していきます*2。目標を数値で固定する前に、業務が止まった場合の影響範囲を洗い出しておく必要があります。
Google Cloudのディザスタリカバリ計画ガイドは、RTOをアプリケーションがオフラインになってよい時間の上限と位置づけています*5。RPOについても、重大な障害でデータが失われてよい時間の上限としており、AWSと近い考え方です*5。
バックアップ＆リストア・パイロットライト・ウォームスタンバイ・マルチサイト——4つのDR方式の実装レベル
AWSが整理する4つの方式は、コストと復旧の速さのトレードオフを段階的に示したものです*1。バックアップ＆リストアはデータのみを複製し、障害発生時に基盤とアプリケーションを再構築する方式で、4方式の中では最も低コストな位置づけです*1。
パイロットライトは、データベースなどのコア基盤を常時稼働させ、アプリケーションサーバーは起動を止めた状態で待機させる方式です*1。障害発生時にアプリケーションサーバーを起動して復旧するため、バックアップ＆リストアより短時間での復旧が見込めます*1。
ウォームスタンバイは、縮小構成の環境を常時稼働させておき、障害発生時にスケールアウトして本番規模に戻す方式です*1。パイロットライトとの違いは、常時トラフィックを処理できる状態にあるかどうかにあります*1。
マルチサイト(アクティブ/アクティブ)は、複数リージョンで同時に本番トラフィックを処理する方式です*1。実装と運用の難易度は4方式の中で最も高くなりますが、リージョン障害時の復旧時間を近似的にゼロへ近づけられます*1。
| 方式 | 概要 | RTOの傾向 | コストの傾向 |
|---|---|---|---|
| バックアップ＆リストア | データのみ複製し、障害時に基盤・アプリを再構築*1 | 4方式の中で最も長い | 4方式の中で最も低い |
| パイロットライト | コア基盤は常時稼働、アプリ部分は起動待機*1 | バックアップ＆リストアより短縮 | 中程度 |
| ウォームスタンバイ | 縮小構成の環境が常時稼働しスケールアウトで復旧*1 | パイロットライトより短縮 | パイロットライトより高い |
| マルチサイト(アクティブ/アクティブ) | 複数リージョンで同時稼働しトラフィックを振り分け*1 | 4方式の中でほぼゼロに近づく | 4方式の中で最も高い |
表の通り、復旧の速さを追求するほどコストと構成の複雑さが増える関係にあります*1。自社の業務でどこまでの速さが必要かを見極めることが、方式選定の出発点になります。
リージョン間レプリケーションの仕組み——非同期複製で複数リージョンにデータを持たせる
パイロットライト以降の方式では、リージョン間でのデータレプリケーションが前提になります*1。AWSはAmazon S3のクロスリージョンレプリケーションなど、非同期でのクロスリージョン複製機能を複数のサービスで提供しています*1。データベース向けには、Amazon Auroraグローバルデータベースのような機能も用意されています*1。
Amazon Auroraグローバルデータベースの場合、セカンダリリージョンへの複製は通常1秒未満のレイテンシーで行われると説明されています*1。障害発生時には、セカンダリリージョンを1分未満で読み書き可能な状態に昇格できるとAWSは述べています*1。
Azure Site Recoveryも、Azureリージョン間でAzure VMを複製する機能を提供しています*4。継続的なレプリケーションに対応し、Hyper-V環境では最短30秒間隔での複製が可能だとマイクロソフトは説明しています*4。
レプリケーション方式を選ぶ際は、データの整合性も検討課題になります。マルチサイト構成で複数リージョンへの書き込みを許可する場合、書き込み先をどう振り分けるかという設計判断が新たに発生します*1。
フェイルオーバーとフェイルバック——切替の判断と復旧後に戻す手順
フェイルオーバーとは、障害発生時に処理を主系から副系のリージョンへ切り替える操作を指します*4。フェイルバックは、主系の環境が復旧した後に、処理を副系から主系へ戻す操作です*4。
AWSはフェイルオーバーの経路として、Amazon Route 53のヘルスチェックによる自動切替を挙げています*1。手動での切替には、AWS Application Recovery Controllerのような仕組みも利用できます*1。誤検知による不要な切替を避けたい場合は、切替の起点を人が判断する方式を選ぶという考え方もあります*1。
Azure Site Recoveryは、計画的な停止であればデータ損失なしのフェイルオーバーが可能だとしています*4。想定外の障害でも、複製の頻度に応じた範囲にデータ損失を抑えられるとされています*4。復旧計画の中で対象マシンをグループ化し、順序立てて切替を実行する機能も備えています*4。
フェイルオーバーだけを整備してフェイルバックの手順を用意していない場合、主系の復旧後も副系での運用が長引きます*4。副系での運用コストは主系より高くなりやすいため、フェイルバックの手順も事前に整えておく必要があります。
DR訓練を定期的に実施する——想定した復旧経路が機能しない事態を防ぐ
AWSのホワイトペーパーは、DR実装を検証し、RTOとRPOを満たせるかを確認するため、フェイルオーバーを定期的にテストする必要があると述べています*3。頻繁に実行しない復旧経路は、実際の障害時に機能しない可能性があるとも指摘しています*3。
例えば、読み取り専用のセカンダリデータストアを障害時の書き込み先として想定している場合を考えます。その切替を頻繁にテストしていないと、想定していた容量やサービスクオータが実際には不足している事態が起こり得ます*3。テストしていない復旧経路は、機能する保証がないと考えるべきです*3。
Azure Site Recoveryは、進行中のレプリケーションに影響を与えずにDR訓練を実行できる機能を備えています*4。本番環境への影響を避けながら訓練を繰り返せる点は、訓練の実施頻度を確保するうえで重要な要素です。
DR訓練では、リージョン構成のドリフト(設定のずれ)も点検対象になります。AMI(Amazon Machine Image、EC2インスタンス起動用のディスクイメージ)が最新の状態を保っているかは、点検すべき項目の一つです。サービスクオータの確認とあわせて、AWS Configなどで継続的に監視する方法も紹介されています*3。
内製と外注の分かれ目——構成の複雑さと運用体制の工数で判断する
クラウドDR構成を内製で担うには、複数領域の知識が必要になります。RTO/RPOの要件定義、リージョン間レプリケーションの設計、フェイルオーバー/フェイルバックの切替手順、DR訓練の運用体制などです*1*3。
対象がバックアップ＆リストアのみで、リージョン単位の障害を想定しないのであれば、既存のインフラ運用担当者が兼務で対応できる場合もあります。一方でパイロットライト以降の方式では、レプリケーション設計とフェイルオーバー手順の両方を継続的に検証できる体制が前提になります*1。
専門パートナーに委託する場合は、依頼範囲の広さが選定の分かれ目になります。RTO/RPOの要件整理から方式選定、レプリケーション構成、DR訓練の定例化までを一括して依頼できるかを確認します。内製では、通常業務と並行してDR訓練を継続する時間の確保が課題になりやすいでしょう。
。対象システムの構成やリージョン障害への要件によって、必要な工数は変わってきます。現状の構成を診断したうえで、内製・外注の切り分けを検討することが実務的です。
まとめ：クラウドDR構成で押さえる3つの判断軸
本稿ではクラウドDR(災害復旧)構成の仕組みを、AWS・Azure・Google Cloudの公式情報をもとに整理しました。要点は3つに集約できます。第一に、方式はバックアップ＆リストア・パイロットライト・ウォームスタンバイ・マルチサイトの4段階に整理できます*1。コストと復旧の速さは、トレードオフの関係にあります。第二に、RTOとRPOという2つの指標を先に定めることが、方式選定の出発点になります*2。第三に、DR訓練を定期的に実施しなければ、想定していた復旧経路が実際には機能しない可能性があります*3。
よくある質問
RTOとRPOはどのように決めればよいですか。
業務が停止した場合の影響範囲を先に洗い出し、そこから許容できる停止時間(RTO)とデータ損失の範囲(RPO)を逆算して決めます*2。数値を短くするほどコストと構成の複雑さが増えるため、事業インパクトとのバランスで設定することが大切です*2。
バックアップだけではDR対策として不十分ですか。
単一データセンターの障害であればバックアップ＆リストアで対応できる場合もあります*1。ただしリージョン規模の障害を想定する場合は、パイロットライトやウォームスタンバイなど、より復旧の速い方式の検討が必要になります*1。
DR訓練はどのくらいの頻度で実施すればよいですか。
AWSは、頻繁にテストした復旧経路だけが実際の障害時に機能すると指摘しており、まれにしか実行しない経路は避けるべきだとしています*3。具体的な頻度は、事業への影響度に応じて社内で設定する必要があります。
フェイルオーバーとフェイルバックの違いは何ですか。
フェイルオーバーは、障害発生時に処理を主系から副系のリージョンへ切り替える操作です*4。フェイルバックは、主系の環境が復旧した後に、処理を副系から主系へ戻す操作を指します*4。
クラウドDR構成の外注を検討する際、何を確認すればよいですか。
RTO/RPOの要件をどこまで一致させて設計するか、レプリケーション方式とリージョンの組み合わせ、DR訓練を定例で実施する体制の3点をまず確認します。契約前に、テスト環境での切替確認までを委託範囲に含められるかをすり合わせておくと、切替後のトラブルを抑えやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：AWS「Disaster Recovery of Workloads on AWS: Disaster recovery options in the cloud」（AWS Whitepapers）（https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html）
- *2 出典：AWS「Disaster Recovery of Workloads on AWS: Recovery Time Objective and Recovery Point Objective」（AWS Whitepapers）（https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/recovery-time-objective-and-recovery-point-objective.html）
- *3 出典：AWS「Disaster Recovery of Workloads on AWS: Testing disaster recovery」（AWS Whitepapers）（https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/testing-disaster-recovery.html）
- *4 出典：Microsoft「About Azure Site Recovery」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-overview）
- *5 出典：Google Cloud「Disaster recovery planning guide」（Google Cloud Architecture Center）（https://docs.cloud.google.com/architecture/dr-scenarios-planning-guide）
