サーバサイド Google Tag Manager 環境を Cloud Run で構築する

Published in

google-cloud-jp

33 min readDec 20, 2021

Google Analytics に代表される Web やアプリのユーザ行動測定の実装方式として、「サーバサイド Google Tag Manager」（以下「sGTM」）が注目を集めています。従来の Google Tag Manager では、クライアントサイドのブラウザ上で直接測定タグの処理を行っていたのに対し、sGTM では、Web サイト運用者が用意する測定用サーバ上で測定タグの処理を行います。

測定用サーバは、公式に提供されているセットアップスクリプトを使って App Engine Flexible 上にデプロイする方法が代表的ですが、実は公開されている Docker イメージを使い、それ以外のプラットフォームで実行することもできます。本記事では Google Cloud のサーバレスなアプリ実行基盤である Cloud Run で構築 する方法をご紹介します。

この記事は Google Cloud Japan Customer Engineer Advent Calendar 2021 の 19 日目の記事です。昨日は Terry Kurumatani の「Google ドライブをドメイン移行するための引っ越し方法」でした。ドメイン移行のような稀な作業はトラブルになりがちなので、覚えておきたいですね。

サーバサイド Google Tag Manager (sGTM) とは

従来の（クライアントサイド）Google Tag Manager では、ユーザの Web ブラウザ上の JavaScript で測定タグの処理を行い、直接各測定サービスへのデータ送信を行っていました。

クライアントサイド Google Tag Manager の仕組み — クライアントサイド GTM のアーキテクチャ

一方 sGTM では、測定タグの処理はサーバサイドで実行されます。ユーザの Web ブラウザからは、イベントの発火を測定用サーバ（サーバサイドコンテナ）にある Client と呼ばれるコンポーネントに渡し、最終的な測定サービスへのデータ送信もサーバコンテナから行われます。

詳細な仕組みについては、公式ドキュメントに記載がありますので、ご興味のある方はそちらをご覧ください。

sGTM のメリット

sGTM を使って測定タグの処理をサーバサイドで行うと、以下のようなメリットが得られます。

パフォーマンスの向上
クライアントサイドのブラウザで行っていた処理の大部分をサーバコンテナに移譲することにより、ブラウザ上での処理は軽量となり、パフォーマンスの向上が期待できます。

セキュリティの向上
収集データはサーバコンテナで一元的に収集・送信されるので、訪問者データの保護が強化されます。

プライバシー保護への対応
セキュリティの向上とも少し重複しますが、近年のプライバシー保護意識の高まりによって、ユーザ行動の測定は適正な方法で（特に Cookie を不適切に濫用することなく）行うことがますます強く求められてきています。Chrome / Safari / Firefox などの主要ブラウザでは、すでに 3rd Party Cookie の廃止が決まっていますし、1st Party Cookie についても、不適切な利用を制限するためにアップデートを行うブラウザも出てきています。

これに対し、sGTM を用いると、自社サイト上でのユーザイベントを自社で管理するサーバに送信して測定する、そして測定用の Cookie も自社で管理するサーバから発行する、という 1st Party に閉じた測定環境を実現することができます。

Cloud Run を使うメリット

冒頭で述べたように、sGTM は App Engine Flexible を使ってセットアップする方法が公式に提供されていますが、そうではなく Cloud Run 上で構築することで、いくつかのメリットが得られます。

コスト面での優位性
Cloud Run が持つ（App Engine Flexibleにはない）コスト面での特長として、100 ミリ秒単位での完全な従量課金、0 インスタンスまでスケールインできる、といった点が挙げられます。実際の金額はユースケースに応じて見積もる必要がありますが、特に小規模な利用では Cloud Run が有利な可能性があります。

マルチリージョン構成を実現できる
本記事の後半で触れますが、Cloud Run に HTTP(S) Load Balancing を組み合わせることでマルチリージョン構成を実現できます。マルチリージョン構成により、可用性を高めたり、レイテンシを削減できます。

Cloud Run の優れた開発者体験
これは個人的かつフワっとした感想になってしまいますが、Cloud Run は開発者観点での細かい不便さなどができる限り排除されており、一度その開発者体験の良さを体感すると「もうできるならもう全部 Cloud Run で動かしたい……」という気持ちになってきます（個人の感想です）。加えて、現在もすごいスピードで機能がアップデートされていっており、使っているだけでその進化の恩恵に預かることができるのもうれしいところです。

Cloud Run を使った sGTM 環境の構築

ここからは、実際に Cloud Run を使って sGTM 環境を構築する方法をご紹介していきます。

構築は以下の流れで進めます。

※ ここからの手順の中で「コンテナ」という単語がよく出てきますが、「Docker コンテナ」などと明記されていない限り、Google Tag Manager のタグを管理する単位である「コンテナ」という概念を指しています。
サーバサイドで実行するアプリケーションも Docker コンテナイメージとして提供されていて紛らわしいのでご注意ください。

1. サーバサイド Google Tag Manager の設定

sGTM を利用するためには、まずは Google Tag Manager の管理画面で設定を行います。まずは、本記事のメインテーマであるサーバサイド Google Tag Manager のコンテナの設定です。

事前準備

今回は測定サービスとして Google Analytics 4（以下「GA4」）を利用します。事前準備として、GA4 の設定を先に済ませた上で、管理メニューの Data Streams で確認できる Measurement ID （G-XXXXXXXXXX）を取得しておきます。

コンテナの作成

ブラウザで Google Tag Manager の管理画面を開き、Target platform で Server を選択してコンテナを新規作成します。

コンテナを作成すると、サーバのセットアップを促すモーダルダイアログが表示されるので、Manually provision tagging server を選択します。表示された Container Config の値を、あとで使うために手元にコピーしておきます。

また、管理画面上に表示された Container ID（GTM-XXXXXXX）の値もコピーしておきます。

GTM コンテナに GA4 タグを追加

作成したコンテナに GA4 タグを追加します。

左ペインメニューから Tags を選択してから New を選択
Tag Configuration で Google Analytics: GA4 を選択
Measurement ID に、先に設定を済ませた GA4 の Measurement ID を入力
Triggering には、All Pages を設定して保存

gtm.js をホストするための設定追加

サーバコンテナから、Google Tag Manager のスクリプト本体となる gtm.js を、サーバコンテナから配信できるようにするために、Web Container の設定を行います。

※ 設定にはクライアントサイドコンテナの Container ID が必要なので、順番としてはクライアントサイドコンテナを作成してから実施します

左ペインメニューから Clients を選択してから New を選択
Client Configuration で Google Tag Manager: Web Container を選択
Add Container ID で、クライアントサイドコンテナの Container ID（GTM-XXXXXXX）を入力

（オプション）GA4 Client の Cookie 設定

すでに GA4 を利用している Web サイトに sGTM を導入する場合、GA4 Client の設定を開き、More Settings から Migrate from JavaScript Managed Client ID を有効にします。これにより、従来のブラウザ上で発行された Cookie から sGTM のサーバ発行の Cookie へ移行できます。

サーバサイドコンテナの公開

管理画面右上の Publish ボタンを押してサーバサイドコンテナを公開します。（詳細な手順はサポートページ参照）

以上でサーバサイドコンテナの設定は完了です。

2. クライアントサイド Google Tag Manager の設定

サーバサイドコンテナにイベントを送信する主な方法としては、

gtag.js を使う
クライアントサイド用の別の Google Tag Manager コンテナを使う

の 2 つがあります。

今回は後者の Google Tag Manager を利用してみます。すべての手順を書くと長くなってしまうので、簡単にポイントだけ触れていきます。

Target platform で Web を選択してコンテナを新規作成
Tags から Google Analytics: GA4 Configuration を追加
Send to server container を有効にし、Server Container URL にサーバコンテナ用の URL を入力
コンテナを Publish

なお、以前は transport_url という値を設定する必要がありましたが、今は必要ありません。

3. Cloud Run で Preview サーバのデプロイ

Google Tag Manager の設定が終わったら、Cloud Run をデプロイしていきます。クライアントサイドからのリクエストを受け付けて測定タグの処理を行う「サーバサイドタグ設定クラスタ」（以下「SST クラスタ」）と、Google Tag Manager の Preview モードで利用する「Preview サーバ」の 2 つをデプロイします。

この 2 つは役割が異なるものの、Docker イメージとしては共通となっており、実行環境に設定する環境変数によって、いずれかのモードで動作するようになっています。

Docker イメージは、公式ドキュメントに記載されているように、以下のタグ名で Google Cloud 上で公開されています。

gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

なお、Docker イメージのオプションなどは、エントリポイントとなる server_bin.jsに --help オプションを付けて実行することで確認できます。

$ docker run gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable /bin/bash -c "node server_bin.js --help"...（中略）...Usage: node server_bin.js [options]
For options that can be set via either command-line flag or an environment variable, the command-line flag value takes precedence.Options:
  --container_config: Base64-encoded container parameters in the URL query string format. This flag is required to be set. May also be set by CONTAINER_CONFIG environment variable. (default: undefined)
  --[no]run_as_preview_server: Enable when the server should run as a preview server. See the documentation for additional details. May also be set by RUN_AS_PREVIEW_SERVER environment variable. (default: false)
  --preview_server_url: URL for the preview server. This should not be set with the run_as_preview_server setting set to true. May also be set by PREVIEW_SERVER_URL environment variable. (default: undefined)
  --container_refresh_seconds: Interval between container refreshes. May also be set by CONTAINER_REFRESH_SECONDS environment variable. (default: 60) (an integer)
  --host: Host on which to bind. Set the value to empty string to listen on the unspecified IPv6 address (::) if available, or the unspecified IPv4 address (0.0.0.0) otherwise. May also be set by HOST environment variable. (default: "")
  --port: Port to listen on. May also be set by PORT environment variable. (default: 8080) (an integer)
  --debug_message_expiration_seconds: Number of seconds after which an unread debug message is deleted. This flag is applicable only when running as the debug server. May also be set by DEBUG_MESSAGE_EXPIRATION_SECONDS environment variable. (default: 600) (an integer)
  --policy_script_url: HTTPS URL from which to load the policy script. May also be set by POLICY_SCRIPT_URL environment variable. (default: undefined)
  --policy_script_refresh_seconds: Interval between policy script refreshes. May also be set by POLICY_SCRIPT_REFRESH_SECONDS environment variable. (default: 60) (an integer)

まずは、Preview サーバをデプロイします。Preview サーバは、Google Tag Manager 管理画面から動作確認やデバッグを行う際に利用します。

デプロイの際のポイントは、以下のような点です。

Preview サーバは 1 台のみ必要なので、最大インスタンス数（--max-instances）を 1 に指定します
動作確認やデバッグにのみ使うサーバなので、インスタンスのスペックは最低限に下げて問題ありません。最小インスタンス数（--min-instances）もデフォルトの 0 を使用します
環境変数で RUN_AS_PREVIEW_SERVER=true を設定することで、Preview サーバとして動作します
環境変数の CONTIANER_CONFIG に、サーバサイドコンテナを設定したときに表示された文字列を設定することで、先ほど設定したサーバサイドコンテナとして動作します

下記コマンドを使って、デプロイを行います。（Container Config の値は差し替えてください）

$ gcloud run deploy preview-server \
--image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
--port=8080 \
--allow-unauthenticated \
--region=asia-northeast1 \
--max-instances=1 \
--cpu=1 \
--memory=256Mi \
--set-env-vars="RUN_AS_PREVIEW_SERVER=true,CONTAINER_CONFIG=<サーバサイドコンテナの Container Config>"Deploying container to Cloud Run service [preview-server] in project [gcp-study-327707] region [asia-northeast1]
OK Deploying new service... Done.              
  OK Creating Revision... Revision deployment finished. Waiting for health check to begin.
  OK Routing traffic...
  OK Setting IAM Policy...
Done.
Service [preview-server] revision [preview-server-00001-kig] has been deployed and is serving 100 percent of traffic.
Service URL: https://preview-server-eq7dhvrkgq-an.a.run.app

デプロイが完了すると、作成されたサービスの URL（https://<{ランダムな名前>.a.app.run/）を確認できます。この URL にヘルスチェック用のパス（/healthy）を追加した URL（https://<{ランダムな名前>.a.app.run/healty）にブラウザからアクセスしてみます。Status Code 200 の ok というレスポンスが返ってこれば正常に動作しています。

4. Cloud Run でサーバサイドタグ設定クラスタ（SST クラスタ）のデプロイ

続いて、SST クラスタをデプロイします。SST クラスタでは、クライアントサイドからのリクエストを受け付けて測定タグの処理を行います。

SST クラスタは、測定を行う Web サイトのアクセスの応じて負荷が高まることになるので、オートスケールするよう最大インスタンス数（--max-instances）を十分に大きな数にします
最小インスタンス数（--min-instances）は、コスト最重視の場合は 0 に、Cold Start が発生してレイテンシが大きくなることを防ぎたい場合は 1 以上に設定します
環境変数で PREVIEW_SERVER_URL に先ほどデプロイした Preview サーバの URL を設定し、SST クラスタから Preview サーバにアクセスできるようにします
環境変数の CONTIANER_CONFIG に、サーバサイドコンテナを設定したときに表示された文字列を設定することで、サーバサイドコンテナとの紐付けを行います

$ gcloud run deploy sst-cluster \
--image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
--port=8080 \
--allow-unauthenticated \
--region=asia-northeast1 \
--min-instances=1 --max-instances=100 \
--set-env-vars="PREVIEW_SERVER_URL=<Preview サーバの URL>,CONTAINER_CONFIG=<サーバサイドコンテナの Container Config>"

※ なお今回インスタンスのスペックは App Engine のスクリプトを参考に、 vCPU 数を 1, RAM を 512MB に、また同時リクエスト数（concurrency）はデフォルトの 80 にしていますが、実際に本番環境で利用する際は適宜チューニングすることをおすすめします。

デプロイが完了したら、Preview サーバと同様に、ブラウザからヘルスチェック用のパス（https://<ランダムな名前>.a.app.run/healthy）にアクセスして、ok が返ってくるか確認します。

SST クラスタへのカスタムドメイン適用

次に、サービスにカスタムドメインを適用します。Cloud Run にカスタムドメインを適用するには、(1) Cloud Run 自体のカスタムドメイン機能を使うか、(2) HTTP(S) Load Balancing の機能を使うかの 2 つの選択肢があります。ここでは、よりお手軽に利用できる (1) Cloud Run 自体のカスタムドメイン機能を使います。

なお、この (1) は現時点ではプレビュー機能ですので、本番用サーバでは後述するマルチリージョン構成のように、(2) HTTP(S) Load Balancing の機能を使うのがおすすめです。

Cloud Run 管理画面の カスタムドメインを管理 メニューから、マッピングを追加 を選択

マッピングするサービスは sst-cluster、確認済みドメインは利用したいドメイン（例: example.com）、サブドメインは SST クラスタに割り当てるサブドメイン（例: analytics.example.com）を指定します
※ 確認済みドメインを追加するためには、所有権を証明するために、指定された TXT レコードをドメインの権威 DNS サーバに追加する必要があります

表示された DNS レコードを、ドメインの権威ネームサーバに追加します
証明書がデプロイされるまで 15 分程度待ちます

以上で sGTM 自体の環境構築は完了です。

5. 動作確認用 Web サイトのデプロイ

sGTM の動作を確認するため、適当なテスト用の静的 Web サイトをデプロイします。

今回は、以下のような HTML を返す Web アプリを作成して Cloud Run にデプロイし、SST クラスタと同様にカスタムドメインをマッピングします（詳細な手順は割愛します）。

一点ポイントとしては、HTML 内に挿入する GTM のコードでは、gtm.js の取得先をデフォルトの www.googletagmanager.com から SST クラスタに割り当てたドメイン（太字部分）に変更しておきます。

<!DOCTYPE html>
<html>
<head>
<title>Home page</title>
<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://analytics.example.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
<!-- End Google Tag Manager -->
</head><body>
<h1>Index</h1>
<a href="/sub1.html">sub 1</a><br />
<a href="/sub2.html">sub 2</a><!-- Google Tag Manager (noscript) -->
<noscript><iframe src="https://analytics.example.com/ns.html?id=GTM-XXXXXXX"
  height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
<!-- End Google Tag Manager (noscript) -->
</body>
</html>

※ 上記コードをそのまま使う場合は GTM-XXXXXXX はクライアントサイドコンテナの Container ID に置き換えてください

6. Google Tag Manager の Preview 機能による動作確認

環境が準備できたので、Google Tag Manager の管理画面から Preview 機能を使って動作確認をしてみます。

サーバサイドコンテナの設定を開き、Preview ボタンを押してサーバサイドコンテナの Preview 画面を開く
クライアントサイドコンテナの設定を開き、Preview ボタンを押してクライアントサイドコンテナの Preview 画面を開く
クライアントサイドコンテナの Preview 画面に動作確認用 Web サイトの URL を入力して接続

動作確認用 Web サイトの画面が開くので、リンクからのページ遷移などの操作を行う
クライアントサイドで発火したイベントが、サーバサイドで受け取られて、GA4 に送信されることを確認する

以上で Cloud Run を使った sGTM 環境の構成は完了です。

応用編: HTTP(S) Load Balancing を使ったマルチリージョン構成

ここまではシンプルに東京リージョンの Cloud Run のみでシステムを構築してみましたが、応用的なアーキテクチャとして、SST クラスタを複数リージョンに分散させたマルチリージョン構成もお手軽に実現できます。これを実現するには、Cloud Run に Google Cloud の HTTP(S) Load Balancing を組み合わせます。

HTTP(S) Load Balancing を組み合わせたマルチリージョン構成

マルチリージョン構成にすることで、可用性を高めたり、エンドユーザに近いリージョンで処理を行うことでレイテンシを短縮できます。

なお、Cloud Run をマルチリージョン構成にした場合、ロードバランサのルーティングのルールは以下のようになります。

バックエンドサービスに複数の NEG が含まれている場合、ロードバランサはトラフィックを負荷分散するために、リクエストを最も近くの使用可能なリージョン内のサーバーレス NEG に転送します。
…（中略）…
最も近いリージョンが利用できないか、そのリージョンの容量が不足している場合、リクエストは別のリージョンにルーティングされます。

https://cloud.google.com/load-balancing/docs/https/setting-up-https-serverless#multi_region_lb

us-central1 リージョンへの SST クラスタデプロイ

では実際に構築してみます。まずは、作成済みの asia-northeast1（東京）の SST クラスタに加えて、us-central1（アメリカ、アイオワ州）にも SST クラスタを作成します。

$ gcloud run deploy sst-cluster-us \
--image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
--port=8080 \
--allow-unauthenticated \
--region=us-central1 \
--min-instances=1 --max-instances=100 \
--set-env-vars="PREVIEW_SERVER_URL=<Preview サーバの URL>,CONTAINER_CONFIG=<サーバサイドコンテナの Container Config>"

以前の手順と同様に、ブラウザからヘルスチェック用のパス（https://<ランダムに払い出された名前>.a.app.run/healthy）にアクセスして、ok が返ってくるか確認します。

ロードバランサの設定

次に、東京・アメリカの 2 つの Cloud Run サービスを配下に持った HTTP(S) Load Balancing を作成します。

一点注意としては、Cloud Run のサービスを HTTP(S) Load Balancing のバックエンドとして直接扱うことはできないので、Serverless NEG という仕組みで抽象化して取り扱う必要があります。Serverless NEG についてはわかりやすい記事（Serverless NEG でシステム開発をより柔軟に）がありますので、ご存知ない方はご一読いただくのがおすすめです。

HTTPS Load Balancer と Serverless NEG の概念図 — HTTP(S) Load Balancing と Serverless NEG の概念図

それでは、以下のようにロードバランサの設定を行っていきます。少し手順が多いようですが、やっている内容は、上図の右側の要素から順番に一つずつ作っているだけです。

# Serverless NEG の作成（東京）
$ gcloud compute network-endpoint-groups create sst-cluster-serverless-neg --region=asia-northeast1 --network-endpoint-type=SERVERLESS --cloud-run-service=sst-cluster# Serverless NEG の作成（アメリカ）
$ gcloud compute network-endpoint-groups create sst-cluster-us-serverless-neg --region=us-central1 --network-endpoint-type=SERVERLESS --cloud-run-service=sst-cluster-us# バックエンドサービスを作成
$ gcloud compute backend-services create sst-cluster-backend-service --global# sst-cluster-serverless-neg（東京）をバックエンドとして追加
$ gcloud compute backend-services add-backend sst-cluster-backend-service --global --network-endpoint-group=sst-cluster-serverless-neg --network-endpoint-group-region=asia-northeast1# sst-cluster-us-serverless-neg（アメリカ）をバックエンドとして追加
$ gcloud compute backend-services add-backend sst-cluster-backend-service --global --network-endpoint-group=sst-cluster-us-serverless-neg --network-endpoint-group-region=us-central1# URL マップの作成
$ gcloud compute url-maps create sst-cluster-url-map --default-service=sst-cluster-backend-service# マネージド証明書の作成（完了まではかなり時間がかかります）
$ gcloud compute ssl-certificates create sst-cluster-managed-certificate --domains=analytics-global.web.nosu.dev --global# HTTPS プロキシの作成
$ gcloud compute target-https-proxies create sst-cluster-target-https-proxy --url-map=sst-cluster-url-map# フォワーディングルールの作成
$ gcloud compute forwarding-rules create sst-cluster-forwarding-rule --target-https-proxy=sst-cluster-target-https-proxy --global --ports 443# フォワーディングルールに割り当てられた Global IP の確認
$ gcloud compute forwarding-rules describe sst-cluster-forwarding-rule --global --format="value(IPAddress)"# 確認した IP アドレスを指す DNS レコード（A レコード）の追加
# （ネームサーバで適宜設定する）

マネージド証明書のデプロイが完了すると、HTTP(S) Load Balancing の IP アドレスに割り当てた FQDN 経由でのアクセスが可能になります。ブラウザから /healthy エンドポイントにアクセスすると、ok が返ってくることを確認します。

リージョン分散の動作確認

まずは、Cloud Shell から HTTP(S) Load Balancing 経由でサーバサイドコンテナにアクセスしてみます。私の環境の場合、Cloud Shell のインスタンスは asia-east1（台湾）にデプロイされていたので、ネットワーク的な距離の近い asia-northeast1（東京）側にアクセスされるはずです。

$ curl https://analytics-global.web.nosu.dev/healthy
# => ok

Cloud Logging のログを確認すると、期待通り東京の Cloud Run でアクセスログが記録されていることがわかります。

※ 参考までに、Cloud Shell インスタンスのリージョンは、以下のようにして Metadata から確認できます。

$ curl -H "Metadata-Flavor: Google" metadata/computeMetadata/v1/instance/zone
# => projects/1092065506125/zones/asia-east1-a

次に、アメリカに検証用 VM を立てて、そこからのアクセスは us-central1（アメリカ）側にアクセスされることを確認します。

$ gcloud compute instances create us-central-vm --zone us-central1-a
$ gcloud compute ssh us-central-vm --zone us-central1-a -- curl https://analytics-global.web.nosu.dev/healthy
# => ok

Cloud Logging を開くと、こちらも期待通りアメリカ側の Cloud Run でアクセスログが記録されていることがわかります。

Google Cloud リソースの作業としては以上で完了ですが、実際にこのマルチリージョン構成で測定を開始するには、以下の作業を追加で行う必要があります。

クライアントサイド Google Tag Manager のサーバコンテナ URL を HTTP(S) Load Balancing に割り当てた FQDN に変更
Web サイトに導入した GTM タグのホスト名を同様に変更
Preview サーバでの動作確認

おわりに

本記事では、sGTM とは何か、そして sGTM を Cloud Run を使って単一リージョンで構成する手順と、応用編としてマルチリージョンで構成する手順をご紹介してきました。

今後ますます sGTM の利用を検討するケースは増えてくると思います。自分の Web サイトでも sGTM を導入したい！となった際には、ぜひ Cloud Run も選択肢として検討いただけると幸いです。