インフラストラクチャの要件と費用のプランニング
サーバーサイド タグ設定のエンドポイントを自動プロビジョニングで構成した際、タグ マネージャーは以下を行いました。
- Google Cloud のプロジェクトを作成
- Cloud Run インフラストラクチャで稼働するサーバーをセットアップ
Cloud Run のデプロイ設定は、サーバー コンテナのテストとセットアップを想定したチョイスです。構成をテストする程度であれば、無料枠の使用量上限を超えることはない見込みです。ただし、ウェブサイトからのライブ トラフィックを扱うためには、インフラストラクチャをアップグレードする必要があります。
環境をアップグレードする段階になったら、いくつか検討しておくべきことがあります。
- 安定性: 予定しているサーバーサイド タグ設定環境の運用には、どの程度の演算能力が必要でしょうか？トラフィックは年間を通してどの程度変動しますか？（繁忙期と閑散期の差、高ボリューム キャンペーン実施中の影響など）
- コスト: 環境の運用予算はどの程度確保されていますか？全トラフィックの負荷を扱うには予算不足の場合は、トラフィックのスロットリングを行い、一部のイベントだけをサーバー コンテナで処理することも検討しましょう。
- メンテナンス: Cloud Run の運用には、Google Cloud Platform に関する一定の知識が必要です。社内の経験で賄えるでしょうか、それとも新たに人員を雇う必要があるでしょうか？
- 組織のポリシー: すでに Google Cloud Platform のアカウント（または「組織」）をお持ちの企業では、サーバーサイド環境へのアップグレード前に確認するべきポリシーが設けられていることもあります。アップグレードの計画を社内の IT 担当や DevOps 担当の方と確認しておくのがいいでしょう。
- ドメイン名サービス（DNS）: トラッキング体制は、ウェブサイトのファーストパーティ コンテキストに移行させるのがおすすめです。社内の IT 担当や DevOps 担当の方と協力して、DNS ゾーンのアップデートを行いましょう。
次は、必要なインスタンス数の見積もりについて解説します。すでにインフラストラクチャの設計に熟達されている方は、スキップしてアップグレード作業の説明にお進みください。
費用と見積もり - Cloud Billing
Cloud Run でのセットアップでサーバーサイド タグ設定を行う場合のコスト構造は、必要な演算能力とストレージ、発生するネットワーク トラフィックの量に応じて決まります。
Google Cloud の料金計算ツールを使用して月額料金を見積もることは可能ですが、計算しにくい場合もあります。一般的なウェブサイトはトラフィックに変動があり、上記 3 種類のコストがいずれも影響を受けるためです。
Cloud Run デプロイにかかる費用をおおまかに見積もるには、次の要素を検討します。
| 費用タイプ | 料金への影響 | 備考 |
|---|---|---|
| 演算（インスタンス数） | 高い – 固定 | 最小限の費用を求めるには、指定した最小インスタンス数にサーバー 1 台あたりの費用を掛けます。サーバーのスケーリングを想定し、より現実的な価格帯を求めるなら、指定した最大インスタンス数にサーバー 1 台あたりの費用を掛けます。料金は 1 インスタンスあたり月間 50 米ドル程度です。 |
| ネットワーク（外向きトラフィック） | 中程度 – 変動あり | サーバー コンテナから外に向けて送信されるネットワーク データはすべて外向きトラフィックとして計算されます。これには、サーバー コンテナのクライアントやタグが送信するリクエストだけでなく、ユーザーのブラウザに返す HTTP レスポンスも含まれます。サーバーサイド タグ設定のエンドポイントが大型のリソースや JavaScript ライブラリを配信する場合、ネットワークの外向きトラフィックがコスト要因になることがあります。 |
| ストレージ（ログ） | 場合によって異なる | 受信したリクエストの数が増え、Cloud Logging の無料枠を超えた後は、ログ保存が大きなコストとなることがあります。ロギングの費用を抑えるには、流入するリクエストをフィルタで除外することや、ログエントリのサンプルだけを保存することが考えられます。 |
この他に、Google Cloud Platform のご請求レポートで費用の推移を注視しつつ適切な予算を設定し、組織の DevOps チームと協力して、サーバーサイド タグ設定環境の最適なスケールアップ方法を検討するのも効果的です。
インフラストラクチャ設計時に検討するべきポイント
デプロイメントをさらにしっかりコントロールしたい場合は、下のチェックリストの内容を把握しておきましょう。Cloud Run ではサーバーの運用やメンテナンスは最大限シンプルになっていますが、サーバーがどのような技術的コンテキストで機能しているのか理解することにより、的確な意思決定がしやすくなります。
| トピック | 説明 | 考慮事項 |
|---|---|---|
| コールドブート所要時間 | トラフィックの急増を受けて自動的に新しいインスタンスが作成される際は、Cloud Run がタグ設定環境の起動とセットアップを行う必要があります。 これにはある程度時間がかかることもあり、インフラストラクチャが適応を終えるまではレイテンシが増加する可能性があります。 |
トラフィックの定期的な変動に対応できるよう、最小インスタンス数を十分な水準に設定しましょう。 トラフィックが増える時期に入ることがわかっている場合は、Cloud Run のデプロイ設定を更新して、最小インスタンス数の設定を引き上げておきます。 |
| Blue/Green デプロイ | Docker イメージをアップデートする際は、Cloud Run サーバーを再デプロイする必要があります。Cloud Run がサーバーの新バージョンを構成している間は、トラフィックは旧バージョンのサーバーへ流れます（ステータス: Blue）。新バージョンの準備ができた時点で、トラフィックの誘導先はそちらへ切り替えられ（ステータス: Green）、旧バージョンは停止されます。 | アップデート中、アプリケーションの複数のバージョンがデプロイされることがありますが、これは正常な動作です。新バージョンのセットアップとトラフィックの切り替えは自動的に行われます。 |
| ヘルスチェック | Cloud Run のログを確認すると、/healthz への定期的なリクエストが見つかることがあります。これは、デプロイメントが自動生成するヘルスチェックによるものです。ヘルスチェック用のリクエストが失敗した場合、デプロイメントの状態に問題があるという意味であり、自動的に環境が再デプロイされます。 |
/healthz へのリクエストはサイズとしてはごく小さく、ログストレージの占有量もわずかですが、重要なログエントリだけを参照しやすいよう Cloud Logging のログから除外したほうが便利なこともあります。 |
| カスタム ドメインのサポート | カスタム ドメインのサポートは、タグ設定の構成をファーストパーティ コンテキストで稼働させるために必要です。 Google Cloud Run では、統合により、グローバル外部アプリケーション ロードバランサでカスタム ドメイン マッピングをすばやく設定できます。 |
Google Cloud Platform を使用している場合、サーバーサイド タグ設定環境に複数のカスタム ドメインをデプロイすることができます。 Cloud Run でデプロイする必要がある場合、サービスをデプロイするリージョンによって条件が異なります。ドメイン マッピングの現在の制限事項をご確認ください。 費用と複雑さは増すものの、多くの場合はロードバランサを使用するのが最善の方法になります。 |
| Cloud リージョン | 自動プロビジョニングによるサーバー コンテナのセットアップでは、リージョン「us-central1」に Cloud Run アプリケーションが作成されます。リージョンを変更するには、Cloud Run ユーザー インターフェースで新しいリージョンを設定して新しいサービスを作成し、既存のサービスを削除する必要があります。 | サーバーサイド タグ設定環境を複数のリージョンで稼働させたい場合は、Google Cloud Run で複数のサービスをセットアップしたうえで、トラフィックはすべてロードバランサを経由させ、ユーザーの所在地域に応じて各サービスに振り分けられるようにします。 |
リソース:
まとめ
この章では、サーバーの最適なセットアップ方法を考えるうえで役立つ情報をご紹介しました。結論に至らなかった場合は、社内の IT 部門の方にご相談いただくか、タグ マネージャーのパートナー企業にご相談ください。
サーバーをアップグレードする準備は万全ですか？それでは次の章へ進みましょう。