views4GCPのストレージサービスについてまとめてみた。Exp:8154前はオンプレのデータセンターをAWSに移行するPM兼SEでした。その影響で、心が疲れるとLANケーブルを作り出したり、物理のネットワーク機器をいじったりする癖があります。TweetShareHatena注意この記事は2018年1月11日に更新されたもので、内容が古い可能性がありますのでご注意ください。Recovery:DR)。近年は必ずIT視点での対策も必要となるため、担当者としては、経営から圧力かかるわ、ユーザに負担かかるわ、お金が出て行くわで、非常に悩ましい取り組みではないでしょうか。GCPならそんな面倒も一発解決。DR環境がカンタンに実現できてしまうんです。ボタン一発でネットワークやサーバが簡単に作成できるし、本当に必要な時だけ起動すればコストはからないし、いいことづくめ。今回は、IaaSとしてGCEを使い、10台程度のサーバーを使った比較的簡単なシナリオで、マルチリージョンのDR環境を構築してみます。データ退避の災害対策(DR)シナリオざっくり言って今回は「データ退避」と言われる設計パターンです。一般的なサーバ利用として以下のようなゆるめの要件を想定します。Objective(RTO))は1日以内程度を想定。利用するサービスはIaaSのみを想定。メインとなるリージョンにはサーバ10台が稼働している。サーバの仕様は以下の通り。※スナップショット量算出に必要データ同期のため、メインとバックアップリージョンは内部IPで接続したい。このレベルの要件であれば一旦データを日時で別リージョンにさえ退避しておけば、被災時にリモートリージョンで手作業で復旧することで最低限の復旧が可能になります。GCPにおける災害対策設計メインリージョンで、GCEのサーバを10台構築する。メインリージョンで1日1回サーバのスナップショットを取得する。有事の際は、スナップショットから任意のタイミングでインスタンスを復旧する。プロジェクトは一つ、ネットワークはマルチリージョン設定とし、ルータでリージョン間を内部接続する。データ退避はDRとしてはかなりライトな設計ですが、コストをかけられない企業では、落とし所としてよくありがちなシナリオでしょう。スナップショットの取得頻度を多くすればRPOは短縮出来ます(スナップショット領域費用とのトレードオフ)し、復旧手順の自動化やスクリプト化、リハーサルなどによりRTOの短縮も可能でしょう。それ以上重厚にやるのでしたら、業務設計から、復旧目標時間や復旧目標地点の定義から、復旧リハーサルから、やることは色々ありますが、それはまた次の機会に。DR環境構築手順では早速設計シナリオに沿ってDRを構築していきましょう。言っても、実はGCPでやることはほとんどありません。(1)VPCネットワーク作成時に「グローバル」を指定。(2)用途に応じてGCEでサーバを構築します。詳細は省略しますが、画面から普通に必要なサーバを立てていけばOKです。※詳細は以下URL参照GCEのスナップショットバックアップ機能詳細とお得な使い方!GCEのスナップショットバックアップ機能詳細とお得な使い方!これだけ。本当にこれだけでいいんです。被災時の手順あまり考えたくないですが、実際に被災した際にサービス復旧が必要になった場合、どんなオペレーションが必要なのでしょうか。こちらもGCPならカンタンです。(1)コンソールでスナップショットを開く。(2)スナップショットからインスタンスを作成する。