BigQuery でのマルチテナント ワークロードに関するベスト プラクティス
このドキュメントでは、マルチテナント データ プラットフォームとエンタープライズ データマートで使用される定番の手法とベスト プラクティスについて説明します。
企業、SaaS（Software as a Service）ベンダー、行政機関では、地理的境界と行政区分を越えて、内部およびサードパーティ双方のデータを安全にホストしなければならないことがよくあります。BigQuery は、異なるビジネス ユニット間で、エクサバイト規模のデータと数十万のデータ利用者に対するマルチテナント プラットフォームの要件を一貫性をもって扱える優れたツールです。このドキュメントは、BigQuery にマルチテナント プラットフォームをデプロイし、利用可能なアクセス制御とパフォーマンス管理機能を把握したい組織を対象としています。
マルチテナント プラットフォームを構築する組織では、多くの場合、次の点を考慮する必要があります。
- データの分離: 複数のテナントにまたがるデータ漏洩を防ぐため、優れた統制を実施します。
- 安定したパフォーマンス: BigQuery の予約を構成して割り当てることで、複数のテナントにわたり安定したパフォーマンスを維持できます。
- リソース管理: 割り当てと上限の影響を計画します。
- 地理的な分散: 指定された所定の地理的なロケーションにデータを配置します。コンプライアンス関連の問題については、Google Cloud のコンプライアンス状況をご覧ください。
- 監査とセキュリティ: 不適切なアクセスとデータの引き出しからテナントデータを保護します。
- コスト管理: 各テナントをホストする BigQuery の費用を一定に保ちます。
- 運用上の複雑さ: 新しいテナントをホストする上でのシステムの変動要素を最小限に抑えます。
共有のテナント インフラストラクチャを持つ SaaS ベンダー
サードパーティ データをホストする SaaS ベンダーは、同社のお客様が信頼してサービスを利用できるようにし、お客様の全フリートを分離する必要があります。そうしたお客様の数は数万にもなり、顧客データには共有されたサービス インフラストラクチャを介してアクセスされる可能性があります。また、テナントのフリート全体の分析を行うためにサニタイズされた中央データストアを維持する SaaS ベンダーも存在します。
テナント単位のデータセットという設計によって、テナントの数が数千規模に増える場合に組織が経験する次のような問題を軽減できます。
- 管理の複雑性: お客様ごとの新しいプロジェクトとクラウド リソースの合計数
- エンドツーエンドのレイテンシ: テナントの分析ソリューションと顧客間分析ソリューションの両方に対して、データストアがどのくらい最新の状態に保たれているか
- パフォーマンスの想定値: テナントのパフォーマンスを許容範囲内に保つ
テナントごとにデータセットを構成する
顧客データの保存専用のプロジェクトでは、各顧客データが BigQuery データセットによって分離されています。ホスト組織内では、第 2 のプロジェクトを使用して、統合した顧客データに分析と機械学習をデプロイします。その後、データ処理エンジン（Dataflow）を構成して、内部テーブルおよびテナント固有のテーブル双方に受信データを書き込むことができます。Dataflow 構成では、承認済みビューではなく、完全に書き込まれたテーブルが使用されます。完全に書き込まれたテーブルを使用すると、地理的な分散を一様に扱うことができ、テナントの数が増えても承認済みビューの上限に達することを回避できます。
BigQuery のストレージとコンピューティングを分離することで、クラスタベースのウェアハウスと比較して、サービスの階層やデータ分離などの問題に対処するために構成するプロジェクトの数を減らせます。別の専用クラウド リソースを使用してテナントを構成する必要がない場合は、テナントごとに専用データセットのデフォルトの構成を検討することをおすすめします。次の図では、この推奨設計に基づくプロジェクト構成の例を示します。
図 1: テナント数の増加に合わせて、一定数のプロジェクトでデータと処理のニーズに対処します。
図 1 のプロジェクト構成には、次のプロジェクトがあります。
- データ パイプライン プロジェクト: テナントのデータを受信、処理、分散するコア インフラストラクチャ コンポーネントは、すべて 1 つのプロジェクトにパッケージ化されます。
- 複合テナントデータ プロジェクト: お客様ごとにデータセットを管理するコアデータ プロジェクト。テナントデータは、コンピューティング階層プロジェクトを介してアクセスされます。
- 内部開発プロジェクト: 分析チームがテナントデータを評価し、新機能をビルドするために使用する、セルフマネージド リソースを表すプロジェクト。
- エンドユーザー アプリケーション プロジェクト: エンドユーザーとやり取りするように設計されたリソースを含むプロジェクト。テナントスコープ サービス アカウントを使用してテナント データセットにアクセスし、堅牢で安全なビルド パイプラインを使用してアプリケーションをデプロイすることをおすすめします。
- 予約コンピューティング階層プロジェクト: テナントのクエリ操作を BigQuery の予約にマッピングするプロジェクト。
予約を共有する
この方法での予約は、BigQuery の予約に組み込まれているフェア スケジューリング アルゴリズムに基づいています。各コンピューティング階層の予約は、1 つのプロジェクトに割り当てられます。テナントのクエリでは、各コンピューティング階層のプロジェクトで使用できるフェア スケジューリング スロットが使用されます。どの階層でも未使用のスロットがあれば、自動的に別の階層で再利用されます。テナントに特定のタイミング要件がある場合は、決まったスロット数を提供する専用のプロジェクト予約ペアを使用できます。
VPC Service Controls の境界を構成する
この構成では、VPC Service Controls の境界を使用することをおすすめします。これにより、テナント データセットが Google Cloud 組織外に誤って公開されることや、承認されていないデータが組織内に紛れ込むことを避けられます。
境界
この構成では、次のサービス境界を作成することをおすすめします。
- データ パイプライン: データ パイプライン プロジェクトの境界は、テナントデータを受信する必要がないすべてのサービスに適用します。
- テナントデータ: テナント データセット プロジェクトの境界とテナント BigQuery コンピューティング プロジェクトの境界。組織外からのアクセスを防ぐために、すべてのサービスに適用します。
- 内部アプリケーション: すべてのサービスに適用し、アクセスレベルを使用して部門チームにリソースへのアクセスを許可します。
- 外部アプリケーション: SaaS アプリケーションの境界。アプリケーションの機能には必要ないサービスすべてに適用します。
境界ブリッジ
この構成では、次の境界ブリッジを作成することをおすすめします。
- データ パイプラインとテナントデータ: データをパイプラインからテナント データセットに書き込めるようになります。
- データ パイプラインと内部アプリケーション: パイプラインがお客様間データセットにデータを書き込めるようにします。
- 外部アプリケーションとテナントデータ: 外部向けアプリケーションがテナントデータをクエリできるようにします。
- 外部アプリケーションと内部アプリケーション: 内部アプリケーションで開発およびデプロイしたモデルを使用して、外部向けアプリケーションがデータを処理できるようにします。
専用のテナント インフラストラクチャを持つ SaaS ベンダー
より複雑なシナリオでは、SaaS ベンダーが専用のコンピューティング インフラストラクチャを各テナントに対してデプロイする場合があります。このシナリオでは、専用のインフラストラクチャが BigQuery 内のテナントデータのリクエストの処理を担当します。
専用のテナント インフラストラクチャ設計により、BigQuery とともに各テナントにインフラストラクチャをデプロイする際に発生する、次に挙げる共通の問題に対処できます。
- 課金の説明責任: オンボーディングされた各テナントに関連するインフラストラクチャ費用の追跡。
- エンドツーエンドのレイテンシ: テナントの分析ソリューションと顧客間分析ソリューションの両方に対して、データストアがどのくらい最新の状態に保たれているか。
- パフォーマンスの想定値: テナントのパフォーマンスを許容範囲内に保つようにする。
データセットを専用リソースと同じ場所に配置する
専用のテナント インフラストラクチャをデプロイする場合は、テナント固有のプロジェクトの親フォルダを作成することをおすすめします。それから、そのテナントに代わって、テナントの BigQuery データセットを、データにアクセスする専用のリソースとともにプロジェクトに配置します。テナントデータのエンドツーエンドのレイテンシを最小限に抑えるため、Dataflow パイプラインでは、データを直接テナント データセットに挿入します。
この設計では、前述の共有インフラストラクチャの設計と同様、上流データの処理と配信に対応します。ただし、テナントデータと、テナントデータにアクセスするアプリケーションは、テナント固有のプロジェクト（および必要に応じてテナント専用フォルダ）内に編成され、課金とリソース管理が簡素化されます。次の図では、この推奨設計に基づくプロジェクト構成の例を示します。
図 2. データ パイプライン プロジェクトが、単一のテナントに対する別の複数のプロジェクトからのデータに対応します。
図 2 のプロジェクト構成には、次のプロジェクトがあります。
- データ パイプライン プロジェクト: テナントのデータを受信、処理、分散するコア インフラストラクチャ コンポーネントは、すべて 1 つのプロジェクトにパッケージ化されます。
- 専用テナント プロジェクト: BigQuery データセットなど、1 つのテナント専用のクラウド リソースすべてを含むプロジェクト。顧客データセットにアクセスできるアカウントとサービス アカウントの範囲は、Identity and Access Management（IAM）を使用して、かなり制限することをおすすめします。
- 内部分析プロジェクト: 分析チームがテナントデータを評価し、新機能をビルドするために使用する、セルフマネージド リソースを表すプロジェクト。
- 外部ネットワーク プロジェクト: テナント リクエストに対応して、専用のバックエンドに転送するプロジェクト。
予約を共有する
この方法での予約は、BigQuery の予約に組み込まれているフェア スケジューリング アルゴリズムに基づいています。この構成では、コンピューティング階層の予約が、その階層を使用する各テナント プロジェクトに割り当てられます。テナントに固有のタイミング要件がある場合は、専用の予約を作成してテナント プロジェクトに決まった数のスロットを指定できます。
IAM コントロールを使用して鍵の作成を無効にする
このシナリオには、VPC Service Controls の境界が適切ではない場合があります。プロジェクト関連の制限により、組織はテナント プロジェクトとやり取りするプロジェクトに境界を使用する必要がなくなります。代わりに、厳しい IAM 制御を使用して鍵の作成を無効にし、望ましくない外部アクセスから保護することをおすすめします。
権限が集中したデータマート
データマートは設計における共通のテーマです。この設計では、コア分析データが中央リポジトリに保存され、その一部が事業ラインに沿って共有されます。データマートは、検討対象の事業ラインとして表される数十または数百のテナントを抱えることがよくあります。
BigQuery のデータマート設計は、次のようなニーズに適しています。
- 安全なデータ コラボレーション: 複数のチームにわたる不適切なアクセスを最小限に抑えるため、技術的なコントロールによってデータを共有する。
- 中央データ ガバナンス: 重要なビジネス レポートに使用されるコアデータ アセットの標準化と検証を徹底する。
- ビジネス ユニットの費用の特性: ビジネス ユニットごとにコンピューティングの使用状況を追跡して調整する。
一元管理されたリポジトリを使用する
この設計では、コアデータは一元的なリポジトリに取り込まれます。承認済みビュー、認可済みのユーザー定義関数（UDF）、列ポリシーは、機密データの誤配信を防止しながら事業ラインとデータを共有するために、たびたび一緒に使用されます。
テナント プロジェクトのチームは、アカウントの権限に基づいて、一元的に管理されるデータセットにアクセスできます。チームは、自身のプロジェクトに割り当てられたスロットを使用して、レポートと派生データセットを作成します。コアデータ チームは、承認済みビューを使用して、データマートのアセットに対するアクセス制御の完全な所有権を管理します。この構成では、コアデータ プロジェクトが提供するオブジェクトの上に、複数レイヤのビューを作成しないようにすることをおすすめします。次の図では、この推奨設計に基づくプロジェクト構成の例を示します。
図 3. 組織全体からアクセス可能な一元化されたデータマートをコアデータ プロジェクトが維持しています。
図 3 のプロジェクト構成には、次のプロジェクトがあります。
- コアデータ プロジェクト: コアデータとデータマート ビューへのアクセスを管理するための管理境界。このプロジェクトにあるデータセット内で承認済みビューを管理し、グループのメンバーシップに基づいて承認済みビューを分析チームに許可します。
- 抽出、変換、ロード（ETL）インフラストラクチャ: 上流のデータソースを処理してコアデータにするためのインフラストラクチャ。ETL インフラストラクチャは、管理の分離ニーズに応じて、独自のプロジェクトか、コアデータ プロジェクトの一部としてデプロイできます。
- 分析チーム プロジェクト: データマートの利用者は、これらのプロジェクトを使用し、さらに独自にプロビジョニングしたインフラストラクチャ アクセスを使用してデータマート内のデータを処理します。分析チーム プロジェクトは、ローカルで使用する派生データセットを構築できる状態であることが期待されます。
2 層予約設計を使用する
データマートを使用する場合は、2 層設計を使用することをおすすめします。2 層設計では、一般的な使用を考慮し、この組織リソースを少量のスロットを持つ予約に割り当てます。チームに多くのニーズがある場合は、プロジェクト レベルまたはフォルダレベルで予約を割り当てます。
VPC Service Controls の境界を構成する
この構成では、Google Cloud 組織の外に BigQuery データセットが誤って公開されないように、VPC Service Controls の境界の使用をおすすめします。
境界
この構成では、次のサービス境界を作成することをおすすめします。
- コアデータ: データ ウェアハウスとデータマート データセットを保護する境界。
- データ パイプライン: ETL インフラストラクチャ プロジェクトの境界。データ パイプラインで Google Cloud 組織の外部にリクエストを行う必要がある場合は、この境界をコアデータ境界から分離することをおすすめします。
- 分析: 組織内部の分析アセットを構築してデプロイするための境界。この境界は、ブリッジされるコアデータ境界よりも制限の厳しいアクセス ポリシーを含むことが想定されます。
境界ブリッジ
この構成では、次の境界ブリッジを作成することをおすすめします。
- データ パイプラインとコアデータ: データ パイプラインがコアデータ プロジェクトに書き込めるようになります。
- コアデータと分析: 分析プロジェクトのユーザーが承認済みビューをクエリできます。
マルチリージョン構成用にデータセットをコピーする
BigQuery では、複数のリージョンをまたぐクエリを使用できないため、データマートが複数のリージョンに存在する場合に承認済みビューでデータをセグメント化する方法は使用できません。代わりに、BigQuery Data Transfer Service を使用することで、関連するデータセットを別のリージョンにコピーできます。このシナリオでは、データが存在する新たなリージョンごとにデータカタログ内に列ポリシーを作成します。次の図では、マルチリージョン構成を示します。
図 4. マルチリージョン構成でリージョン間でデータセットをコピーするために BigQuery Data Transfer Service を使用します。
図 4 のプロジェクト構成には、次のプロジェクトがあります。
- コアデータ プロジェクト: コアデータとデータマート ビューへのアクセスを管理するための管理境界。データは、世界中のチームがアクセス可能なリージョン データセットにコピーされて管理されます。
- ETL インフラストラクチャ: 上流のデータソースを処理してコアデータにするインフラストラクチャ。ETL インフラストラクチャは、管理の分離ニーズに応じて、独自のプロジェクトか、コアデータ プロジェクトの一部としてデプロイできます。
- 分析チーム プロジェクト: データマートの利用者は、これらのプロジェクトを使用し、独自のプロビジョニングされたインフラストラクチャを使用して、データマートのリージョン データセット内でデータを処理します。分析チーム プロジェクトは、ローカルで使用する派生データセットを構築できる状態であることが期待されます。
BigQuery Data Transfer Service は、スケジュール設定された追加コンポーネントで、いくつかの制限があります。組み込みのサービス スケジューラは、最小間隔を 15 分に制限されており、ソース データセットからすべてのテーブルをコピーする必要があります。リージョン固有のデータ サブセットを作成するために、追加のスクリプトを BigQuery Data Transfer Service のスケジューラに組み込む方法はありません。
組織にさらに柔軟性が必要な場合は、次のオプションを利用できます。
- Cloud Composer のジョブ: リージョン サブセットを作成する ETL ジョブを発行するように Cloud Composer ジョブをスケジュールした後、クライアント API を介して BigQuery Data Transfer Service をトリガーします。組織がレイテンシの増大を許容できる場合は、このオプションをおすすめします。
- ETL インフラストラクチャ: Dataflow などの ETL インフラストラクチャでは、リージョンのサブセットをターゲット リージョンに 2 か所同時に書き込むことができます。リージョン間でデータのレイテンシを最小限に抑える必要がある場合は、このオプションをおすすめします。
分権化されたデータマート
システム オーナー、事業ライン、地理的な問題ごとに管理を分割する必要がある場合は、分権化を行います。
分権化されたデータマートは、標準のデータマートと次の点で異なります。
- 安全なデータ コラボレーション: 複数のチームにわたる不適切なアクセスを最小限に抑えるため、技術的なコントロールによってデータを共有する。
- データの検出: チームはデータセットを検出してアクセス権をリクエストできる必要があります。
- データの出所: 中央のキュレーター チームがない場合は、分析プロダクトに取り込むデータの送信元を信頼できなければなりません。
コアデータ管理を委任する
この設計では、分権化によってコアデータ管理の意思決定が組織のコンポーネント サブグループに委任されるため、従来のデータマート方式とは異なります。分権を使用すると、Cloud Key Management Service（Cloud KMS）、列ポリシー、VPC Service Controls、予約を使用して、セキュリティと BigQuery の容量を一元的に管理できます。したがって、セルフマネージド ウェアハウスでよく発生するデータの無秩序な拡大が回避されます。次の図では、分権を使用するアーキテクチャを示します。
図 5. コアガバナンス プロジェクトが一貫したセキュリティを確保し、個々のグループは引き続きデータ オペレーションを行います。
図 5 のプロジェクト構成には、次のプロジェクトがあります。
- コアガバナンス プロジェクト: 複数の組織にまたがる管理の問題を受け持つプロジェクト。このプロジェクトでは、Cloud KMS キーリングやデータカタログの列ポリシーなどのセキュリティ リソースを作成します。このプロジェクトは、BigQuery の予約管理プロジェクトとしての役割を果たします。これにより、スロットを組織全体で共有できます。
- 組織部門のデータ プロジェクト: 幅広い組織のセルフマネージド データマートのオーナー。コアガバナンス プロジェクトは、組織部門データ プロジェクトの制限付きスコープを管理します。
- 分析チーム プロジェクト: データマートの利用者が使用するプロジェクト。これらのプロジェクトは独自にプロビジョニングされたインフラストラクチャとスロットを使用し、データマート内のデータにアクセスして処理します。
2 層予約設計を使用する
分権化されたデータマートには、標準のデータマートと同じ 2 層設計を使用することをおすすめします。この構成では、一般的な使用を考慮して、この組織リソースを少量のスロットを持つ予約に割り当てます。チームに多くのニーズがある場合は、プロジェクト レベルまたはフォルダレベルで予約を割り当てます。
データカタログを使用する
データカタログは、組織全体の調査、メタデータのタグ付け、列ポリシーの構成を実現します。Dataplex の検出により、組織全体のすべての新しい BigQuery テーブルのメタデータ エントリが自動的に作成されます。Dataplex の機能は、データ ガバナンス管理者が新しいデータアセットをすばやく特定し、適切な制御を適用するうえでも役立ちます。
VPC Service Controls の境界を構成する
この構成では、Google Cloud 組織の外に BigQuery データセットが誤って公開されないように、VPC Service Controls の境界の使用をおすすめします。
境界
この構成では、次のサービス境界を作成することをおすすめします。
- コアデータ: データ ウェアハウスとデータマート データセットを保護する境界。この境界には、すべての組織部門プロジェクトとデータ ガバナンス プロジェクトを含める必要があります。
- 分析: 組織内部に分析アセットを構築してデプロイするための境界。この境界は、ブリッジされるコアデータ境界よりも制限の厳しいアクセス ポリシーを含むことが想定されます。
境界ブリッジ
この構成では、次の境界ブリッジを作成することをおすすめします。
- コアデータと分析: 分析プロジェクトのユーザーが承認済みビューをクエリできます。
複数組織のデータ共有
複数組織の共有は、データマートの設計を目的とした設計上の特別な配慮です。このデータ共有設計は、独自の Google 組織を持つ別のエンティティとデータセットを安全に共有する必要がある組織を対象としています。
組織間のデータ共有により、データ共有に関する次のような課題に対処できます。
- 機密性の共有: 共有したデータには、指定したグループのみがアクセスできます。
- 不適切なアクセスからの保護: 指定したリソースだけが外部からアクセス可能になります。
- コンピューティングの分離: 外部のグループは、実行したクエリに対して課金されます。
共有データ プロジェクトから社内プロジェクトを保護する
複数組織のデータ共有設計では、共有データ プロジェクトにおける取り組みから組織の内部プロジェクトを保護することに重点を置いています。共有データセット プロジェクトは、機密性の高い内部データの処理へのアクセスを遮断するバッファとして機能しますが、同時に、データを外部と共有する機能も提供します。
外部プロジェクトによって開始されたクエリは、呼び出し元のプロジェクトのコンピューティング リソースを使用します。クエリされたデータセットすべてが同じ Google Cloud リージョンを共有している場合、こうしたクエリは、複数の組織にわたるデータを結合できます。次の図では、複数組織のプロジェクト構成でデータセットが共有される様子を示します。
図 6: 共有プロジェクト内の複数のデータセットから外部組織がデータをクエリしています。
図 6 のプロジェクト構成には、次のプロジェクトがあります。
- 組織内部プロジェクト: 機密性の高い内部データを含むプロジェクト。内部プロジェクトは、サニタイズされたデータを共有データ プロジェクトのデータセットにコピーすることで、外部とデータを共有できます。内部プロジェクトは、共有データの更新を受け持つサービス アカウントを所有している必要があります。
- 共有データ プロジェクト: 内部プロジェクトからコピーされるサニタイズされた情報を格納するプロジェクト。外部ユーザー グループを使用して外部のグループによるアクセスを管理します。このシナリオでは、グループ メンバーを管理機能として管理し、グループを介してデータセットにアクセスできるように、外部のアカウントに閲覧者権限を付与します。
VPC Service Controls の境界を構成する
この構成では、VPC Service Controls の境界でデータを外部と共有し、BigQuery データセットが内部プロジェクト以外に誤って公開されないようにすることをおすすめします。
境界
この構成では、次のサービス境界を作成することをおすすめします。
- 内部データ: コアデータ アセットを保護する境界。VPC Service Controls では、BigQuery へのアクセスを強制的に実行します。
- 外部共有データ: 外部組織と共有できるデータセットをホストするための境界。この境界により、BigQuery へのアクセスの強制が無効になります。
境界ブリッジ
この構成では、次の境界ブリッジを作成することをおすすめします。
- 内部から外部へのデータ: 境界ブリッジにより、保護が強化された内部データ プロジェクトから外部データ共有プロジェクトに下り（外向き）データを送信できます。
マルチテナント システムにおけるその他の考慮事項
このセクションでは、特殊なケースについて詳しく説明します。これまでに挙げたベスト プラクティスと併せて検討してください。
Google Cloud リソースの上限と割り当て
- サービス アカウントのソフト割り当ては、プロジェクトごとに 100 個までに制限されます。テナント サービス アカウントを管理するプロジェクトの場合は、Google Cloud コンソール から割り当てをリクエストできます。
- BigQuery の同時実行数は、クエリを発行するプロジェクトごとにデフォルトで 100 クエリです（データセットを保持するプロジェクトにこのような制限はありません）。このソフト割り当てを増やすには、営業担当者にお問い合わせください。
- VPC Service Controls では、組織全体のサービス境界内で 10,000 件のプロジェクトという上限が設定されています。テナントごとのプロジェクト設計が、大きなスケールアップを含んだものである場合は、代わりにテナントごとのデータセット設計を使用することをおすすめします。
- VPC Service Controls では、ブリッジも含め組織ごとの境界が 100 個までに制限されています。
承認済みビューやマテリアライズド サブセット テーブルの使用
大規模なファクト テーブルのサブセットへのテナント アクセスを管理するには、テナント固有の承認済みビューを使用するか、テナント固有のサブセット テーブルを作成します。次の表では、これらの方法の比較を示します。
| 機能 | 承認済みビュー | サブセット テーブル |
|---|---|---|
| サポートされるテナントの数 | データセットごとに承認済みリソースは 2,500 個までというハードリミットがあります。 | 承認済みリソースには、承認済みビュー、承認済みデータセット、承認済み関数が含まれます。プロジェクト内のデータセットの数やデータセット内のテーブルの数に制限はありません。 |
| パーティショニングとクラスタリング |
承認済みビューは、ベーステーブルの共通のパーティショニングとクラスタ スキームを共有している必要があります。 テナント セグメンテーションのパフォーマンスを向上させるため、テナント ID で親テーブルをクラスタ化することをおすすめします。 |
サブセット テーブルは、テナントのニーズに応じて、パーティション分割しクラスタ化できます。 |
| リージョン指定 | 承認済みビューがリージョンを越えることはできません。また、ベーステーブルの Google Cloud リージョンになければなりません。リージョン指定は、地理的に離れたテナントに影響を与えます。 | サブセット テーブルは、テナントに最適なリージョンに配置できます。追加費用が発生する場合があります。 |
| 列ポリシーの適用 | ベーステーブルに適用される列ポリシーは、そのビューに対する権限に関係なく、すべての承認済みビューに適用されます。 | 列ポリシーの効果を得るには、各サブセット テーブルに適用する必要があります。 |
| データアクセスのロギング | データアクセス ログは、ベーステーブルのロギングに反映されます。 | 各サブセット テーブルへのアクセスは、個別にロギングされます。 |
| 変換の柔軟性 | 承認済みビューを使用すると、テナントがアクセスするオブジェクトをすぐに再設計できます。 | サブセット テーブルの変更には、複雑なスキーマの変更が必要です。 |
センシティブ データの管理
データへの不正アクセスを防ぐため、BigQuery には、標準の IAM 権限以外にも複数の機能が用意されています。
クライアント指定の暗号化
クライアント データの暗号化は、テナントに代わってデータの保存や処理を行うホスティング組織がデータの内容にアクセスすることを禁じる場合に有効です。たとえば、個人データやデバイスデータが機密とみなされ、ホスティングを行う組織によるアクセスが禁じられる場合があります。
データ送信者は、オープンソースの Tink ライブラリの AEAD 暗号鍵を使用して機密データを暗号化することをおすすめします。Tink ライブラリの AEAD 暗号鍵は、BigQuery の AEAD 関数と互換性があります。テナントは、認可済みの UDF 内の鍵マテリアルにアクセスするか、鍵マテリアルをクエリ パラメータとして BigQuery に渡すことで、データを復号できますが、ホスト組織が鍵をログに記録することはできません。
列アクセス ポリシー
マルチテナントのデータマートでは、コラボレーションしているチーム間で機密性の高いコンテンツが誤って漏洩するのを防ぐために、列ポリシーがよく使用されます。承認済みビューは、データマートのシナリオでチーム間でデータを共有する場合に適しています。承認済みビューで保護された列へのアクセスが許可されることはありません。
アクセス制御を適用するようにポリシーを設定すると、ポリシーに対するきめ細かい読み取りロールを付与されていないユーザーへのアクセスが回避されます。ポリシーが適用されていない場合でも、分類された列に対するすべてのユーザー アクセスがポリシーによってログに記録されます。
Sensitive Data Protection
機密データの保護 は、BigQuery や Cloud Storage データセットに保存される機密コンテンツを識別して低減することを容易にする API とスキャン ユーティリティを提供します。マルチテナントのシナリオでは、機密データを識別し、必要に応じてトークン化した後、機密データを保存するために DLP API（Sensitive Data Protection の一部）がよく使用されます。
スロット予約管理
マルチテナント システムでの予約管理は、テナントのスケールアップに伴う費用をコントロールし、各テナントに対するパフォーマンス保証を確かなものにします。
予約を管理するには、予約管理プロジェクトを 1 つだけ作成することをおすすめします。同じ管理プロジェクト内で購入されたスロット コミットメントは、その管理プロジェクトから発生したすべての予約で共有できます。スロット コミットメントを使用するプロジェクトは、一度に 1 つの予約にのみ割り当てることができます。プロジェクトから派生するすべてのクエリは、使用可能なリソースに基づいてスロットを共有します。
テナントのサービスレベル目標（SLO）を確実に達成するため、予約は、Cloud Logging と BigQuery 情報スキーマを使用してモニタリングできます。分析アクティビティや優先ジョブによってビジー状態が長く続く場合は、Flex Slots のスロットを使用して追加の容量を割り当てることができます。
テナント コンピューティング階層としての予約
通常、数十から数千ものテナントを持つ SaaS ベンダーは、限られた数の BigQuery 予約を共有リソースとして構成します。
共有のテナント インフラストラクチャを持つ SaaS ベンダーの場合は、それぞれの予約を 1 つのプロジェクト専用とし、テナントをグループ化して BigQuery コンピューティング用にそのプロジェクトを共有することをおすすめします。この設計によって、数千の追加のプロジェクトと予約を持つという管理上のオーバーヘッドが削減され、組織では、予約に対して期待されるパフォーマンスのニーズを満たすために必要な最低限のスロット容量を割り当てることができます。
ELT データ処理のタイムラインが最優先事項である場合は、その処理を行うために予約を割り当てることをおすすめします。アドホック ワークロードに使用される余分なスロットを使用しないようにするには、アイドル スロットを無視するように予約を設定します。
次の例では、テナント コンピューティング階層として予約を構成する方法を示します。
- データ処理: 2,000 スロット（アイドル スロットは無視）。この予約は、データ処理の SLO を満たすように構成されます。
- 内部プロジェクト: 1,000 スロット（アイドル スロットを許可）。この予約は、内部分析に使用するプロジェクトに適用されます。スロットがデータ処理階層やコンピューティング階層に残っている場合は、それが再利用されます。
- 低コンピューティング階層: 2,000 スロット（アイドル スロットは無視）。この予約は、リソースが少ないテナントに適用されます。高コンピューティング階層とは異なり、この予約ではアイドル スロットを無視します。
- 高コンピューティング階層: 3,000 スロット（アイドル スロットを許可）。この予約は、リソースが多いテナントに適用されます。クエリを高速化するため、他の予約のアイドル スロットが自動的に適用されます。
テナントが専用のインフラストラクチャで動作している場合は、指定されたフォルダやプロジェクトを適切な共有予約に割り当てることをおすすめします。
チームあたりの予約数
データマートの設定で複数のチームに対応する場合は、追加のコンピューティングが必要なチームごとに予約を作成することをおすすめします。次に、その予約を、チームのプロジェクトを含む親フォルダに割り当てます。そのチームの新しいすべてのプロジェクトでは、同じリソース割り当てのフェア スケジューリング スロットが使用されます。
次の例では、チームごとの予約の構成方法を示します。
- 組織レベルの予約: 500 スロット（アイドル スロットを許可）。この予約は、最上位の組織に割り当てられ、専用の予約があるプロジェクトを使用していない BigQuery ユーザーにスロットを割り当てます。
- データ処理: 1,000 スロット（アイドル スロットは無視）。この予約は、最低限のデータ処理 SLO を満たすように構成されます。
- コアデータ管理: 500 スロット（アイドル スロットを許可）。この予約は、内部管理に使用されるプロジェクトに適用されます。スロットがデータ処理階層やコンピューティング階層に残っている場合は、それが再利用されます。
- 分析処理の予約: 500 スロット（アイドル スロットを許可）。これは、分析チームに与えられる専用の予約です。
マルチリージョン ホスティングの要件
通常、マルチリージョン ホスティングの要件は、利用者に対するデータ レイテンシの削減か、規制義務の遵守のどちらかのニーズに応じたものになります。
Google Cloud 内のプロジェクトはグローバルと見なされ、どのリージョンでもリソースをプロビジョニングできます。BigQuery では、データセット、列ポリシー、スロット コミットメントがリージョン リソースと見なされます。スロットはローカル リージョン内のデータセットにのみアクセスできます。列ポリシーは、ローカル データセット内のテーブルにのみ適用できます。容量ベースの料金を利用するには、データセットが含まれている各リージョンのスロットを購入する必要があります。
規制要件を遵守する方法については、営業担当者にお問い合わせください。
次のステップ
- IAM のベスト プラクティスについて確認する。