このアーキテクチャは、BigQuery バックアップ戦略の開発に役立つフレームワークとリファレンス デプロイを提供します。この推奨フレームワークとその自動化により、組織は次のことができます。
- 組織の障害復旧の目標に準拠する。
- 人為的なミスによって失われたデータを復元します。
- 規制を遵守する。
- 運用効率を高める。
BigQuery データのスコープに、フォルダ、プロジェクト、データセット、テーブルを含める(または除外する)ことができます。この推奨アーキテクチャでは、反復的なバックアップ オペレーションを大規模に自動化する方法を示します。テーブルごとに、BigQuery スナップショットと BigQuery から Cloud Storage へのエクスポートの 2 つのバックアップ方法を使用できます。
このドキュメントは、組織でデータポリシーを定義して自動化したいクラウド アーキテクト、エンジニア、データ ガバナンス担当者を対象としています。
アーキテクチャ
次の図は、自動バックアップのアーキテクチャを示しています。
上の図に示すワークフローには、次のフェーズが含まれています。
- Cloud Scheduler は、Pub/Sub メッセージを使用してディスパッチャ サービスの実行をトリガーします。このメッセージには、含める BigQuery データと除外する BigQuery データのスコープが含まれています。実行は cron 式を使用してスケジュールされます。
- Cloud Run 上に構築されたディスパッチャ サービスは、BigQuery API を使用して BigQuery スコープ内のテーブルを一覧表示します。
- ディスパッチャ サービスは、Pub/Sub メッセージを通じて、テーブルごとに 1 つのリクエストをコンフィギュレータ サービスに送信します。
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 スナップショット: ベーステーブルと比較して更新および削除されたデータに基づいてストレージ費用が発生します。したがって、追加専用または更新が制限されているテーブルでは、スナップショットの方が費用対効果が高くなります。
- BigQuery から Cloud Storage へのエクスポート。標準のストレージ料金が発生します。ただし、切り捨てと読み込みのアプローチに従う大規模なテーブルの場合は、低価格のストレージ クラスでエクスポートとしてバックアップする方が費用対効果が高くなります。
- スナップショットの有効期限: スナップショットのストレージ コストが無期限に発生しないように、有効期間(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 | 戦略的クラウド エンジニア