Google Cloud Backup：BaaSの完全ガイド

GCP向けに実際に構築されていないベンダーを見分ける方法 

バックアップベンダーが実際にGoogle Cloud向けに構築されているかどうかは、最初の営業電話での質問内容で見分けることができます。 もし初期の質問が「バックアップサーバーはいくつ必要ですか」や「最大容量はテラバイト単位でどれくらいですか」といった内容であれば、そのベンダーはGoogle Cloud向けに構築したものではありません。彼らは固定型のアプライアンスを構築し、それをGCPに移植したに過ぎません。 

このパターンは頻繁に繰り返されるため、私は現在これを診断の指標として活用しています。 ベンダーが尋ねる質問からは、そのベンダーが提供するアーキテクチャが明らかになります。クラウドネイティブなアーキテクチャでは、そのような回答は必要ありません。 一方、クラウドでホストされるアプライアンスには、そうした回答が必要です。 

この記事では、Google Cloud向けの真のBaaSが提供すべきもの、ベンダーを評価するための適切な質問、そしてGCPのネイティブ機能がカバーする範囲と、カバーしきれていない部分について解説します。 

Google Cloudの組み込み機能が戦略とならない理由 

Googleは有用な保護プリミティブを提供しています。 Persistent Diskのスナップショット、Cloud SQLの自動バックアップ、GCSのオブジェクトバージョン管理、BigQueryのテーブルスナップショットなどです。これらはバックアップ戦略そのものではありません。

GCPの責任分担モデルは明確です。Googleはインフラのセキュリティと可用性を担当します。 顧客はデータを管理します。管理者がプロジェクトを削除したり、ランサムウェアによってPersistent Diskが暗号化されたり、設定ミスでCloud SQLのデータが消去されたり、開発者が誤ってBigQueryのテーブルを削除したりした場合でも、Googleはその操作を忠実に実行します。復旧は顧客の責任となります。

ネイティブ機能では埋められない4つのギャップがあります。 ソースとなるワークロードが削除されてもバックアップが維持される「独立した保存期間」。データベースやアプリケーションが、単にクラッシュ一貫性だけでなく、クリーンに復旧するための「アプリケーション一貫性」。ある場所で侵害が発生しても保護が失われないよう確保する「リージョン間およびプロジェクト間の分離」。そして、すべてを再構築することなく、単一のファイル、テーブル、またはVMを復元できる「きめ細かな復旧」です。 

GCPの完全なカバレッジが実際に意味すること 

 Compute EngineのVMのみを保護するベンダーは、2018年式のクラウドバックアップを販売しています。 真のBaaSは、単一の管理プレーンを通じてあらゆるワークロードクラスを保護します。 

GCPバックアップベンダーに尋ねるべき適切な質問 

クラウドネイティブアーキテクチャとクラウドホスト型アプライアンスの違いを浮き彫りにする5つの質問です。 

そのソリューションは、Google Cloudに合わせて弾力的に拡張できますか？ 正解は「はい」です。バックアップポリシーとCloud Storageバケットを通じて実現され、ノードのプロビジョニングや容量の予測は不要です。明日新しいGCPプロジェクトを追加しても、運用上の介入なしに保護が自動的に適用されます。 

ソリューションはどの程度ネイティブで統合されているか？　3つの具体的な検証項目。 まず、IAMです。サービスはGoogle Cloud IAMを通じて認証を行い、既存の権限やプロジェクト構造を継承していますか？　次に、APIインターフェースです。サービスはGoogle Cloud APIを通じて動作し、データがGCPの境界外に出ることがないようになっていますか？　3つ目は、課金です。Google Cloud Marketplaceを通じて利用可能で、料金は既存のGCPの請求に組み込まれていますか？ 

Cloud SQL、BigQuery、GKE、および SAP HANAなど、Compute Engineだけにとどまらないのでしょうか？ VMのみのバックアップでは、現代のGCP環境で実行されているもののほとんどをカバーできません。各ワークロードクラスに関する具体的な情報を尋ねてください。一般的な回答は、一般的な保護を意味します。 

リージョン間およびプロジェクト間の復旧はどのような形になるのでしょうか？ワークロードは、マルチリージョンおよびマルチプロジェクトの展開へと拡大していきます。 単一のプロジェクトで機能していたバックアップメカニズムは、境界を越えると機能しなくなります。両方を跨ぐ復元の手順について、ベンダーに説明を求めてください。 

環境の拡大に伴い、価格設定はどのように変化しますか？最大予約容量ではなく、実際にバックアップされたソースデータに基づいた「保護分だけ支払う」という料金体系を探してください。 

3つの柱：バックアップ、移行、DR 

Google Cloud向けBaaSは、密接に関連する3つのユースケースに対応しています。 優れたソリューションは、1つのプラットフォーム、1つのポリシーフレームワーク、1つのリカバリモデルを通じて、これら3つすべてに対応します。 

バックアップそのもの。すべてのワークロードクラスに対するアプリケーション一貫性のあるバックアップとリカバリを実現し、ネイティブなGoogle Cloudスナップショットを最初の保護層として、Google Cloud Storageを長期保存として活用します。 プラットフォームとの緊密な統合により、本番環境のパフォーマンスへの影響はほぼゼロです。 

GCP への移行および GCP 内での移行。このバックアップメカニズムは、移行メカニズムとしても機能します。既存のバックアップデータを移行ソースとして活用し、オンプレミス、他のクラウド、または GCP の別のリージョンから、本番ワークロードをリフト・アンド・シフトで移行できます。 移行中もアプリケーションの一貫性が維持されます。 

GCP を利用した災害復旧。オンプレミスや他のクラウド上のワークロードの災害復旧（DR）先として Google Cloud を活用します。 経済的なモデルが重要です。バックアップコピーをGCPに低コストで継続的に保存しつつ、実際にDRが宣言された場合にのみ、コンピューティングリソースと高性能ストレージを利用します。1年の大半はストレージの料金のみを支払います。災害が発生する稀な日には、コンピューティングリソースの料金を支払います。 これは、常時稼働型の災害復旧コストのほんの一部に過ぎません。 

バックアップデータを用いたGCPの「リフト・アンド・シフト」の実際の仕組み 

オンプレミスからCompute Engineのワークロードを移行する際の技術的なフローは、4つのステップで構成されています。 

既存のバックアップから本番用VMのディスクイメージを復元します。 移行用ワークステーションからアクセス可能なSMBまたはNFSターゲットにエクスポートします。 

ワークステーションにGoogle Cloud SDKをインストールします。 

移行先のプロジェクトにCloud Storageバケットを作成し、VMディスクファイルをアップロードします。 

gcloud compute images import コマンドを使用して、ソースバケットとオペレーティングシステムを指定し、ディスクを Compute Engine カスタムイメージとしてインポートします。

カスタムイメージが作成されると、そこから直接新しい Compute Engine インスタンスを起動できます。この同じ手順で、GCP 内のリージョン間移行や、他のクラウドからの移行も処理できます。

GCPのバックアップに関するよくある質問 

Google Cloudの組み込み機能のみに頼ることはできますか？ 

いいえ。 組み込み機能は有用な基本機能ですが、独立したデータ保持、マルチリソースワークロード全体でのアプリケーションの一貫性、プロジェクト間の分離、および多くのワークロードタイプに対するきめ細かな復旧機能は備えていません。 真のBaaSは、これらの組み込み機能の上に構築されています。 

誤削除やランサムウェア被害後の復旧はどのように行えばよいですか？ 

削除や暗号化の後であっても、任意の保持時点にデータを復元できます。 復旧オプションには、VM 内の単一ファイル、BigQuery 内の単一テーブル、GKE 内の単一ネームスペースから、元のリージョンまたは別のリージョンへの VM 全体やプロジェクト全体の復元まで、幅広い選択肢があります。 保存期間は、ソースとなるワークロードとは独立しています。 

GCP BaaS は安全で、コンプライアンスに準拠していますか？ 

転送中および保存中のデータの暗号化、Google Cloud IAM との統合、SOC 2、HIPAA、GDPR に対する認証を取得しています。 クラウドネイティブアーキテクチャにより、バックアップデータは全工程を通じてGCPの境界内に留まります。 

BaaSはSAP HANA、GKE、BigQueryに対応していますか？ 

対応しているはずです。 SAP HANAには、HANAのログ管理と統合されたアプリケーション認識型のバックアップが必要です。GKEには、コンテナ、永続ボリューム、およびネームスペース単位の粒度が必要です。BigQueryには、データセットおよびテーブルレベルのバックアップが必要です。 Compute EngineのVMのみを扱うベンダーでは、現代のGCPで実行されている機能の大部分をカバーできていません。 

ご自身の環境で試してみてください 

「HYCU R-Cloud for Google Cloud」は、Google Cloud Marketplaceから直接ご利用いただけます。 トライアルでは、お客様の実際のGCPアカウント、実際のワークロード、実際のデータを使用します。15分で稼働させることができます。 ほとんどのチームは、数日以内に本ソリューションが適しているかどうかを判断できます。試用リンクは hycu.com/trial.