情報システム担当者なら、誰もが一度は検討に迫られたことがあるビジネス継続性計画(Business Continuity Plan: BCP)と災害対策(Disaster Recovery:DR)。近年は必ずIT視点での対策も必要となるため、担当者としては、経営から圧力かかるわ、ユーザに負担かかるわ、お金が出て行くわで、非常に悩ましい取り組みではないでしょうか。
しかしGCPならそんな面倒も一発解決。DR環境がカンタンに実現できてしまうんです。ボタン一発でネットワークやサーバが簡単に作成できるし、本当に必要な時だけ起動すればコストはからないし、いいことづくめ。
今回は、IaaSとしてGCEを使い、10台程度のサーバーを使った比較的簡単なシナリオで、マルチリージョンのDR環境を構築してみます。
1. データ退避の災害対策（DR）シナリオ
ざっくり言って今回は「データ退避」と言われる設計パターンです。
とにかくデータのみリモートのリージョンにバックアップしておき、被災時には必要に応じてリモート側で最低限のサービス復旧も可能です。
災害対策要件
最低限の一般的なサーバ利用として以下のようなゆるめの要件を想定します。
- リージョンが丸ごと全滅してしまうような大規模災害を想定し、目標復旧時刻（Recovery Point Objective（RPO))は1日前を想定。
- 目標復旧時間（Recovery Time Objective（RTO））は1日以内程度を想定。
- 利用するサービスはIaaSのみを想定。
- メインとなるリージョンにはサーバ10台が稼働している。サーバの仕様は以下の通り。
- OS: Linux系 CPU2コア メモリ8GB HDD500GB
- 日々の差分は10GB(ディスクの2%) ※スナップショット量算出に必要
- データ同期のため、メインとバックアップリージョンは内部IPで接続したい。
このレベルの要件であれば一旦データを日時で別リージョンにさえ退避しておけば、被災時にリモートリージョンで手作業で復旧することで最低限の復旧が可能になります。
GCPにおける災害対策設計
- メインリージョンで、GCEのサーバを10台構築する。
- メインリージョンで1日1回サーバのスナップショットを取得する。
- 有事の際は、スナップショットから任意のタイミングでインスタンスを復旧する。
- プロジェクトは一つ、ネットワークはマルチリージョン設定とし、ルータでリージョン間を内部接続する。
データ退避はDRとしてはかなりライトな設計ですが、コストをかけられない企業では、落とし所としてよくありがちなシナリオでしょう。スナップショットの取得頻度を多くすればRPOは短縮出来ます（スナップショット領域費用とのトレードオフ）し、復旧手順の自動化やスクリプト化、リハーサルなどによりRTOの短縮も可能でしょう。
それ以上重厚にやるのでしたら、業務設計から、復旧目標時間や復旧目標地点の定義から、復旧リハーサルから、やることは色々ありますが、それはまた次の機会に。
2. DR環境構築手順
では早速設計シナリオに沿ってDRを構築していきましょう。
と言っても、実はGCPでやることはほとんどありません。
(1)VPCネットワーク作成時に「グローバル」を指定。
(2)用途に応じてGCEでサーバを構築します。
詳細は省略しますが、画面から普通に必要なサーバを立てていけばOKです。
(3)スナップショットを1日1回取るよう設定 ※詳細は以下URL参照
GCEのスナップショットバックアップ機能詳細とお得な使い方！
これだけ。
本当にこれだけでいいんです。
3. 被災時の手順
あまり考えたくないですが、実際に被災した際にサービス復旧が必要になった場合、どんなオペレーションが必要なのでしょうか。
こちらもGCPならカンタンです。
(1)コンソールでスナップショットを開く。
(2)スナップショットからインスタンスを作成する。
これだけ。本当にこれだけです。
そして何と！ どのリージョン、どのゾーンに対しても復旧可能！
4. AWSでの構築との比較
GCPがネットワーク設定とスナップショット取得だけだったのに対してAWSは、以下のような作業が必要です。※下図の赤字部分
- メインとバックアップのリージョンでIPSec VPN接続
- バックアップリージョンにスナップショットを転送
詳しくは説明しませんが、AWSはリージョンを跨いだ内部ネットワークを、標準サービスでは構成できず、かつスナップショット領域のS3がリージョン依存であることが関係しています。リージョン跨ぎの復旧はそのままではできません。
また、AWSは、インスタンスの復旧という点に関しても、ディスクをデタッチ/アタッチしたり、スナップショットからディスクを作ったりでちょっと複雑で面倒です。
補足： スナップショットからの Amazon EBS ボリュームの復元
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-restoring-volume.html
GCPの方がより現実的なオペレーションに近いと言えるでしょう。
5. コスト比較
GCP、AWSの公式料金見積もりツールを使い、結果を比較してみました。
https://cloud.google.com/products/calculator/?hl=ja
https://calculator.s3.amazonaws.com/index.html
以下はAWSとの月額の運用費用比較表です。
| GCP | AWS | |||
|---|---|---|---|---|
| 項目 | 金額($) | 項目 | 金額($) | |
| インスタンス | n1-standard-2 ×10 | $623.42 | m4.large × 10 | $944.30 |
| ディスク | persistent 500GB×10 | $260.00 | st1 500GB × 10 | $600.00 |
| スナップショット(メイン) | 初期取得分500GB×10 ＋ 差分500GB×10 × 2% × 30 | $212.99 | 500GB×10台 × 2% × 30日 | $203.75 |
| スナップショット(バックアップ) | – | – | 3000GB | $203.75 |
| データ転送費用 | – | – | VPN outbound | $462.00 |
| 計 | $1096.41 | 計 | $2,413.80 | |
なんと、倍以上の差がついてしまいました！
GCPは元から安いのに加え、AWSはバックアップリージョン用スナップショットの費用とリージョン跨ぎの転送費用が余計にかかってしまうのが大きいです。（GCPではスナップショットを取得してのリストアはリージョンを跨いでも2018年1月時点では無課金です）
6. まとめ
面倒なマルチリージョンのDR環境構築も、GCPを使えばお安く簡単にできることが分かりました。
これぞクラウドの醍醐味ですね！
ちなみにオンプレミスで構築すると…。
まずはデータセンターの契約、回線契約、ハードウェア調達、等々からでしょうか。初期からえげつないコストと手間と時間がかかると思います。オンプレの話は忘れましょう。
DRに悩んだら、まずGCPを検討してみてください。
さて、今回は簡単なDRの例を紹介しましたが、クラウドエースでは高度なGCP導入・運用支援サービスも提供しております。
ご興味のある方はこちらまでお問い合わせください。DRに限らず、あらゆるGCPサービスのサポートが可能です。