이 문서에서는 확장 가능한 BigQuery 백업 자동화를 배포하는 방법을 설명합니다.
이 문서는 조직에서 데이터 정책을 정의하고 자동화하려는 클라우드 설계자, 엔지니어, 데이터 거버넌스 책임자를 대상으로 합니다. Terraform 사용 경험이 도움이 됩니다.
아키텍처
다음 다이어그램은 자동 백업 아키텍처를 보여줍니다.
Cloud Scheduler가 실행을 트리거합니다. BigQuery API를 사용하는 전달 서비스는 범위 내 테이블을 나열합니다. 디스패처 서비스는 Pub/Sub 메시지를 통해 구성기 서비스에 각 테이블에 대한 요청을 하나씩 제출합니다. 구성 도구 서비스는 테이블의 백업 정책을 결정한 후 각 테이블에 대해 하나의 요청을 관련 Cloud Run 서비스에 제출합니다. 그러면 Cloud Run 서비스가 BigQuery API에 요청을 제출하고 백업 작업을 실행합니다. Pub/Sub은 결과를 로깅하고 Cloud Storage 메타데이터 영역에서 백업 상태를 업데이트하는 태그 지정자 서비스를 트리거합니다.
아키텍처에 관한 자세한 내용은 확장 가능한 BigQuery 백업 자동화를 참고하세요.
목표
- Cloud Run 서비스 빌드
- Terraform 변수를 구성합니다.
- Terraform 및 수동 배포 스크립트를 실행합니다.
- 솔루션을 실행합니다.
비용
이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
- BigQuery
- Pub/Sub
- Cloud Logging
- Cloud Run
- Cloud Storage
- Cloud Scheduler
- Firestore in Datastore mode (Datastore)
프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.
이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참고하세요.
시작하기 전에
솔루션을 다시 배포하는 경우 이 섹션을 건너뛸 수 있습니다 (예: 새 커밋 후).
이 섹션에서는 일회성 리소스를 만듭니다.
In the Google Cloud console, activate Cloud Shell.
배포의 호스트 프로젝트로 사용할 새 Google Cloud 프로젝트를 만들려면
gcloud projects create
명령어를 사용합니다.gcloud projects create
PROJECT_ID PROJECT_ID를 만들려는 프로젝트의 ID로 바꿉니다.
Maven을 설치합니다.
- Maven을 다운로드합니다.
Cloud Shell에서
PATH
에 Maven을 추가합니다.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
- 서버리스 VPC 액세스 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"
인프라 배포하기
시작하기 전에를 한 번 이상 완료했는지 확인합니다.
이 섹션에서는 최신 코드베이스를 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 .tfvarsFILENAME을 만든 변수 파일 이름 (예:
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
변수에서 하나 이상의 스케줄러를 정의합니다. 스케줄러는 테이블 수준 백업 크론 일정에 따라 주기적으로 필요한 백업 테이블을 나열하고 확인합니다.{ 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 * * * *
은 시간당 빈도입니다. - FORCE_RUN: 불리언 값입니다. 스케줄러가 테이블의 크론 일정을 사용하도록 하려면 값을
false
로 설정합니다.true
로 설정하면 크론 설정과 관계없이 범위 내의 모든 테이블이 백업됩니다. - 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: 테이블이 백업되는 빈도를 설정하는 크론 표현식입니다 (예: 6시간마다 백업하는 경우
0 0 */6 * * *
지정). Spring-Framework 호환 크론 표현식이어야 합니다. - 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_CRON: 테이블이 백업되는 빈도를 설정하는 크론 표현식입니다 (예: 6시간마다 백업하는 경우
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
에 지정된 프로젝트에 데이터 세트가 이미 있어야 합니다.
- SNAPSHOT_EXPIRATION: 각 스냅샷을 보관할 일수입니다 (예:
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 단일 바이트 문자여야 합니다.
\t
또는tab
을 사용하여 탭 구분 기호를 지정할 수 있습니다.gcs_snapshot_format
가 CSV 유형 형식인 경우 이 필드는 필수입니다. - CSV_EXPORT_HEADER: 불리언 값입니다.
true
로 설정하면 열 헤더가 CSV 파일로 내보내집니다. 이 필드는gcs_snapshot_format
가 CSV 유형 형식인 경우에 필요합니다.
자세한 내용과 Avro 유형 매핑은 다음 표를 참고하세요.
BigQuery 유형 Avro 논리 유형 TIMESTAMP
timestamp-micros
(AvroLONG
에 주석 추가)DATE
date
(AvroINT
주석)TIME
timestamp-micro
(AvroLONG
에 주석 추가)DATETIME
STRING
(맞춤 이름이 지정된 논리 유형datetime
)- STORAGE_BUCKET: 내보낸 데이터를 저장할 Cloud Storage 버킷이며
특정 폴더, 프로젝트, 데이터 세트, 테이블의 재정의 변수를 추가합니다.
}, "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 변수에 정의된 모든 프로젝트입니다.
- BACKUP_OPERATIONS_PROJECT: 대체 정책 및 테이블 수준 정책의
배포 스크립트 실행
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.shBACKUP_STORAGE_PROJECT ./scripts/prepare_backup_operation_projects.shBACKUP_OPERATIONS_PROJECT 다음을 바꿉니다.
DATA_PROJECTS: 백업하려는 소스 테이블이 포함된 데이터 프로젝트 (또는 소스 프로젝트)(예:
project1 project2
)입니다. 다음 프로젝트를 포함합니다.- Terraform 변수
schedulers
의 포함 목록에 지정된 프로젝트입니다. - 호스트 프로젝트의 테이블을 백업하려면 호스트 프로젝트를 포함합니다.
- Terraform 변수
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 작업은 크론 표현식을 기반으로 자동으로 실행됩니다.
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 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트는 유지하되 개별 리소스를 삭제하세요.
프로젝트 삭제
- In the Google Cloud console, go to the Manage resources page.
- 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에 대해 자세히 알아보세요.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.
참여자
저자: 카림 와디 | 전략적 클라우드 엔지니어
기타 참여자:
- 크리스 디포레스트 | 사이트 안정성 엔지니어
- Eyal Ben Ivri | 클라우드 솔루션 설계자
- Jason Davenport | 개발자 애드보킷
- 잘리야 에카나야케 | 엔지니어링 관리자
- 무함마드 자인 | 전략적 클라우드 엔지니어