このページは 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 ユーザーは無料トライアルをご利用いただける場合があります。

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

始める前に

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

このセクションでは、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 の状態バケットを準備します。

gsutil mb -p $PROJECT_ID -l $COMPUTE_REGION -b on $BUCKET

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

gsutil 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`
```
1 回の実行で発生したすべての致命的なエラー（再試行できないエラー）を取得します。
```
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）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

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

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

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

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

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

次のステップ

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

寄稿者

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

その他の寄稿者:

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

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

アーキテクチャ

目標

料金

始める前に

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

gcloud CLI 構成を有効にする

Cloud Run サービス イメージを作成する

Terraform 変数を構成する

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

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

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

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

ソースと宛先へのアクセスを設定する

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

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

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

モニタリングと報告

制限事項

クリーンアップ

プロジェクトの削除

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

次のステップ

寄稿者

Cloud Run サービスイメージを作成する

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

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

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

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

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

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