- tech系
Google Cloud（GCP）圧勝！ DR（災害対策）環境構築で GCP と AWS を比較してみた
目次
こんにちは。
クラウドエース編集部です。
情報システム担当者なら、誰もが一度は検討に迫られたことがあるビジネス継続性計画(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 のスナップショットバックアップ機能詳細とお得な使い方！
https://www.apps-gcp.com/gce-snapshot-backup/
これだけ。
本当にこれだけでいいんです。
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 サービスのサポートが可能です。
他の分野も比較してみよう
今回は、DR の環境構築を比較しましたが、下記の資料では他の分野はもちろん、AWS だけでなく Azure とも比較した情報が詳細にまとめられていますので、ぜひご覧になってください。
AWS・GCP・Azure 3大クラウドサービス 比較表
この記事を共有する
