App Engine によるサーバーサイド タグ設定をセットアップする

このガイドでは、以下の方法を説明します。

  • Google Cloud Platform(GCP)の App Engine でタグ設定サーバーをプロビジョニングする
  • ライブ トラフィックを処理できるようタグ設定サーバーをアップグレードする
  • Google タグ マネージャーのコンテナを実行しているサーバーの数を調整する
  • サーバーのプロビジョニング後、タグ設定サーバーを最新のバージョンに保つ

前提条件

  1. GCP アカウントが必要です。お持ちでない場合は、新しい GCP アカウントを作成してください。
  2. GCP の請求先アカウントが必要です。お持ちでない場合は、新しい GCP 請求先アカウントを作成してください(「請求先アカウント作成者」ロールが必要です)。
  3. 「プロジェクト作成者」および「請求先アカウント ユーザー」ロールが必要です。詳細: ロールの追加

1. サーバーをプロビジョニングする

App Engine のインスタンスで新しいタグ設定サーバーを作成するには、以下を行う必要があります。

  • タグ マネージャーでサーバー コンテナを作成する
  • 新しい Google Cloud プロジェクト(GCP)を作成する
  • 新しい App Engine タグ設定サーバーをプロビジョニングする
  • タグ マネージャーのサーバー コンテナに新しいタグ設定サーバーの URL を追加する

Google タグ マネージャーでサーバー コンテナを作成する

  1. Google タグ マネージャーを開きます。

  2. 使用するアカウントの欄のオーバーフロー メニューをクリックして、[コンテナを作成] を選択します。

  3. サーバー用のコンテナを新規作成します。

  4. ラジオボタン [タグ設定サーバーを手動でプロビジョニングする] をクリックします。コンテナ設定をメモします。コンテナ設定は、サーバーのプロビジョニングに必要になります。

新しい GCP プロジェクトを作成する

タグ設定サーバー用の GCP プロジェクトを新規作成する手順:

  1. Google Cloud コンソールを開きます。

  2. 新しい GCP プロジェクトを作成します

  3. プロジェクトに名前を付けます。コンテナ ID をそのままプロジェクト名にすることをおすすめします。この名前は GCP 内でのみ使用されます。

  4. GCP プロジェクト ID を控えておきましょう。タグ設定サーバーを作成する際に必要になります。

新しいタグ設定サーバーをプロビジョニングする

タグ設定サーバーを作成する手順:

  1. Cloud Shell を開きます。

  2. Cloud Shell で GCP プロジェクトを設定します。project ID とある箇所は、先ほど控えた実際の GCP プロジェクト ID で置き換えてください。

    gcloud config set project project ID
    
  3. シェル スクリプトに従って、タグ設定サーバーを作成しましょう。デプロイメント タイプは testing に設定します。

    bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
    

タグ設定サーバーの URL をタグ マネージャーに追加する

  1. Google タグ マネージャーを開きます。

  2. [管理] > [コンテナの設定] で、[URL を追加] をクリックします。サーバーの URL がわからない場合は、Cloud Shell で次のコマンドを実行します。

    gcloud app browse
    

    結果: タグ設定サーバーをセットアップして、testing 設定でプロビジョニングすることができました。これでサーバーサイド タグ設定のテストが可能です。

サーバーの初期設定(testing

testing 設定は、プロダクトの動作を確認するために少量のテスト トラフィックを送信する場合や、タグ マネージャーでプレビュー機能を使用する場合に適した設定です。テスト設定は、スタンダード環境の App Engine F1 インスタンス クラスに相当し、通常は費用が発生しません。

2. App Engine を本番環境で使用する

production 設定のサーバーは、1 台あたり月額約 40 ドルの料金がかかります。各サーバーは、1 個の vCPU、0.5 GB のメモリ、10 GB のディスクを備えたフレキシブル環境の App Engine インスタンスです。

App Engine の課金と請求アラートの設定方法については、App Engine の費用の管理をご覧ください。請求アラートは、作成することを強くおすすめします。

サーバーが停止した場合のデータ損失リスクを軽減するため、サーバーは最低でも 3 台稼動させることをおすすめします。ただし、稼動サーバー数は必要に応じて減らすことも(増やすことも)可能です。サーバー 3~6 台で自動スケーリングした場合、処理できるリクエストの数は秒間 50~200 件程度と見込まれますが、実際のパフォーマンスは、タグの数とその処理内容によって異なります。

タグ設定サーバーを構成する手順:

  1. Google Cloud Platform Cloud Shell を開きます。
  2. Cloud Shell で Cloud Platform プロジェクトを設定します。project ID を、先ほど控えた実際の GCP プロジェクト ID で置き換えてください。
    gcloud config set project project ID
  3. タグ設定サーバーを本番環境向けに再構成するには、下のセットアップ スクリプトを実行しましょう。以下を行う必要があります。
    bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
    1. デプロイメント タイプを production に変更します。
    2. 本番トラフィックを処理できるよう、追加のサーバーをセットアップします。サーバーは最低でも 3 台稼働させることをおすすめします。

任意: ロギングを無効化する

リクエストのロギング

デフォルトでは、App Engine は受信したすべてのリクエストの情報(例: リクエストのパス、クエリ パラメータなど)をログに記録しています。タグ設定サーバーで処理するリクエストの数が多い場合(月間 100 万件を超える場合など)、そのログメッセージによって多額のロギングの料金が発生する可能性があります。ロギングの料金を削減または排除するには、App Engine リクエストのロギングを無効にすることをおすすめします。

App Engine でのリクエストのロギングを無効化する手順:

  1. Google Cloud Platform で、ログルーターを開きます。開いているプロジェクトの名前が、使用するコンテナの ID と一致していることを確認しましょう。
    GCP プロジェクト セレクタにタグ マネージャー コンテナ ID の例が表示されている様子のスクリーンショット。
  2. [種類] が「Cloud Logging バケット」、[名前] が「_Default」の行で、オーバーフロー メニューをクリックして、[シンクを編集] を選択します。
  3. [シンクの宛先] で、_Default ログバケットを選択します。
  4. [シンクに含めるログの選択] で、新しい行を追加します。既存の包含フィルタに次のルールを追記しましょう。

    NOT LOG_ID("appengine.googleapis.com/nginx.request") AND NOT
    LOG_ID("appengine.googleapis.com/request_log")
    
  5. ロードバランサからのロギングも無効化する場合は、さらに新しい行を追加して、既存の一致フィルタに次のルールを追記します。

    NOT LOG_ID("requests")
    
  6. シンクを更新して、変更内容を適用します。これで、App Engine リクエストがロギングから除外されます。

  7. ログ エクスプローラのログに、新しいリクエストが表示されなくなっていることを確認します。

コンソールのロギング

タグ設定サーバー、クライアント、コンテナ内のタグがコンソールへのメッセージをログすることによって、ロギングの料金が発生する場合があります。ロギングの料金を削減または排除するには、不要なコンソールログ メッセージを無効化すると効果的です。

不要なコンソールログを識別する手順:

  1. GCP でログ エクスプローラを開きます。
  2. タグ由来の不要なログメッセージを探します。たとえば次のようにします。

    タグが以下のログを送信しているとします。

    const logToConsole = require('logToConsole');
    
    logToConsole('Custom message: ' + data.param1);
    logToConsole('An important message to keep around!');
    data.gtmOnSuccess()
    

    textPayload フィールドで、対応するログメッセージを見つけましょう。
    GCP ログ エクスプローラでログの例を表示している様子のスクリーンショット。

コンソールログ メッセージを無効化する手順:

  1. Google Cloud Platform で、ログルーターを開きます。開いているプロジェクトの名前が、使用するコンテナの ID と一致していることを確認しましょう。
    GCP プロジェクト セレクタにタグ マネージャー コンテナ ID の例が表示されている様子のスクリーンショット。
  2. [種類] が「Cloud Logging バケット」、[名前] が「_Default」の行で、オーバーフロー メニューをクリックして、[シンクを編集] を選択します。
  3. [シンクの宛先] で、_Default ログバケットを選択します。
  4. [シンクに含めるログの選択] で、新しい行を追加します。既存の包含フィルタに次のルールを追記しましょう。

    NOT textPayload:"Custom message:"
    

    Custom message: とある箇所は、無効化したいコンソールログの部分文字列に置き換えましょう。より複雑なフィルタを作成するには、Logging のクエリ言語を活用します。

  5. シンクを更新して、変更内容を適用します。これで、条件に一致する logToConsole メッセージがロギングの対象から除外されるはずです。

  6. ログ エクスプローラのログに、新しいコンソールログ メッセージが表示されなくなっていることを確認します。

3. デプロイメントをカスタム ドメインにマッピングする

デフォルトのサーバー側タグ設定は、App Engine ドメインでホストされます。代わりに、ウェブサイトのサブドメインを使用するように変更することをおすすめします。

ウェブサイトのサブドメインをタグ設定サーバーにマッピングする

4. サーバーの URL を Google タグ マネージャーに追加する

サーバーが用意できたので、次は Google タグ マネージャーにそのサーバーを使用するよう伝えます。

  1. Google タグ マネージャーを開きます。

  2. 用意したタグ設定サーバーを使用させたいサーバー コンテナをクリックします。

  3. サーバー コンテナの設定を開きます([管理] タブ > [コンテナの設定])。

  4. [URL を追加] をクリックして、サーバーの URL を貼り付けます。

  5. [保存] をクリックしてワークスペースに戻ります。

5. 検証

セットアップの済んだタグ設定サーバーが意図どおりに動作するか確認しましょう。タグ マネージャーのワークスペースで、[プレビュー] ボタンをクリックします。プレビュー ページの読み込みが成功する場合は、セットアップが問題なく完了しています。

複数の URL のプレビュー

複数のドメインを同じタグ設定サーバーにマッピングした場合は、各 URL がコンテナの設定に追加されていることを確認しましょう。

複数の URL を指定した場合、パス(ドメイン名の後の文字列)はすべて一致している必要があります。

OK NG
URL 1: example.com/abc
URL 2: example2.com/abc
URL 1: example.com/abc
URL 2: example2.com/def

複数の URL が追加してある場合、[プレビュー] ボタンの隣にアイコンが表示され、プレビューする URL を選択できます。

タグ設定サーバーのバージョンをアップデートする

タグ設定サーバーのアップデートには、セキュリティ上の脆弱性の修正や、新機能の追加が含まれます。タグ マネージャーでアップデートを促す通知が表示された際に、最低でも各メジャー バージョン リリースへのアップグレード(例: バージョン 1.x.x から 2.x.x へのアップグレード)は行うことをおすすめします。

タグ設定サーバーをアップデートするには、前回と同じ設定を使ってセットアップ スクリプトを再実行します。デフォルトで既存の設定が引き継がれます。

タグ設定サーバーをアップデートするには:

  1. Google Cloud Platform Cloud Shell を開きます。
  2. Cloud Shell で Cloud Platform プロジェクトを設定します。project ID を、先ほど控えた実際の GCP プロジェクト ID で置き換えてください。
    gcloud config set project project ID
  3. 前回と同じ設定を使ってセットアップ スクリプトを実行します。デフォルトで既存の設定が引き継がれます。
    bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"

アップデートが正常に終了したことを確認します。手順は次のとおりです。

  1. サーバー コンテナで、[プレビュー] ボタンをクリックして、新しいデバッグ セッションを開始し、別のタブでリクエストを送信します。
  2. 概要で、[コンソール] タブを選択し、タグ設定サーバーの更新を求めるメッセージがないことを確認します。

タグ マネージャーでは、サーバーが正常に更新されてから最大 1 日の間、タグ設定サーバーの更新を求めるメッセージが表示される場合があります。ただし、プレビュー ページには、タグ設定サーバーのバージョンに関する最新のメッセージが表示されます。

本番環境のデプロイ タイムアウトのトラブルシューティング

セットアップ スクリプトを実行してタグ設定サーバーを作成または再設定する際に、スクリプトがタイムアウトする場合があります。これにはいくつかの原因が考えられますが、最も一般的な原因として以下の 2 つが挙げられます。

  1. サービス アカウントに付与されている権限が不適切 - Compute Engine と App Engine のサービス アカウントは、本番環境のデプロイと管理を担当します。デフォルトでは、適切な権限があらかじめ設定されていますが、組織のポリシーによっては付与される権限が不適切な場合があります。

    1. Google Cloud コンソールの左側のナビゲーション バーから [IAM と管理] ページに移動します。
    2. Compute Engine サービス アカウント <project_number>-compute@developer.gserviceaccount.com と App Engine サービス アカウント <project_name>@appspot.gserviceaccount.com を見つけます。
    3. 両方のサービス アカウントに Editor のロールが必要です。アカウントのいずれかが Editor ロールを持たない場合は、アカウントの右側にある鉛筆アイコンをクリックし、既存のロールのプルダウンをクリックして、一番上までスクロールして [Project]、[編集者] の順にクリックしてロールを更新します。
  2. 割り当て不足 - 本番環境のデプロイでは Compute Engine の割り当てが消費されます。プロジェクトの割り当てが不足している場合、リソースのプロビジョニングを試行中にデプロイがタイムアウトすることがあります。

    1. Google Cloud コンソールの左側のナビゲーション バーから [IAM と管理] ページに移動し、左側のナビゲーション バーの [割り当て] をクリックします。
    2. ページ上部の [表をフィルタリング] と表示されているテキスト ボックスをクリックし、「Compute Engine API」と入力します。残った 1 件をクリックします。
    3. 割り当てのステータスがすべて上限内であるか、緑色のチェックマークが表示されていることを確認します。
    4. CPU を見つけてクリックします。現在の使用量とデプロイしようとしているインスタンス数を合わせても、デプロイメント リージョンの上限以内に収まることを確認します。