Opt Technologies Magazine

オプトテクノロジーズ 公式Webマガジン

サーバーサイドGTMの動作環境をGoogleAppEngineとCloudRunで性能比較した

サーバーサイドGTMの動作環境をGoogleAppEngineとCloudRunで性能比較したので紹介していきます。

あいさつ

こんにちは。Opt Technologies で開発をしている鈴木省吾(@munaita_)です。広告データを取り扱うプロダクトの開発に関わっています。

サーバーサイドGTMとは

参照: サーバーサイド タグ設定の概要

既存のウェブコンテナだけを使ったタグマネジャーではなく、サーバーコンテナを使ったタグマネージャーのことです。

サーバーコンテナを用意することで、以下のメリットがあります。

  • パフォーマンスの向上
  • セキュリティが強化
  • ITP対策になる

サーバーサイドで処理を行えるため、ウェブサイト上での測定タグが少なくなり、クライアント側で実行されるコードが減少するのでパフォーマンスがよくなります。また、サーバーサイドでデータ収集や配布が行われるため、データのセキュリティ保護が促進されます。(参考「Google Developersのドキュメント」) さらに、マーケティング観点からすると、最もメリットがあるのはITP対策になることです。3rdパーティークッキーが廃止されたり、CNAMEドメインでのクッキーも制限が行われる中、Aレコードでクッキーを長期保存できるサーバーコンテナのタグマネージャーにはマーケティング制度の向上という面で大きなメリットがあります。

サーバーサイドGTMの動作環境

サーバーサイドGTMではタグサーバーが動作する環境を構築する必要があります。Google Developers ドキュメントでは、GoogleAppEngine(以下GAE)での構築が紹介されています。開発環境ではGAEのStandard環境、本番環境ではGAEのFlexibleでの構築が推奨されています。一方、同ドキュメントではタグサーバーのdocker imageも紹介されており、これを利用したコンテナベースのタグサーバー環境を構築することが可能です。2021年12月には google-cloud-jpの記事 "サーバサイド Google Tag Manager 環境を Cloud Run で構築する" でCloudRun上でのサーバーサイドGTMの構築事例が紹介されました。

そこで、今回サーバーサイドGTMのサーバー構築環境の検証として、以下3つの負荷試験における性能比較を行うことにしました。

  • Google App Engine Flexible
  • Google App Engine Standard
  • Cloud Run

検証の目的

3つの環境において、エラー率、レイテンシ、コストにおいてどれが一番適しているかを比較していきます。具体的には以下の2つのシナリオのテストを行います。

1. 短期のトラフィック急増を想定した負荷試験

30分程度で秒間25,000まで増加するリクエストを各環境に実行し、エラー率とレイテンシを比較します。

2. 長期の一定ペースのリクエストに対すエラー率とコストの比較

1週間毎秒50リクエストを実行し続け、エラー率・レイテンシ・かかった費用を比較します。

シナリオの詳細

今回、負荷試験用にGKE(autopilot) + lucustで負荷試験用クラスタを用意しました (詳細: GKE(autopilot) + locust で数万qpsが可能な負荷テスト環境作ってみたメモ)。 このクラスタから各環境にリクエストを送っていきます。1ユーザーが1000リクエストを送信するシナリオを作成し、接続ユーザーを目的となるリクエスト数に応じて増加させていきます。本テストでは、サーバーコンテナにはタグを2つ設置しました。GA4へのタグと、自社サーバーにイベント情報を送信するオリジナルタグです。

1. 短期のトラフィック急増を想定した負荷試験 においては、worker podsを1000個用意し、1秒間に5ユーザーずつ増加させるシナリオとしました。大体30分程度かけて秒間25,000リクエストまで増えるような設定です。

2. 長期の一定ペースのリクエストに対するエラー率とコスト比較 においては、 worker podを1個用意し、接続ユーザー数は1の状態で1週間リクエストを送り続けます。大体秒間50リクエストとなるような設定です。

各環境のスペック

GAE Flexible
  • autoscale
    • instance: min3 ~ max1000
    • cpu_target_utilization: 0.6
  • リソース
    • vCPU: 1
    • memory: 0.5GB
    • disk_size: 10GB
GAE Standard
  • F1のautoscale
    • max_concurrent: 50
    • target_cpu_utilization: 0.6
    • instance: min1 ~ max10000
CloudRun
  • instance: min1 ~ max1000
  • containerConcurrency: 80
  • resouce_limits.cpu: 1000m
  • resource_limits.memory: 512Mi
  • LoadBalancingなし

結果

1. 短期のトラフィック急増を想定した負荷試験

GAE Flexibleではエラーが頻発

今回のシナリオではGAEのFlexible環境では急増するトラフィックを捌ききれずタイムアウトエラーが頻発しました。秒間300リクエストあたりでタイムアウトエラーの発生が始まり、秒間500リクエストを超えると90%tile(小さい方から数えて90%目の値)のレイテンシも1秒を越えるようになりました。リクエストの増加にGAE Flexibleのスケールアウトが間に合わなかった結果であると考えられます。この時点で弊社でのビジネス要求を満たさないため、サーバー構築環境の要件を満たさないと判断し、ここでGAE Flexibleの検証は終了としました。

CloudRunのFail数が少なく安定

エラー率の観点ではCloudRunが一番fail数が少なく安定していました。GAE Standardでは502のBad Gatewayエラーが定期的に発生するという問題がありました。

レイテンシは若干GAE Standardが早い

若干CloudRunのレイテンシが遅いという結果が見られました。特に、5,000rpsまでの初期のスケールの段階では、GAE Standardの方が90%ileの値は大幅に早かったです。後半にかけてはそこまで大きな差は見られませんでした。この辺りはCloudRunのチューニングで解決できるかもしれません。

2. 長期の一定ペースのリクエストに対するエラー率とコスト比較

※ GAE Flexibleが1の検証で十分な結果が得られなかったためGAE Flexibleは検証対象から外しています

CloudRunのエラー率が低く安定し、コストも安い

エラー率の観点では、CloudRunの方がエラー率は低くなりました。1でも見られたように、定期的に502のBad Gatewayエラーが発生していたためです。

また、コストの観点でも、CloudRunの方が安くなりました。

リクエストが安定している場合、CloudRunの方がレイテンシが早い

レイテンシの観点でも、今回の検証ではCloudRunの方が早かったです。スケールアウトが多い場合だとGAE Standardの方がレイテンシが速くなるのかもしれません。

GAE Flexibleの費用について

GAE Flexibleについては今回は検証としませんでしたが、Google Developers ドキュメントの サーバーサイドGTMのApp Engine設定ガイドに料金に関する情報が記載されているので補足しておきます。

本番環境では、サーバー 1 台あたり毎月約 40 ドルかかります。

~ 略 ~

サーバーが停止した場合のデータ損失リスクを軽減するため、少なくとも 3 台のサーバーを実行することをおすすめします。

~ 略 ~

3~6 台のサーバーを自動スケーリングすることで 1 秒あたり 50~200 件のリクエストを処理できます

ここから、秒間50 ~ 200のリクエストであれば、月額約$150 ~ $240 の費用となることが想定されます。

まとめ

サーバーサイドGTMのGAEとCloudRrunでの性能比較を行ってきました。

短期的なスパイクにおける負荷試験を行い、GAE Flexibleがエラーを頻発させることがわかりました。CloudRunとGAE Standardを比較した場合、CloudRunのエラー率が低く安定している一方、レイテンシの観点では若干GAE Standardが良いパフォーマンスとなりました。

長期の一定ペースのリクエストに対するエラー率とコスト比較では、CloudRunがエラー率の観点でも、レイテンシの観点でもパフォーマンスが優れていることがわかりました。

この性能比較の目的となった案件では非常に高いリクエストを捌くことが要求されているため、弊社の動作環境としてはCloudRunが最適なものであるという結論に至りました。CloudRunにおいてはCloudLoadBalancingを使えばマルチリージョン構成が可能であり、可用性が高いことも採用の後押しとなりました。しかし、ビジネス要求により最適な動作環境は異なるためその点はご了承ください。

今回はGAEとCloudRunでの比較でしたが、サーバーサイドGTM用のdocker imageが配布されているので、コンテナベースのサービスであれば、環境構築が可能です。今回は検証しませんでしたが、GKEやSpotVM を使った環境でも安価に環境を構築できる可能性があります。

最後に

Opt Technologies ではエンジニアを募集中です。カジュアル面談も可能ですので、下記リンク先よりお気軽にご応募ください。