データ ウェアハウス をクラウド上でセキュアに（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 日です。

利点

• 特定の条件を満たすユーザアカウント、接続元ネットワーク、デバイスのみが境界内のリソースにアクセスできます。具体的な設定は 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 

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

• D1-7-S01: 実例から学ぶ、VPC Service Control Deep Dive

参照文献

• VPC Service Controls の概要

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

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 と Google Cloud Storage がありますが、前述の課題を解決すべくそれらのセキュリティレベルを確保するために使用されるのが VPC Service Controls です。VPC Service Controls を用いることにより、特定のサービスのリソースとデータをサービス境界内に配置し保護します。保護すべきデータをプロジェクトまたはプロジェクトグループとして保持し、それらをサービス境界内へ置くことで境界型のセキュリティを実現します。

• また、監査を目的として BigQuery や Google Cloud Storage へのアクセスログを長期に渡って保存する場合には Cloud Logging に集約したデータアクセスログを BigQuery や Google Cloud Storage に書き戻すことにより実現ができます。なお Cloud Logging のデフォルトのログ保持期間は 30 日です。

BigQuery Reservations の概要

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

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

• クエリ料金の固定
  クエリ定額料金の料金モデルが適用されるため、毎月のクエリ料金が固定となります。そのため、クエリ料金を気にせずに、データ分析を実施したり、BigQuery ML を用いた機械学習モデルの構築と予測を実施したりすることが可能となります。

• クエリ料金の予測
  毎月のクエリ料金が固定となるため、将来的に発生するクエリ料金を予測することが可能となります。

• 柔軟性
  Web UI 上で、クエリ定額料金のスロットを、必要な分だけ購入することができます。また、オンデマンド料金とクエリ定額料金の両方の料金モデルを併用することができます。たとえば、あるワークロードをオンデマンド料金で実行して、別のワークロードをクエリ定額料金で実行するなど、ワークロードに応じて、適用する料金モデルを変更することができます。

• ワークロード管理
  購入したクエリ定額料金のスロットを、部署やワークロードごとに分割して利用することができます。これにより、「クリティカルなワークロードに、優先的に多くのスロットを割り当てる」など、部署やワークロードの重要度に応じて、スロットの優先度や数を制御することが可能となります。また、未使用のスロットは、組織内で自動的に共有されて有効活用されるようになっています。たとえば、あるワークロード用に割り当てられているスロットが未使用である場合、別のワークロードの処理で、そのスロットを自動的に使用することができるようになっています。

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

• コミットメント
  クエリ定額料金のスロットの購入契約を表します。コミットメントには、「どのコミットメント プランで、どのリージョンのスロットを、何スロット購入したか」という情報が含まれます。コミットメント プランの種類としては、コミットメントの期間と料金体系が異なる、以下の 3 つのものがあります。

  • 1. Flex Slots：購入してから 60 秒後にキャンセルが可能となる契約

    2. 月次契約：購入してから 30 日後にキャンセルが可能となる契約

    3. 年間契約：購入してから 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 のコミットメント、予約、割り当ての設定のイメージは、以下の図のようになります。

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

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

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

備考

• 購入したスロットは、他の組織とは共有できません。

• BigQuery Reservations でのスロットの購入と割り当てを実施するための専用のプロジェクトを作成することを推奨します。このようなプロジェクトは「管理プロジェクト」と呼ばれ、コミットメントの管理を一元化することができます。

• 未使用スロットは、同じ管理プロジェクト内に作成された予約間でのみ共有されます。複数の管理プロジェクトを使用する場合、異なる管理プロジェクトの予約間でスロットが共有されることはありません。

• コミットメントは、リージョン リソースです。あるリージョンで購入したコミットメントを他のリージョンで使用することや、コミットメントをリージョン間で移動することはできません。

• 予約にプロジェクトを割り当てる際には、以下のいずれかのジョブタイプを選択します。詳細については、公式ドキュメントを参照してください。

  • QUERY: この予約は、SQL、DDL、DML、BigQuery ML クエリなどのクエリジョブに使用します。

  • PIPELINE: この予約は、読み込み、エクスポート、その他のパイプライン ジョブに使用します。

  • ML_EXTERNAL: この予約は、BigQuery の外部にあるサービスを使用する BigQuery ML クエリに使用します。

• BigQuery Reservations 予約のスロットの使用状況は、BigQuery の INFORMATION_SCHEMA または Cloud Monitoring を使用して確認することができます。詳細については、公式ドキュメントを参照してください。 

参照文献

• Reservations の概要 | BigQuery | Google Cloud

• Reservations を使ってみる | BigQuery | Google Cloud

• Reservations を使用したワークロード管理 | BigQuery | Google Cloud

• Reservations を操作する | BigQuery | Google Cloud

• Reservations の詳細と制限事項 | BigQuery | Google Cloud

• BigQuery Reservations のモニタリング | BigQuery | Google Cloud

• スロット | BigQuery | Google Cloud

• BigQuery の料金 | Google Cloud

• BigQuery ML の料金 | Google Cloud 

位置情報を活用したデータ分析のパターン

今日では、スマートフォンをはじめ、さまざまなデバイスで位置情報を取得することが可能になっています。取得した位置情報を利用して、地図や交通情報アプリのみならず、SNS、ゲーム、お店の会員アプリなど、多くのアプリケーションで、実際にサービスが提供されています。

このように、位置情報を利用したサービスは身近になってきていますが、サービスを提供する側でも、位置情報をデータ分析基盤に取り込んで、CRMや購買情報、在庫情報など、業務アプリケーションのデータとかけあわせた分析をすることで、より深い洞察を得ることができ、顧客満足度や収益の向上、コスト削減につながるアクションを取ることもできます。

位置情報を活用した分析例として、下記のようなものが挙げられます。

• 店舗の近くにいる顧客に対して、パーソナライズされたクーポン情報の通知を行うことにより、顧客の訪問を増やすことができます。

• オンラインだけでなく、オフラインも含めてカスタマー ジャーニーを理解することにより、それぞれのチャネルで相乗効果を上げることができる店舗やウェブサイト、アプリケーションの開発に役立てることができます。

• 地理的に有利な条件に合致したロケーションを分析、抽出することにより、小売店、飲食店の新規出店計画に活用することができます。

• 位置情報を使って最適なルートを計算することにより、配達計画、設備メンテナンスの計画検討に利用できます。

• 交通情報の分析による都市計画への活用、設備の設置計画などに利用できます。

位置情報を格納して分析するには、大規模なデータでも問題なく収集、格納、分析できるプラットフォームが不可欠となります。SQL で地理情報を分析することができ、ペタバイト規模のデータも分析可能なデータ ウェアハウスである BigQuery、大量のデータをストリーミングで収集することができる Pub/Sub、ストリーミング データを変換、処理するオートスケール可能な Dataflow など、位置情報を含めたさまざまなデータ分析に最適なサービスを提供しています。  

ここでは位置情報を使ったデータ分析基盤を、Google Cloud で構築する際のパターンを解説します。

解決する課題・使い所

位置情報などの新たな分析をする場合、課題になるのが分析基盤を使えるようになるための学習コストや時間です。ここでは、SQL を使った位置情報の分析が可能な BigQuery を使い、データ分析者が既存のスキルセットで学習コストを抑え、すぐにでも始めることができるアーキテクチャを紹介します。

位置情報を収集する場合、課題となるのが大量のデータへの対応です。例えば、モバイル アプリケーションで位置情報を収集する場合、フォアグラウンドで利用時に送信、バックグランドで定期的に送信、特定のジオ フェンスに入ったタイミングで送信など、さまざまな場面で送信することが予想されます。また、ユーザーの増加によってもデータ量の急激な増加が起こりえます。このような状況でも、同一のアーキテクチャで対応できることが必要です。

位置情報などの新たな分析をする場合には、既存のデータを分析することが可能なサービスに移動したり、複製したりする必要があります。規模が大きくなると、移動の時間がかかったり、コストが非常に高くなったりと無視できなくなります。ここで紹介する BigQuery は、ペタバイト規模のデータを分析する処理能力をもちながら、BigQuery 内で位置情報の分析が可能なため、これらの課題にも対応することができます。 

アーキテクチャ

位置情報データ分析基盤を構成する要素は、主に下記の 4 つになります。 

1. モバイル デバイスのバックエンド サービス
   モバイル デバイスからの位置情報の受信などは、サーバー サイドの機能を提供するレイヤーのため、本デザイン パターンの対象外となりますが、この仕組みはサーバー レスな Cloud Run や Cloud Spanner などで構築することができます。詳細は、アプリケーションおよびデータベースのモダナイゼーションの章をご覧ください。

2. データ収集
   バックエンド サービスから、データ分析基盤にデータを収集するレイヤーです。バッチ処理で連携する場合は、オブジェクト ストレージである Cloud Storage にファイルを転送します。リアルタイム分析の要件には、Publish / Subsriber モデルのメッセージング サービスである Pub/Sub を使うことで、バックエンド サービスから非同期でデータを送信できます。  

3. データ処理
   収集したデータに変換、加工、エンリッチメントなどの処理を実行し、データ ウェアハウスに連携するレイヤーです。ここでは、OSS である Apache Beam をベースにしたデータ処理サービスである Dataflow を使います。Dataflow は、ストリーミング、バッチの両方に対応しているので、コードの再利用性が高く、自動スケーリングもできるので、大量の位置情報の処理にも対応できます。

4. 格納 / 分析
   処理されたデータを、格納し分析するレイヤーです。ここでは、サーバー レスでぺタバイト規模の処理が可能なデータ ウェアハウスである BigQuery を使います。BigQuery は、ストリーミングに対応しているため、データ処理レイヤーで変換された大量のデータをリアルタイムに挿入することができます。また、SQL を使った位置情報の分析だけでなく、機械学習の機能も提供しているので、多様な分析が可能になります。

このように地理関数を使うことで、複雑な位置情報の計算も簡単に行うことができます。また、GEOGRAPHY 型は、可視化ツールを使って地図上にマッピングして可視化することもできます。下の図は、BigQuery Geo Viz の例となります。 

BigQuery では、位置情報の分析以外に機械学習もできるので、大規模なデータに対して多様な分析を行い、より深い洞察を得ることもできます。 

• 汎用性
  ここで紹介したアーキテクチャは、位置情報の分析だけでなく、幅広いストリーミング分析に活用できます。学習コストを抑えながら、新たな分析の仕組みを作ることが可能になります。 

関係するデザイン パターン

• アプリケーションおよびデータベースのモダナイゼーション

• データ プラットフォーム （分析 / AI）

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

• JapanTaxi株式会社

参考文献

• Maps API を使用した、スケーラブルな位置情報テレメトリー システムの構築

• 地理空間分析の概要

• ストリーム分析

• データポータルと BigQuery GIS を使用した地理空間の分析情報の活用

• BigQuery の一般公開境界データセットを活用した地理空間分析

• BigQuery への地理空間データの読み込みを FME でより簡単に