이 아키텍처는 BigQuery 백업 전략을 개발하는 데 도움이 되는 프레임워크 및 참조 배포를 제공합니다. 여기에서 권장되는 프레임워크와 자동화 기능은 조직에서 다음을 수행하는 데 도움을 줄 수 있습니다.
- 조직의 재해 복구 목표를 준수합니다.
- 인적 오류로 인해 손실된 데이터를 복구합니다.
- 규정을 준수합니다.
- 운영 효율성을 개선합니다.
BigQuery 데이터 범위에는 폴더, 프로젝트, 데이터 세트, 테이블이 포함(또는 제외)될 수 있습니다. 이 권장 아키텍처는 반복되는 백업 운영을 대규모로 자동화하는 방법을 보여줍니다. 각 테이블에 BigQuery 스냅샷 및 Cloud Storage로 BigQuery 내보내기의 2가지 백업 방법을 사용할 수 있습니다.
이 문서는 조직에서 데이터 정책을 정의하고 자동화하려는 클라우드 설계자, 엔지니어, 데이터 거버넌스 관리자를 대상으로 합니다.
아키텍처
다음 다이어그램은 자동화된 백업 아키텍처를 보여줍니다.
위 다이어그램에 표시된 워크플로에는 다음 단계가 포함됩니다.
- Cloud Scheduler는 포함 및 제외된 BigQuery 데이터 범위가 포함된 Pub/Sub 메시지를 통해 디스패처 서비스에 대해 실행 작업을 트리거합니다. 실행 작업은 크론 표현식을 사용하여 예약됩니다.
- Cloud Run에서 빌드되는 디스패처 서비스는 BigQuery API를 사용하여 BigQuery 범위 내에 있는 테이블을 나열합니다.
- 디스패처 서비스는 Pub/Sub 메시지를 통해 각 테이블당 하나의 요청을 구성기 서비스에 제출합니다.
Cloud Run 구성기 서비스는 다음 정의된 옵션 중 하나를 사용하여 테이블의 백업 정책을 계산합니다.
- 데이터 소유자가 정의한 테이블 수준 정책
- 정책이 정의되지 않은 테이블에 대해 데이터 거버넌스 관리자가 정의한 대체 정책
백업 정책에 대한 자세한 내용은 백업 정책을 참조하세요.
구성기 서비스는 계산된 백업 정책을 기반으로 각 테이블당 하나의 요청을 다음 서비스에 제출합니다.
백업 방법에 따라 다음 커스텀 Cloud Run 서비스 중 하나가 BigQuery API에 요청을 제출하고 백업 프로세스를 실행합니다.
- BigQuery 스냅샷은 테이블을 스냅샷으로 백업합니다.
- 데이터 내보내기를 위한 서비스는 테이블을 Cloud Storage에 대한 데이터 내보내기로 백업합니다.
백업 방법이 테이블 데이터 내보내기일 때 Cloud Logging 로그 싱크는 다음 단계의 비동기 실행을 사용 설정하기 위해 내보내기 작업 완료 이벤트를 리슨합니다.
백업 서비스가 작업을 완료한 후 Pub/Sub가 태그 지정 서비스를 트리거합니다.
각 테이블에 대해 태그 지정 서비스는 백업 서비스 결과를 로깅하고 Cloud Storage 메타데이터 레이어에서 백업 상태를 업데이트합니다.
사용 제품
이 참조 아키텍처에는 다음과 같은 Google Cloud 제품이 사용됩니다.
- BigQuery: 머신러닝 지리 정보 분석 및 비즈니스 인텔리전스와 같은 기본 제공 기능으로 데이터를 관리 및 분석하는 데 도움이 되는 엔터프라이즈 데이터 웨어하우스입니다.
- Cloud Logging: 스토리지, 검색, 분석, 알림을 지원하는 실시간 로그 관리 시스템입니다.
- Pub/Sub: 메시지 생성 서비스를 메시지 처리 서비스와 분리하는 비동기식의 확장 가능한 메시징 서비스입니다.
- Cloud Run: Google의 확장 가능한 인프라에서 직접 컨테이너를 실행할 수 있게 해주는 서버리스 컴퓨팅 플랫폼입니다.
- Cloud Storage: 다양한 데이터 유형에 적합한 저비용, 무제한 객체 저장소입니다. Google Cloud내부 및 외부에서 데이터에 액세스할 수 있고 중복성을 위해 여러 위치에 복제됩니다.
- Cloud Scheduler: 정의된 시간 또는 일정 간격으로 예약된 작업 단위를 실행하도록 설정할 수 있는 완전 관리형 엔터프라이즈급 크론 작업 스케줄러입니다.
- Datastore: 웹 및 모바일 애플리케이션을 위한 확장 가능한 NoSQL 데이터베이스입니다.
사용 사례
이 섹션에서는 이 아키텍처를 사용할 수 있는 사용 사례를 보여줍니다.
백업 자동화
예를 들어 귀사는 엄격한 규정을 준수해야 하는 규제 업계에 속해 있고 BigQuery를 기본 데이터 웨어하우스로 사용할 수 있습니다. 귀사가 소프트웨어 개발, 코드 검토, 출시 엔지니어링 부문의 권장사항을 따르더라도 여전히 인적 오류로 인해 데이터 손실 또는 데이터 손상이 발생할 위험이 있습니다. 규제 업계에서는 가능한한 이러한 위험을 최소화해야 합니다.
이러한 인적 오류에는 다음이 포함됩니다.
- 실수로 인한 테이블 삭제
- 잘못된 데이터 파이프라인 로직으로 인한 데이터 손상
이러한 유형의 인적 오류는 일반적으로 최대 7일 전까지 데이터를 복구할 수 있는 시간 이동 기능으로 해결할 수 있습니다. 또한 BigQuery는 삭제된 데이터가 시간 이동 기간 이후 추가 7일 동안 장애 안전 스토리지에 보관되는 장애 안전 기간을 제공합니다. 이 데이터는 Cloud Customer Care를 통한 긴급 복구에 사용할 수 있습니다. 하지만 회사에서 적정 기간 내에 오류를 찾아서 해결하지 않으면 삭제된 데이터를 마지막으로 안정적이던 상태로부터 더 이상 복구할 수 없습니다.
이를 해결하기 위해서는 소스 데이터에서 다시 생성할 수 없는 모든 BigQuery 테이블을 정기적으로 백업하는 것이 좋습니다. 여기에는 시간이 지남에 따라 비즈니스 로직이 변경되는 과거 레코드와 KPI가 포함됩니다.
회사에서 수십 개 정도의 테이블은 기본 스크립트를 사용하여 백업할 수 있습니다. 하지만 조직 내에서 수백 또는 수천 개가 넘는 테이블을 정기적으로 백업하려면 다음과 같은 기능의 확장 가능한 자동화 솔루션이 필요합니다.
- 다양한 Google Cloud API 한도를 처리합니다.
- 백업 정책을 정의하기 위한 표준화된 프레임워크를 제공합니다.
- 백업 작업에 대해 투명성 및 모니터링 기능을 제공합니다.
백업 정책
회사에서는 또한 다음과 같은 사용자 그룹에 따라 백업 정책을 정의해야 할 수 있습니다.
- 테이블에 가장 익숙한 데이터 소유자는 적절한 테이블 수준 백업 정책을 설정할 수 있습니다.
- 데이터 거버넌스 팀은 테이블 수준 정책이 없는 테이블을 지원하기 위한 대체 정책을 보장합니다. 대체 정책은 회사의 데이터 보관 규정에 따라 특정 데이터 세트, 프로젝트, 폴더가 백업되도록 보장합니다.
이 참조 아키텍처를 배포하는 데 있어서 테이블의 백업 정책을 정의하는 방법은 두 가지가 있으며, 이 둘은 함께 사용할 수 있습니다.
데이터 소유자 구성(분산형): 테이블에 수동으로 연결되는 테이블 수준 백업 정책입니다.
- 데이터 소유자는 일반 버킷에 저장되는 테이블 수준 JSON 파일을 정의합니다.
- 수동 정책은 솔루션에서 테이블의 백업 정책을 결정할 때 대체 정책보다 우선 적용됩니다.
- 배포에 대한 자세한 내용은 테이블 수준 백업 정책 설정을 참조하세요.
조직 기본 구성(중앙 집중형): 수동으로 연결된 정책이 없는 테이블에만 적용되는 대체 정책입니다.
- 데이터 거버넌스 팀은 솔루션의 일환으로 Terraform에서 중앙 JSON 파일을 정의합니다.
- 대체 정책은 폴더, 프로젝트, 데이터 세트, 테이블 수준에 대한 기본 백업 전략을 제공합니다.
- 배포에 대한 자세한 내용은 대체 백업 정책 정의를 참조하세요.
백업과 복제 비교
백업 프로세스는 데이터가 손실 또는 손상되었을 때 복원할 수 있도록 특정 시점에 테이블 데이터의 사본을 만듭니다. 백업은 일회성으로 또는 반복적으로(예약된 쿼리 또는 워크플로 사용) 실행할 수 있습니다. BigQuery에서는 스냅샷을 사용하여 특정 시점에 백업을 생성할 수 있습니다. 스냅샷을 사용하면 소스 데이터와 동일한 스토리지 위치 내에서 7일 간의 시간 이동 기간 이상까지 데이터 사본을 유지할 수 있습니다. BigQuery 스냅샷은 리전 오류를 복구하는 것 보다는 데이터 손실 또는 손상으로 이어지는 인적 오류 이후에 데이터를 복구하는 데 특히 유용합니다. BigQuery는 버전에 따라 99.9%~99.99%까지 서비스 수준 목표(SLO)를 제공합니다.
반면에 복제는 데이터베이스의 변경 사항을 다른 위치에 있는 보조(또는 복제본) 데이터베이스로 복사하는 지속적인 프로세스입니다. BigQuery에서 리전 간 복제는 소스 데이터 리전과 다른 보조 Google Cloud 리전에 데이터의 읽기 전용 사본을 생성함으로써 지리적 중복성을 제공하는 데 도움이 될 수 있습니다. 하지만 BigQuery 리전 간 복제는 전체 리전 중단 시나리오를 위한 재해 복구 계획용으로 의도되지 않았습니다. 리전 장애 시 복원력을 위해서는 BigQuery 관리형 재해 복구를 사용하는 것이 좋습니다.
BigQuery 리전 간 복제는 데이터 소비자에게 가까운 리전에서 데이터의 동기화된 읽기 전용 사본을 제공합니다. 이러한 데이터 사본을 사용하면 동일한 리전 내에서 조인을 빠르게 수행할 수 있으며 리전 간 데이터 이동으로 인한 트래픽과 비용을 방지할 수 있습니다. 하지만 인적 오류로 인해 데이터 손상이 발생한 경우에는 손상된 데이터가 복제본에 자동으로 복사되기 때문에 복제만 사용해서는 복구하는 데 도움이 되지 않습니다. 이러한 경우에는 시점 백업(스냅샷)이 더 나은 방법입니다.
다음 표에서는 백업 방법과 복제 간의 차이를 요약해서 보여줍니다.
| 방법 | 빈도 | 스토리지 위치 | 사용 사례 | 비용 |
|---|---|---|---|---|
| 백업 (스냅샷 또는 Cloud Storage 내보내기) |
일회 또는 반복 | 소스 테이블 데이터와 동일 | 시간 이동 기간 이상까지 원본 데이터 복원 | 스냅샷에서 데이터 변경 사항에 대한 스토리지 비용만 발생 내보내기 시 표준 스토리지 비용 발생 가능 비용 최적화 참조 |
| 리전 간 복제 | 지속적 | 원격 | 다른 리전에 복제본 생성 리전 간 일회성 마이그레이션 |
복제본에서 데이터 저장 비용 발생 데이터 복제 비용 발생 |
설계 고려사항
이 섹션에서는 이 참조 아키텍처를 사용해서 보안, 안정성, 비용 최적화, 운영 효율성, 성능 관련 특정 요구사항을 충족하는 토폴로지를 개발할 때 고려할 사항을 안내합니다.
보안, 개인 정보 보호, 규정 준수
이 배포에는 설계 및 구현 시 다음과 같은 보안 측정 방법이 사용됩니다.
- Cloud Run의 네트워크 인그레스 설정에서는 인터넷 액세스를 제한하기 위해 내부 트래픽만 허용됩니다. 또한 인증된 사용자 및 서비스 계정만 서비스를 호출할 수 있습니다.
- 각 Cloud Run 서비스와 Pub/Sub 구독에는 필요한 권한만 할당된 개별 서비스 계정이 사용됩니다. 이렇게 하면 시스템에 하나의 서비스 계정을 사용할 때와 관련된 위험을 줄이고 최소 권한의 원칙을 따를 수 있습니다.
개인 정보 보호를 고려해서 이 솔루션은 개인 식별 정보(PII)를 수집하거나 처리하지 않습니다. 하지만 소스 테이블에서 PII가 노출된 경우 해당 테이블로부터 생성된 백업에도 이러한 노출된 데이터가 포함됩니다. 소스 데이터 소유자는 열 수준 보안, 데이터 마스킹, 수정 등을 통해 소스 테이블의 모든 PII를 보호해야 합니다. 백업 보안은 소스 데이터가 안전한 경우에만 보장됩니다. 또 다른 방법은 노출된 PII와 함께 백업 데이터가 포함된 프로젝트, 데이터 세트, 버킷에 승인된 사용자만 액세스할 수 있도록 제한하는 필요한 Identity and Access Management(IAM) 정책을 설정하는 것입니다.
이 참조 배포는 범용 솔루션이므로 특정 업계의 요구사항을 반드시 준수하지는 않습니다.
안정성
이 섹션에서는 안정성을 위한 기능 및 설계 고려사항에 대해 설명합니다.
세분성을 통한 문제 완화
수천 개의 테이블 백업을 수행할 경우 각 프로젝트의 스냅샷 및 내보내기 작업 한도와 같이 기본 Google Cloud 제품의 API 한도에 도달할 가능성이 높습니다. 하지만 한 테이블의 백업이 잘못된 구성 또는 기타 일시적인 문제로 인해 잘못될 경우 이것이 전반적인 실행과 다른 테이블의 백업 기능에 영향을 주지 않아야 합니다.
잠재적 문제를 해결하기 위해 참조 배포는 세부적인 Cloud Run 서비스를 사용하고 Pub/Sub를 통해 이를 연결함으로써 처리 단계를 분리합니다. 테이블 백업 요청이 최종 태그 지정 서비스 단계에서 실패할 경우 Pub/Sub는 이 단계만 재시도하고 전체 프로세스를 재시도하지 않습니다.
하나의 Cloud Run 서비스로 호스팅되는 여러 엔드포인트 대신 여러 Cloud Run 서비스로 흐름을 세분화하면 각 서비스 구성을 세부적으로 제어하는 데 도움이 됩니다. 구성 수준은 서비스 기능 및 서비스가 통신하는 API에 따라 달라집니다. 예를 들어 디스패처 서비스는 실행 작업별로 한 번만 실행되지만 BigQuery 백업 범위 내에서 모든 테이블을 나열하는 데 상당한 시간이 필요합니다. 따라서 디스패처 서비스는 타임아웃 및 메모리 설정을 높게 구성해야 합니다. 하지만 BigQuery용 Cloud Run 서비스 스냅샷은 단일 실행 작업에서 테이블당 한 번만 실행되며 디스패처 서비스보다 짧은 시간 내에 완료됩니다. 따라서 Cloud Run 서비스는 서비스 수준에서 여러 구성 집합이 필요합니다.
데이터 일관성
안정적인 백업 전략을 유지하기 위해서는 테이블 및 뷰 사이의 데이터 일관성이 매우 중요합니다. 데이터가 지속적으로 업데이트 및 수정되기 때문에 여러 다른 시간에 생성된 백업은 데이터 세트에 대해 서로 다른 상태를 포착할 수 있습니다. 이렇게 여러 다른 상태의 백업으로 인해 특히 동일한 기능 데이터 세트에 속하는 테이블의 경우 데이터를 복원할 때 결과가 일치하지 않을 수 있습니다. 예를 들어 판매 테이블을 재고 테이블과 다른 시점으로 복원하면 사용 가능한 재고가 일치하지 않을 수 있습니다. 마찬가지로 여러 테이블에서 데이터를 집계하는 데이터베이스 뷰는 이러한 비일관성 문제에 특히 민감할 수 있습니다. 기본 테이블이 일관적인 상태인지 확인하지 않고 이러한 뷰를 복원하면 부정확하거나 잘못된 결과로 이어질 수 있습니다. 따라서 BigQuery 백업 정책과 빈도를 설계할 때는 이러한 일관성 문제를 고려하고 특정 시점에서 데이터 세트의 실제 상태가 복원된 데이터에 정확하게 반영되는지 확인해야 합니다.
예를 들어 이 참조 아키텍처의 배포에서 데이터 일관성은 백업 정책의 다음 두 가지 구성을 통해 제어됩니다. 이러한 구성은 반드시 모든 테이블을 동시에 백업하지 않더라도 시간 이동을 통해 정확한 테이블 스냅샷 시간을 계산합니다.
backup_cron: 테이블을 백업하는 빈도를 제어합니다. 실행 작업의 시작 타임스탬프는 이 실행 작업으로 백업되는 모든 테이블의 시간 이동 계산을 위한 기준점으로 사용됩니다.backup_time_travel_offset_days: 테이블의 정확한 시간 이동 버전을 계산하기 위해 참조 시점(실행 시작 시간)에서 며칠을 빼야 하는지 결정합니다.
자동 백업 복원
이 참조 아키텍처는 대규모 백업 자동화에 집중되어 있지만 이러한 백업을 자동화된 방법으로 복원하는 방법도 고려할 수 있습니다. 이러한 추가적인 자동화 기능은 개선된 복구 효율성과 속도, 다운타임 감소를 비롯하여 백업 자동화와 비슷한 이점을 제공할 수 있습니다. 이 솔루션은 태그 지정 서비스를 통해 모든 백업 매개변수 및 결과를 유지하기 때문에 복원 작업을 대규모로 적용하는 비슷한 아키텍처를 개발할 수 있습니다.
예를 들어 한 범위의 BigQuery 데이터를 디스패처 서비스로 전송하여 테이블당 하나의 요청을 구성기 서비스로 발송하는 주문형 트리거를 기반으로 솔루션을 만들 수 있습니다. 구성기 서비스는 특정 테이블에 필요한 백업 기록을 가져올 수 있습니다. 그런 다음 구성기 서비스는 이를 BigQuery 스냅샷 복원 서비스 또는 Cloud Storage 복원 서비스로 전달하여 상황에 맞게 복원 작업을 적용할 수 있습니다. 마지막으로 태그 지정 서비스는 이러한 작업의 결과를 상태 저장소에 저장할 수 있습니다. 이렇게 해서 자동화된 복원 프레임워크는 이 문서에 설명된 백업 프레임워크와 동일한 설계 원칙을 따를 수 있습니다.
비용 최적화
이 아키텍처의 프레임워크는 전반적인 비용 최적화를 위해 다음 매개변수를 설정하는 백업 정책을 제공합니다.
- 백업 방법: 이 프레임워크는 다음 두 가지 백업 방법을 제공합니다.
- BigQuery 스냅샷은 기본 테이블과 달리 업데이트 및 삭제된 데이터를 기준으로 스토리지 비용이 발생합니다. 따라서 추가 전용으로 사용되거나 업데이트가 제한된 테이블의 경우 스냅샷이 더 비용 효율적입니다.
- Cloud Storage에 대한 BigQuery 내보내기는 표준 스토리지 비용이 발생합니다. 하지만 자르기 및 로드 접근 방식을 따르는 대규모 테이블의 경우에는 저렴한 스토리지 클래스에 내보내기로 백업하는 것이 더 비용 효율적입니다.
- 스냅샷 만료: TTL(수명)은 스냅샷에 대해 반복적인 스토리지 비용이 무제한 발생하지 않도록 단일 테이블 스냅샷용으로 설정됩니다. 테이블에 만료 시간이 없으면 시간이 지날수록 스토리지 비용이 증가할 수 있습니다.
운영 효율성
이 섹션에서는 운영 효율성을 위한 기능 및 고려사항에 대해 설명합니다.
세분화되고 확장 가능한 백업 정책
이 프레임워크의 목적 중 하나는 필요한 노력을 낮고 관리 가능하게 유지하면서 비즈니스 성과를 늘림으로써 운영 효율성을 높이는 데 있습니다. 예를 들어 이 프레임워크는 많은 수의 테이블을 정기적으로 백업할 수 있게 해주고 관리할 백업 정책과 구성은 소수만 필요로 합니다.
테이블 수준에서 백업 정책을 허용하는 것 외에도 데이터 세트, 프로젝트, 폴더, 전역 수준에서 정책을 허용합니다. 즉, 폴더 또는 프로젝트와 같은 상위 수준에 필요한 구성을 줄이고 수백 또는 수천 개의 테이블을 대규모로 정기적으로 백업할 수 있습니다.
모니터링 가능성
자동화 프레임워크에서는 프로세스 상태를 파악하는 것이 중요합니다. 예를 들어 다음과 같은 일반적인 쿼리에 대한 정보를 찾을 수 있어야 합니다.
- 각 테이블에 대해 시스템에 사용되는 백업 정책
- 각 테이블의 백업 기록과 백업 위치
- 단일 실행 작업의 전반적인 상태(처리된 테이블과 실패한 테이블 수)
- 단일 실행 작업에서 발생한 치명적인 오류와 오류가 발생한 프로세스의 구성요소 또는 단계
이러한 정보를 제공하기 위해 이 배포는 Cloud Run 서비스를 사용하는 각 수행 단계에서 Cloud Logging에 구조화된 로그를 기록합니다. 로그에는 다른 진행률 체크포인트와 함께 입력, 출력, 오류가 포함됩니다. 로그 싱크는 이러한 로그를 BigQuery 테이블에 라우팅합니다. 일반적인 모니터링 가능성 사용 사례에 대해 실행 작업을 모니터링하고 보고서를 얻기위해 많은 쿼리를 실행할 수 있습니다. BigQuery의 로그 및 쿼리에 대한 자세한 내용은 BigQuery에 라우팅된 로그 보기를 참조하세요.
성능 최적화
각 실행 작업을 수행할 때마다 수천 개의 테이블을 처리하기 위해 이 솔루션은 백업 요청을 병렬로 처리합니다. 디스패처 서비스는 BigQuery 백업 범위 내에 포함된 모든 테이블을 나열하고 실행 작업을 수행할 때마다 테이블당 하나의 백업 요청을 생성합니다. 이렇게 하면 애플리케이션이 순차적이 아닌 병렬 방식으로 수천 개의 요청과 테이블을 처리할 수 있습니다.
처음에는 기본 Google Cloud API 한도에 도달하거나 네트워크 문제 발생 등의 일시적인 이유로 이러한 요청 중 일부가 실패할 수 있습니다. Pub/Sub는 요청이 완료될 때까지 지수 백오프 재시도 정책을 사용하여 요청을 자동으로 재시도합니다. 부적절한 백업 대상 또는 권한 누락과 같은 치명적인 오류가 있으면 오류가 기록되고 전체 실행 작업에 영향을 주지 않고 해당 테이블 요청의 실행이 종료됩니다.
한도
이 아키텍처에는 다음과 같은 할당량 및 한도가 적용됩니다.
테이블 스냅샷의 경우 사용자가 지정하는 각 백업 작업 프로젝트에 다음이 적용됩니다.
- 프로젝트에서 최대 100개의 동시 테이블 스냅샷 작업을 실행할 수 있습니다.
- 프로젝트에서 하루에 최대 50,000개의 테이블 스냅샷 작업을 실행할 수 있습니다.
- 프로젝트에서 하루에 테이블당 최대 50개의 테이블 스냅샷 작업을 실행할 수 있습니다.
자세한 내용은 테이블 스냅샷을 참조하세요.
내보내기 작업(Cloud Storage로 내보내기)의 경우 다음이 적용됩니다.
- 공유 슬롯 풀을 사용하면 프로젝트에서 매일 50TiB까지 데이터를 무료로 내보낼 수 있습니다.
- 프로젝트에서 하루에 최대 100,000회의 내보내기를 실행할 수 있습니다. 이 한도를 늘리려면 슬롯 예약을 만드세요.
자세한 한도 확대 방법은 내보내기 작업을 참조하세요.
동시 실행 한도와 관련해서 이 아키텍처는 Pub/Sub를 사용해서 이러한 한도로 인해 실패한 요청이 API로 처리될 때까지 자동으로 재시도합니다. 하지만 일별 프로젝트당 작업 수에 영향을 주는 기타 한도의 경우에는 할당량 증가 요청을 사용하거나 백업 작업(스냅샷 또는 내보내기)을 여러 프로젝트로 분산하는 방식으로 문제를 해결할 수 있습니다. 프로젝트 간에 작업을 분산하려면 다음 배포 섹션에 설명된 대로 백업 정책을 구성합니다.
배포
이 아키텍처를 배포하려면 확장 가능한 BigQuery 백업 자동화 배포를 참조하세요.
다음 단계
- BigQuery 자세히 알아보기:
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.
참여자
저자: 카림 와디 | 전략적 클라우드 엔지니어
기타 참여자:
- 크리스 디포레스트 | 사이트 안정성 엔지니어
- 에얄 벤 이브리 | 클라우드 솔루션 설계자
- 제이슨 데이벤포트 | Developer Advocate
- 잘리야 에카나야케 | 엔지니어링 관리자
- 무함마드 자인 | 전략적 클라우드 엔지니어