このページは Cloud Translation API によって翻訳されました。

スケーラブルな BigQuery バックアップ自動化をデプロイする

Last reviewed 2024-09-17 UTC

このドキュメントでは、スケーラブルな BigQuery バックアップ自動化をデプロイする方法について説明します。

このドキュメントは、組織でデータポリシーを定義して自動化するクラウドアーキテクト、エンジニア、データガバナンス担当者を対象としています。また、Terraform の使用経験も役に立ちます。

アーキテクチャ

次の図は、自動バックアップのアーキテクチャを示しています。

自動バックアップソリューションのアーキテクチャ。

Cloud Scheduler が実行をトリガーします。ディスパッチャーサービスは、BigQuery API を使用して、スコープ内のテーブルを一覧表示します。ディスパッチャーサービスは、Pub/Sub メッセージを介して、テーブルごとに 1 つのリクエストを構成サービスに送信します。構成サービスは、テーブルのバックアップポリシーを決定し、テーブルごとに 1 つのリクエストを関連する Cloud Run サービスに送信します。Cloud Run サービスは、BigQuery API にリクエストを送信し、バックアップオペレーションを実行します。Pub/Sub はタガーサービスをトリガーします。このサービスは結果をロギングし、Cloud Storage メタデータレイヤのバックアップ状態を更新します。

アーキテクチャの詳細については、スケーラブルな BigQuery バックアップの自動化をご覧ください。

目標

Cloud Run サービスを構築する。
Terraform 変数を構成します。
Terraform スクリプトと手動デプロイスクリプトを実行します。
ソリューションを実行します。

費用

このドキュメントでは、課金対象である次の Google Cloudコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。

新規の Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

ソリューションを再デプロイする場合は、このセクションをスキップできます（新しいコミットの後など）。

このセクションでは、1 回限りのリソースを作成します。

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
デプロイのホストプロジェクトとして使用する新しい Google Cloud プロジェクトを作成する場合は、gcloud projects create コマンドを使用します。
```
   gcloud projects create PROJECT_ID
```
PROJECT_ID は、作成するプロジェクトの ID に置き換えます。
Maven をインストールします。
1. Maven をダウンロードします。
2. Cloud Shell で、Maven を PATH に追加します。
```
export PATH=/DOWNLOADED_MAVEN_DIR/bin:$PATH
```

Cloud Shell で GitHub リポジトリのクローンを作成します。

git clone https://github.com/GoogleCloudPlatform/bq-backup-manager.git

次の環境変数を設定してエクスポートします。

export PROJECT_ID=PROJECT_ID
export TF_SA=bq-backup-mgr-terraform
export COMPUTE_REGION=COMPUTE_REGION
export DATA_REGION=DATA_REGION
export BUCKET_NAME=${PROJECT_ID}-bq-backup-mgr
export BUCKET=gs://${BUCKET_NAME}
export DOCKER_REPO_NAME=docker-repo
export CONFIG=bq-backup-manager
export ACCOUNT=ACCOUNT_EMAIL

gcloud config configurations create $CONFIG
gcloud config set project $PROJECT_ID
gcloud config set account $ACCOUNT
gcloud config set compute/region $COMPUTE_REGION

gcloud auth login
gcloud auth application-default login

次のように置き換えます。

PROJECT_ID: ソリューションのデプロイ先の Google Cloud ホストプロジェクトの ID。
COMPUTE_REGION: Cloud Run や Identity and Access Management（IAM）などのコンピューティングリソースをデプロイする Google Cloud リージョン。
DATA_REGION: データリソース（バケットやデータセットなど）をデプロイする Google Cloud リージョン。
ACCOUNT_EMAIL: ユーザーアカウントのメールアドレス。

API を有効にします。
```
./scripts/enable_gcp_apis.sh
```
このスクリプトは次の API を有効にします。
- Cloud Resource Manager API
- IAM API
- Data Catalog API
- Artifact Registry API
- BigQuery API
- Pub/Sub API
- Cloud Storage API
- Cloud Run Admin API
- Cloud Build API
- Service Usage API
- App Engine Admin API
- Serverless VPC Access API
- Cloud DNS API

Terraform 状態バケットを準備します。

gcloud storage buckets create $BUCKET --project=$PROJECT_ID --location=$COMPUTE_REGION --uniform-bucket-level-access

Terraform サービスアカウントを準備します。
```
./scripts/prepare_terraform_service_account.sh
```

このソリューションで使用するイメージを公開するには、Docker リポジトリを準備します。

gcloud artifacts repositories create $DOCKER_REPO_NAME
  --repository-format=docker \
  --location=$COMPUTE_REGION \
  --description="Docker repository for backups"

インフラストラクチャをデプロイする

始める前にを少なくとも 1 回完了していることを確認します。

このセクションでは、最新のコードベースを Google Cloud 環境にデプロイまたは再デプロイする手順について説明します。

gcloud CLI 構成を有効にする

Cloud Shell で、gcloud CLI 構成を有効にして認証します。

gcloud config configurations activate $CONFIG

gcloud auth login
gcloud auth application-default login

Cloud Run サービスイメージをビルドする

Cloud Shell で、Cloud Run サービスで使用される Docker イメージをビルドしてデプロイします。

export DISPATCHER_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-dispatcher-service:latest
export CONFIGURATOR_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-configurator-service:latest
export SNAPSHOTER_BQ_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-bq-service:latest
export SNAPSHOTER_GCS_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-gcs-service:latest
export TAGGER_IMAGE=${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-tagger-service:latest

./scripts/deploy_services.sh

Terraform 変数を構成する

このデプロイでは、構成とデプロイスクリプトに Terraform を使用します。

Cloud Shell で、このセクションの変数をオーバーライドできる新しい Terraform TFVARS ファイルを作成します。
```
export VARS=FILENAME
.tfvars
```
FILENAME は、作成した変数ファイルの名前（my-variables など）に置き換えます。example-variables ファイルを参照として使用できます。
TFVARS ファイルで、プロジェクト変数を構成します。
```
project = "PROJECT_ID"
compute_region = "COMPUTE_REGION"
data_region = "DATA_REGION"
```
variables.tf ファイルで定義されているデフォルト値を使用するか、値を変更できます。
始める前にで作成して準備した Terraform サービスアカウントを構成します。
```
terraform_service_account =
"bq-backup-mgr-terraform@PROJECT_ID.iam.gserviceaccount.com"
```
作成したアカウントの完全なメールアドレスを使用してください。

以前にビルドしてデプロイしたコンテナイメージを使用するように Cloud Run サービスを構成します。

dispatcher_service_image     = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-dispatcher-service:latest"
configurator_service_image   = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-configurator-service:latest"
snapshoter_bq_service_image  = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-bq-service:latest"
snapshoter_gcs_service_image = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-snapshoter-gcs-service:latest"
tagger_service_image         = "${COMPUTE_REGION}-docker.pkg.dev/${PROJECT_ID}/${DOCKER_REPO_NAME}/bqsm-tagger-service:latest"

このスクリプトは、Terraform が後で作成する Cloud Run サービスで、これらの公開イメージを使用するように Terraform に指示します。

Terraform は、Cloud Run サービスを既存のイメージにリンクするだけです。コードベースからイメージをビルドしません。これは前の手順で完了しているためです。

schedulers 変数で、少なくとも 1 つのスケジューラを定義します。スケジューラは、テーブルレベルのバックアップ cron スケジュールに基づいて、必要なバックアップのテーブルを定期的に一覧表示して確認します。
```
{
name    = "SCHEDULER_NAME"
cron    = "SCHEDULER_CRON"
payload = {
    is_force_run = FORCE_RUN
    is_dry_run   = DRY_RUN

    folders_include_list  = [FOLDERS_INCLUDED]
    projects_include_list = [PROJECTS_INCLUDED]
    projects_exclude_list = [PROJECTS_EXCLUDED]
    datasets_include_list =  [DATASETS_INCLUDED]
    datasets_exclude_list =  [DATASETS_EXCLUDED]
    tables_include_list   =  [TABLES_INCLUDED]
    tables_exclude_list   =  [TABLES_EXCLUDED]
    }
}
```
次のように置き換えます。
- SCHEDULER_NAME: Cloud Scheduler の表示名。
- SCHEDULER_CRON: スケジューラが、個々のバックアップスケジュールに基づいて、バックアップの対象となるテーブルのバックアップの期限が切れているかどうかをチェックする頻度。unix-cron 互換の任意の文字列を指定できます。たとえば、0 * * * * は 1 時間ごとの頻度です。
- FORCE_RUN: ブール値。スケジューラでテーブルの cron スケジュールを使用する場合は、値を false に設定します。true に設定すると、cron 設定に関係なく、スコープ内のすべてのテーブルがバックアップされます。
- DRY_RUN: ブール値。true に設定すると、実際のバックアップオペレーションは実行されません。ログメッセージのみが生成されます。バックアップ費用を発生させずにソリューションをテストしてデバッグする場合は、true を使用します。
- FOLDERS_INCLUDED: BigQuery データを含むフォルダの数値 ID のリスト（例: 1234, 456）。設定すると、ソリューションは指定されたフォルダ内のテーブルをバックアップし、projects_include_list、datasets_include_list、tables_include_list フィールドの設定を無視します。
- PROJECTS_INCLUDED: プロジェクト名のリスト（"project1", "project2" など）。設定すると、ソリューションは指定されたプロジェクトのテーブルをバックアップし、datasets_include_list フィールドと tables_include_list フィールドの設定を無視します。folders_include_list フィールドを設定すると、この設定は無視されます。
- PROJECTS_EXCLUDED: プロジェクト名または正規表現のリスト（例: "project1", "regex:^test_"）。設定すると、ソリューションは指定されたプロジェクトのテーブルのバックアップを作成しません。この設定は、folders_include_list フィールドと組み合わせて使用できます。
- DATASETS_INCLUDED: データセットのリスト（"project1.dataset1", "project1.dataset2" など）。設定すると、ソリューションは指定されたデータセット内のテーブルをバックアップし、tables_include_list フィールドの設定を無視します。folders_include_list フィールドまたは projects_include_list フィールドを設定した場合、この設定は無視されます。
- DATASETS_EXCLUDED: データセットのリストまたは正規表現（例: "project1.dataset1", "regex:.*\\_landing$"）。設定すると、ソリューションは指定されたデータセット内のテーブルのバックアップを作成しません。この設定は、folders_include_list フィールドまたは projects_include_list フィールドと組み合わせて使用できます。
- TABLES_INCLUDED: テーブルのリスト（例: "project1.dataset1.table 1", "project1.dataset2.table2"）。設定すると、ソリューションは指定されたテーブルをバックアップします。folders_include_list、projects_include_list、datasets_include_list フィールドを設定すると、この設定は無視されます。
- TABLES_EXCLUDED: テーブルのリストまたは正規表現（例: "project1.dataset1.table 1", "regex:.*\_test"）。設定すると、ソリューションは指定されたテーブルのバックアップを取得しません。この設定は、folders_include_list、projects_include_list、datasets_include_list の各フィールドと組み合わせて使用できます。
すべての除外リストで、regex:REGULAR_EXPRESSION 形式の正規表現を使用できます。

完全修飾エントリ名（"project.dataset.table" など）が指定された正規表現のいずれかに一致する場合、バックアップスコープから除外されます。

一般的なユースケースは次のとおりです。
- _landing で終わるすべてのデータセット名を除外します: datasets_exclude_list = ["regex:.*\\_landing$"]
- _test、_tst、_bkp、_copy で終わるすべてのテーブルを除外します。 tables_exclude_list = ["regex:.*\_(test|tst|bkp|copy)"]

フォールバックポリシーを定義する

実行ごとに、ソリューションはスコープ内の各テーブルのバックアップポリシーを決定する必要があります。ポリシーの種類の詳細については、バックアップポリシーをご覧ください。このセクションでは、フォールバックポリシーを定義する方法について説明します。

フォールバックポリシーは、default_policy 変数と、さまざまなレベル（フォルダ、プロジェクト、データセット、テーブル）の例外またはオーバーライドのセットで定義されます。このアプローチでは、各テーブルのエントリを必要とせずに、きめ細かい柔軟性が得られます。

使用するバックアップ方法（BigQuery スナップショット、Cloud Storage へのエクスポート、またはその両方）に応じて、追加のポリシーフィールドセットがあります。

TFVARS ファイルの default_policy 変数に、デフォルトポリシーの次の共通フィールドを設定します。
```
fallback_policy = {
  "default_policy" : {
    "backup_cron" : "BACKUP_CRON"
    "backup_method" : "BACKUP_METHOD",
    "backup_time_travel_offset_days" : "OFFSET_DAYS",
    "backup_storage_project" : "BACKUP_STORAGE_PROJECT",
    "backup_operation_project" : "BACKUP_OPERATIONS_PROJECT",
```
次のように置き換えます。
- BACKUP_CRON: テーブルのバックアップ頻度を設定する cron 式（例: 6 時間ごとにバックアップする場合は 0 0 */6 * * * を指定）。これは、Spring-Framework 互換の cron 式である必要があります。
- BACKUP_METHOD: メソッド。BigQuery Snapshot、GCS Snapshot（Cloud Storage へのエクスポートメソッドを使用する場合）、または Both として指定します。後述するように、選択したバックアップ方法ごとに必須フィールドを指定する必要があります。
- OFFSET_DAYS: テーブルのバックアップを開始する時点を決定する過去の日数。値は 0 ～ 7 の数値です。
- BACKUP_STORAGE_PROJECT: すべてのスナップショットとエクスポートオペレーションが保存されるプロジェクトの ID。これは、bq_snapshot_storage_dataset と gcs_snapshot_storage_location が存在するのと同じプロジェクトです。小規模なデプロイではホストプロジェクトを使用できますが、大規模なデプロイでは別のプロジェクトを使用する必要があります。
- BACKUP_OPERATIONS_PROJECT: オプションの設定。すべてのスナップショットとエクスポートオペレーションが実行されるプロジェクトの ID を指定します。このプロジェクトには、スナップショットとエクスポートジョブの割り当てと上限が適用されます。これは backup_storage_project と同じ値にすることができます。設定しない場合、ソリューションはソーステーブルのプロジェクトを使用します。
backup_method として BigQuery Snapshot または Both を指定した場合は、default_policy 変数の共通フィールドの後に次のフィールドを追加します。
```
  "bq_snapshot_expiration_days" : "SNAPSHOT_EXPIRATION",
  "bq_snapshot_storage_dataset" : "DATASET_NAME",
```
次のように置き換えます。
- SNAPSHOT_EXPIRATION: 各スナップショットを保持する日数（例: 15）。
- DATASET_NAME: スナップショットを保存するデータセットの名前（例: backups）。データセットは、backup_storage_project で指定されたプロジェクトにすでに存在している必要があります。

backup_method として GCS Snapshot（Cloud Storage へのエクスポートメソッドを使用するため）または Both を指定した場合は、default_policy 変数に次のフィールドを追加します。

  "gcs_snapshot_storage_location" : "STORAGE_BUCKET",
  "gcs_snapshot_format" : "FILE_FORMAT",
  "gcs_avro_use_logical_types" : AVRO_TYPE,
  "gcs_csv_delimiter" : "CSV_DELIMITER",
  "gcs_csv_export_header" : CSV_EXPORT_HEADER

次のように置き換えます。

STORAGE_BUCKET: エクスポートされたデータを保存する Cloud Storage バケット（gs://bucket/path/ 形式）。例: gs://bucket1/backups/
FILE_FORMAT: BigQuery テーブルを Cloud Storage にエクスポートするために使用されるファイル形式と圧縮。使用可能な値は、CSV、CSV_GZIP、JSON、JSON_GZIP、AVRO、AVRO_DEFLATE、AVRO_SNAPPY、PARQUET、PARQUET_SNAPPY、PARQUET_GZIP です。
AVRO_TYPE: ブール値。false に設定すると、BigQuery の型は文字列としてエクスポートされます。true に設定されている場合、型は対応する Avro 論理型としてエクスポートされます。gcs_snapshot_format が Avro 型形式の場合、このフィールドは必須です。
CSV_DELIMITER: エクスポートされた CSV ファイルに使用される区切り文字。値には ISO-8859-1 の任意の 1 バイト文字を使用できます。\t または tab を使用することで、タブを区切り文字に指定できます。gcs_snapshot_format が CSV 形式の場合、このフィールドは必須です。
CSV_EXPORT_HEADER: ブール値。true に設定すると、列ヘッダーが CSV ファイルにエクスポートされます。gcs_snapshot_format が CSV 形式の場合、このフィールドは必須です。

詳細と Avro 型のマッピングについては、次の表をご覧ください。

BigQuery の型	Avro の論理型
`TIMESTAMP`	`timestamp-micros`（Avro `LONG` をアノテーション）
`DATE`	`date`（Avro `INT` をアノテーション）
`TIME`	`timestamp-micro`（Avro `LONG` をアノテーション）
`DATETIME`	`STRING`（カスタム名前付き論理型 `datetime`）

特定のフォルダ、プロジェクト、データセット、テーブルのオーバーライド変数を追加します。
```
  },
  "folder_overrides" : {
   "FOLDER_NUMBER" : {
   },
  },

  "project_overrides" : {
   "PROJECT_NAME" : {
   }
  },

  "dataset_overrides" : {
   "PROJECT_NAME.DATASET_NAME" : {
   }
  },

  "table_overrides" : {
   "PROJECT_NAME.DATASET_NAME.TABLE_NAME" : {
   }
  }
}
```
次のように置き換えます。
- FOLDER_NUMBER: オーバーライドフィールドを設定するフォルダを指定します。
- PROJECT_NAME: 特定のプロジェクト、データセット、テーブルのオーバーライドフィールドを設定するときに、プロジェクトを指定します。
- DATASET_NAME: 特定のデータセットまたはテーブルのオーバーライドフィールドを設定するときに、データセットを指定します。
- TABLE_NAME: オーバーライドフィールドを設定するテーブルを指定します。
project_overrides 変数の特定のプロジェクトなどのオーバーライドエントリごとに、共通フィールドと、default_policy で指定したバックアップメソッドに必要なフィールドを追加します。

特定のレベルのオーバーライドを設定しない場合は、その変数を空のマップ（project_overrides : {} など）に設定します。

次の例では、BigQuery スナップショットメソッドを使用する特定のテーブルにオーバーライドフィールドを設定しています。
```
  },
  "project_overrides" : {},

  "table_overrides" : {
   "example_project1.dataset1.table1" : {
    "backup_cron" : "0 0 */5 * * *", # every 5 hours each day
    "backup_method" : "BigQuery Snapshot",
    "backup_time_travel_offset_days" : "7",
    "backup_storage_project" : "project name",
    "backup_operation_project" : "project name",
    # bq settings
    "bq_snapshot_expiration_days" : "14",
    "bq_snapshot_storage_dataset" : "backups2"
    },
   }
}
```

フォールバックポリシーの完全な例については、example-variables ファイルをご覧ください。

追加のバックアップオペレーションプロジェクトを構成する

外部構成（テーブルレベルのバックアップポリシー）またはテーブルソースプロジェクトで定義されたバックアッププロジェクトなど、追加のバックアッププロジェクトを指定する場合は、次の変数を構成します。
```
additional_backup_operation_projects = [ADDITIONAL_BACKUPS]
```
ADDITIONAL_BACKUPS は、プロジェクト名のカンマ区切りのリスト（"project1", "project2" など）に置き換えます。テーブルレベルの外部ポリシーを使用せずにフォールバックバックアップポリシーのみを使用する場合は、値を空のリストに設定できます。

このフィールドを追加しない場合、省略可能な backup_operation_project フィールドで指定されたプロジェクトは、バックアッププロジェクトとして自動的に含まれます。

Terraform サービスアカウントの権限を構成する

前の手順では、バックアップオペレーションが実行されるバックアッププロジェクトを構成しました。Terraform は、これらのバックアッププロジェクトにリソースをデプロイする必要があります。

Terraform が使用するサービスアカウントには、指定されたバックアッププロジェクトに必要な権限が付与されている必要があります。

Cloud Shell で、バックアップオペレーションが実行されるすべてのプロジェクトに対する権限をサービスアカウントに付与します。
```
./scripts/prepare_backup_operation_projects_for_terraform.sh BACKUP_OPERATIONS_PROJECT DATA_PROJECTS ADDITIONAL_BACKUPS
```
次のように置き換えます。
- BACKUP_OPERATIONS_PROJECT: フォールバックポリシーとテーブルレベルのポリシーの backup_operation_project フィールドで定義されているプロジェクト。
- DATA_PROJECTS: フォールバックポリシーまたはテーブルレベルのポリシーで backup_operation_project フィールドが定義されていない場合は、それらのソーステーブルのプロジェクトを含めます。
- ADDITIONAL_BACKUPS: additional_backup_operation_projects Terraform 変数で定義されているプロジェクト。

デプロイスクリプトを実行する

Cloud Shell で、Terraform デプロイスクリプトを実行します。

cd terraform

terraform init \
    -backend-config="bucket=${BUCKET_NAME}" \
    -backend-config="prefix=terraform-state" \
    -backend-config="impersonate_service_account=$TF_SA@$PROJECT_ID.iam.gserviceaccount.com"

terraform plan -var-file=$VARS

terraform apply -var-file=$VARS

Firestore の有効期間（TTL）ポリシーを追加します。
```
gcloud firestore fields ttls update expires_at \
    --collection-group=project_folder_cache \
    --enable-ttl \
    --async \
    --project=$PROJECT_ID
```
このソリューションでは、状況に応じて Datastore をキャッシュとして使用します。費用を節約し、ルックアップのパフォーマンスを向上させるため、TTL ポリシーを使用すると、Firestore は期限切れのエントリを自動的に削除できます。

送信元と宛先へのアクセスを設定する

Cloud Shell で、ソリューションで使用されるサービスアカウントの次の変数を設定します。

export SA_DISPATCHER_EMAIL=dispatcher@${PROJECT_ID}.iam.gserviceaccount.com
export SA_CONFIGURATOR_EMAIL=configurator@${PROJECT_ID}.iam.gserviceaccount.com
export SA_SNAPSHOTER_BQ_EMAIL=snapshoter-bq@${PROJECT_ID}.iam.gserviceaccount.com
export SA_SNAPSHOTER_GCS_EMAIL=snapshoter-gcs@${PROJECT_ID}.iam.gserviceaccount.com
export SA_TAGGER_EMAIL=tagger@${PROJECT_ID}.iam.gserviceaccount.com

Terraform でデフォルト名を変更した場合は、サービスアカウントのメールアドレスを更新します。

folders_include_list フィールドを設定し、特定のフォルダを含めるように BigQuery スキャンのスコープを設定する場合は、フォルダレベルで必要な権限を付与します。
```
./scripts/prepare_data_folders.sh FOLDERS_INCLUDED
```
アプリケーションが異なるプロジェクトで必要なタスクを実行できるようにするには、これらの各プロジェクトに必要な権限を付与します。
```
./scripts/prepare_data_projects.sh DATA_PROJECTS
./scripts/prepare_backup_storage_projects.sh BACKUP_STORAGE_PROJECT
./scripts/prepare_backup_operation_projects.sh BACKUP_OPERATIONS_PROJECT
```
次のように置き換えます。
- DATA_PROJECTS: バックアップするソーステーブルを含むデータプロジェクト（またはソースプロジェクト）（例: project1 project2）。次のプロジェクトを含めます。
  - Terraform 変数 schedulers の包含リストで指定されたプロジェクト。
  - ホストプロジェクトのテーブルをバックアップする場合は、ホストプロジェクトを含めます。
- BACKUP_STORAGE_PROJECT: ソリューションがバックアップを保存するバックアップストレージプロジェクト（または宛先プロジェクト）（例: project1 project2）。次のフィールドで指定されたプロジェクトを含める必要があります。
  - すべてのフォールバックポリシーの backup_storage_project フィールド。
  - すべてのテーブルレベルのポリシーの backup_storage_project フィールド。
  複数のフィールドで使用されているバックアップストレージプロジェクト、または移行元と移行先の両方のプロジェクトとして使用されているバックアップストレージプロジェクトを含めます
- BACKUP_OPERATIONS_PROJECT: ソリューションがバックアップオペレーションを実行するデータオペレーションプロジェクト（例: project1 project2）。次のフィールドで指定されたプロジェクトを含める必要があります。
  - すべてのフォールバックポリシーの backup_operation_project フィールド。
  - BigQuery スキャンのスコープ内のすべての包含リスト（backup_operation_project フィールドを設定していない場合）。
  - すべてのテーブルレベルのポリシーの backup_operation_project フィールド。
  複数のフィールドで使用されているバックアップオペレーションプロジェクト、またはソースプロジェクトと宛先プロジェクトの両方として使用されているバックアップオペレーションプロジェクトを含めます。
列レベルのアクセス制御を使用するテーブルの場合は、テーブルで使用されているすべてのポリシータグの分類（存在する場合）を特定し、ソリューションのサービスアカウントにテーブルデータへのアクセス権を付与します。
```
TAXONOMY="projects/TAXONOMY_PROJECT/locations/TAXONOMY_LOCATION/taxonomies/TAXONOMY_ID"

gcloud data-catalog taxonomies add-iam-policy-binding \
$TAXONOMY \
--member="serviceAccount:${SA_SNAPSHOTER_BQ_EMAIL}" \
--role='roles/datacatalog.categoryFineGrainedReader'

gcloud data-catalog taxonomies add-iam-policy-binding \
$TAXONOMY \
--member="serviceAccount:${SA_SNAPSHOTER_GCS_EMAIL}" \
--role='roles/datacatalog.categoryFineGrainedReader'
```
次のように置き換えます。
- TAXONOMY_PROJECT: ポリシータグの分類体系内のプロジェクト ID
- TAXONOMY_LOCATION: ポリシータグの分類で指定されたロケーション
- TAXONOMY_ID: ポリシータグの分類の分類 ID
ポリシータグの分類ごとに、前の手順を繰り返します。

ソリューションを実行する

ソリューションをデプロイしたら、次のセクションでソリューションの実行と管理を行います。

テーブルレベルのバックアップポリシーを設定する

Cloud Shell で、必要なフィールドを含むテーブルレベルのポリシーを作成し、ポリシーの Cloud Storage バケットにポリシーを保存します。

# Use the default backup policies bucket unless overwritten in the .tfvars
export POLICIES_BUCKET=${PROJECT_ID}-bq-backup-manager-policies

# set target table info
export TABLE_PROJECT='TABLE_PROJECT'
export TABLE_DATASET='TABLE_DATASET'
export TABLE='TABLE_NAME'

# Config Source must be 'MANUAL' when assigned this way
export BACKUP_POLICY="{
'config_source' : 'MANUAL',
'backup_cron' : 'BACKUP_CRON',
'backup_method' : 'BACKUP_METHOD',
'backup_time_travel_offset_days' : 'OFFSET_DAYS',
'backup_storage_project' : 'BACKUP_STORAGE_PROJECT',
'backup_operation_project' : 'BACKUP_OPERATION_PROJECT',
'gcs_snapshot_storage_location' : 'STORAGE_BUCKET',
'gcs_snapshot_format' : 'FILE_FORMAT',
'gcs_avro_use_logical_types' : 'AVRO_TYPE',
'bq_snapshot_storage_dataset' : 'DATASET_NAME',
'bq_snapshot_expiration_days' : 'SNAPSHOT_EXPIRATION'
}"

# File name MUST BE backup_policy.json
echo $BACKUP_POLICY >> backup_policy.json

gcloud storage cp backup_policy.json gs://${POLICIES_BUCKET}/policy/project=${TABLE_PROJECT}/dataset=${TABLE_DATASET}/table=${TABLE}/backup_policy.json

次のように置き換えます。

TABLE_PROJECT: テーブルが存在するプロジェクト
TABLE_DATASET: テーブルのデータセット
TABLE_NAME: テーブルの名前。

バックアップオペレーションをトリガーする

前に構成した Cloud Scheduler ジョブは、cron 式に基づいて自動的に実行されます。

Google Cloud コンソールでジョブを手動で実行することもできます。詳細については、ジョブを実行するをご覧ください。

モニタリングと報告

ホストプロジェクト（PROJECT_ID）を選択した状態で、BigQuery Studio で次のクエリを実行して、レポートと情報を取得できます。

各実行の進行状況の統計情報を取得します（進行中の実行を含む）。
```
SELECT * FROM `bq_backup_manager.v_run_summary_counts`
```
単一の実行のすべての致命的（再試行不可）エラーを取得します。
```
SELECT * FROM `bq_backup_manager.v_errors_non_retryable`
WHERE run_id = 'RUN_ID'
```
RUN_ID は、実行の ID に置き換えます。

テーブルのすべての実行とその実行情報を取得します。

SELECT * FROM `bq_backup_manager.v_errors_non_retryable`
WHERE tablespec = 'project.dataset.table'

grouped バージョンを指定することもできます。

SELECT * FROM `bq_backup_manager.v_audit_log_by_table_grouped`, UNNEST(runs) r
WHERE r.run_has_retryable_error = FALSE

デバッグ用に、各サービス呼び出しの詳細なリクエストとレスポンスの情報を取得できます。

SELECT
jsonPayload.unified_target_table AS tablespec,
jsonPayload.unified_run_id AS run_id,
jsonPayload.unified_tracking_id AS tracking_id,
CAST(jsonPayload.unified_is_successful AS BOOL) AS configurator_is_successful,
jsonPayload.unified_error AS configurator_error,
CAST(jsonPayload.unified_is_retryable_error AS BOOL) AS configurator_is_retryable_error,
CAST(JSON_VALUE(jsonPayload.unified_input_json, '$.isForceRun') AS BOOL) AS is_force_run,
CAST(JSON_VALUE(jsonPayload.unified_output_json, '$.isBackupTime') AS BOOL) AS is_backup_time,
JSON_VALUE(jsonPayload.unified_output_json, '$.backupPolicy.method') AS backup_method,
CAST(JSON_VALUE(jsonPayload.unified_input_json, '$.isDryRun') AS BOOL) AS is_dry_run,
jsonPayload.unified_input_json AS request_json,
jsonPayload.unified_output_json AS response_json
FROM `bq_backup_manager.run_googleapis_com_stdout`
WHERE jsonPayload.global_app_log = 'UNIFIED_LOG'
-- 1= dispatcher, 2= configurator, 3=bq snapshoter, -3=gcs snapshoter and 4=tagger
AND jsonPayload.unified_component = "2"

フォールバックに基づいてシステムによって手動で追加または割り当てられたバックアップポリシーを取得します。
```
SELECT * FROM `bq_backup_manager.ext_backup_policies`
```

制限事項

backup_operation_project フィールドで指定された各プロジェクトの上限と割り当ての詳細については、上限をご覧ください。

クリーンアップ

このデプロイで使用したリソースについて、 Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトを削除する

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

新しいリソースを削除する

プロジェクトを削除する代わりに、この手順で作成したリソースを削除することもできます。

Cloud Shell で、Terraform リソースを削除します。
```
terraform destroy -var-file="${VARS}"
```
このコマンドは、ほとんどのリソースを削除します。削除するすべてのリソースが削除されていることを確認します。

次のステップ

BigQuery の詳細:
- BigQuery テーブルスナップショット
- Cloud Storage への BigQuery テーブルのエクスポート
Cloud アーキテクチャセンターで、リファレンスアーキテクチャ、図、ベストプラクティスを確認する。

寄稿者

著者: Karim Wadie | 戦略的クラウドエンジニア

その他の寄稿者:

サイト信頼性エンジニア | Chris DeForeest
Eyal Ben Ivri | クラウドソリューションアーキテクト
Jason Davenport | デベロッパーアドボケイト
Jaliya Ekanayake | エンジニアリングマネージャー
Muhammad Zain | 戦略的クラウドエンジニア

スケーラブルな BigQuery バックアップ自動化をデプロイする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

アーキテクチャ

目標

費用

始める前に

インフラストラクチャをデプロイする

gcloud CLI 構成を有効にする

Cloud Run サービス イメージをビルドする

Terraform 変数を構成する

フォールバック ポリシーを定義する

追加のバックアップ オペレーション プロジェクトを構成する

Terraform サービス アカウントの権限を構成する

デプロイ スクリプトを実行する

送信元と宛先へのアクセスを設定する

ソリューションを実行する

テーブルレベルのバックアップ ポリシーを設定する

バックアップ オペレーションをトリガーする

モニタリングと報告

制限事項

クリーンアップ

プロジェクトを削除する

新しいリソースを削除する

次のステップ

寄稿者

スケーラブルな BigQuery バックアップ自動化をデプロイする

Cloud Run サービスイメージをビルドする

フォールバックポリシーを定義する

追加のバックアップオペレーションプロジェクトを構成する

Terraform サービスアカウントの権限を構成する

デプロイスクリプトを実行する

テーブルレベルのバックアップポリシーを設定する

バックアップオペレーションをトリガーする