Google Cloud Platform（GCP）で集計サービスを使用する

1. 1. 前提条件

所要時間: 1 ～ 2 時間

この Codelab を実施するモードは、ローカルテストと集約サービスの 2 つがあります。ローカルテストモードでは、ローカルマシンと Chrome ブラウザが必要です（Google Cloud リソースの作成や使用は不要です）。Aggregation Service モードでは、Google Cloud に Aggregation Service を完全にデプロイする必要があります。

この Codelab をどちらのモードでも行うには、いくつかの前提条件が必要です。各要件には、ローカルテストと集計サービスにどちらが必要かが表示されます。

1.1. 登録と構成証明を完了する（集計サービス）

プライバシー サンドボックス API を使用するには、Chrome と Android の両方で登録と構成証明が完了していることを確認してください。

1.2. 広告プライバシー API を有効にする（ローカル テストと集計サービス）

プライバシー サンドボックスを使用するため、プライバシー サンドボックスの広告 API を有効にすることをおすすめします。

ブラウザで chrome://settings/adPrivacy に移動し、すべての広告プライバシー API を有効にします。

また、サードパーティ Cookie が有効になっていることも確認してください。

chrome://settings/cookies で、サードパーティ Cookie がブロックされていないことを確認します。Chrome のバージョンによっては、この設定メニューに表示されるオプションが異なる場合がありますが、有効な設定には次のようなものがあります。

  • [サードパーティの Cookie をすべてブロックする] = 無効
  • [サードパーティの Cookie をブロックする] = 無効
  • [シークレット モードでサードパーティ Cookie をブロックする] = 有効

Cookie の有効化 Cookie の有効化

1.3. ローカルテストツールをダウンロードする（ローカルテスト）

ローカルテストを行うには、ローカルテストツールをダウンロードする必要があります。このツールは、暗号化されていないデバッグ レポートから概要レポートを生成します。

ローカル テストツールは、GitHub の Cloud Functions JAR アーカイブからダウンロードできます。LocalTestingTool_{version}.jar という名前にする必要があります。

1.4. JAVA JRE がインストールされていることを確認する（ローカル テストと集計サービス）

[ターミナル] を開き、java --version を使用して、マシンに Java または openJDK がインストールされているかどうかを確認します。

Java のバージョンを確認します。 Java のバージョンを確認します。

インストールされていない場合は、Java のサイトまたは openJDK のサイトからダウンロードしてインストールできます。

1.5. aggregatable_report_converter をダウンロードする（ローカル テストと集計サービス）

aggregatable_report_converter のコピーは、プライバシー サンドボックスのデモの GitHub リポジトリからダウンロードできます。GitHub リポジトリでは IntelliJ または Eclipse の使用について言及されていますが、どちらも必須ではありません。これらのツールを使用しない場合は、代わりに JAR ファイルをローカル環境にダウンロードします。

1.6. Cloud Platform 環境を設定する（集約サービス）

Aggregation Service では、クラウド プロバイダを使用する高信頼実行環境を使用する必要があります。この Codelab では、Aggregation Service を Google Cloud にデプロイしますが、AWS もサポートされています。

GitHub のデプロイ手順に沿って、gcloud CLI を設定し、Terraform バイナリとモジュールをダウンロードし、Aggregation Service の Google Cloud リソースを作成します。

デプロイ手順の主な手順は次のとおりです。

  1. 環境に「gcloud」CLI と Terraform を設定します。
  2. Terraform の状態を保存する Cloud Storage バケットを作成します。
  3. 依存関係をダウンロードします。
  4. adtech_setup.auto.tfvars を更新し、adtech_setup Terraform を実行します。adtech_setup.auto.tfvars ファイルの例については、付録をご覧ください。ここで作成されたデータバケットの名前をメモします。これは、コードラボで作成するファイルを保存するために使用されます。
  5. dev.auto.tfvars を更新し、デプロイ サービス アカウントの権限を借用して、dev Terraform を実行します。dev.auto.tfvars ファイルの例については、付録をご覧ください。
  6. Deployment が完了したら、Terraform の出力から frontend_service_cloudfunction_url をキャプチャします。これは、後続のステップで集計サービスにリクエストを送信する際に必要になります。

1.7. 集計サービスのオンボーディングを完了する（集計サービス）

集計サービスを使用するには、コーディネーターにオンボーディングする必要があります。集計サービスのオンボーディング フォームに、レポート サイトなどの情報を入力し、[Google Cloud] を選択してサービス アカウントのアドレスを入力します。このサービス アカウントは、前の前提条件（1.6Google Cloud 環境を設定する）。（ヒント: 指定されたデフォルト名を使用する場合、このサービス アカウントは「worker-sa@」で始まります）。

オンボーディング プロセスが完了するまで 2 週間ほどかかります。

1.8. API エンドポイント（集計サービス）を呼び出す方法を決定する

この Codelab では、Aggregation Service API エンドポイントを呼び出す方法として、cURL と Postman の 2 つの方法を紹介します。cURL は、最小限の設定で追加のソフトウェアを必要とせず、ターミナルから API エンドポイントを呼び出すのが簡単で速い方法です。ただし、cURL を使用したくない場合は、代わりに Postman を使用して API リクエストを実行し、保存して後で使用できます。

セクション 3.2 で、Aggregation Service の使用方法をご覧ください。両方のオプションの使用方法について詳しく説明しています。どちらの方法を使用するか判断するために、ここでプレビューできます。Postman を選択した場合は、次の初期設定を行います。

1.8.1. ワークスペースをセットアップ

Postman アカウントを登録します。登録すると、ワークスペースが自動的に作成されます。

Postman ワークスペース。 Postman ワークスペース。

ワークスペースが作成されていない場合は、上部のナビゲーション アイテムの [ワークスペース] に移動し、[ワークスペースを作成] を選択します。

[空のワークスペース] を選択し、[次へ] をクリックして「GCP Privacy Sandbox」という名前を付けます。[個人] を選択し、[作成] をクリックします。

事前構成済みのワークスペースの JSON 構成と グローバル環境ファイルをダウンロードします。

[インポート] ボタンを使用して、両方の JSON ファイルを [マイ ワークスペース] にインポートします。

[インポート] ボタン。 インポート ボタン。

これにより、createJob と getJob の HTTP リクエストとともに「GCP Privacy Sandbox」コレクションが作成されます。

1.8.2. 認可を設定する

[GCP Privacy Sandbox] コレクションをクリックし、[認可] タブに移動します。

承認ボタン。 承認ボタン。

「Bearer Token」メソッドを使用します。ターミナル環境でこのコマンドを実行し、出力をコピーします。

gcloud auth print-identity-token

次に、このトークン値を Postman の認可タブの [トークン] フィールドに貼り付けます。

こちらの トークン フィールド。

1.8.3. 環境を設定する

右上の [環境の概要] に移動します。

環境のクイックルック ボタン。 環境の概要ボタン。

[編集] をクリックし、[environment]、[region]、[cloud-function-id] の [現在の値] を更新します。

現在の値を設定します。 現在の値を設定します。

「request-id」は後で入力するため、今は空白のままにします。他のフィールドには、前提条件 1.6 の Terraform デプロイの正常な完了から返された frontend_service_cloudfunction_url の値を使用します。URL の形式は https://--frontend-service--uc.a.run.app です。

2. 2. ローカルテスト コードラボ

完了までの推定時間: 1 時間未満

マシン上のローカル テストツールを使用して、集計を実行し、暗号化されていないデバッグ レポートを使用して概要レポートを生成できます。始める前に、「ローカルテスト」とラベル付けされた前提条件をすべて完了していることを確認します。

Codelab の手順

ステップ 2.1. レポートをトリガーする: Private Aggregation レポートをトリガーしてレポートを収集できるようにします。

ステップ 2.2. デバッグ用 AVRO レポートを作成する: 収集した JSON レポートを AVRO 形式のレポートに変換します。このステップは、広告テクノロジーが API レポート エンドポイントからレポートを収集し、JSON レポートを Avro 形式のレポートに変換する場合と同様です。

ステップ 2.3. バケットキーを取得する: バケットキーは広告テクノロジーが設計します。この Codelab では、バケットが事前定義されているため、提供されているバケットキーを取得します。

ステップ 2.4. 出力ドメインの AVRO を作成する: バケットキーを取得したら、出力ドメインの AVRO ファイルを作成します。

ステップ 2.5. 概要レポートを作成する: ローカルテストツールを使用して、ローカル環境で概要レポートを作成できます。

ステップ 2.6. 概要レポートを確認する: ローカル テストツールによって作成された概要レポートを確認します。

2.1. トリガー レポート

限定公開集計レポートをトリガーするには、プライバシー サンドボックスのデモサイト（https://privacy-sandbox-demos-news.dev/?env=gcp）または独自のサイト（https://adtechexample.com など）を使用できます。独自のサイトを使用している場合、登録と構成証明、集約サービスのオンボーディングを完了していない場合は、Chrome フラグと CLI スイッチを使用する必要があります。

このデモでは、プライバシー サンドボックスのデモサイトを使用します。リンクをクリックしてサイトにアクセスし、chrome://private-aggregation-internals でレポートを表示します。

Chrome 内部ページ。 Chrome 内部ページ。

{reporting-origin}/.well-known/private-aggregation/debug/report-shared-storage エンドポイントに送信されたレポートは、Chrome Internals ページに表示されるレポートの [レポート本文] にも表示されます。

ここに多くのレポートが表示されますが、この Codelab では、Google Cloud 固有でデバッグ エンドポイントによって生成される集計可能なレポートを使用します。[Report URL] には「/debug/」が含まれ、[Report Body] の aggregation_coordinator_origin field には URL「https://publickeyservice.msmt.gcp.privacysandboxservices.com」が含まれます。

Google Cloud デバッグ レポート。 Google Cloud デバッグ レポート。

2.2. デバッグ集計レポートを作成する

chrome://private-aggregation-internals の [Report Body] にあるレポートをコピーし、privacy-sandbox-demos/tools/aggregatable_report_converter/out/artifacts/aggregatable_report_converter_jar フォルダ（前提条件 1.5 でダウンロードしたリポジトリ内）に JSON ファイルを作成します。

この例では、Linux を使用しているため vim を使用しています。ただし、任意のテキスト エディタを使用できます。

vim report.json

レポートを report.json に貼り付けて、ファイルを保存します。

レポートの JSON コード。 レポートの JSON コード。

次に、aggregatable_report_converter.jar を使用して、デバッグ用集計レポートを作成します。これにより、現在のディレクトリに report.avro という集計可能なレポートが作成されます。

java -jar aggregatable_report_converter.jar \
  --request_type convertToAvro \
  --input_file report.json \
  --debug

2.3. レポートからバケットキーを取得する

output_domain.avro ファイルを作成するには、レポートから取得できるバケットキーが必要です。

バケットキーは広告テクノロジーによって設計されますが、この場合はサイト プライバシー サンドボックスのデモがバケットキーを作成します。このサイトの非公開集計はデバッグモードであるため、[レポート本文] の debug_cleartext_payload を使用してバケットキーを取得できます。

レポート本文から debug_cleartext_payload をコピーします。

クリアテキスト ペイロードをデバッグします。 クリアテキスト ペイロードをデバッグします。

goo.gle/ags-payload-decoder を開き、[INPUT] ボックスに debug_cleartext_payload を貼り付けて [Decode] をクリックします。

デコード ボタン。 デコード ボタン。

このページには、バケットキーの小数値が表示されます。バケットキーの例を次に示します。

バケットキーの例。 バケットキーのサンプル。

2.4. 出力ドメイン AVRO を作成する

バケットキーが作成されたので、作業していたフォルダに output_domain.avro を作成します。バケットキーを取得したバケットキーに置き換えたことを確認します。

java -jar aggregatable_report_converter.jar \
  --request_type createDomainAvro \
  --bucket_key <bucket key>

このスクリプトにより、現在のフォルダに output_domain.avro ファイルが作成されます。

2.5. ローカル テストツールを使用して概要レポートを作成する

前提条件 1.3 でダウンロードした LocalTestingTool_{version}.jar を使用して、次のコマンドを使用して概要レポートを作成します。{version} は、ダウンロードしたバージョンに置き換えます。LocalTestingTool_{version}.jar を現在のディレクトリに移動するか、相対パスを追加して現在の場所を参照してください。

java -jar LocalTestingTool_{version}.jar \
  --input_data_avro_file report.avro \
  --domain_avro_file output_domain.avro \
  --output_directory .

コマンドを実行すると、次のようなメッセージが表示されます。これが完了すると、レポート output.avro が作成されます。

AVRO を出力する 出力 AVRO

2.6. 概要レポートを確認する

作成されるサマリー レポートは AVRO 形式です。これを読み取るには、AVRO から JSON 形式に変換する必要があります。理想的には、広告テクノロジーで AVRO レポートを JSON に変換するコードを記述する必要があります。

aggregatable_report_converter.jar を使用して、AVRO レポートを JSON に戻します。

java -jar aggregatable_report_converter.jar \
  --request_type convertToJson \
  --input_file output.avro

これにより、次のようなレポートが返されます。同じディレクトリに作成されたレポート output.json も作成されます。

出力 JSON 出力 JSON

Codelab が完了しました

概要: 集計サービスの集計動作をシミュレートするローカル テストツールを使用して、デバッグ レポートを収集し、出力ドメイン ファイルを作成し、概要レポートを生成しました。

次のステップ: ローカル テストツールを試したところで、次は、ご自身の環境で Aggregation Service を本番環境にデプロイして、同じ演習を行ってみましょう。前提条件を再確認して、「Aggregation Service」モード用にすべてが設定されていることを確認してから、ステップ 3 に進みます。

3. 3. 集計サービス Codelab

所要時間: 1 時間

始める前に、「Aggregation Service」というラベルが付いた前提条件をすべて完了していることを確認します。

Codelab の手順

ステップ 3.1. 集計サービス入力の作成: 集計サービス用にバッチ処理される集計サービス レポートを作成します。

  • ステップ 3.1.1. トリガー レポート
  • ステップ 3.1.2. 集計可能レポートを収集する
  • ステップ 3.1.3. レポートを AVRO に変換する
  • ステップ 3.1.4. output_domain AVRO を作成する
  • ステップ 3.1.5. レポートを Cloud Storage バケットに移動する

ステップ 3.2. 集計サービスの使用: Aggregation Service API を使用して概要レポートを作成し、概要レポートを確認します。

  • ステップ 3.2.1. createJob エンドポイントを使用してバッチ化する
  • ステップ 3.2.2. getJob エンドポイントを使用してバッチ ステータスを取得する
  • ステップ 3.2.3. 概要レポートを確認する

3.1. 集計サービスの入力の作成

集計サービスへのバッチ処理用に AVRO レポートを作成します。これらの手順のシェルコマンドは、Google Cloud の Cloud Shell 内（前提条件の依存関係が Cloud Shell 環境にクローンされている場合）またはローカル実行環境で実行できます。

3.1.1. トリガー レポート

リンクをクリックしてサイトにアクセスし、chrome://private-aggregation-internals でレポートを表示します。

Chrome 内部ページ Chrome 内部ページ

{reporting-origin}/.well-known/private-aggregation/debug/report-shared-storage エンドポイントに送信されたレポートは、Chrome Internals ページに表示されるレポートの [レポート本文] にも表示されます。

ここに多くのレポートが表示されますが、この Codelab では、Google Cloud 固有でデバッグ エンドポイントによって生成される集計可能なレポートを使用します。[Report URL] には「/debug/」が含まれ、[Report Body] の aggregation_coordinator_origin field には URL「https://publickeyservice.msmt.gcp.privacysandboxservices.com」が含まれます。

Google Cloud デバッグ レポート。 Google Cloud デバッグ レポート。

3.1.2. 集計可能レポートを収集する

対応する API の .well-known エンドポイントから集計可能レポートを収集します。

  • Private Aggregation: {reporting-origin}/.well-known/private-aggregation/report-shared-storage
  • アトリビューション レポート - 概要レポート: {reporting-origin}/.well-known/attribution-reporting/report-aggregate-attribution

この Codelab では、レポートの収集を手動で行います。本番環境では、広告テクノロジーがレポートをプログラマティックに収集して変換することが求められます。

chrome://private-aggregation-internals の [レポート本文] にある JSON レポートをコピーしましょう。

この例では、Linux を使用しているため vim を使用します。ただし、任意のテキスト エディタを使用できます。

vim report.json

レポートを report.json に貼り付けて、ファイルを保存します。

レポート JSON レポート JSON

3.1.3. レポートを AVRO に変換する

.well-known エンドポイントから受信したレポートは JSON 形式であるため、AVRO レポート形式に変換する必要があります。JSON レポートを取得したら、report.json が保存されている場所に移動し、aggregatable_report_converter.jar を使用して、デバッグ用に集約可能なレポートを作成します。これにより、現在のディレクトリに report.avro という集計可能なレポートが作成されます。

java -jar aggregatable_report_converter.jar \
  --request_type convertToAvro \
  --input_file report.json

3.1.4. output_domain AVRO を作成する

output_domain.avro ファイルを作成するには、レポートから取得できるバケットキーが必要です。

バケットキーは広告テクノロジーによって設計されますが、この場合はサイト プライバシー サンドボックスのデモがバケットキーを作成します。このサイトの非公開集計はデバッグモードであるため、[レポート本文] の debug_cleartext_payload を使用してバケットキーを取得できます。

レポート本文から debug_cleartext_payload をコピーします。

クリアテキスト ペイロードをデバッグします。 クリアテキスト ペイロードをデバッグします。

goo.gle/ags-payload-decoder を開き、[INPUT] ボックスに debug_cleartext_payload を貼り付けて [Decode] をクリックします。

デコード ボタン。 デコード ボタン。

このページには、バケットキーの小数値が表示されます。バケットキーの例を次に示します。

バケットキーの例。 バケットキーのサンプル。

バケットキーが作成されたので、作業していたフォルダに output_domain.avro を作成します。バケットキーを取得したバケットキーに置き換えたことを確認します。

java -jar aggregatable_report_converter.jar \
  --request_type createDomainAvro \
  --bucket_key <bucket key>

このスクリプトにより、現在のフォルダに output_domain.avro ファイルが作成されます。

3.1.5. レポートを Cloud Storage バケットに移動する

AVRO レポートと出力ドメインが作成されたら、レポートと出力ドメインを Cloud Storage のバケット（前提条件 1.6 でメモしたバケット）に移動します。

ローカル環境に gcloud CLI が設定されている場合は、次のコマンドを使用してファイルを対応するフォルダにコピーします。

gcloud storage cp report.avro gs://<bucket_name>/reports/

gcloud storage cp output_domain.avro gs://<bucket_name>/output_domain/

それ以外の場合は、ファイルをバケットに手動でアップロードします。「reports」というフォルダを作成し、そこに report.avro ファイルをアップロードします。「output_domains」というフォルダを作成し、そこに output_domain.avro ファイルをアップロードします。

3.2. 集計サービスの使用状況

前提条件 1.8 で、Aggregation Service エンドポイントへの API リクエストに curl または Postman を選択したことを思い出してください。両方のオプションの手順は次のとおりです。

ジョブがエラーで失敗した場合は、GitHub のトラブルシューティング ドキュメントで、対処方法の詳細を確認してください。

3.2.1. createJob エンドポイントを使用してバッチ化する

次の curl または Postman の手順のいずれかを使用して、ジョブを作成します。

curl

「ターミナル」でリクエスト本文ファイル（body.json）を作成し、次の JSON オブジェクトを貼り付けます。プレースホルダの値は必ず更新してください。各フィールドの詳細については、こちらの API ドキュメントをご覧ください。

{
    "job_request_id": "<job_request_id>",
    "input_data_blob_prefix": "<report_folder>/<report_name>.avro",
    "input_data_blob_prefixes": [ // Mutually exclusive to input_data_blob_prefix as of v2.11.0
      "<report_folder>/<report_name-1>/",
      "<report_folder>/<report_name-2>/",
      "<report_folder>/<report_name>.avro"
    ],
    "input_data_bucket_name": "<bucket_name>",
    "output_data_blob_prefix": "<output_folder>/<summary_report_prefix>",
    "output_data_bucket_name": "<bucket_name>",
    "job_parameters": {
      "output_domain_blob_prefix": "<output_domain_folder>/<output_domain>.avro",
      "output_domain_bucket_name": "<bucket_name>",
      "attribution_report_to": "<reporting origin of report>",
      "reporting_site": "<domain of reporting origin(s) of report>", // Mutually exclusive to attribution_report_to as of v2.7.0
      "report_error_threshold_percentage": "10",
      "debug_run": "true"
    }
}

次のリクエストを実行します。curl リクエストの URL のプレースホルダを、frontend_service_cloudfunction_url の値に置き換えます。この値は、前提条件 1.6 の Terraform デプロイが正常に完了した後に出力されます。

curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
  -d @body.json \
  https://<environment>-<region>-frontend-service-<cloud-function-id>-uc.a.run.app/v1alpha/createJob

Aggregation Service がリクエストを承認すると、HTTP 202 レスポンスが返されます。その他のレスポンス コードについては、API の仕様をご覧ください。

Postman

createJob エンドポイントの場合、集計可能なレポート、出力ドメイン、概要レポートの場所とファイル名を集計サービスに提供するために、リクエスト本文が必要です。

createJob リクエストの [Body] タブに移動します。

[本文] タブ 本文タブ

指定された JSON 内のプレースホルダを置き換えます。これらのフィールドとその内容の詳細については、API ドキュメントをご覧ください。

{
    "job_request_id": "<job_request_id>",
    "input_data_blob_prefix": "<report_folder>/",
    "input_data_blob_prefixes": [ // Mutually exclusive to input_data_blob_prefix as of v2.11.0
      "<report_folder>/<report_name-1>/",
      "<report_folder>/<report_name-2>/",
      "<report_folder>/<report_name>.avro"
    ],
    "input_data_bucket_name": "<bucket_name>",
    "output_data_blob_prefix": "<output_folder>/<summary_report_prefix>",
    "output_data_bucket_name": "<bucket_name>",
    "job_parameters": {
      "output_domain_blob_prefix": "<output_domain_folder>/<output_domain>.avro",
      "output_domain_bucket_name": "<bucket_name>",
      "attribution_report_to": "<reporting origin of report>",
      "reporting_site": "<domain of reporting origin(s) of report>", // Mutually exclusive to attribution_report_to as of v2.7.0
      "report_error_threshold_percentage": "10",
      "debug_run": "true"
    }
}

createJob API リクエストを「送信」します。

送信ボタン 送信ボタン

レスポンス コードはページの下半分に表示されます。

レスポンス コード レスポンス コード

Aggregation Service がリクエストを承認すると、HTTP 202 レスポンスが返されます。その他のレスポンス コードについては、API の仕様をご覧ください。

3.2.2. getJob エンドポイントを使用してバッチ ステータスを取得する

次の curl または Postman の手順のいずれかを使用してジョブを取得します。

curl

ターミナルで次のリクエストを実行します。URL のプレースホルダを frontend_service_cloudfunction_url の値に置き換えます。これは、createJob リクエストに使用した URL と同じです。「job_request_id」には、createJob エンドポイントで作成したジョブの値を使用します。

curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
  https://<environment>-<region>-frontend-service-<cloud-function-id>-uc.a.run.app/v1alpha/getJob?job_request_id=<job_request_id>

結果として、HTTP ステータス 200 でジョブリクエストのステータスが返されます。リクエストの「Body」には、job_status、return_message、error_messages（ジョブでエラーが発生した場合）などの必要な情報が含まれます。

Postman

ジョブリクエストのステータスを確認するには、getJob エンドポイントを使用します。getJob リクエストの [Params] セクションで、job_request_id の値を createJob リクエストで送信された job_request_id に更新します。

ジョブ リクエスト ID ジョブ リクエスト ID

getJob リクエストを「送信」します。

送信ボタン 送信ボタン

結果として、HTTP ステータス 200 でジョブリクエストのステータスが返されます。リクエストの「Body」には、job_status、return_message、error_messages などの必要な情報が含まれます（ジョブでエラーが発生した場合）。

レスポンス JSON レスポンス JSON

3.2.3. 概要レポートを確認する

出力 Cloud Storage バケットに概要レポートが届いたら、ローカル環境にダウンロードできます。概要レポートは AVRO 形式で、JSON に変換できます。aggregatable_report_converter.jar を使用して、次のコマンドでレポートを読み取ることができます。

java -jar aggregatable_report_converter.jar \
  --request_type convertToJson \
  --input_file <summary_report_avro>

これにより、各バケットキーの集計値の JSON が返されます。次に例を示します。

概要レポート。 概要レポート。

createJob リクエストに debug_run が true として含まれている場合は、output_data_blob_prefix にあるデバッグ フォルダに概要レポートを受け取ることができます。レポートは AVRO 形式で、上記のコマンドを使用して JSON に変換できます。

レポートには、バケットキー、ノイズなしの指標、ノイズなしの指標に追加されて概要レポートを形成するノイズが含まれています。レポートは次のようになります。

ノイズ入りレポート ノイズのある報告

アノテーションには、「in_reports」または「in_domain」（またはその両方）も含まれます。これは、次のように解釈されます。

  • in_reports - 集計可能なレポート内でバケットキーを使用できます。
  • in_domain - バケットキーは output_domain AVRO ファイル内で使用できます。

Codelab が完了しました

概要: Aggregation Service を独自のクラウド環境にデプロイし、デバッグ レポートを収集し、出力ドメイン ファイルを作成して、これらのファイルを Cloud Storage バケットに保存し、ジョブを正常に実行しました。

次のステップ: 環境で Aggregation Service を引き続き使用するか、手順 4 のクリーンアップ手順に沿って作成したクラウド リソースを削除します。

4. 4. クリーンアップ

Terraform を使用して Aggregation Service 用に作成されたリソースを削除するには、adtech_setup フォルダと dev フォルダ（または他の環境）で destroy コマンドを使用します。

$ cd <repository_root>/terraform/gcp/environments/adtech_setup
$ terraform destroy
$ cd <repository_root>/terraform/gcp/environments/dev
$ terraform destroy

集計可能なレポートと概要レポートを保持する Cloud Storage バケットを削除するには:

$ gcloud storage buckets delete gs://my-bucket

前提条件 1.2 の Chrome Cookie 設定を以前の状態に戻すこともできます。

5. 5. 付録

adtech_setup.auto.tfvars ファイルの例

/**
 * Copyright 2023 Google LLC
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

project = "my-project-id"

# Required to generate identity token for access of Adtech Services API endpoints
service_account_token_creator_list = ["user:me@email.com"]

# Uncomment the below line if you like Terraform to create an Artifact registry repository
# for self-build container artifacts. "artifact_repo_location" defaults to "us".
artifact_repo_name     = "my-ags-artifacts"

# Note: Either one of [1] or [2] must be uncommented.

# [1] Uncomment below lines if you like Terraform grant needed permissions to
# pre-existing service accounts
# deploy_service_account_email = "<YourDeployServiceAccountName>@<ProjectID>.iam.gserviceaccount.com"
# worker_service_account_email = "<YourWorkerServiceAccountName>@<ProjectID>.iam.gserviceaccount.com"

# [2] Uncomment below lines if you like Terraform to create service accounts
# and needed permissions granted e.g "deploy-sa" or "worker-sa"
deploy_service_account_name = "deploy-sa"
worker_service_account_name = "worker-sa"
# Uncomment the below line if you want Terraform to create the
# below bucket. "data_bucket_location" defaults to "us".
data_bucket_name     = "my-ags-data"

# Uncomment the below lines if you want to specify service account customer role names
# deploy_sa_role_name = "<YourDeploySACustomRole>"
# worker_sa_role_name = "<YourWorkerSACustomRole>"

dev.auto.tfvars ファイルの例

/**
 * Copyright 2022 Google LLC
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

# Example values required by job_service.tf
#
# These values should be modified for each of your environments.
region      = "us-central1"
region_zone = "us-central1-c"

project_id  = "my-project-id"
environment = "operator-demo-env"

# Co-locate your Cloud Spanner instance configuration with the region above.
# https://cloud.google.com/spanner/docs/instance-configurations#regional-configurations
spanner_instance_config = "regional-us-central1"

# Adjust this based on the job load you expect for your deployment.
# Monitor the spanner instance utilization to decide on scale out / scale in.
# https://console.cloud.google.com/spanner/instances
spanner_processing_units = 100

# Uncomment the line below at your own risk to disable Spanner database protection.
# This needs to be set to false and applied before destroying all resources is possible.
spanner_database_deletion_protection = false

instance_type = "n2d-standard-8" # 8 cores, 32GiB

# Container image location that packages the job service application
# If not set otherwise, uncomment and edit the line below:
#worker_image = "<location>/<project>/<repository>/<image>:<tag or digest>"

# Service account created and onboarded for worker
user_provided_worker_sa_email = "worker-sa@my-project-id.iam.gserviceaccount.com"

min_worker_instances = 1
max_worker_instances = 20