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の請求に組み込まれていますか？ 

Compute Engineだけでなく、Cloud SQL、BigQuery、GKE、SAP HANAにも対応していますか？VMのみのバックアップでは、現代のGCP環境で稼働しているワークロードの大部分をカバーできません。各ワークロードクラスに関する具体的な情報を確認してください。一般的な回答は、一般的な保護しか提供されないことを意味します。 

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

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

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

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

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

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

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

バックアップデータを用いた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にあります。