horizontalline

データ ウェアハウス をクラウド上でセキュアに(IP 制限、専用線等)構築するパターン

解決する課題・使い所

 個人を特定できる情報 (PII = Personally Identifiable Information) を保管するデータベースに対して、データベース インスタンスを保護単位として、境界型のセキュリティルールによるネットワーク分離等の制約を課す企業があります。一方で BigQuery や Google Cloud Storage はサーバーインスタンスという概念を持たないサービスです。それらサービスに対して、管理対象をプロジェクトリソースとして切り出し、プロジェクト内リソースへのアクセスを管理することで境界型のセキュリティルールを設定することでセキュリティルールへ準拠することができるようになります。 また、データセキュリティやデータガバナンス ルールにより、データアクセスに対する監査要件への対処が求められることがあります。そういったケースで DWH へのデータアクセスログを必要な粒度で必要な期間に保管する方法を説明します。

アーキテクチャ

  • データ ウェアハウス を構築する際に主に使用されるコンポーネントとして BigQuery と Google Cloud Storage がありますが、前述の課題を解決すべくそれらのセキュリティレベルを確保するために使用されるのが VPC Service Controls です。VPC Service Controls を用いることにより、特定のサービスのリソースとデータをサービス境界内に配置し保護します。保護すべきデータをプロジェクトまたはプロジェクトグループとして保持し、それらをサービス境界内へ置くことで境界型のセキュリティを実現します。
  • また、監査を目的として BigQuery や Google Cloud Storage へのアクセスログを長期に渡って保存する場合には Cloud Logging に集約したデータアクセスログを BigQuery や Google Cloud Storage に書き戻すことにより実現ができます。なお Cloud Logging のデフォルトのログ保持期間は 30 日です。
VPC SC の構成図

利点

  • 特定の条件を満たすユーザアカウント、接続元ネットワーク、デバイスのみが境界内のリソースにアクセスできます。具体的な設定は Access Context Manager より Access Level を作成することにより可能です。
  • サービス境界外の未承認リソースにデータをコピーすることはできません。例えば、あるユーザアカウントが複数のプロジェクトに所属している場合、一方のプロジェクトから他方のプロジェクトに容易にデータをコピーできますが、サービス境界内のデータをサービス境界外のプロジェクトにコピーすることはできません。 

注意事項

  • サービス境界の設定は Google Cloud Storage や BigQuery といったサービス単位となります。これらのサービスが多くのユーザに多様な用途で使用されている場合、意図せず他のユーザの用途を妨げてしまう可能性があります。そのような場合は、保護対象のデータを扱うプロジェクトを別途作成し、そのプロジェクトをサービス境界内に設定してください。

サンプル コンフィグ

  • Access Context Manager
    • サービス境界内へのアクセスを許可する条件を定義します。アクセス元の IP アドレスによる制御を行う場合は IP サブネットワークを選択し CIDR ブロック表記で記述します。
  • VPC Service Controls
    • 保護するサービスに BigQuery API、Cloud Storage API を選択します。
    • Access Context Manager で作成したアクセスレベルを選択します。
  • BigQuery
    • 特になし
  • GCS
    • アクセスログを取得する設定を行います。具体的には Cloud Console で「IAM と管理」→「監査ログ」より Google Cloud Storage のデータ読み取りにチェックをつけます。
  • Cloud Logging
    • ログルータよりシンクを 2 つ作成、宛先サービスに Cloud Storage バケット かBigQuery Dataset を選択(BigQuery Dataset のほうがログの扱いが容易だが若干高価)
    • リソース:BigQuery・Google Cloud Storage バケット(それぞれひとつずつ)
    • データ種別:cloudaudit.googleapis.com/data_access 

このパターンで作成された事例

参照文献

VPC Service Controls の概要

データレイクからデータ ウェアハウスまでのパイプラインの保護

horizontalline

BigQuery Reservations によるワークロード管理

解決する課題

BigQuery をデフォルトの設定で使用している場合、オンデマンド料金という料金モデルが適用されます。この料金モデルでは、実行された各クエリの「処理されたバイト数(読み取りバイト数)」に基づいて料金が請求されます。たとえば、東京 (asia-northeast1) リージョンの場合、1 TB あたり $6 の料金が請求されます(最新の料金体系は、公式ドキュメントを参照してください)。また、この料金モデルにおける、プロジェクト内で利用可能な BigQuery スロット数の上限は、基本的に 2,000 スロットとなっています(状況によって、一時的に 2,000 スロット以上が使用可能となる場合もあります )。

このオンデマンド料金は、クエリ実行に応じて、つまりは、利用した分だけ料金が発生する料金モデルであるため、BigQuery の検証時や導入初期など、BigQuery を小規模に使用する段階においては、適切な料金モデルであると言えるでしょう。しかし、複数の部署やワークロードなどで BigQuery を大規模に使用する場合、以下のような課題に対応する必要があります。

  • BigQuery のクエリがどのくらい実行されるのかを予測することが難しく、BigQuery の毎月のクエリ料金を予測することが難しい
  • 大量データを検索するクエリの誤実行により、意図しないクエリ料金が発生する可能性がある
  • プロジェクト内で利用可能なスロットの上限が基本的に 2,000 スロットとなっており、これ以上のスロットを定常的に利用するような、大規模なデータの処理や分析の実施が難しい
  • 「クリティカルなワークロードに、優先的に多くのスロットを割り当てる」など、部署やワークロードの重要度に応じて、スロットの優先度や数を制御することが難しい

前述のような課題を解決し、BigQuery を複数の部署やワークロードなどで大規模に、安定的かつ効率的に利用できるようにするために、BigQuery では、BigQuery Reservations という、クエリ定額料金のスロットを購入してプロジェクトに割り当てることができる機能を提供しています。

BigQuery Reservations の概要

BigQuery Reservations とは、クエリ定額料金のスロットを購入し、また、そのスロットをプロジェクトに割り当てることができる機能です。クエリ定額料金とは、毎月のクエリ料金が固定となる料金モデルであり、購入したスロット数に基づいて料金が請求されます。たとえば、月定額契約の東京 (asia-northeast1) リージョンの場合、100 スロットあたり $2,400 の料金が毎月請求されます(最新の料金体系は、公式ドキュメントを参照してください)。

BigQuery Reservations を利用することのメリットとしては、主に以下のことが挙げられます。

  • クエリ料金の固定:クエリ定額料金の料金モデルが適用されるため、毎月のクエリ料金が固定となります。そのため、クエリ料金を気にせずに、データ分析を実施したり、BigQuery ML を用いた機械学習モデルの構築と予測を実施したりすることが可能となります。
  • クエリ料金の予測:毎月のクエリ料金が固定となるため、将来的に発生するクエリ料金を予測することが可能となります。
  • 柔軟性:Web UI 上で、クエリ定額料金のスロットを、必要な分だけ購入することができます。また、オンデマンド料金とクエリ定額料金の両方の料金モデルを併用することができます。たとえば、あるワークロードをオンデマンド料金で実行して、別のワークロードをクエリ定額料金で実行するなど、ワークロードに応じて、適用する料金モデルを変更することができます。
  • ワークロード管理:購入したクエリ定額料金のスロットを、部署やワークロードごとに分割して利用することができます。これにより、「クリティカルなワークロードに、優先的に多くのスロットを割り当てる」など、部署やワークロードの重要度に応じて、スロットの優先度や数を制御することが可能となります。また、未使用のスロットは、組織内で自動的に共有されて有効活用されるようになっています。たとえば、あるワークロード用に割り当てられているスロットが未使用である場合、別のワークロードの処理で、そのスロットを自動的に使用することができるようになっています。

BigQuery Reservations を構成する要素としては、主に以下のものがあります。

  • コミットメント:クエリ定額料金のスロットの購入契約を表します。コミットメントには、「どのコミットメント プランで、どのリージョンのスロットを、何スロット購入したか」という情報が含まれます。コミットメント プランの種類としては、コミットメントの期間と料金体系が異なる、以下の 3 つのものがあります。
    • Flex Slots:購入してから 60 秒後にキャンセルが可能となる契約
    • 月次契約:購入してから 30 日後にキャンセルが可能となる契約
    • 年間契約:購入してから 365 日後にキャンセルが可能となる契約
  • 予約:購入したクエリ定額料金のスロットを、部署やワークロードごとに分割して使用するためのものです。たとえば、アドホック分析のワークロード用の予約と、ETL バッチ処理のワークロード用の予約を作成し、購入したクエリ定額料金のスロットを分割して、それぞれの予約にスロットを設定することができます。 
  • 割り当て:どのプロジェクト(または組織やフォルダ)が、どの予約に割り当てられているかを表します。プロジェクト(または、組織やフォルダ)を予約に割り当てることで、そのプロジェクト(または、組織やフォルダ配下のプロジェクト)に対してクエリ定額料金の料金モデルが適用され、そのプロジェクトでの BigQuery のクエリ実行時には、予約に設定されているスロットが使用されるようになります。

BigQuery Reservations によるワークロード管理

BigQuery Reservations で購入したクエリ定額料金のスロット(コミットメント)を、複数の予約に分割して設定し、各予約にプロジェクト(または組織やフォルダ)を割り当てることで、部署やワークロードごとにスロットを分離して利用することができます。

たとえば、合計で 1,000 スロットのコミットメントがあり、データ サイエンス、ELT、BI という 3 つの種類のワークロードがあるとします。

  • 500 スロットを使用して ds 予約を作成し、データ サイエンス ワークロードで使用される全てのプロジェクトを ds 予約に割り当てることができます。
  • 300 スロットを使用して elt 予約を作成し、ELT ワークロードで使用される全てのプロジェクトを elt 予約に割り当てることができます。
  • 200 スロットを使用して bi 予約を作成し、BI ワークロードで使用される全てのプロジェクトを bi 予約に割り当てることができます。

この例における BigQuery Reservations のコミットメント、予約、割り当ての設定のイメージは、以下の図のようになります。

reservations

ここでは、前述の例のような BigQuery Reservations のコミットメント、予約、割り当ての設定方法をご紹介します。

  1. スロット(コミットメント)の購入 

まず、BigQuery Reservations のコミットメント、予約、割り当ての購入や設定を実施するための管理プロジェクトを用意します。その管理プロジェクトで BigQuery Web UI にアクセスし、左側のメニューの「予約」をクリックします。

bqmenu

「予約」ページへの遷移後、画面上部の「スロットを購入」をクリックします。

reservations_message

「スロットの購入」ページへの遷移後、画面上で「コミット期間」、「ロケーション」、「スロット数」を入力し、「次へ」ボタンをクリックします。以下の図は、「コミット期間」に「Flex」、「ロケーション」に「United States」、「スロット数」に「1000」を入力したときの例になります。

slot_purchase

「注文確認」に「CONFIRM」を入力して「購入」ボタンをクリックし、スロットの購入手続きを完了させます。

purchase_confirm

購入リクエスト完了の確認メッセージが表示されます。「スロット コミットメントを表示」ボタンをクリックします。

purchase_done

「予約」ページへ遷移し、画面下部に購入した 1,000 スロットのコミットメントが表示されていることを確認します。

commitments

以上の手順で、スロット(コミットメント)の購入手続きが完了しました。

2. 予約の作成

先ほどのスロットの購入により、デフォルトの予約と割り当てが作成されているため、まずはこれらを削除します。「予約」ページの「ASSIGNMENTS」タブをクリックします。表示されているデフォルトの割り当てを削除します。

reservations_list

同様に、「予約」ページの「RESERVATIONS」タブをクリックします。表示されているデフォルトの予約を削除します。

reservation_delete

「予約」ページの上部の「予約を作成」をクリックします。「予約を作成」ページへの遷移後、「予約名」、「場所」、「スロット数」を入力し、「保存」ボタンをクリックして予約を作成します。以下の図では、「予約名」に「ds」、「場所」に「United States」、「スロット数」に「500」をそれぞれ入力しています。

create_reservation

「予約」ページの「RESERVATIONS」タブにて、作成した ds 予約が表示されていることを確認します。

check_reservation

次に、「ASSIGNMENTS」タブをクリックし、予約へのプロジェクトの割り当てを実施します。画面下部の「組織、フォルダ、プロジェクトを選択」欄で、割り当てるプロジェクトを設定します。また、「予約」欄には、前述の手順で作成した ds 予約を設定します。「作成」ボタンをクリックして、予約へのプロジェクトの割り当てを実施します。以下の図では、「組織、フォルダ、プロジェクトを選択」欄に「ds-project-a」というプロジェクトを設定しています。

create_assignment

「予約」ページの「ASSIGNMENTS」タブにて、割り当てが作成されたことを確認します。

check_assignment

以上の手順で、ds 予約に対するプロジェクトの割り当てが完了しました。このプロジェクトでは、割り当てられている予約のリージョンで BigQuery のクエリを実行すると、割り当てられた予約のクエリ定額料金のスロットを使用して、クエリの処理が実行されるようになります。BigQuery Web UI の「クエリ結果」の「ジョブ情報」の「予約」欄で、どの予約のスロットが使用されてクエリが処理されたのかを確認することができます。

query_editor

同様の手順で、elt 予約と bi 予約の作成、および、それらの予約へのプロジェクトの割り当てを実施することができます。

3. 割り当て、予約、コミットメントの削除

最後に、今回の手順で作成、購入した、割り当て、予約、コミットメントを削除します。まずは、BigQuery Web UI の「予約」ページの「ASSIGNMENTS」タブを選択し、ds 予約へのプロジェクトの割り当てを削除します。 

delete_assignment

次に、「予約」ページの「RESERVATIONS」タブを選択し、ds 予約を削除します。

delete_reservation

最後に、「予約」ページの「SLOT COMMITMENT」タブを選択し、コミットメントを削除します。

delete_commitment

以上で、今回の手順で作成、購入した、割り当て、予約、コミットメントの削除が完了しました。 

備考

  • 購入したスロットは、他の組織とは共有できません。
  • BigQuery Reservations でのスロットの購入と割り当てを実施するための専用のプロジェクトを作成することを推奨します。このようなプロジェクトは「管理プロジェクト」と呼ばれ、コミットメントの管理を一元化することができます。
  • 未使用スロットは、同じ管理プロジェクト内に作成された予約間でのみ共有されます。複数の管理プロジェクトを使用する場合、異なる管理プロジェクトの予約間でスロットが共有されることはありません。
  • コミットメントは、リージョン リソースです。あるリージョンで購入したコミットメントを他のリージョンで使用することや、コミットメントをリージョン間で移動することはできません。
  • 予約にプロジェクトを割り当てる際には、以下のいずれかのジョブタイプを選択します。詳細については、公式ドキュメントを参照してください。
    • QUERY: この予約は、SQL、DDL、DML、BigQuery ML クエリなどのクエリジョブに使用します。
    • PIPELINE: この予約は、読み込み、エクスポート、その他のパイプライン ジョブに使用します。
    • ML_EXTERNAL: この予約は、BigQuery の外部にあるサービスを使用する BigQuery ML クエリに使用します。
  • BigQuery Reservations 予約のスロットの使用状況は、BigQuery の INFORMATION_SCHEMA または Cloud Monitoring を使用して確認することができます。詳細については、公式ドキュメントを参照してください。 

参照文献