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

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

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

前提条件

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

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

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

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

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

Google タグマネージャーを開きます。
使用するアカウントの欄のオーバーフローメニューをクリックして、[コンテナを作成] を選択します。
サーバー用のコンテナを新規作成します。
ラジオボタン [タグ設定サーバーを手動でプロビジョニングする] をクリックします。コンテナ設定をメモします。コンテナ設定は、サーバーのプロビジョニングに必要になります。

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

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

Google Cloud コンソールを開きます。
新しい GCP プロジェクトを作成します。
プロジェクトに名前を付けます。コンテナ ID をそのままプロジェクト名にすることをおすすめします。この名前は GCP 内でのみ使用されます。
GCP プロジェクト ID を控えておきましょう。タグ設定サーバーを作成する際に必要になります。

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

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

Cloud Shell を開きます。
Cloud Shell で GCP プロジェクトを設定します。project ID とある箇所は、先ほど控えた実際の GCP プロジェクト ID で置き換えてください。
```
gcloud config set project project ID
```
シェルスクリプトに従って、タグ設定サーバーを作成しましょう。デプロイメントタイプは testing に設定します。

ヒント: プロンプトで何を入力するべきか自信がない場合は、「?」と入力すればヘルプが表示されます。
```
bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
```

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

Google タグマネージャーを開きます。
[管理] > [コンテナの設定] で、[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 件程度と見込まれますが、実際のパフォーマンスは、タグの数とその処理内容によって異なります。

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

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

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

リクエストのロギング

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

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

Google Cloud Platform で、ログルーターを開きます。開いているプロジェクトの名前が、使用するコンテナの ID と一致していることを確認しましょう。
[種類] が「Cloud Logging バケット」、[名前] が「_Default」の行で、オーバーフローメニューをクリックして、[シンクを編集] を選択します。
[シンクの宛先] で、_Default ログバケットを選択します。
[シンクに含めるログの選択] で、新しい行を追加します。既存の包含フィルタに次のルールを追記しましょう。
```
NOT LOG_ID("appengine.googleapis.com/nginx.request") AND NOT
LOG_ID("appengine.googleapis.com/request_log")
```
ロードバランサからのロギングも無効化する場合は、さらに新しい行を追加して、既存の一致フィルタに次のルールを追記します。
```
NOT LOG_ID("requests")
```
注: これにより、サーバーコンテナに送信されていないリクエストを含む、ロードバランサからのすべてのロギングが無効になります。
シンクを更新して、変更内容を適用します。これで、App Engine リクエストがロギングから除外されます。
ログエクスプローラのログに、新しいリクエストが表示されなくなっていることを確認します。

コンソールのロギング

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

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

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

タグが以下のログを送信しているとします。
```
const logToConsole = require('logToConsole');

logToConsole('Custom message: ' + data.param1);
logToConsole('An important message to keep around!');
data.gtmOnSuccess()
```
textPayload フィールドで、対応するログメッセージを見つけましょう。

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

Google Cloud Platform で、ログルーターを開きます。開いているプロジェクトの名前が、使用するコンテナの ID と一致していることを確認しましょう。
[種類] が「Cloud Logging バケット」、[名前] が「_Default」の行で、オーバーフローメニューをクリックして、[シンクを編集] を選択します。
[シンクの宛先] で、_Default ログバケットを選択します。
[シンクに含めるログの選択] で、新しい行を追加します。既存の包含フィルタに次のルールを追記しましょう。
```
NOT textPayload:"Custom message:"
```
Custom message: とある箇所は、無効化したいコンソールログの部分文字列に置き換えましょう。より複雑なフィルタを作成するには、Logging のクエリ言語を活用します。
シンクを更新して、変更内容を適用します。これで、条件に一致する logToConsole メッセージがロギングの対象から除外されるはずです。
ログエクスプローラのログに、新しいコンソールログメッセージが表示されなくなっていることを確認します。

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

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

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

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

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

Google タグマネージャーを開きます。
用意したタグ設定サーバーを使用させたいサーバーコンテナをクリックします。
サーバーコンテナの設定を開きます（[管理] タブ > [コンテナの設定]）。
[URL を追加] をクリックして、サーバーの URL を貼り付けます。
[保存] をクリックしてワークスペースに戻ります。

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 へのアップグレード）は行うことをおすすめします。

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

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

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

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

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

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

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

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

サービスアカウントに付与されている権限が不適切 - 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]、[編集者] の順にクリックしてロールを更新します。
割り当て不足 - 本番環境のデプロイでは Compute Engine の割り当てが消費されます。プロジェクトの割り当てが不足している場合、リソースのプロビジョニングを試行中にデプロイがタイムアウトすることがあります。
1. Google Cloud コンソールの左側のナビゲーションバーから [IAM と管理] ページに移動し、左側のナビゲーションバーの [割り当て] をクリックします。
2. ページ上部の [表をフィルタリング] と表示されているテキストボックスをクリックし、「Compute Engine API」と入力します。残った 1 件をクリックします。
3. 割り当てのステータスがすべて上限内であるか、緑色のチェックマークが表示されていることを確認します。
4. CPU を見つけてクリックします。現在の使用量とデプロイしようとしているインスタンス数を合わせても、デプロイメントリージョンの上限以内に収まることを確認します。