このページは Cloud Translation API によって翻訳されました。

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

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

コンテナのプレビュー機能を有効化するためにプレビューサーバーをプロビジョニングする
ライブトラフィックを扱うタグ設定サーバーをプロビジョニングする
Google タグマネージャーのコンテナを実行しているサーバーの数を調整する
サーバーのプロビジョニング後、タグ設定サーバーを最新のバージョンに保つ

前提条件

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

プレビューサーバーとタグ設定サーバーをプロビジョニングする

Cloud Run サービスのプロビジョニングは、Google タグマネージャーで自動的に行う方法と、Google Cloud で手動で行う方法があります。

サービスの設定を編集する

サービスの設定を変更する手順:

Cloud Run を開きます。
調整したいサービスを選択します。
[新しいリビジョンの編集とデプロイ] をクリックします。
必要な変更を加えて、[デプロイ] をクリックします。

Cloud Run の費用

この設定で Cloud Run を運用すると、サーバー 1 台あたり月額 45 米ドル程度の費用が発生します。各サーバーは、vCPU 1 個、メモリ 0.5 GB で「CPU を常に割り当てる」設定の Cloud Run インスタンスです。

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

Cloud Run は負荷に応じて動的にスケーリングを行います。max-instances 設定は最悪の場合に発生するリソース使用料の上限を決めるものであり、必要もないのにそれだけのインスタンス数がプロビジョニングされることはありません。

Cloud Run 計算ツール

任意: App Engine からの移行

App Engine デプロイメントを作成してあった場合は、想定外の料金が発生しないよう、App Engine アプリケーションを無効化しましょう（App Engine デプロイメントにトラフィックが流れなくなっていることを確認したうえで無効化します）。

任意: マルチリージョンデプロイ

グローバルなプレゼンスを持つウェブサイトの場合や、サービスを冗長化したい場合は、タグ設定サーバーを複数のリージョンにデプロイしましょう。

事前準備:

ロードバランサを作成します。
選択した BACKEND_NAME を控えておきます。

デプロイメントのリージョンを追加する手順:

REGION とある箇所を、プレビューサーバーがデプロイされているリージョンに差し替えます。コマンドラインを使う方法でプレビューおよびタグ設定サーバーをプロビジョニングした場合は、この箇所はすでに入力されていることもあります。
CONTAINER_CONFIG とある箇所を、タグマネージャーの画面で控えた実際のコンテナ設定文字列に差し替えます。コマンドラインを使う方法でプレビューおよびタグ設定サーバーをプロビジョニングした場合は、この箇所はすでに入力されていることもあります。
NEW_REGION とある箇所を、タグ設定サーバーを新たにデプロイするリージョンに差し替えます。
BACKEND_NAME とある箇所を、ロードバランサをプロビジョニングする際に選択した名前に差し替えます。
任意: さらに別のリージョンを追加するには、NEW_REGION 変数を差し替えてコードスニペットを再実行します。

    gcloud run deploy "server-side-tagging" \
    --region NEW_REGION \
    --image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
    --platform managed \
    --ingress all \
    --min-instances 2 \
    --max-instances 10 \
    --timeout 60 \
    --allow-unauthenticated \
    --no-cpu-throttling \
    --update-env-vars PREVIEW_SERVER_URL="$(
      gcloud run services describe server-side-tagging-preview \--region "REGION" \
      --format="value(status.url)")",CONTAINER_CONFIG="CONTAINER_CONFIG" && \

    gcloud compute network-endpoint-groups create server-side-tagging-neg \
    --region=NEW_REGION \
    --network-endpoint-type=SERVERLESS \
    --cloud-run-service="server-side-tagging" && \

    gcloud compute backend-services add-backend --global "BACKEND_NAME" \
    --network-endpoint-group-region=NEW_REGION \
    --network-endpoint-group=server-side-tagging-neg

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

リクエストのロギング

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

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

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

コンソールのロギング

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

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

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 メッセージがロギングの対象から除外されるはずです。
ログエクスプローラのログに、新しいコンソールログメッセージが表示されなくなっていることを確認します。

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

カスタムドメインをセットアップするには、グローバル外部アプリケーションロードバランサを使用します。

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

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

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

4. 検証

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

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

タグ設定サーバーをアップデートするには、前回と同じ設定を使って新しいリビジョンをデプロイします。

Cloud Run を開きます。
アップデートするサービスを選択します。
[新しいリビジョンの編集とデプロイ] をクリックします。
[コンテナイメージの URL] が gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable に設定されていることを確認して、[デプロイ] をクリックします。

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

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

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