概要
クラウドサービスを利用するにあたって、障害が生じた際にどれだけ迅速に復旧が実行できる構成が取れているか、という観点が重要だと言われている(Design for Failure)。
AWSのホワイトペーパーで取り上げられている以下の4つの DR 対策をまとめる。
- バックアップとリストア
- パイロットライト
- ウォームスタンバイ
- マルチサイト(ホットスタンバイ)
注意されたい事項
記述される構成は一例であるということ。
DNS のフェイルオーバーに関しては省略する。
本番環境は On-premise または Region 1, スタンバイ環境は Region 2 とする。
バックアップとリストア
準備段階においては、Storage Gateway のボリュームゲートウェイ(Gateway-cached Volumes)を使用して On-premise 環境から S3 にバックアップを取る。
復旧段階においては、AWS 環境で EC2 インスタンスを立ち上げ、取得済みのバックアップ(ここでは EBS スナップショット)から EBS ボリュームを復元し、インスタンスへアタッチする。
バックアップとリストアはバックアップを取得しておいて、障害時にはリソースを展開し、データをバックアップから復旧させる
手法。
パイロットライト
pilotlight は種火という意味。ガスコンロを使用するときの "カチカチカチ" って鳴るあれを思い出すと良い。pilotlight 自体は小さな火であるが、ガスに点火することによって一気に炎が広がっていく。
この様子を障害復旧の構成に例えたものである。
準備段階においては、本番環境で起動しているインスタンスの AMI をスタンバイ環境に保存し、DB のリードレプリカを配置しておく。
復旧段階においては、AMI からインスタンスを起動、リードレプリカをメイン DB に昇格させることで障害時の対応を行う。
パイロットライトは復旧リージョンで最小限の構成を行っておいて、障害時にはそれらに基づいてリソースを展開して復旧を図る
手法。
ウォームスタンバイ
準備段階においては、スタンバイ環境で本番環境と同様の構成でリソースを配置し起動しておく。ただしこのとき、リソースのスペックは本番環境に比べて低いものを配置しておく。
復旧段階においては、トラフィックをスタンバイ環境に向け、本番環境のアクセス数に対応できるように、スケールアウト・スケールアップを行う。
ウォームスタンバイはパイロットライトの拡張版で、低スペックのリソースを配置して起動しておき、障害時にはそれらのリソースのスケールアップ・スケールアウトを行って復旧を図る
手法。
マルチサイト(ホットスタンバイ)
準備段階において、スタンバイ環境でリソースを本番環境と同様の構成かつスペックで配置し起動しておく。
復旧段階においては、トラフィックをスタンバイ環境に向ける。
マルチサイトはウォームスタンバイの拡張版で、本番環境と同じ構成をスタンバイ環境で取っておき、障害時に迅速に復旧を図る
手法。
参考