[Cloud OnAir] Google Cloud で実現するバックアップディザスタリカバリのベストプラクティス 2019年4月25日放送

Cloud Onr
Cloud OnAir
Cloud OnAir
2019 年 4月 25 日放送
Google Cloud で実現するバックアップ
ディザスタリカバリのベストプラクティス

Agenda
Cloud OnAir
1
3
2
4
バックアップ / リストア
クラウドインフラのバックアップとリストア
ディザスタリカバリ
クラウドインフラのディザスタリカバリ

Cloud OnAir
Cloud OnAir
バックアップ / リストア

Cloud OnAir
データやシステムの状態を複製し、システムの停止やデータの損失といった障
害の発生時にリストア（復旧）できるように備えること
バックアップとは
Local
Storage
Local
Compute
稼働中のシステム
Local
Storage
Local
Compute
システムのバックアップ
2019/04/25
…………...
2019/04/25
…………...
2019/04/25
…………...
2019/04/25
…………...
状態を複製

Cloud OnAir
システムやデータが失われた際に、取得していたバックアップから
データやシステムの状態を復元すること
リストアとは
Local
Storage
Local
Compute
稼働中のシステム
（障害発生中）
Local
Storage
Local
Compute
システムのバックアップ
Local
Storage
Local
Compute
復元されたシステム
2019/04/25
…………...
2019/04/25
…………...
2019/04/25
…………...
2019/04/25
…………...
2019/04/26
…………...
2019/04/26
…………...
バックアップから復元

Cloud OnAir
● RPO（Recovery Point Objective：目標復旧時点）
○ 障害が発生してデータが失われた際に、どこまで障害発生時刻に近
い時間のデータを復旧目標にするかという指標
● RTO（Recovery Time Objective：目標復旧時間）
○ 障害が発生した際に、どれだけ早く復旧するかという指標
● RLO（Recovery Level Objective：目標復旧レベル）
○ RTO の範囲内にどの水準まで業務を復旧させるかという指標
バックアップ、リストアの非機能要件

Cloud OnAir
バックアップ、リストアのジレンマ
RTO
RPO
コスト
RTO 長、RPO 短
RTO 短、RPO 長コスト増
コスト減

Cloud OnAir
オンプレミス環境のバックアップとその限界
スナップショット
サーバ
ブロック
ストレージ
バックアップ
サーバ
バックアップ
ストレージ
バックアップ
ソフトウェア
レプリケーション
サーバ
ストレージ
リアルタイム
ディスクストレージ
(D2D)
テープ
(D2T)
ファイルブロック
・低速
・マニュアルオペレーション
・データ量予測に合わせた
キャパシティプランニングの限界

Cloud OnAir
Cloud OnAir
クラウドインフラの
バックアップとリストア

Cloud OnAir
Cloud OnAir
Compute Engine 編

Cloud OnAir
● 仮想マシン（VM）のサービス
● CPU やメモリなどのリソースを柔軟に変更可能
● ライブマイグレーションを標準実装。
Google 都合による計画停止無し
● SLA 99.99%
● 使えば使うほど下がっていく料金体系
● データは永続ディスクに保存
○ 予め冗長化されており、 RAID などの
ハードウェア耐障害性設計は不要
Compute Engine (GCE)
永続ディスクのバックアップを
どう取るか？

Cloud OnAir
Compute Engine の永続ディスクをバックアップする方法は
大きく分けて三種類
Compute Engine のバックアップ
バックアップ
永続ディスクまるごと
ファイル単位
イメージ
Cloud Storage に
コピー

Cloud OnAir
スナップショットとイメージの比較
スナップショットイメージ
主な用途永続ディスク上のデータの
バックアップ
インスタンスの作成や
インスタンステンプレートの作成
保存方法フルバックアップ＋増分常にフルバックアップ
スケジュール実行可能 (BETA) 不可能
保存時のサイズ圧縮される＋実使用量のみ非圧縮＋ディスク容量全て
保存コスト低い高い
所要時間短い長い

Cloud OnAir
● 増分 & 圧縮保存のため、イメージ作
成に比べ短時間で作成でき、
かつ安価に保管
スナップショットの特徴 (1)
初回はフルバックアップのためサイ
ズが大きいが、二回目以降は増分
のみの取得のためサイズが小さい
https://cloud.google.com/compute/docs/disks/
create-snapshots

Cloud OnAir
スナップショットの特徴 (2)
● スナップショットを別リージョンに保存
可能（データ転送料不要）
● 更にスナップショットから直接
インスタンスを作成したり、
イメージに変換してインスタンスを作
成することも可能
Region A
Region B
Compute Engine
Persistent
Disk Snapshot
Persistent
Disk
Disk Image

Cloud OnAir
スナップショットを定期的に自動実行
● 時間（何時間おきに実行す
るか） / 日 / 週
● スナップショットの
保持期間
● 日常のバックアップ手段と
して利用可能
スナップショットスケジュール BETA
https://cloud.google.com/compute/docs/disks/scheduled-snapshots

Cloud OnAir
● スナップショットの整合性は、厳密には担保されない
○ 大量の書き込みが発生している最中にはなるべく実施しない
○ 厳密な整合性を必要とする場合、ディスクバッファをフラッシュしてからス
ナップショットを取得
■ 参考 (https://cloud.google.com/compute/docs/disks/create-snapshots?authuser=3&hl=ja)
○ Windows VM の場合、VSS スナップショットを使用して整合性を
確保（ブートディスクには不向き）
■ 参考
(https://cloud.google.com/compute/docs/instances/windows/creating-windows-persistent-disk-snapshot)
● ディスク単位でのバックアップのため、特定ファイルのみのバックアップ/ リスト
ア用途には利用できない
スナップショットの注意点

Cloud OnAir
Cloud Storage (GCS) とは？
● Restful API でオブジェクトを操作する
オブジェクトストレージサービス
● 様々な用途に応じたストレージクラス
○ 価格設定や可用性、性能が異なる
● 11 9’s の年間耐久性
● オブジェクトのバージョニング（世代管理）に対応
● 指定保持期間が過ぎたオブジェクトをより低頻度
アクセスのストレージに移行したり削除が出来る
ライフサイクル管理機能
● 高い可用性を活かしてファイルベースの
バックアップ先として活用可能
Cloud Storage を使ったファイルバックアップ

Cloud OnAir
● gsutil コマンドを使用
● 大量のファイルを転送する場合、
マルチスレッドコピーで転送効率を上げる
● 定期的に実行する場合はOS 側でスクリプトの
作り込みが必要
● その他、 GCS への保存に対応する
各種サードパーティの製品群を利用可能(→ P50)
GCE から GCS へのファイルバックアップ
# ファイル単位でのコピー
gsutil cp [FILE_NAME] gs://[BACKET_NAME]
# ディレクトリ単位でのコピー
gsutil cp -r [DIRECTORY] gs://[BACKET_NAME]
gsutil -m cp -r [DIRECTORY] gs://[BACKET_NAME]

Cloud OnAir
Compute Engine バックアップのベストプラクティス
リージョンA
リージョンB
Compute
Engine
Cloud
Storage
Persistent
Disk Snapshot
Persistent
Disk
● 世代管理を有効化（バージョニング）
うっかり上書きしてしまったファイルを取り出
せるように！
● 一定日数を経過したファイルは
削除もしくはNearline / Coldline に
退避（ライフサイクル）
バックアップの肥大化による使用料増をなる
べく少なく！
ファイル単位のバックアップは
gsutil コマンドで
Cloud Storage へ
永続ディスク全体のバックアッ
プはスナップショットで別リー
ジョンへ
● スナップショットスケジュール(BETA)で処理
を自動化
常に最新のスナップショットが取れている状
態を作る

Cloud OnAir
● 厳密な整合性を求める場合、取得前にディスクバッファをフ
ラッシュする（各 OS 側の機能）
● ディスク I/O が頻発する時間帯の実施は避ける
Compute Engine バックアップのベストプラクティス
方法
頻度・スケジュール
注意点
永続ディスク全体
ファイル単位
● イメージではなくスナップショットで取得
● 別リージョンに保管（DR 観点）
● Cloud Storage バケットに保管
● バージョニングを有効化して世代管理
● スクリプトが必要
ファイル単位
● スナップショットスケジュールで自動的・定期的に実行
● RPO の要件を満たすよう取得頻度を調整
● スケジューリングは OS 側（cron 等）
ファイル単位 ● HTTPS を使ったオブジェクト（≒ファイル）単位の転送のた
め、大量の転送を行う際はマルチスレッドコピーを使用するな
どの工夫が必要

Cloud OnAir
スナップショットを使えばディスクを高速、安価にバックアップ
リージョン障害に備えてスナップショットは別リージョンに !
ファイル単位でのリストアが必要なら Cloud Storage も併用
ここまでのまとめ

Cloud OnAir
Cloud OnAir
Cloud SQL 編

Cloud OnAir
● フルマネージドのデータベースサービス
● MySQL と PostgreSQL に加え、SQL Server (Alpha)
を利用可能
● 第 2 世代では高可用性フェイルオーバー、
リードレプリカをサポート
Cloud SQL

Cloud OnAir
リストア方法のメリットとデメリット
リストア方法メリットデメリット
バックアップから復元・元のインスタンス上に復元が可能
・自動的に2つのリージョンに保管
される
・復元ポイントはバックアップ完了の
タイミングになる
・別リージョンに復元する際は
別インスタンスになるため、 DB
クライアントからの接続先が変わる
バックアップ＋
ポイントインタイム
リカバリ
・バイナリログに記録されている
任意のポジションを指定して
復元することが可能
・バイナリログには通常の
ストレージ料金が別途加算
・書き込みのパフォーマンスが若干低下
・リージョン障害には耐えることが
出来ない
・バックアップが必ず必要
・クローンを作成して復元するため、 DB
クライアントからの接続先が変わる

Cloud OnAir
シーン別 Cloud SQL バックアップのベストプラクティス
リージョン障害の際もバックアップからデー
タベースを復旧させたい
自動バックアップ
あの変更が加えられる直前のデータに
戻したい(リージョン障害は諦める )
自動バックアップ+PITR

Cloud OnAir
何をするにもバックアップは有効化しておく！
バックアップを取得するだけで単一リージョン障害から復旧できる
同一インスタンスへの復元以外の手段では、アプリからの参照先が変わる

Cloud OnAir
Cloud OnAir

Cloud OnAir
ディザスタリカバリ（DR）とは
災害等による被害から事業
やサービス、システムなどを
回復したり影響を最小限に抑
える施策
日本のメインサイトが
被災
北米のバック
アップサイトで
サービス再開
日々更新されるデータは WAN
等を経由してバッチ / リアルタ
イムに同期

Cloud OnAir
遠隔地でサービスを提供するリソース
○ 規模は RLO 次第。本番の半分で良ければ半分のリソース
遠隔地でも本番と時間軸で同期の取れたデータ
○ データの新鮮さは RPO 次第。一日前で良ければ前日分のデータ
発動時にシステムを速やかに切り替える仕組み
ディザスタリカバリに必要な要素

Cloud OnAir
さらに細分化すると...
本番のデータをリアルタイムもしくは定期的に同期する仕組み
本番環境と DR 環境を高速で接続するネットワーク
本番環境と同じ機能が提供できるサーバやネットワーク機器
（公開サービスの場合）インターネット接続
電力や空調、スペースなどのファシリティ

Cloud OnAir
どうやって遠隔地にデータを同期する ?
というのは簡単だが ?
国際専用線や国際WAN は非常に高額　データ転送コスト
レイテンシーも大きく同期にも時間が掛かる　レイテンシー
どうやって遠隔地にインフラを構築する ?
普段は稼働しないインフラなのに投資しなければならない　二重投資
そのインフラ、誰が面倒見るの?　監視、運用保守
いざ切り替える、となったとき手順は大丈夫?　切替オペレーション
そもそもどこにインフラを置く?　ファシリティ

Cloud OnAir
Cloud OnAir
クラウドインフラの

Cloud OnAir
Cloud OnAir
DR にまつわる悩みはクラウドで解決
既に Cloud に
ALL-IN なインフラ編

Cloud OnAir
クラウド特有の場所の概念と障害の影響範囲
リージョン ∋ ゾーン ∋ 各リソース
・asia-northeast1 (東京)
・us-west2 (ロサンゼルス)
・…
・asia-northeast1-a
・asia-northeast1-b
・asia-northeast1-c
・...
・GCE VM インスタンス
・Cloud SQL インスタンス
・...
障害の程
度
重度軽度
・かなりの部分の障害を設計で緩和可能な領域
（HA 構成の採用やロードバランサー / フェイルオーバー
クラスタの活用、リージョナルリソースの活用など）
・都市 / 地方レベルの障害
・DR の設計が重要

Cloud OnAir
DR にまつわる悩み
レイテンシーも大きく同期にも時間が掛かる..　レイテンシー

Cloud OnAir
データ転送に必要なコストを圧縮
Compute Engine
永続ディスク
リージョンをまたいでスナップショットを転送する際にデータ
転送料は発生しない（高額な国際 WAN 不要）
Cloud SQL
バックアップは自動的に二箇所の
リージョン（自リージョン
+1）に保管され、リージョン間転送
料は発生しない
リージョンをまたいでネイティブにバックアップデータを保存する機能を使えば、距離による遅延の
影響を極小化しつつ、同時にデータ転送コストを大幅に圧縮することが可能
各リージョン間は Google の高速な
バックボーンで接続されている

Cloud OnAir

Cloud OnAir
スナップショットを使えば、DR 発動時以外 VM インスタンスは不要
● スナップショットの保存コストのみ
● Cloud SQL インスタンスも同様
DR 環境に必要なファシリティは全て Google 側が所有
平常時は起動せず、ハードウェアの保守は全て Google が行うため、DR 発
動時の正常起動を担保するための運用監視は不要
DR もリソースオンデマンド

Cloud OnAir

Cloud OnAir
リージョン障害からサービス復旧までのフローチャート
特定リージョン
が使用不能に
別リージョンで
サービス継続
リージョンの
復旧を待つ
既に別リージョンで
DR インフラが
稼働中
別リージョンに
バックアップ有
（稼働は停止中）
バックアップがないの
で復旧を待つ
Cloud DNS や
ロードバランサーで
トラフィックをDR環境にルー
ティングする
バックアップから本番同等の
DR 環境を構築し、
トラフィックを DR 環境にルー
ティングする
高コスト
＆
RTO 小
低コスト
＆
RTO 大
Google Cloud の機能を使って
RTO を最小限に抑える！！

Cloud OnAir
RTO を最小限に抑える発想
大規模なインフラの復旧作業を人手で行うと、時
間も掛かるしミスも増える ...
復旧後のインフラの ”あるべき姿” を
コード化し、コードに即して自動構築が
可能になれば復旧時間の短縮とミス低減につ
ながる

Cloud OnAir
Cloud Deployment Manager
● リソースをテンプレートで管理し、
多数同時に並行デプロイ
● リソース間の依存関係を認識し、構築順序を自
動コントロール
● 構築内容をコミットする前に、実行結果を事前
確認することが可能(dry-run)
● よく使われる GCP サービスのほとんどに対応
復旧（構築）作業のテンプレート化

Cloud OnAir
Cloud Deployment Manager による復旧作業シナリオ（例）
Cloud Load Balancing
Compute Engine
Cloud SQL
復旧させる構成前提：
・本番とは別リージョンに復旧させる
・別リージョンにスナップショットは取得済み
・Cloud SQL はバックアップ有効／取得済み
・障害が発生しているリージョンは１つ
・テンプレートは記載済み
事前準備
1. スナップショットからブート
ディスクイメージを作成
2. ディスクイメージに
合わせてテンプレートを修
正
デプロイ
3. Deployment Manager で
テンプレートから
デプロイ
切替準備
4. Cloud SQL インスタンスに
バックアップから
データを復元
5. アプリからの DB 接続先を
変更
切替
6. DNSの切替

Cloud OnAir
DR にまつわる悩みが解決

Cloud OnAir
Cloud OnAir
DR にまつわる悩みはクラウドで解決
Cloud はまだまだ
これから編

Cloud OnAir
オンプレミスにおける障害の影響範囲
地方 ∋
ビル /
データセンター
∋ 各リソース
・首都圏、近畿圏、中京圏等
・自社ビル
・コロケーション事業者の建屋等
・物理サーバ、仮想サーバ
・ストレージ機器、ネットワーク機器等
障害の程
度
重度軽度
・冗長化
（RAID/FTサーバ/HA等）
・ファシリティが冗長化されていない環境では、
ファシリティが停止した時点でデータ復旧の手段を失う
・バックアップセンター等ファシリティレベルの冗長化が必須

Cloud OnAir
オンプレミスのバックアップ環境としてのクラウド利用
Google cloud
Storage
On-premise
Servers
クラウド to クラウド
バックアップ
オンプレミス環境の
バックアップ
Google Compute
Engine
DR
オンプレミスから GCS への
データ転送に対応するプロダクトを利
用してデータを GCS に
バックアップする
※対応製品例は次頁
Velostrata 等
オンプレミスの VM を
GCP にマイグレーションす
るプロダクトを
利用して、徐々に GCP に
Lift する
https://cloud.google.com/velostrata/

Cloud OnAir
VERITAS - NetBackup
https://www.veritas.com/ja/jp/solution/google-cloud-pla
tform
CARONITE
https://www.carbonite.com/
CloudBerry Lab - CloudBerry Backup
https://www.cloudberrylab.com/
Actiﬁo
https://www.actifio.com/technology/integrations/google
-cloud/#sthash.9kvuFZHF.dpbs
GCP へのデータバックアップをサポートする製品群
Pure Storage
https://www.purestorage.com/products/objectengine.html
rubrik
https://www.rubrik.com/partners/technology-partners/goo
gle-cloud-platform/
DELL EMC
https://www.dellemc.com/en-us/data-protection/cloud.ht
m
NetApp
https://www.netapp.com/us/cloud-marketplace/google-cloud-p
latform.aspx
他にも多くの製品が Google Cloud へのデータバックアップをサポート
https://cloud.google.com/storage/partners/

Cloud OnAir
オンプレミス環境の DR 対策は、クラウドに移行済みの環境と
比べてハードルが高く、全てをオンプレミスで担うのは困難
データのバックアップ先など部分的にクラウドを取り入れることで、安価かつ
堅牢なバックアップ環境が手に入る
オンプレミスから GCP へのデータバックアップをサポートする
サードパーティ製品を活用すれば、データ移行がより容易に

Cloud OnAir
Cloud OnAir
補足資料

Cloud OnAir
耐障害性を高める GCP の機能やサービス
機能名
リージョン永続ディスク
(BETA)
複数ゾーン間でレプリケーションされた永続ディスク
単一ゾーン障害の際には強制的にスタンバイ VM にアタッチすることで
データを引き継いでサービスを継続することが可能
Compute Engine と Kubernetes Engine で利用可能
Cloud Load Balancing 単一のエニーキャストアドレスが世界中のリージョンに分散されたバックエ
ンドインスタンスのフロントとして機能する、グローバルなロードバラン
サー。バックエンドを複数リージョンにまたがって配置しておけば、リージョ
ン単位での障害の際にもサービスを停止する
こと無く提供し続けることが可能

Cloud OnAir
Cloud OnAir
まとめ

Cloud OnAir
バックアップ・リストア・ディザスタリカバリはクラウドの得意と
するところ
特にオンプレミスではハードルの高いファシリティレベルの冗長性が
クラウドでは標準実装されている
最適化されたコストで DR を実現するには、サービスがネイティブで
持つ機能をうまく組み合わせて使うことが重要
クラウドへの移行がまだの場合も、クラウドはオンプレミスの堅牢で
安価なバックアップ環境として利用できる
本日のまとめ

[Cloud OnAir] Google Cloud で実現するバックアップディザスタリカバリのベストプラクティス 2019年4月25日放送

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à [Cloud OnAir] Google Cloud で実現するバックアップディザスタリカバリのベストプラクティス 2019年4月25日放送

Similaire à [Cloud OnAir] Google Cloud で実現するバックアップディザスタリカバリのベストプラクティス 2019年4月25日放送 (20)

Plus de Google Cloud Platform - Japan

Plus de Google Cloud Platform - Japan (20)