災害復旧
大規模障害や災害からシステムを復旧するための計画と仕組み
災害復旧とは
災害復旧 (Disaster Recovery, DR) は、大規模障害 (リージョン障害、データセンター障害) からシステムを復旧するための計画と仕組みである。RPO (目標復旧時点) と RTO (目標復旧時間) で要件を定義する。詳細は「RPO/RTO」を参照。
DR 戦略
DR 戦略を以下にまとめる。
| 戦略 | RTO | コスト | 説明 |
|---|---|---|---|
| Backup & Restore | 数時間 | 最低 | バックアップから復元 |
| Pilot Light | 数十分 | 低 | 最小限のリソースを常時稼働 |
| Warm Standby | 数分 | 中 | 縮小版のシステムを常時稼働 |
| Multi-Site Active/Active | 秒〜分 | 最高 | 複数リージョンで同時稼働 |
AWS での DR 構成
AWS での DR 構成の流れを図で示す。
プライマリ (ap-northeast-1) セカンダリ (us-east-1)
┌──────────────────┐ ┌──────────────────┐
│ CloudFront │ │ CloudFront │
│ API Gateway │ │ API Gateway │
│ Lambda │ │ Lambda │
│ DynamoDB │ ──────→ │ DynamoDB │
│ (Global Tables) │ レプリ │ (Global Tables) │
│ S3 │ ──────→ │ S3 │
│ (Cross-Region) │ ケーション│ (Cross-Region) │
└──────────────────┘ └──────────────────┘
サーバーレスの DR 優位性
サーバーレスの DR 優位性を以下にまとめる。
| 観点 | サーバーレス | サーバーベース |
|---|---|---|
| インフラの復旧 | 不要 (マネージド) | EC2/RDS の起動が必要 |
| データの復旧 | DynamoDB Global Tables | RDS のリードレプリカ昇格 |
| コスト (待機時) | ほぼゼロ | 常時稼働コスト |
| 切り替え | Route 53 のフェイルオーバー | DNS + インフラ起動 |
DR テスト
DR テストを以下にまとめる。
| テスト | 頻度 |
|---|---|
| バックアップの復元テスト | 月 1 回 |
| フェイルオーバーテスト | 四半期 1 回 |
| 全体 DR 訓練 | 年 1 回 |
災害復旧の理解を深めるには関連書籍が参考になる。
この記事は役に立ちましたか?
関連用語
RPO / RTO
災害復旧の目標指標で、許容できるデータ損失量 (RPO) と復旧時間 (RTO) を定義する
フェイルオーバー
障害発生時にスタンバイシステムへ自動的に切り替え、サービスの継続性を確保する仕組み
Blue/Green デプロイ
2 つの同一環境を用意し、トラフィックを切り替えることでゼロダウンタイムデプロイを実現する手法
サーバーレス
サーバーの管理をクラウドプロバイダーに委ね、コードの実行に対してのみ課金されるコンピューティングモデル
テスト戦略
プロジェクトのテスト種類、範囲、自動化レベルを体系的に定義する計画
ペットと家畜
サーバーを個別に管理する「ペット」から、使い捨て可能な「家畜」へ移行するインフラ運用の考え方
関連する記事
障害対応の夜に思い出す、あの本の 1 ページ
本番障害の緊迫した場面で、過去に読んだ技術書の知識が助けてくれた経験はありませんか。「いつか役立つ」知識が「今この瞬間」に変わる読書の価値を考えます。
テスト本ガイド - テスト設計を学べる技術書の選び方
テストの書き方からテスト戦略まで学べる技術書の選び方を紹介。テストピラミッド、TDD の正しい読み方、テストの ROI の考え方を解説します。
バグを生むのは知識不足ではなく想像力不足である
バグの多くは、コードを書いた時点で「こういうケースもありうる」と想像できなかったことが原因です。想像力を鍛える読書法と、エッジケースへの感度を高める方法を解説します。