このガイドでは、以下の方法について説明します。
- Google Cloud Platform App Engine にタグ設定サーバーを手動でプロビジョニングする
- 自動プロビジョニングされたタグ設定サーバーをアップグレードして、トラフィックをリアルタイムで処理できるようにする
- サーバー用コンテナを実行するサーバーの数を増減する
このプロセスには以下の操作が含まれます。
- Google Cloud Platform プロジェクトを作成するか、Google Cloud Console で既存のプロジェクトに移動します。
- シェル スクリプトを実行して、タグ設定サーバーを設定する手順や、既存のタグ設定サーバーの設定を変更する手順を確認します。
(自動プロビジョニング中にデフォルトで設定される)テスト用設定は、件数が少ないテスト トラフィックや、タグ マネージャーのプレビュー機能を使用する場合に適しています。大量のライブ トラフィックをサーバーへ送信するときは、事前にシェル スクリプトを使用して、サーバーを本番環境にアップグレードすることをおすすめします。
ほとんどの場合、テスト環境では料金が発生しません。テスト環境は、スタンダード環境の App Engine F1 インスタンス クラスに相当します。
本番環境では、サーバー 1 台あたり毎月約 40 ドルかかります。各サーバーは、1 個の vCPU、0.5 GB のメモリ、10 GB のディスクを備えたフレキシブル環境の App Engine インスタンスです。サーバーが停止した場合のデータ損失リスクを軽減するため、少なくとも 3 台のサーバーを実行することをおすすめします。ただし、実行するサーバーの数は状況に応じて増減できます。3~6 台のサーバーを自動スケーリングすることで 1 秒あたり 50~200 件のリクエストを処理できますが、実際のパフォーマンスは、タグの数とその処理内容によって異なります。
App Engine の課金と請求アラートの設定方法については、App Engine 費用の管理をご覧ください。請求アラートを設定することを強くおすすめします。
Google Cloud Platform(GCP)プロジェクトを作成する
GCP サーバーを自動的にプロビジョニングした場合は、その時点で GCP プロジェクトも作成されています。console.cloud.google.com に移動すると、作成された GCP プロジェクトが表示され、アクセスすることができます。プロジェクト ID は、コンテナ ID の末尾にランダムな文字列が付加されたものになります。
自動プロビジョニングによって GCP サーバーを作成しなかった場合:
新しい GCP ユーザー: 新しい GCP アカウントを作成し、GCP 請求先アカウントを作成します。
既存の GCP ユーザー: GCP で新しいプロジェクトを作成します。プロジェクトには任意の名前を付けることができますが、利便性の点から、コンテナ ID を使用することをおすすめします。この名前は GCP 内でのみ使用されます。プロジェクト ID をメモしてください。
タグ設定サーバーを作成する、または既存のタグ設定サーバーを再設定する
- 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)"
このシェル スクリプトでは、次のタスクを実行できます。
- タグ設定サーバーをまだ設定していない場合、このスクリプトで設定できます。
- 既存のタグ設定サーバーから本番環境トラフィックを配信する場合、このスクリプトを使用してサーバーを追加します。
- タグ設定サーバーがすでに存在する場合、このスクリプトで設定を変更できます。
サーバー コンテナの URL を設定する
自動プロビジョニング プロセスを使用してサーバーを設定した場合は、この手順を省略します。
アプリケーションが App Engine サブドメインにデプロイされます。次のコマンドを実行して URL を取得します。
gcloud app browse
その URL をコピーし、タグ マネージャーのサーバー側コンテナに移動します。[管理] > [コンテナの設定] の [サーバー コンテナの URL] にコピーした URL を貼り付け、[保存] をクリックしてワークスペースに戻ります。
検証
タグ マネージャーで、設定したコンテナをプレビューします。プレビュー ページが読み込まれると、すべて正しく設定されていることがわかります。
カスタム ドメインをマッピングする
新しいタグ設定サーバーを作成したら、こちらの手順に沿って、そのタグ設定サーバーにウェブサイトのサブドメインをマッピングします。
App Engine リクエストのロギングを無効にする(省略可)
デフォルトでは、App Engine は受信したすべてのリクエストに関する情報(リクエストパス、クエリ パラメータなど)を記録します。タグ設定サーバーで 1 か月に大量のリクエスト(例: 100 万件以上)を処理する場合、そのログメッセージによって多額のロギングの料金が発生する可能性があります。ロギングの料金を削減または排除するには、App Engine リクエストのロギングを無効にすることをおすすめします。App Engine リクエストのロギングを無効にするには、以下の操作を行います。
- [ロギング] -> [ログルーター] に移動します。プロジェクトがコンテナ 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 リクエストがロギングから除外されます。[ロギング] -> [ログビューア] で、新しいリクエストがログに表示されていないことを確認します。
本番環境のデプロイ タイムアウトのトラブルシューティング
セットアップ スクリプトを実行してタグ設定サーバーを作成または再設定すると、スクリプトがタイムアウトする場合があります。これにはいくつかの原因が考えられますが、最も一般的な原因として以下の 2 つが挙げられます。
サービス アカウントに不適切な権限が含まれている - Compute Engine と App Engine のサービス アカウントは、本番環境でのデプロイメントのデプロイと管理を担当します。デフォルトでは、適切な権限があらかじめ設定されていますが、組織のポリシーによっては不適切な権限が含まれる場合があります。
- Google Cloud Console の左側のナビゲーション バーの [IAM と管理] ページに移動します。
- Compute Engine サービス アカウント
<project_number>-compute@developer.gserviceaccount.com
と App Engine サービス アカウント<project_name>@appspot.gserviceaccount.com
を見つけます。 - 両方のサービス アカウントに
Editor
のロールが必要です。 アカウントのいずれかがEditor
ロールを持たない場合は、アカウントの右側にある鉛筆アイコンをクリックし、既存のロールのプルダウンをクリックして、一番上までスクロールして [プロジェクト]、[編集者] の順にクリックしてロールを更新します。
割り当て不足 - 本番環境のデプロイでは Compute Engine の割り当てが消費されます。プロジェクトの割り当てが不足している場合、リソースのプロビジョニングを試行中にデプロイがタイムアウトすることがあります。
- Google Cloud Console の左側のナビゲーション バーの [IAM と管理] ページに移動し、左側のナビゲーション バーの [割り当て] タブをクリックします。
- ページ上部の [表をフィルタリング] と表示されているテキスト ボックスをクリックし、「
Compute Engine API
」と入力します。唯一の結果をクリックします。 - 割り当てのステータスがすべて上限内であるか、緑色のチェックマークが表示されていることを確認します。
- CPU を見つけてクリックします。現在の使用量と、デプロイされているインスタンスの数がデプロイ リージョンの上限を超えていないことを確認します。