BigQuery의 멀티 테넌트 워크로드 권장사항

이 문서에서는 멀티 테넌트 데이터 플랫폼 및 엔터프라이즈 데이터 마트에 사용되는 일반적인 패턴의 기법과 권장사항을 제공합니다.

상업용 기업, Software as a service(SaaS) 공급업체, 정부 조직은 지리적 경계와 관리상의 경계에서 내부 데이터와 타사 데이터를 모두 안전하게 호스팅해야 합니다. BigQuery는 서로 다른 비즈니스 단위에서 수 엑사바이트의 데이터와 수만에 달하는 데이터 소비자의 멀티 테넌트 플랫폼 요구사항을 일관되게 해결할 수 있는 강력한 도구입니다. 이 문서는 BigQuery에 멀티 테넌트 플랫폼을 배포하는 조직과 사용 가능한 액세스 제어 및 성능 관리 기능을 이해하고자 하는 사용자를 대상으로 합니다.

멀티 테넌트 플랫폼 빌더는 다음과 같은 고려사항의 균형을 맞춰야 하는 경우가 종종 있습니다.

• 데이터 격리: 테넌트 전체의 데이터 유출을 방지하는 강력한 제어를 구현합니다.
• 일관된 성능: 테넌트 전체에서 일관된 성능을 유지하도록 BigQuery 예약을 구성하고 결정합니다.
• 리소스 관리: 할당량 및 한도의 영향을 계획합니다.
• 지리적 분포: 지정된 필수 지리적 위치에서 데이터를 찾습니다. 규정 준수 관련 우려사항은 Google Cloud의 규정 준수 제품을 참조하세요.
• 감사 및 보안: 부적절한 액세스 및 무단 반출로부터 테넌트 데이터를 보호합니다.
• 비용 관리: 각 테넌트를 호스팅하기 위해 일관된 BigQuery 비용을 보장합니다.
• 운영 복잡성: 새 테넌트를 호스팅하는 데 필요한 시스템 변동성을 최소화합니다.

공유 테넌트 인프라가 있는 SaaS 공급업체

타사 데이터를 호스팅하는 SaaS 공급업체는 고객 전체의 안정성과 격리를 보장해야 합니다. 이러한 고객은 수만 명에 달할 수 있으며 고객 데이터는 공유 서비스 인프라를 통해 액세스할 수 있습니다. 또한 일부 SaaS 공급업체는 테넌트 전체에 대한 분석을 수행하기 위해 삭제된 중앙 데이터 저장소를 유지합니다.

데이터 세트별 테넌트 설계는 수천 개의 테넌트로 확장할 때 조직이 경험하는 다음과 같은 우려를 완화하는 데 도움이 됩니다.

• 관리 복잡성: 고객별 신규 프로젝트 및 클라우드 리소스 총수
• 엔드 투 엔드 지연 시간: 테넌트와 교차 고객 분석 솔루션 모두에 대한 데이터 저장소의 최신 상태
• 성능 기대치: 테넌트 성능을 허용 가능한 한도 내에 유지

각 테넌트의 데이터 세트 구성

고객 데이터 저장 전용 프로젝트 내에서 각 고객의 데이터는 BigQuery 데이터 세트로 구분됩니다. 호스트 조직 내에서 두 번째 프로젝트를 사용하여 결합된 고객 데이터에 대한 분석 및 머신러닝을 배포합니다. 그런 다음 데이터 처리 엔진인 Dataflow를 구성하여 내부 테이블 및 테넌트별 테이블에 수신 데이터를 이중으로 쓸 수 있습니다. Dataflow 구성은 승인된 뷰 대신 완전히 작성된 테이블을 사용합니다. 완전히 작성된 테이블을 사용하면 지리적 분포를 균일하게 처리할 수 있으며, 테넌트 수가 확장될 때 승인된 뷰 한도에 도달하는 것을 방지할 수 있습니다.

BigQuery의 스토리지와 컴퓨팅을 분리하면 클러스터 기반 웨어하우스에 비해 적은 수의 프로젝트를 구성하여 서비스 계층 및 데이터 격리와 같은 문제를 처리할 수 있습니다. 추가 전용 클라우드 리소스로 테넌트를 구성할 필요가 없는 경우 각 테넌트에 대한 전용 데이터 세트의 기본 구성을 사용하는 것이 좋습니다. 다음 다이어그램은 이 권장 설계에 따른 예시 프로젝트 구성을 보여줍니다.

그림 1. 테넌트 수가 증가함에 따라 일정 개수의 리소스가 데이터 및 프로세싱 요구를 처리합니다.

그림 1의 프로젝트 구성에는 다음 프로젝트가 포함됩니다.

• 데이터 파이프라인 프로젝트: 테넌트 데이터를 수신하고, 처리하고, 배포하는 모든 핵심 인프라 구성요소가 패키징되는 단일 프로젝트입니다.
• 통합된 테넌트 데이터 프로젝트: 고객별로 데이터 세트를 유지관리하는 핵심 데이터 프로젝트입니다. 테넌트 데이터는 컴퓨팅 등급 프로젝트를 통해 액세스할 수 있습니다.
• 내부 개발 프로젝트: 분석팀이 테넌트 데이터를 평가하고 새 기능을 빌드하는 데 사용하는 자체 관리형 리소스를 나타내는 프로젝트입니다.
• 최종 사용자 애플리케이션 프로젝트: 최종 사용자와 상호작용하도록 설계된 리소스가 포함된 프로젝트입니다. 테넌트 범위의 서비스 계정을 사용하여 테넌트 데이터 세트에 액세스하고 강력하고 안전한 빌드 파이프라인을 사용하여 애플리케이션을 배포하는 것이 좋습니다.
• 예약 컴퓨팅 등급 프로젝트: 테넌트 쿼리 활동을 BigQuery 예약에 매핑하는 프로젝트입니다.

예약 공유

이 접근방식의 예약은 BigQuery 예약에 내장된 공정 예약 알고리즘을 사용합니다. 각 컴퓨팅 등급 예약은 단일 프로젝트에 할당됩니다. 테넌트 쿼리는 각 컴퓨팅 등급 프로젝트에서 사용 가능한 공정 예약 슬롯을 사용하며, 모든 등급의 사용되지 않은 슬롯은 다른 등급에서 자동으로 재사용됩니다. 테넌트에 특정 타이밍 요구사항이 있는 경우 정확한 슬롯 수를 제공하는 전용 프로젝트-예약 쌍을 사용할 수 있습니다.

VPC 서비스 제어 경계 구성

이 구성에서는 VPC 서비스 제어 경계를 사용하여 Google Cloud 조직 외부의 테넌트 데이터 세트가 실수로 노출되는 것을 방지하고 조직 내에서 승인되지 않은 데이터가 들어가지 않도록 하는 것이 좋습니다.

경계

이 구성에서는 다음 서비스 경계를 만드는 것이 좋습니다.

• 데이터 파이프라인: 테넌트 데이터를 수신할 필요가 없는 모든 서비스를 시행해야 데이터 파이프라인 프로젝트 주변의 경계입니다.
• 테넌트 데이터: 테넌트 데이터 세트 프로젝트 및 테넌트 BigQuery 컴퓨팅 프로젝트 주변의 경계입니다. 모든 서비스를 시행하여 조직 외부에서 액세스하지 못하도록 합니다.
• 내부 애플리케이션: 모든 서비스를 시행하고 액세스 수준을 사용하여 부서 팀에 리소스 액세스 권한을 부여합니다.
• 외부 애플리케이션: SaaS 애플리케이션 주변의 경계입니다. 애플리케이션이 작동하는 데 필요하지 않은 모든 서비스를 시행합니다.

경계 브리지

이 구성에서는 다음과 같은 경계 브리지를 만드는 것이 좋습니다.

• 데이터 파이프라인 및 테넌트 데이터: 파이프라인이 테넌트 데이터 세트에 데이터를 쓸 수 있도록 허용합니다.
• 데이터 파이프라인 및 내부 애플리케이션: 파이프라인이 교차 고객 데이터 세트에 데이터를 쓸 수 있도록 허용합니다.
• 외부 애플리케이션 및 테넌트 데이터: 외부 애플리케이션이 테넌트 데이터를 쿼리할 수 있도록 허용합니다.
• 외부 애플리케이션 및 내부 애플리케이션: 외부 애플리케이션이 내부 애플리케이션에서 개발하고 배포하는 모델을 사용하여 데이터를 처리할 수 있도록 허용합니다.

전용 테넌트 인프라가 있는 SaaS 공급업체

더 복잡한 시나리오에서는 SaaS 공급업체가 테넌트마다 전용 컴퓨팅 인프라를 배포할 수 있습니다. 이 시나리오에서는 전용 인프라가 BigQuery 내부의 테넌트 데이터에 대한 요청을 처리합니다.

전용 테넌트 인프라 설계는 BigQuery와 함께 테넌트마다 인프라를 배포할 때 다음과 같은 일반적인 우려사항을 해결합니다.

• 결제 책임: 온보딩된 각 테넌트와 연결된 인프라 비용 추적
• 엔드 투 엔드 지연 시간: 테넌트와 교차 고객 분석 솔루션 모두에 대한 데이터 저장소의 최신 상태
• 성능 기대치: 테넌트 성능을 허용 가능한 한도 내에 유지

전용 리소스로 데이터 세트 공동 배치

전용 테넌트 인프라를 배포할 때는 테넌트 관련 프로젝트의 상위 폴더를 만드는 것이 좋습니다. 그런 다음 테넌트 대신 해당 데이터에 액세스하는 전용 리소스와 함께 프로젝트에 있는 테넌트의 BigQuery 데이터 세트를 함께 배치합니다. 테넌트 데이터의 엔드 투 엔드 지연 시간을 최소화하기 위해 Dataflow 파이프라인은 데이터를 테넌트 데이터 세트에 직접 삽입합니다.

이 설계는 이전 공유 인프라 설계와 유사하게 업스트림 데이터 처리 및 배포를 처리합니다. 하지만 테넌트 데이터와 테넌트 데이터에 액세스하는 애플리케이션은 테넌트별 프로젝트(및 필요에 따라 테넌트 전용 폴더) 아래 구성되어 청구 및 리소스 관리를 간소화합니다. 다음 다이어그램은 이 권장 설계에 따른 예시 프로젝트 구성을 보여줍니다.

그림 2. 데이터 파이프라인 프로젝트는 여러 다른 프로젝트의 단일 테넌트 데이터를 처리합니다.

그림 2의 프로젝트 구성에는 다음 프로젝트가 포함됩니다.

• 데이터 파이프라인 프로젝트: 테넌트 데이터를 수신하고, 처리하고, 배포하는 모든 핵심 인프라 구성요소가 패키징되는 단일 프로젝트입니다.
• 전용 테넌트 프로젝트: BigQuery 데이터 세트를 포함한 단일 테넌트 전용 클라우드 리소스가 포함된 프로젝트입니다. Identity and Access Management(IAM)를 사용하여 고객 데이터 세트에 액세스할 수 있는 계정 및 서비스 계정의 범위를 크게 제한하는 것이 좋습니다.
• 내부 분석 프로젝트: 분석팀이 테넌트 데이터를 평가하고 새 기능을 빌드하는 데 사용하는 자체 관리형 리소스를 나타내는 프로젝트입니다.
• 외부 네트워킹 프로젝트: 테넌트 요청을 처리하고 전용 백엔드로 라우팅하는 프로젝트입니다.

예약 공유

이 접근방식의 예약은 BigQuery 예약에 내장된 공정 예약 알고리즘을 사용합니다. 이 구성에서는 컴퓨팅 등급 예약이 이 등급을 사용하는 각 테넌트 프로젝트에 할당됩니다. 테넌트에 특정 타이밍 요구사항이 있는 경우 전용 예약을 만들어 테넌트 프로젝트에 정확한 수의 슬롯을 제공할 수 있습니다.

IAM 제어 사용 및 키 생성 사용 중지

VPC 서비스 제어 경계는 이 시나리오에 적합하지 않을 수 있습니다. 프로젝트 관련 한도는 조직이 테넌트 프로젝트와 상호작용하는 프로젝트 주변의 경계를 사용하지 못하도록 합니다. 대신 원치 않는 외부 액세스로부터 보호하기 위해 엄격한 IAM 제어를 사용하고 키 생성을 사용 중지하는 것이 좋습니다.

중앙 권한이 있는 데이터 마트

데이터 마트는 핵심 분석 데이터가 중앙 저장소에 저장되고 하위 집합이 비즈니스 분야에 걸쳐 공유되는 공통 설계 테마입니다. 데이터 마트에는 고려해야 할 비즈니스 분야로 표시되는 테넌트가 수십 또는 수백 개 있는 경우가 많습니다.

BigQuery의 데이터 마트 설계는 다음의 요구를 해결합니다.

• 안전한 데이터 협업: 팀 간의 부적절한 액세스를 최소화하기 위해 기술 제어를 통해 데이터를 공유합니다.
• 중앙 데이터 거버넌스: 중요한 비즈니스 보고서에 사용되는 핵심 데이터 애셋을 표준화하고 검증합니다.
• 비즈니스 단위 비용 기여 분석: 비즈니스 단위별로 계산 사용량을 추적하고 조정합니다.

중앙에서 관리되는 저장소 사용

이 설계에서 핵심 데이터는 중앙에서 관리되는 저장소에 담깁니다. 승인된 뷰, 승인된 사용자 정의 함수(UDF), 열 정책은 종종 비즈니스 라인과 데이터를 공유하면서 민감한 정보를 실수로 배포하는 것을 방지합니다.

테넌트 프로젝트의 팀은 계정 권한을 기준으로 중앙 제어 데이터 세트에 액세스할 수 있습니다. 팀은 자체 프로젝트에 할당된 슬롯을 사용하여 보고서 및 파생된 데이터 세트를 빌드합니다. 핵심 데이터팀은 승인된 뷰를 사용하여 데이터 마트의 애셋에 대한 액세스 제어의 전체 소유권을 유지합니다. 이 구성에서는 핵심 데이터 프로젝트가 제공하는 객체 위에 여러 계층의 뷰를 빌드하지 않는 것이 좋습니다. 다음 다이어그램은 이 권장 설계에 따른 예시 프로젝트 구성을 보여줍니다.

그림 3. 핵심 데이터 프로젝트는 조직 전체에서 액세스할 수 있는 중앙 집중식 데이터 마트를 유지합니다.

그림 3의 프로젝트 구성에는 다음 프로젝트가 포함됩니다.

• 핵심 데이터 프로젝트: 핵심 데이터 및 데이터 마트 뷰에 대한 액세스를 관리하기 위한 거버넌스 경계입니다. 이 프로젝트 내의 데이터 세트 내에서 승인된 뷰를 유지하고 그룹 멤버십에 따라 애널리틱스팀에 승인된 뷰를 부여합니다.
• 추출, 변환, 로드(ETL) 인프라: 업스트림 데이터 소스를 핵심 데이터로 처리하기 위한 인프라입니다. 관리 분리 요구사항에 따라 ETL 인프라를 자체 프로젝트 또는 핵심 데이터 프로젝트의 일부로 배포할 수도 있습니다.
• 애널리틱스팀 프로젝트: 데이터 마트를 이용하는 소비자는 이 프로젝트를 사용하고 자체 프로비저닝된 인프라를 사용하여 데이터 마트 내에서 데이터를 처리합니다. 애널리틱스팀 프로젝트는 로컬 사용을 위한 파생 데이터 세트를 빌드할 수 있습니다.

2단계 예약 설계 사용

데이터 마트에 대해 작업하는 경우 2단계 설계를 사용하는 것이 좋습니다. 2단계 설계에서는 일반적인 사용을 지원하기 위해 적은 수의 슬롯이 있는 예약을 조직 리소스를 할당합니다. 팀에 더 많은 요구사항이 있는 경우 프로젝트 또는 폴더 수준에서 예약을 할당합니다.

VPC 서비스 제어 경계 구성

이 구성에서는 VPC 서비스 제어 경계를 사용하여 Google Cloud 조직 외부에서 BigQuery 데이터 세트가 실수로 노출되는 것을 방지하는 것이 좋습니다.

경계

이 구성에서는 다음 서비스 경계를 만드는 것이 좋습니다.

• 핵심 데이터: 데이터 웨어하우스 및 데이터 마트 데이터 세트를 보호하는 경계입니다.
• 데이터 파이프라인: ETL 인프라 프로젝트의 경계입니다. 데이터 파이프라인이 Google Cloud 조직 외부에서 요청을 수행해야 하는 경우 이 경계를 핵심 데이터 경계와 분리하는 것이 좋습니다.
• 애널리틱스: 조직 내부에 분석 애셋을 빌드하고 배포하는 경계입니다. 이 경계는 연결된 핵심 데이터 경계보다 더 많이 허용되는 액세스 정책이 있을 것으로 예상됩니다.

경계 브리지

이 구성에서는 다음과 같은 경계 브리지를 만드는 것이 좋습니다.

• 데이터 파이프라인 및 핵심 데이터: 데이터 파이프라인이 핵심 데이터 프로젝트에 쓸 수 있도록 허용합니다.
• 핵심 데이터 및 분석: 애널리틱스 프로젝트의 사용자가 승인된 뷰를 쿼리할 수 있도록 허용합니다.

멀티 리전 구성을 위한 데이터 세트 복사

BigQuery는 리전 간 쿼리를 허용하지 않으므로 데이터 마트가 여러 리전에 있어야 하는 경우에는 승인된 뷰로 데이터를 세분화하는 전략을 사용할 수 없습니다. 대신 BigQuery Data Transfer Service를 사용하여 관련 데이터 세트를 다른 리전에 복사할 수 있습니다. 이 시나리오에서는 데이터가 있는 추가 리전마다 Data Catalog 내에서 열 정책을 만듭니다. 다음 다이어그램은 멀티 리전 구성을 보여줍니다.

그림 4. 멀티 리전 구성은 BigQuery Data Transfer Service를 사용하여 리전 간에 데이터 세트를 복사합니다.

그림 4의 프로젝트 구성에는 다음 프로젝트가 포함됩니다.

• 핵심 데이터 프로젝트: 핵심 데이터 및 데이터 마트 뷰에 대한 액세스를 관리하기 위한 거버넌스 경계입니다. 데이터는 전 세계 팀에 제공할 수 있는 리전 데이터 세트로 복사되고 유지관리됩니다.
• ETL 인프라: 업스트림 데이터 소스를 핵심 데이터로 처리하기 위한 인프라입니다. 관리 분리 요구사항에 따라 ETL 인프라를 자체 프로젝트 또는 핵심 데이터 프로젝트의 일부로 배포할 수도 있습니다.
• 애널리틱스 팀 프로젝트: 데이터 마트를 이용하는 소비자는 이 프로젝트를 사용하고 자체 프로비저닝된 인프라를 사용하여 데이터 마트의 리전 데이터 세트 내에서 데이터를 처리합니다. 애널리틱스팀 프로젝트는 로컬 사용을 위한 파생 데이터 세트를 빌드할 수 있습니다.

BigQuery Data Transfer Service는 몇 가지 제한사항이 있는 추가 예약 구성요소입니다. 기본 제공 서비스 스케줄러는 최소 간격 15분으로 제한되며 소스 데이터 세트에서 모든 테이블을 복사해야 합니다. BigQuery Data Transfer Service 스케줄러에 리전별 데이터 하위 집합을 만들기 위한 추가 스크립트를 삽입하는 방법은 없습니다.

조직의 유연성을 높여야 하는 경우 다음 옵션을 사용할 수 있습니다.

• Cloud Composer 작업: 클라이언트 API를 통해 BigQuery Data Transfer Service를 트리거하기 전에 리전별 하위 집합을 만드는 ETL 작업을 실행하도록 Cloud Composer 작업을 예약할 수 있습니다. 조직에서 추가 지연 시간을 지원할 수 있다면 이 옵션을 사용하는 것이 좋습니다.
• ETL 인프라: Dataflow와 같은 ETL 인프라는 리전별 하위 집합을 대상 리전에 이중으로 쓸 수 있습니다. 조직에서 리전 간 데이터 지연 시간을 최소화해야 하는 경우 이 옵션을 사용하는 것이 좋습니다.

분산된 권한이 있는 데이터 마트

시스템 소유자, 비즈니스 분야 또는 지리적 우려사항에 따라 관리 분리가 필요한 경우 분산된 권한을 사용합니다.

분산된 데이터 마트는 표준 데이터 마트와 비교하여 다음과 같은 우려가 있습니다.

• 안전한 데이터 협업: 팀 간의 부적절한 액세스를 최소화하기 위해 기술 제어를 통해 데이터를 공유합니다.
• 데이터 검색 가능 여부: 팀이 데이터 세트를 검색하고 액세스를 요청할 수 있어야 합니다.
• 데이터 출처: 중앙 큐레이터팀이 없으면 팀은 분석 제품으로 들어오는 데이터의 출처를 신뢰할 수 있어야 합니다.

핵심 데이터 관리 위임

이 설계는 기존의 데이터 마트 접근방식과는 다릅니다. 분산된 권한이 핵심 데이터 관리 결정을 조직의 구성요소 하위 그룹에 위임하기 때문입니다. 분산된 권한을 사용하는 경우 Cloud Key Management Service(Cloud KMS), 열 정책, VPC 서비스 제어, 예약을 사용하여 보안 및 BigQuery 용량에 대한 중앙 제어를 유지합니다. 따라서 자체 관리형 웨어하우스에서 흔히 발생하는 데이터 불일치를 방지할 수 있습니다. 다음 다이어그램은 분산된 권한을 사용하는 아키텍처를 보여줍니다.

그림 5. 핵심 거버넌스 프로젝트는 개별 그룹이 데이터 작업을 유지관리하면서 일관된 보안을 보장하는 데 도움이 됩니다.

그림 5의 프로젝트 구성에는 다음 프로젝트가 포함됩니다.

• 핵심 거버넌스 프로젝트: 조직 간 관리 우려를 담당하는 프로젝트입니다. 이 프로젝트에서는 Cloud KMS 키링 및 Data Catalog 열 정책과 같은 보안 리소스를 만듭니다. 이 프로젝트는 BigQuery 예약 관리 프로젝트 역할을 하여 조직 전체의 슬롯 공유를 사용 설정합니다.
• 조직 단위 데이터 프로젝트: 광범위한 조직 내에서 자체 관리형 데이터 마트의 소유자입니다. 핵심 거버넌스 프로젝트는 조직 단위 데이터 프로젝트의 제한된 범위를 관리합니다.
• 애널리틱스팀 프로젝트: 데이터 마트 소비자가 사용하는 프로젝트입니다. 이러한 프로젝트는 자체 프로비저닝된 인프라와 슬롯을 사용하여 데이터 마트 내의 데이터에 액세스하고 처리합니다.

2단계 예약 설계 사용

분산된 데이터 마트는 표준 데이터 마트와 동일한 2단계 설계를 사용하는 것이 좋습니다. 이 구성에서는 일반적인 사용을 위한 지원하기 위해 적은 수의 슬롯이 있는 예약을 조직 리소스에 할당합니다. 팀에 더 많은 요구사항이 있는 경우 프로젝트 또는 폴더 수준에서 예약을 할당합니다.

Data Catalog 사용

Data Catalog는 조직 전체 검색, 메타데이터 태그 지정, 열 정책 구성을 제공합니다. Dataplex의 검색 기능이 조직 전체에서 모든 새 BigQuery 테이블에 대한 메타데이터 항목을 자동으로 만듭니다. Dataplex의 기능은 데이터 거버넌스 관리자가 새로운 데이터 애셋을 빠르게 식별하고 적절한 제어를 적용하는 데 도움이 됩니다.

VPC 서비스 제어 경계 구성

이 구성에서는 VPC 서비스 제어 경계를 사용하여 Google Cloud 조직 외부에서 BigQuery 데이터 세트가 실수로 노출되는 것을 방지하는 것이 좋습니다.

경계

이 구성에서는 다음 서비스 경계를 만드는 것이 좋습니다.

• 핵심 데이터: 데이터 웨어하우스 및 데이터 마트 데이터 세트를 보호하는 경계입니다. 이 경계에는 모든 조직 단위 프로젝트와 데이터 거버넌스 프로젝트가 포함되어야 합니다.
• 애널리틱스: 조직 내부에 분석 애셋을 빌드하고 배포하는 경계입니다. 이 경계는 연결된 핵심 데이터 경계보다 더 많이 허용되는 액세스 정책이 있을 것으로 예상됩니다.

경계 브리지

이 구성에서는 다음과 같은 경계 브리지를 만드는 것이 좋습니다.

• 핵심 데이터 및 분석: 애널리틱스 프로젝트의 사용자가 승인된 뷰를 쿼리할 수 있도록 허용합니다.

다중 조직 데이터 공유

다중 조직 공유는 데이터 마트 설계를 위한 특별한 설계 고려사항입니다. 이 데이터 공유 설계는 자체 Google 조직이 있는 다른 조직과 데이터 세트를 안전하게 공유해야 하는 조직을 위한 것입니다.

다중 조직 데이터 공유는 데이터 공유자에 다음과 같은 우려를 해결합니다.

• 비밀유지 공유: 의도된 당사자만 공유 데이터에 액세스할 수 있습니다.
• 부적절한 액세스로부터 보호: 액세스할 의도가 있는 리소스만 외부에서 액세스할 수 있습니다.
• 컴퓨팅 분리: 외부 당사자가 시작한 쿼리에 대해 요금이 청구됩니다.

참고: 외부 조직에서 발생한 쿼리가 예기치 않게 실패할 수 있습니다. 클라우드 고객 관리는 구성 변경을 시작하여 문제를 해결할 수 있도록 지원합니다.

공유 데이터 프로젝트로부터 내부 프로젝트 보호

다중 조직 데이터 공유 설계는 공유 데이터 프로젝트의 활동으로부터 조직의 내부 프로젝트를 보호하는 데 중점을 둡니다. 공유 데이터 세트 프로젝트는 민감한 내부 데이터 처리에 대한 액세스를 허용하지 않는 동시에 데이터를 외부에 공유하는 기능을 제공하는 버퍼 역할을 합니다.

외부 프로젝트에서 시작하는 쿼리는 호출 프로젝트의 컴퓨팅 리소스를 사용합니다. 쿼리된 모든 데이터 세트가 동일한 Google Cloud 리전을 공유하는 경우 이러한 쿼리는 조직 간에 데이터를 조인할 수 있습니다. 다음 다이어그램은 다중 조직 프로젝트 구성에서 데이터 세트가 공유되는 방법을 보여줍니다.

그림 6. 외부 조직은 공유 프로젝트의 여러 데이터 세트에서 데이터를 쿼리합니다.

그림 6의 프로젝트 구성에는 다음 프로젝트가 포함됩니다.

• 조직 내부 프로젝트: 민감한 내부 데이터가 포함된 프로젝트입니다. 내부 프로젝트는 삭제된 데이터를 공유 데이터 프로젝트의 데이터 세트로 복사하여 외부와 데이터를 공유할 수 있습니다. 내부 프로젝트는 공유 데이터 업데이트를 담당하는 서비스 계정을 소유해야 합니다.
• 공유 데이터 프로젝트: 내부 프로젝트에서 복사되는 삭제된 정보가 포함된 프로젝트입니다. 외부 사용자 그룹을 사용하여 외부 당사자의 액세스를 관리합니다. 이 시나리오에서는 그룹 멤버십을 관리 기능으로 관리하고 이 계정을 통해 데이터 세트에 액세스할 수 있도록 외부 계정에 뷰어 권한을 부여합니다.

VPC 서비스 제어 경계 구성

이 구성에서는 VPC 서비스 제어 경계를 사용하여 데이터를 외부에 공유하고 내부 프로젝트 외부에서 BigQuery 데이터 세트가 실수로 노출되는 것을 방지하는 것이 좋습니다.

경계

이 구성에서는 다음 서비스 경계를 만드는 것이 좋습니다.

• 내부 데이터: 핵심 데이터 애셋을 보호하는 경계입니다. VPC 서비스 제어는 BigQuery에 대한 액세스를 시행합니다.
• 외부 공유 데이터: 외부 조직과 공유될 수 있는 데이터 세트를 호스팅하는 경계입니다. 이 경계는 BigQuery에 대한 액세스 시행을 사용 중지합니다.

경계 브리지

이 구성에서는 다음과 같은 경계 브리지를 만드는 것이 좋습니다.

• 내부-외부 데이터: 경계 브리지를 사용하면 보다 안전한 내부 데이터 프로젝트가 데이터를 외부 데이터 공유 프로젝트로 이그레스할 수 있습니다.

멀티 테넌트 시스템의 추가 고려사항

이 섹션에서는 앞의 권장사항과 함께 고려할 수 있는 특수한 사례를 자세히 살펴봅니다.

Google Cloud 리소스 한도 및 할당량

• 서비스 계정은 프로젝트당 서비스 계정 100개의 소프트 할당량으로 제한됩니다. 테넌트 서비스 계정을 유지하는 프로젝트에 대해 Google Cloud 콘솔을 통해 할당량을 요청할 수 있습니다.
• BigQuery 동시 실행은 쿼리를 발행하는 프로젝트당 100개 쿼리라는 기본 동시 실행을 갖습니다(데이터 세트를 보유하는 프로젝트에는 이러한 제한이 없음). 소프트 할당량을 늘리려면 영업 담당자에게 문의하세요.
• VPC 서비스 제어에는 조직 전체의 서비스 경계 내에서 프로젝트가 10,000개로 제한됩니다. 테넌트별 프로젝트 설계가 높은 확장성을 갖는 경우 대신 테넌트별 데이터 세트 설계를 사용하는 것이 좋습니다.
• VPC 서비스 제어에는 조직당 브리지를 포함하여 경계가 100개로 제한됩니다.

승인된 뷰 또는 구체화된 하위 집합 테이블 사용

대형 팩트 테이블의 하위 집합에 대한 테넌트 액세스를 관리하려면 테넌트별 승인된 뷰를 사용하거나 테넌트별 하위 집합 테이블을 만들면 됩니다. 다음 표에서는 이러한 접근방식을 비교해서 보여줍니다.

특성	승인된 뷰	하위 집합 테이블
지원되는 테넌트 수	데이터 세트당 승인된 리소스 2,500개라는 엄격한 제한이 적용됩니다.	승인된 리소스에는 승인된 뷰, 승인된 데이터 세트, 승인된 함수가 포함됩니다. 프로젝트의 데이터 세트 수 또는 데이터 세트의 테이블 수에는 제한이 없습니다.
파티션 나누기 및 클러스터링	승인된 뷰는 기본 테이블의 공통 파티션 나누기 및 클러스터 스킴을 공유해야 합니다. 테넌트 세분화의 성능을 향상시키려면 테넌트 ID에 상위 테이블을 클러스터링하는 것이 좋습니다.	하위 집합 테이블의 파티션을 나누고 테넌트의 필요에 따라 클러스터링할 수 있습니다.
리전화	승인된 뷰는 리전을 교차할 수 없으며 기본 테이블의 Google Cloud 리전에 있어야 합니다. 리전화는 지리적으로 원격 테넌트에 영향을 줍니다.	하위 집합 테이블은 테넌트에 가장 적합한 리전에 존재할 수 있습니다. 추가 비용이 부과될 수 있습니다.
열 정책 시행	기본 테이블에 적용된 열 정책은 해당 뷰의 권한과 관계없이 승인된 모든 뷰에 적용됩니다.	각 하위 집합 테이블은 열 정책을 적용해야 적용됩니다.
데이터 액세스 로깅	데이터 액세스 로그는 기본 테이블의 로깅에 반영됩니다.	각 하위 집합 테이블에 대한 액세스는 별도로 로깅됩니다.
변환 유연성	승인된 뷰를 사용하면 테넌트가 액세스하는 객체를 즉시 재설계할 수 있습니다.	하위 집합 테이블을 변경하려면 복잡한 스키마를 변경해야 합니다.

민감한 정보 제어

데이터에 대한 무단 액세스를 방지하기 위해 BigQuery는 표준 IAM 권한 외에도 여러 추가 기능을 제공합니다.

클라이언트 제공 암호화

클라이언트 데이터 암호화는 호스팅 조직에서 테넌트를 대신하여 데이터를 저장하고 처리하지만 일부 데이터 콘텐츠에 액세스할 수 없는 경우를 포함합니다. 예를 들어 호스팅 조직에서는 민감한 정보로 간주되는 개인 데이터 또는 기기 데이터에 액세스하지 못할 수 있습니다.

데이터 발신자는 오픈소스 Tink 라이브러리의 AEAD 암호화 키를 사용하여 민감한 정보를 암호화하는 것이 좋습니다. Tink 라이브러리 AEAD 암호화 키는 BigQuery AEAD 함수와 호환됩니다. 그러면 테넌트가 승인된 UDF에서 키 자료에 액세스하거나 호스트 조직에 키를 로깅할 수 없는 BigQuery에 키 자료를 쿼리 매개변수로 전달하여 데이터를 복호화할 수 있습니다.

열 액세스 정책

멀티 테넌트 데이터 마트에서는 민감한 콘텐츠가 실수로 협업팀 간에 유출되는 것을 방지하기 위해 열 정책을 사용하기도 합니다. 승인된 뷰는 데이터 마트 시나리오에서 팀 간에 데이터를 공유하기 위한 선호되는 메커니즘입니다. 승인된 뷰는 보호된 열에 대한 액세스 권한을 부여할 수 없습니다.

액세스 제어를 시행하도록 정책을 설정하면 정책에 대한 세분화된 리더 역할을 부여받지 않은 사용자의 액세스가 차단됩니다. 정책이 시행되지 않아도 정책은 분류된 열에 대한 모든 사용자 액세스를 로깅합니다.

민감한 정보 보호

민감한 정보 보호는 BigQuery 또는 Cloud Storage 데이터 세트 내에 저장된 민감한 콘텐츠를 식별하고 완화하는 데 도움이 되는 API와 스캔 유틸리티를 제공합니다. 멀티 테넌트 시나리오에서 조직은 DLP API(민감한 정보 보호의 일부)를 사용하여 민감한 정보를 저장하기 전에 식별하고 선택적으로 토큰화하는 경우가 많습니다.

슬롯 예약 관리

멀티 테넌트 시스템의 예약 관리는 테넌트가 수직 확장될 때 비용을 제어하고 각 테넌트의 성능을 보장합니다.

예약을 관리하려면 단일 예약 관리 프로젝트를 만드는 것이 좋습니다. 동일한 관리 프로젝트 내에서 구매한 슬롯 약정은 관리 프로젝트에서 시작되는 모든 예약에서 공유 가능합니다. 슬롯 약정을 사용하는 프로젝트는 한번에 하나의 예약에만 할당될 수 있습니다. 프로젝트에서 시작되는 모든 쿼리는 사용 가능한 리소스를 기준으로 슬롯을 공유합니다.

테넌트 서비스 수준 목표(SLO)를 충족하도록 하려면 Cloud Logging 및 BigQuery 정보 스키마를 통해 예약을 모니터링할 수 있습니다. 애널리스트 활동 또는 우선순위 작업으로 인해 바쁜 기간을 경험하는 조직은 가변 슬롯을 사용하여 추가 용량을 할당할 수 있습니다.

테넌트 컴퓨팅 단계 예약

수십 개에서 많게는 수천 개의 테넌트를 보유한 SaaS 공급업체는 일반적으로 한정된 수의 BigQuery 예약을 공유 리소스로 구성합니다.

테넌트 인프라를 공유한 SaaS 공급업체인 경우, 각 예약을 단일 프로젝트 및 그룹 테넌트에 할당하여 BigQuery 컴퓨팅에 해당 프로젝트를 공유하는 것이 좋습니다. 이 설계는 수천 개의 추가 프로젝트 및 예약으로 인한 관리 오버헤드를 줄이면서 조직이 예약에 대해 예상되는 성능 요구사항을 충족하는 데 필요한 최소한의 슬롯 용량을 할당할 수 있도록 합니다.

ELT 데이터 처리 시의성이 최우선인 경우 처리를 수행하도록 예약을 할당하는 것이 좋습니다. 임시 워크로드에 사용할 수 있는 추가 슬롯을 사용하지 않으려면 유휴 슬롯을 무시하도록 예약을 설정합니다.

다음은 예약을 테넌트 컴퓨팅 계층으로 구성하는 방법의 예시입니다.

• 데이터 처리: 슬롯 2,000개, 유휴 슬롯 무시. 이 예약은 데이터 처리 SLO를 충족하도록 구성됩니다.
• 내부 프로젝트: 슬롯 1,000개, 유휴 슬롯 허용. 이 예약은 내부 애널리틱스에 사용되는 프로젝트에 적용됩니다. 데이터 처리 또는 컴퓨팅 등급에서 남은 슬롯은 다시 사용됩니다.
• 낮은 컴퓨팅 등급: 슬롯 2,000개, 유휴 슬롯 무시. 이 예약은 리소스가 적은 테넌트에 적용됩니다. 높은 등급과 달리 이 예약은 유휴 슬롯을 무시합니다.
• 높은 컴퓨팅 등급: 슬롯 3,000개, 유휴 슬롯 허용. 이 예약은 리소스가 많은 테넌트에 적용됩니다. 쿼리 속도를 높이기 위해 다른 예약의 유휴 슬롯이 자동으로 적용됩니다.

테넌트가 전용 인프라에서 작동하는 경우 지정된 폴더 또는 프로젝트를 적절한 공유 예약에 할당하는 것이 좋습니다.

팀별 예약

데이터 마트 설정에서 팀과 작업하는 경우 추가 컴퓨팅이 필요한 각 팀의 예약을 만드는 것이 좋습니다. 그런 다음 해당 예약을 팀의 프로젝트가 포함된 상위 폴더에 할당합니다. 해당 팀의 모든 새 프로젝트는 동일한 리소스 할당에 있는 공정 예약 슬롯을 사용합니다.

다음은 팀별로 예약을 구성하는 방법의 예시입니다.

• 조직 수준 예약: 슬롯 500개, 유휴 슬롯 허용. 이 예약은 최상위 조직에 할당되며, 전용 예약이 있는 프로젝트를 사용하지 않는 BigQuery 사용자에게 슬롯을 제공합니다.
• 데이터 처리: 슬롯 1,000개, 유휴 슬롯 무시. 이 예약은 최소 데이터 처리 SLO를 충족하도록 구성됩니다.
• 핵심 데이터 관리: 슬롯 500개, 유휴 슬롯 허용. 이 예약은 내부 관리에 사용되는 프로젝트에 적용됩니다. 데이터 처리 또는 컴퓨팅 등급에서 남은 슬롯은 다시 사용됩니다.
• 애널리틱스 처리 예약: 슬롯 500개, 유휴 슬롯 허용. 이는 애널리틱스팀에 제공되는 전용 예약입니다.

멀티 리전 호스팅 요구사항

멀티 리전 호스팅 요구사항은 일반적으로 소비자의 데이터 지연 시간을 줄이거나 규제 요구사항을 충족해야 하기 때문에 발생합니다.

Google Cloud의 프로젝트는 전역으로 간주되어 모든 리전에서 리소스를 프로비저닝할 수 있습니다. BigQuery는 데이터 세트, 열 정책, 슬롯 약정을 리전별 리소스로 간주합니다. 슬롯은 로컬 리전의 데이터 세트에만 액세스할 수 있으며 열 정책은 로컬 데이터 세트 내의 테이블에만 적용될 수 있습니다. 용량 기반 가격 책정을 사용하려면 데이터 세트가 포함된 각 리전에서 슬롯을 구매해야 합니다.

규제 요구사항을 준수하기 위한 안내는 영업 담당자에게 문의하세요.

다음 단계

• IAM 권장사항 알아보기