こんにちは、エクスチュアの権泳東(權泳東/コン・ヨンドン)です。
今回は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] を開きます。
するとデプロイされてるソースファイルが見えるので、この中のtesting.yamlのファイルの中身をコピペしてapp.yamlというファイル名でSSGTMソースファイルと同じディレクトリに保存します。
設定ファイルを編集
そして、今回は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のデバッグビューも見ます。
ビーコンが届いてるのが確認出来ました。
Google Analyticsのリアルタイムレポートもちゃんと反応し続けてます。
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などのパブリッククラウドを使ったデータ分析基盤構築コンサルティングサービスを提供しております。
お問い合わせはこちらからどうぞ。