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 環境を設定する（集約サービス）

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

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

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

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

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

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

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

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

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

セクション 3.2 を参照してください。集計サービスの使用方法で、両方のオプションの使用方法について詳しく説明しています。どちらの方法を使用するかを決めるために、今すぐプレビューできます。Postman を選択した場合は、次の初期設定を行います。

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

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

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

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

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

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

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

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

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

1.8.2. 認可を設定する

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

[Authorize] ボタン。 [Authorize] ボタン。

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

gcloud auth print-identity-token

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

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

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 内部ページに表示されるレポートの [レポート本文] にもあります。

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

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 コード。

この ID を取得したら、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 ファイルを作成するには、レポートから取得できるバケットキーが必要です。

バケットキーは広告テクノロジーによって設計されますが、このケースではサイト Privacy Sandbox Demo がバケットキーを作成します。このサイトのプライベート アグリゲーションはデバッグモードであるため、「レポート本文」の debug_cleartext_payload を使用してバケットキーを取得できます。

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

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

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

[Decode] ボタン。 デコード ボタン。

このページは、バケットキーの 10 進数値を返します。バケットキーのサンプルを次に示します。

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

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 が完了しました。

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

次のステップ: ローカル テストツールを試したので、ご自身の環境でアグリゲーション サービスのライブ デプロイを使用して同じ演習を試すことができます。前提条件を再度確認して、「集計サービス」モードのセットアップがすべて完了していることを確認してから、ステップ 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. 集計サービスの使用状況: 集計サービス 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 内部ページに表示されるレポートの [レポート本文] にもあります。

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

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 ファイルを作成するには、レポートから取得できるバケットキーが必要です。

バケットキーは広告テクノロジーによって設計されますが、このケースではサイト Privacy Sandbox Demo がバケットキーを作成します。このサイトのプライベート アグリゲーションはデバッグモードであるため、「レポート本文」の debug_cleartext_payload を使用してバケットキーを取得できます。

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

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

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

[Decode] ボタン。 デコード ボタン。

このページは、バケットキーの 10 進数値を返します。バケットキーのサンプルを次に示します。

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

バケットキーを取得したので、これまで作業してきたフォルダに 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 のプレースホルダを、前提条件 1.6 で Terraform デプロイが正常に完了した後に出力される frontend_service_cloudfunction_url の値に置き換えます。

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

リクエストがアグリゲーション サービスによって受け入れられると、HTTP 202 レスポンスが返されます。その他のレスポンス コードについては、API 仕様のドキュメントをご覧ください。

Postman

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

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

[Body]（ボディ）タブ [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 リクエストを「送信」します。

送信ボタン 送信ボタン

レスポンス コードはページの下半分にあります。

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

リクエストがアグリゲーション サービスによって受け入れられると、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 が完了しました。

概要: 独自のクラウド環境に集計サービスをデプロイし、デバッグ レポートを収集し、出力ドメイン ファイルを作成し、これらのファイルを 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