AWS のホワイトペーパー Using AWS for Disaster Recovery を読み解いてみます。
(注:このホワイトペーパーは既存のクラウド上でないシステムの存在を前提にしているフシがある)
キーワード
一般用語
- Recovery Time Objective, RTO
- 災害から回復までの所要時間とサービスレベルの目標。 objective(目標)であって mandate(指令)ではないところがポイント。 RTOを満足しない作戦をとることもありうるし、その場合でもRTOは目標として堅持すべき。
- Recovery point objective, RPO
- 許容可能なデータロス期間の上限目標。 例えば、RPOとして4時間を設定したとすると、日次バックアップは適切な手段ではないことになる。
AWS用語
- リージョン
- 国くらいの粒度の地域単位。AWSでは往々にしてリージョンをまたぐような操作に壁がある。
- アベイラビリティ・ゾーン, AZ
- リージョンの中に複数個存在。地理的に離れていて独立性が高い、ということになっている。 普段目にするのは論理AZであって物理AZではないため、アカウントをまたぐとゾーン名が一緒でも物理的には違うなどということがあるらしい。 (ソース)
- CloudFormation
- インスタンスの作成などをテンプレート化して自動化するための仕掛け。(今のところ、UVでこれを活用したことはない)
災害復旧シナリオ例
Backup and Restore
昔なら定期的にテープにフルダンプをとってオフサイト送り、となるところ。S3がテープメディアの代わりに。EBSのスナップショットも有効。
バックアップで話は終わりじゃない!
リストアまでがシナリオです。- バックアップに使うツールは適切か?
- データ保持(期間)のポリシーは適切か?
- セキュリティ対策は?
- 作ったバックアップ からの復元のテストを定期的に!
Pilot Light(種火)
最重要なコア要素をAWSで動かすようにする。災害時にはこのコア要素に取り巻きを立て直すことで復旧とする。
準備
データはパイロットライト系統にレプリケーション。OSのようなあまり更新頻度の高くないようなものは定期的にAMI(マシンイメージ)を更新しておく。
復旧
水平展開によるスケーリングの方がオススメ。インスタンスタイプを上位に変更してのスケールアップ手法もとれないことはない。復旧が一段落したら、冗長性を速やかに取り戻すべし。
キーポイント
- アプリケーションサーバのAMIを作って、そこからすぐ立ち上げられるように
- 必要に応じてスケールアップ
- 災害時はDNSをいじってAWS側を向くように
- AMIベースでない要素の構成を忘れずに、理想的には自動化
Warm Standby
Pilot Light 方式の拡張。 インスタンスタイプその他を必要最小限に抑えた一式をAWSに用意する方式。災害時にはこちらをスケールアップして負荷を捌く。
Multi-Site
平時はオンプレミスとAWS上のシステムを同時に動かしておく方式。データレプリケーションの方式
- 同期(Multi-AZな AWS RDB はこの構成になる)
- 非同期(バックアップ用や参照系のユースケースならこれで充分なことが多い)
0 件のコメント:
コメントを投稿