Google Cloud Platform

Server-side GTMのAppEngine設定をカスタマイズする

こんにちは、エクスチュアの権泳東(權泳東/コン・ヨンドン)です。

今回はServer-side GTM(以下SSGTM)が使うGoogle AppEngine(以下GAE)のインスタンス設定を変更して、オートスケールの動作をカスタマイズする方法について紹介します。

 

1. SSGTMのデプロイ種類

SSGTMをGAEにデプロイする際には、テスト用の「testing」か本番稼働用の「production」のいずれかを選ぶようになってます。

しかし、この時選択されるGAEのインスタンスで使うマシンタイプやインスタンス数が固定されているので、今回はこれを任意の設定に変えます。
なるべく安く、スケーラブルな設定にしたいですよね!

というわけでGAEのドキュメントを読みつつ、GAEの適切なサイジングとオートスケール設定をして行きます。

Google App Engine スタンダード環境のドキュメント  |  Google Cloud

App Engine の料金  |  App Engine ドキュメント  |  Google Cloud

 

2. GAEインスタンスのカスタマイズ

なお、私は既にSSGTMを「testing」モードでデプロイして稼働させてます。
まだSSGTMをGAEにデプロイしてない場合、下記の記事を参考にしてSSGTMを手動デプロイして稼働させておきます。

Server-side GTM を Google AppEngine にデプロイする

以下の作業はGCPのCloud Shellか、またはbashとgcloud SDKを使える環境で実行してください。

 

ダウンロード

まずはSSGTMのソースファイルをダウンロードして解凍します。

$ curl -O https://storage.googleapis.com/serverside-tagging/gtm-cloud-image.zip
$ unzip gtm-cloud-image.zip

 

設定ファイル(.yaml)の取得

続いて、GAEに既に展開されているソースファイルの中から設定ファイルを取得します。

GCPにログインして、 [App Engine] > [Versions] > [Diagnose] > [Source] を開きます。

GAEの設定ファイルを見る

するとデプロイされてるソースファイルが見えるので、この中のtesting.yamlのファイルの中身をコピペしてapp.yamlというファイル名でSSGTMソースファイルと同じディレクトリに保存します。

設定ファイル(YAML)

 

設定ファイルを編集

そして、今回はapp.yamlを下記のように編集しました。

service: default
runtime: nodejs10
instance_class: F1
automatic_scaling:
  max_instances: 3
  min_instances: 1
  max_concurrent_requests: 80
  target_cpu_utilization: 0.75
  target_throughput_utilization: 0.75
env_variables:
  CONTAINER_CONFIG: XXXXXXXXXX #SSGTM設定キーを入れる
  INCLUDE_DEBUG_SERVER: true
  POLICY_SCRIPT_URL: ''
handlers:
- url: /.*
  secure: always
  script: auto

上記の設定の意味はこういう事です。
トラフィックが増えた場合のオートスケール設定を変更してます。

max_instances … 3 (最大3台まで起動)
min_instances … 1 (普段は1台だけ起動)
max_concurrent_requests … 80 (最大同時接続数を最大値の80にしておく)
target_cpu_utilization … 0.75 (CPU利用率が75%を超えたらスケールアウトする)
target_throughput_utilization … 0.7 (max_concurrent_requestsで設定した接続数の75%に達したらスケールアウトする)

もっとスケーラブルにしたいのですが、私の財布の中身がスケールしないので・・・(小声

※2020/09/14追記
当初F1インスタンスの代わりにF4インスタンスを使ってみましたが、F4だとF1クラス4台分の課金になるので、F1に戻しました(汗

バズって急激にアクセスが殺到した時にSSGTMを鬼スケールさせたい方は常時稼働させる台数を増やすなどチューニングしてください。
(その前にサイトそのものもスケールしないと意味ありません)

AppEngineスタンダードは無料枠があるのと、インスタンスがない状態から起動するまで数ミリ秒から数秒です。
一方AppEngineフレキシブルだと無料枠がなく、起動するのにも数分掛かるので最初からトラフィックを予測して数台起動させておく必要があります。

というわけで私はGAEスタンダードをチューニングして使います。

 

GAEにデプロイ

変更を保存したら、以下のコマンドでGAEにデプロイします。

$ gcloud app deploy

しばらくすると、デプロイが完了します。

 

3. デプロイの確認

SSGTMのデプロイが終わったら、色々と設定を確認しましょう。

まずはGAEのサービス状態を確認。

新しいバージョンが稼働してます。
この時点でインスタンスが2台になっておりますが、旧バージョンにはもうトラフィックは発生してません。

新バージョン稼働中

設定を確認します。
[Config] > [View] を開くと見れます。

設定を確認

デフォルトの項目が何個か追加されてますが、変更が反映されている事が確認出来ました。

さらに、SSGTMのデバッグビューも見ます。
ビーコンが届いてるのが確認出来ました。

SSGTMデバッグビュー

Google Analyticsのリアルタイムレポートもちゃんと反応し続けてます。

GAリアルタイムレポート

AppEngineのインスタンスの稼働状況も見てみます。
デプロイ直後に一瞬50xエラーが起きてますが、まぁ細けぇこたぁいいんだよキニスンナ(震え声

稼働状況

さて、新しい設定での稼働が確認出来ました。

前のバージョンのインスタンスが稼働してると4時間以上経つと課金されてしまうので、止めるか消すかします。
私は消しました。

旧バージョンは削除

ただ、消す前に「トラフィック分割機能」を使って、新旧両方のバージョンにトラフィックを送ってテストする事も可能です。

トラフィックの分割  |  Node.js 用 App Engine スタンダード環境に関するドキュメント  |  Google Cloud

今回はトラフィック分割は割愛します。

そして、オートスケール設定を変えたらGAEのダッシュボードとGCP課金レポートをこまめに確認しましょう。
低レイテンシで応答できてるか、オートスケール設定が十分か、想定外に高い課金になってないか等を見て下さい。

 

おまけ) これからGCPを始めるマーテックエンジニアの方へ

今までずっとJavascript/Webの仕事だけやって来た方がいきなりパブリッククラウドなんて言われてもそう簡単には行きませんよね。
私はかつて情報システム部門のUnixエンジニア/Javaプログラマでした。
プライベートPCはLinuxです。

しかし、そんな私が成り行きでJavascriptの仕事をするはめになり、今に至ります。

おかげでGCPを特に抵抗もなく使ってますが、これからGCPを始めるのであればまずはGoogleおよびパートナーが提供するトレーニングの受講をおすすめします。

Google Cloud トレーニング コースと認定資格  |  Google Cloud のトレーニング

GCPのトレーニングは複数ありまして、私も何度かトレーニングとセミナーに参加しましたがとても参考になりました。

GAEでapp.yamlを書いてデプロイする方法など、実際にハンズオンで習うと覚えるのが早いです。

 

TL;DR

今回はSSGTMで使うGAEインスタンスをカスタマイズする方法について紹介しました。
デプロイ用のYAMLファイルを編集すればカスタマイズ出来ます。
そしてGCPをこれから始める方は、まずはトレーニングを受けましょう。

弊社ではGoogleAnalytics/AdobeAnalyticsなどの各Martechツールの導入実装コンサルティングサービスや、GCP/AWSなどのパブリッククラウドを使ったデータ分析基盤構築コンサルティングサービスを提供しております。
お問い合わせはこちらからどうぞ。

 

関連記事

  1. Adobe Analytics

    Adobe Analytics: DatafeedをGoogle BigQueryにロード(2019…

    こんにちは、エクスチュアの權泳東(権泳東/コン・ヨンドン)です。…

  2. Google Tag Manager

    Google Tag Manager: 離脱リンクのクリックをトリガーにする

    こんにちは、エクスチュアの權泳東(権泳東/コン・ヨンドン)です。…

  3. Web解析

    Safari ITP2.xの次なる標的は?

    こんにちは、エクスチュアの權泳東(権泳東/コン・ヨンドン)です。…

  4. Google Analytics

    Google Analytics StandardのデータをBigQueryで分析するための力技

    こんにちは、エクスチュアの權泳東(権泳東/コン・ヨンドン)です。…

  5. Firebase Analytics

    Firebase AnalyticsのデータをフラットなCSVに変換するETL処理

    こんにちは、エクスチュアの權泳東(権泳東/コン・ヨンドン)です。…

  6. Google Cloud Platform

    GoogleNext 2019レポート:初日目

    こんにちは、エクスチュアの權泳東(権泳東/コン・ヨンドン)です。…

最近の記事

  1. YOTTAA:ECサイトで見るべき8つのサイトパフォーマンス…
  2. 【初心者向け】AWSを学ぶ前に確認したい用語
  3. サーバーサイドGTM: ウェブコンテナを使って1stパーティ…
  4. BigQuery: テーブルに格納されたURL文字列をKey…
  5. AdobeAnalytics: Adobe I/OのAPIを…
  1. Adobe Analytics

    Looker: Sankey Diagramを使ってサイト内フローを可視化する
  2. Amazon Web Services

    Databricks Community Editionを使ってApache S…
  3. KARTE

    KARTE:簡単!アンケートの設定、アンケート結果に併せた接客配信
  4. Adobe Analytics

    BigQuery: Adobe Datafeed: event_listカラムの…
  5. Adobe Analytics

    Adobe Analytics: Datafeedのログからフォールアウトレポー…
PAGE TOP