このアーキテクチャは、BigQuery バックアップ戦略の開発に役立つフレームワークとリファレンス デプロイを提供します。この推奨フレームワークとその自動化により、組織は次のことを行えます。
- 組織の障害復旧目標を遵守します。
- ヒューマン エラーによって失われたデータを復元します。
- 規制を遵守する。
- 運用効率を向上させます。
BigQuery データのスコープには、フォルダ、プロジェクト、データセット、テーブルを含める（または除外する）ことができます。この推奨アーキテクチャは、定期的なバックアップ オペレーションを大規模に自動化する方法を示しています。各テーブルには、BigQuery スナップショットと Cloud Storage への BigQuery エクスポートという 2 つのバックアップ方法を使用できます。
このドキュメントは、組織でデータポリシーを定義して自動化するクラウド アーキテクト、エンジニア、データ ガバナンス担当者を対象としています。
アーキテクチャ
次の図は、自動バックアップのアーキテクチャを示しています。
上の図に示すワークフローには、次のフェーズが含まれています。
- Cloud Scheduler は、Pub/Sub メッセージを介してディスパッチャー サービスへの実行をトリガーします。このメッセージには、含まれる BigQuery データの範囲と除外される BigQuery データの範囲が含まれています。実行は cron 式を使用してスケジュールされます。
- Cloud Run 上に構築されたディスパッチャー サービスは、BigQuery API を使用して BigQuery スコープ内のテーブルを一覧表示します。
- ディスパッチャー サービスは、テーブルごとに 1 つのリクエストを Pub/Sub メッセージを介して構成サービスに送信します。
Cloud Run 構成サービスは、次のいずれかの定義済みオプションからテーブルのバックアップ ポリシーを計算します。
- テーブルレベルのポリシー（データ所有者が定義）。
- ポリシーが定義されていないテーブルに対して、データ ガバナンス オフィサーが定義したフォールバック ポリシー。
バックアップ ポリシーの詳細については、バックアップ ポリシーをご覧ください。
構成サービスは、計算されたバックアップ ポリシーに基づいて、テーブルごとに 1 つのリクエストを次のサービスに送信します。
バックアップ方法に応じて、次のいずれかのカスタム Cloud Run サービスが BigQuery API にリクエストを送信し、バックアップ プロセスを実行します。
- BigQuery スナップショットのサービスは、テーブルをスナップショットとしてバックアップします。
- データ エクスポート サービスは、テーブルを Cloud Storage へのデータ エクスポートとしてバックアップします。
バックアップ方法がテーブルデータのエクスポートの場合、Cloud Logging のログシンクは、エクスポート ジョブの完了イベントをリッスンして、次のステップの非同期実行を有効にします。
バックアップ サービスがオペレーションを完了すると、Pub/Sub はタガーサービスをトリガーします。
テーブルごとに、タガーサービスはバックアップ サービスの結果をロギングし、Cloud Storage メタデータ レイヤのバックアップ状態を更新します。
使用するプロダクト
このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。
- BigQuery: ML、地理空間分析、ビジネス インテリジェンスなどの組み込み機能を使用してデータの管理と分析を支援する、Google Cloud のフルマネージド エンタープライズ データ ウェアハウス。
- Cloud Logging: ストレージ、検索、分析、アラート機能を備えたリアルタイムのログ管理システム。
- Pub/Sub: メッセージを処理するサービスとメッセージを生成するサービスを切り離す、非同期でスケーラブルなメッセージング サービス。
- Cloud Run: Google のスケーラブルなインフラストラクチャ上でコンテナを直接実行できるマネージド コンピューティング プラットフォーム。
- Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloudの内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
- Cloud Scheduler: エンタープライズ クラスのフルマネージド cron ジョブ スケジューラ。定義した時刻または一定の間隔で実行される作業単位のスケジュールを設定できます。
- Datastore: ウェブアプリとモバイルアプリのためのスケーラビリティの高い NoSQL データベース。
ユースケース
このセクションでは、このアーキテクチャを使用できるユースケースの例を示します。
バックアップの自動化
たとえば、規制対象の業界で事業を行っており、メインのデータ ウェアハウスとして BigQuery を使用している企業があるとします。ソフトウェア開発、コードレビュー、リリース エンジニアリングでベスト プラクティスに従っている場合でも、人為的エラーによるデータ損失やデータ破損のリスクは残ります。規制の厳しい業界では、このリスクを可能な限り最小限に抑える必要があります。
人的エラーの例を次に示します。
- テーブルの誤削除。
- データ パイプラインのロジックが誤っているため、データが破損する。
通常、このような人的エラーは、最大 7 日前のデータを復元できるタイムトラベル機能で解決できます。また、BigQuery にはフェイルセーフ期間もあります。この期間中、削除されたデータはタイムトラベル期間が経過した後、さらに 7 日間フェイルセーフ ストレージに保持されます。このデータは、Cloud カスタマーケアを通じて緊急復旧に使用できます。ただし、この期間内に会社がこのようなエラーを発見して修正しない場合、削除されたデータは最後の安定した状態から復元できなくなります。
この問題を軽減するには、ソースデータから再構築できない BigQuery テーブル（過去のレコードやビジネス ロジックが変化する KPI など）の定期的なバックアップを実行することをおすすめします。
基本的なスクリプトを使用して、数十個のテーブルをバックアップできます。ただし、組織全体で数百または数千のテーブルを定期的にバックアップする必要がある場合は、次のことを行うことができるスケーラブルな自動化ソリューションが必要です。
- さまざまな Google Cloud API 制限を処理します。
- バックアップ ポリシーを定義するための標準化されたフレームワークを提供します。
- バックアップ オペレーションの透明性とモニタリング機能を提供します。
バックアップ ポリシー
会社によっては、次のグループのユーザーがバックアップ ポリシーを定義することを義務付けている場合があります。
- テーブルに最も精通しており、適切なテーブルレベルのバックアップ ポリシーを設定できるデータ オーナー。
- データ ガバナンス チーム。テーブルレベルのポリシーがないテーブルをカバーするフォールバック ポリシーが設定されていることを確認します。フォールバック ポリシーにより、特定のデータセット、プロジェクト、フォルダがバックアップされ、会社のデータ保持規制が遵守されます。
このリファレンス アーキテクチャのデプロイでは、テーブルのバックアップ ポリシーを定義する方法が 2 つあり、これらを組み合わせて使用できます。
データ所有者の構成（分散型）: テーブルに手動で関連付けられるテーブルレベルのバックアップ ポリシー。
- データ所有者は、共通バケットに保存されているテーブルレベルの JSON ファイルを定義します。
- ソリューションがテーブルのバックアップ ポリシーを決定する場合、手動ポリシーはフォールバック ポリシーよりも優先されます。
- デプロイの詳細については、テーブルレベルのバックアップ ポリシーを設定するをご覧ください。
組織のデフォルト構成（一元管理）: 手動でポリシーが関連付けられていないテーブルにのみ適用されるフォールバック ポリシー。
- データ ガバナンス チームは、ソリューションの一部として、Terraform で中央 JSON ファイルを定義します。
- フォールバック ポリシーは、フォルダ、プロジェクト、データセット、テーブルの各レベルでデフォルトのバックアップ戦略を提供します。
- デプロイの詳細については、フォールバック バックアップ ポリシーを定義するをご覧ください。
バックアップとレプリケーション
バックアップ プロセスでは、特定の時点のテーブルデータのコピーが作成されます。これにより、データが失われたり破損したりした場合に復元できます。バックアップは、1 回限りの実行または定期的な実行（スケジュール設定されたクエリまたはワークフローによる）が可能です。BigQuery では、スナップショットを使用して特定の時点のバックアップを作成できます。スナップショットを使用すると、ソースデータと同じストレージ ロケーション内で、7 日間のタイムトラベル期間を超えてデータのコピーを保持できます。BigQuery スナップショットは、リージョン障害からの復旧ではなく、データ損失や破損につながる人的ミスが発生した後にデータを復元する場合に特に役立ちます。BigQuery は、エディションに応じて 99.9% ～ 99.99% のサービスレベル目標（SLO）を提供します。
一方、レプリケーションは、データベースの変更を別のロケーションにあるセカンダリ（またはレプリカ）データベースにコピーする継続的なプロセスです。BigQuery では、クロスリージョン レプリケーションを使用して、ソースデータ リージョンとは異なるセカンダリ Google Cloud リージョンにデータの読み取り専用コピーを作成することで、地理的冗長性を実現できます。ただし、BigQuery クロスリージョン レプリケーションは、リージョン全体の停止シナリオの障害復旧計画として使用するものではありません。リージョンの障害に対する復元力を高めるには、BigQuery のマネージド障害復旧の使用を検討してください。
BigQuery クロスリージョン レプリケーションは、データ コンシューマーに近いリージョンにデータの同期読み取り専用コピーを提供します。これらのデータコピーにより、コロケーション結合が可能になり、リージョン間のトラフィックと費用を回避できます。ただし、人的エラーによるデータ破損の場合、破損したデータがレプリカに自動的にコピーされるため、レプリケーションだけでは復元できません。このような場合は、特定の時点のバックアップ（スナップショット）の方が適しています。
次の表に、バックアップ方法とレプリケーションの比較の概要を示します。
| メソッド | 頻度 | ストレージのロケーション | ユースケース | 料金 |
|---|---|---|---|---|
| バックアップ （スナップショットまたは Cloud Storage エクスポート） |
1 回限りまたは定期的に | ソーステーブルのデータと同じ | タイムトラベル期間を超えて元のデータを復元する | スナップショットでは、スナップショット内のデータ変更に対してのみストレージ料金が発生します。 エクスポートでは、標準のストレージ料金が発生する可能性があります。 費用の最適化をご覧ください。 |
| クロスリージョン レプリケーション | 継続的 | リモート | 別のリージョンにレプリカを作成する リージョン間の 1 回限りの移行 |
レプリカにデータを保存するための料金が発生します。 データ レプリケーションの費用が発生します。 |
設計上の考慮事項
このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、費用の最適化、運用効率、パフォーマンスに関する特定の要件を満たすトポロジを開発する際に考慮すべきガイダンスを示します。
セキュリティ、プライバシー、コンプライアンス
このデプロイでは、設計と実装に次のセキュリティ対策が組み込まれています。
- Cloud Run のネットワーク上り（内向き）設定は、インターネットからのアクセスを制限するために、内部トラフィックのみを受け入れます。また、認証済みのユーザーとサービス アカウントのみがサービスを呼び出すことができます。
- 各 Cloud Run サービスと Pub/Sub サブスクリプションは、必要な権限のみが割り当てられた個別のサービス アカウントを使用します。これにより、システムに 1 つのサービス アカウントを使用することに関連するリスクが軽減され、最小権限の原則に従うことができます。
プライバシー上の考慮事項として、このソリューションでは個人を特定できる情報（PII）は収集または処理されません。ただし、ソーステーブルに PII が公開されている場合、それらのテーブルのバックアップにもこの公開データが含まれます。ソースデータの所有者は、ソーステーブル内の PII を保護する責任があります（たとえば、列レベルのセキュリティ、データ マスキング、編集を適用するなど）。バックアップは、ソースデータが保護されている場合にのみ安全です。別の方法として、公開された PII を含むバックアップ データを保持するプロジェクト、データセット、バケットに、承認されたユーザーのみにアクセスを制限する必要な Identity and Access Management（IAM）ポリシーがあることを確認します。
汎用ソリューションであるため、このリファレンス デプロイは、特定の業界の特定の要件に必ずしも準拠しているわけではありません。
信頼性
このセクションでは、信頼性に関する機能と設計上の考慮事項について説明します。
粒度による障害の軽減
数千ものテーブルのバックアップを作成する場合、基盤となる Google Cloud プロダクトの API 上限（たとえば、各プロジェクトのスナップショットとエクスポート オペレーションの上限）に達する可能性があります。ただし、構成ミスやその他の一時的な問題により、1 つのテーブルのバックアップが失敗しても、全体的な実行や他のテーブルのバックアップ機能には影響しません。
潜在的な障害を軽減するため、リファレンス デプロイでは、きめ細かい Cloud Run サービスを使用して処理ステップを分離し、Pub/Sub を介して接続します。テーブル バックアップ リクエストが最後のタガー サービス ステップで失敗した場合、Pub/Sub はこのステップのみを再試行し、プロセス全体を再試行しません。
フローを 1 つの Cloud Run サービスでホストされる複数のエンドポイントではなく、複数の Cloud Run サービスに分割すると、各サービス構成をきめ細かく制御できます。構成のレベルは、サービスの機能と通信する API によって異なります。たとえば、ディスパッチャー サービスは実行ごとに 1 回実行されますが、BigQuery バックアップ スコープ内のすべてのテーブルを一覧表示するにはかなりの時間を要します。そのため、ディスパッチャー サービスには、より高いタイムアウトとメモリの設定が必要です。ただし、BigQuery スナップショットの Cloud Run サービスは、1 回の実行でテーブルごとに 1 回実行され、ディスパッチャー サービスよりも短い時間で完了します。そのため、Cloud Run サービスでは、サービスレベルで異なる構成セットが必要です。
データの整合性
信頼性の高いバックアップ戦略を維持するには、テーブルとビュー間のデータ整合性が重要です。データは継続的に更新および変更されるため、異なるタイミングで作成されたバックアップでは、データセットの異なる状態がキャプチャされる可能性があります。状態の異なるこれらのバックアップは、データを復元するときに不整合を引き起こす可能性があります。特に、同じ機能データセットに属するテーブルで不整合が発生する可能性があります。たとえば、売上テーブルを対応する在庫テーブルとは異なる時点に復元すると、利用可能な在庫の不一致が生じる可能性があります。同様に、複数のテーブルからデータを集計するデータベース ビューは、不整合に特に敏感になる可能性があります。基盤となるテーブルが整合性のある状態であることを確認せずにこれらのビューを復元すると、不正確または誤解を招く結果が生じる可能性があります。したがって、BigQuery のバックアップ ポリシーと頻度を設計する際は、この整合性を考慮し、復元されたデータが特定の時点でのデータセットの実際の状態を正確に反映するようにする必要があります。
たとえば、このリファレンス アーキテクチャのデプロイでは、バックアップ ポリシーの次の 2 つの構成によってデータ整合性が制御されます。これらの構成では、必ずしもすべてのテーブルを同時にバックアップするのではなく、タイム トラベルを使用して正確なテーブル スナップショット時間を計算します。
backup_cron: テーブルがバックアップされる頻度を制御します。実行の開始タイムスタンプは、この実行でバックアップされるすべてのテーブルのタイム トラベル計算の基準点として使用されます。backup_time_travel_offset_days: テーブルの正確なタイム トラベル バージョンを計算するために、過去の日数を基準点（実行開始時刻）から減算する方法を制御します。
自動バックアップの復元
このリファレンス アーキテクチャでは、大規模なバックアップの自動化に重点を置いていますが、これらのバックアップの復元も自動化することを検討できます。この追加の自動化により、復元効率と速度の向上、ダウンタイムの短縮など、バックアップの自動化と同様のメリットが得られます。このソリューションでは、タガーサービスを通じてすべてのバックアップ パラメータと結果が追跡されるため、同様のアーキテクチャを開発して、復元オペレーションを大規模に適用できます。
たとえば、オンデマンド トリガーに基づいて、BigQuery データのスコープをディスパッチャー サービスに送信するソリューションを作成できます。このディスパッチャー サービスは、テーブルごとに 1 つのリクエストを構成サービスにディスパッチします。構成サービスは、特定のテーブルに必要なバックアップ履歴を取得できます。構成サービスは、BigQuery スナップショット復元サービスまたは Cloud Storage 復元サービスに渡して、復元オペレーションを適用できます。最後に、タグ付けサービスは、これらのオペレーションの結果を状態ストアに保存できます。これにより、自動復元フレームワークは、このドキュメントで説明するバックアップ フレームワークと同じ設計目標のメリットを享受できます。
費用の最適化
このアーキテクチャのフレームワークは、全体的な費用最適化のために次のパラメータを設定するバックアップ ポリシーを提供します。
- バックアップ方法: フレームワークは次の 2 つのバックアップ方法を提供します。
- BigQuery スナップショット。ベーステーブルと比較して、更新および削除されたデータに基づいてストレージ費用が発生します。したがって、スナップショットは、追加専用のテーブルや更新が制限されているテーブルで費用対効果が高くなります。
- Cloud Storage への BigQuery エクスポート。標準のストレージ料金が発生します。ただし、切り捨てと読み込みのアプローチに従う大規模なテーブルの場合は、低コストのストレージ クラスでエクスポートとしてバックアップする方が費用対効果が高くなります。
- スナップショットの有効期限: 単一のテーブル スナップショットに有効期間（TTL）を設定して、スナップショットのストレージ コストが無期限に発生しないようにします。テーブルに有効期限がない場合、ストレージ費用は時間の経過とともに増加する可能性があります。
業務の効率化
このセクションでは、運用効率に関する機能と考慮事項について説明します。
きめ細かいスケーラブルなバックアップ ポリシー
このフレームワークの目標の 1 つは、ビジネスのインプットを比較的低く管理可能な状態に保ちながら、ビジネスのアウトプットをスケールアップすることで、運用効率を高めることです。たとえば、出力は定期的にバックアップされるテーブルの数が多いのに対し、入力は維持されるバックアップ ポリシーと構成の数が少ない場合などです。
このフレームワークでは、テーブル レベルでバックアップ ポリシーを許可するだけでなく、データセット、プロジェクト、フォルダ、グローバル レベルでポリシーを許可することもできます。つまり、上位レベル（フォルダやプロジェクトなど）でいくつかの構成を行うだけで、数百または数千のテーブルを定期的に大規模にバックアップできます。
オブザーバビリティ
自動化フレームワークでは、プロセスのステータスを理解することが重要です。たとえば、次の一般的なクエリの情報を確認できます。
- システムが各テーブルに使用するバックアップ ポリシー。
- 各テーブルのバックアップ履歴とバックアップの場所。
- 単一の実行の全体的なステータス（処理されたテーブルの数と失敗したテーブルの数）。
- 1 回の実行で発生した致命的なエラーと、エラーが発生したプロセスのコンポーネントまたはステップ。
この情報を提供するために、デプロイは Cloud Run サービスを使用する各実行ステップで構造化ログを Cloud Logging に書き込みます。ログには、入力、出力、エラー、その他の進行状況のチェックポイントが含まれます。ログシンクは、これらのログを BigQuery テーブルに転送します。一般的なオブザーバビリティのユースケースについて、複数のクエリを実行して実行をモニタリングし、レポートを取得できます。BigQuery のログとクエリの詳細については、BigQuery に転送されたログを表示するをご覧ください。
パフォーマンスの最適化
各実行で数千のテーブルを処理するために、このソリューションはバックアップ リクエストを並列で処理します。ディスパッチャー サービスは、BigQuery バックアップ スコープに含まれるすべてのテーブルを一覧表示し、実行ごとにテーブルごとに 1 つのバックアップ リクエストを生成します。これにより、アプリケーションは数千件のリクエストとテーブルを順次ではなく並行して処理できます。
これらのリクエストの一部は、基盤となる Google Cloud API の上限に達した、ネットワークの問題が発生したなどの一時的な理由で、最初は失敗する可能性があります。リクエストが完了するまで、Pub/Sub は指数バックオフ再試行ポリシーを使用してリクエストを自動的に再試行します。無効なバックアップ先や権限の欠落などの致命的なエラーがある場合、エラーがログに記録され、特定のテーブル リクエストの実行が終了しますが、全体的な実行には影響しません。
上限
このアーキテクチャには、次の割り当てと上限が適用されます。
テーブル スナップショットの場合、指定したバックアップ オペレーション プロジェクトごとに次のようになります。
- 1 つのプロジェクトで最大 100 個のテーブル スナップショット ジョブを同時に実行できます。
- 1 つのプロジェクトで、1 日あたり最大 50,000 個のテーブル スナップショット ジョブを実行できます。
- 1 つのプロジェクトで、テーブルごとに 1 日あたり最大 50 件のテーブル スナップショット ジョブを実行できます。
詳細については、テーブル スナップショットをご覧ください。
エクスポート ジョブ（Cloud Storage へのエクスポート）には、次のことが当てはまります。
- 共有スロットプールを使用すると、プロジェクトから 1 日あたり最大 50 TiB のデータを無料でエクスポートできます。
- 1 つのプロジェクトで 1 日あたり最大 100,000 個のエクスポートを実行できます。この上限を引き上げるには、スロットの予約を作成します。
これらの上限の引き上げの詳細については、エクスポート ジョブをご覧ください。
同時実行数の上限については、このアーキテクチャでは Pub/Sub を使用して、上限を超えたために失敗したリクエストを API で処理されるまで自動的に再試行します。ただし、プロジェクトあたりの 1 日あたりのオペレーション数の他の上限については、割り当て増加のリクエストを行うか、バックアップ オペレーション（スナップショットまたはエクスポート）を複数のプロジェクトに分散することで、緩和できます。オペレーションをプロジェクト間で分散するには、次のデプロイ セクションで説明するようにバックアップ ポリシーを構成します。
デプロイ
このアーキテクチャをデプロイするには、スケーラブルな BigQuery バックアップ自動化をデプロイするをご覧ください。
次のステップ
- BigQuery の詳細:
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者: Karim Wadie | 戦略的クラウド エンジニア
その他の寄稿者:
- サイト信頼性エンジニア | Chris DeForeest
- Eyal Ben Ivri | クラウド ソリューション アーキテクト
- Jason Davenport | デベロッパー アドボケイト
- Jaliya Ekanayake | エンジニアリング マネージャー
- Muhammad Zain | 戦略的クラウド エンジニア