Google PCD: コスト、ガバナンス、持続可能なアプリケーション運用 — 学習ガイド

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

こちらの一部です： Google Professional Cloud Developer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

コスト、ガバナンス、持続可能な運用は、現代の Google Cloud アプリケーション開発において不可分です。目標は、支出を可視化して制御し、経済的にスケールするサービスを設計し、環境を安全でコンプライアンスに準拠したクリーンな状態に保つガードレールを適用することです。これらを、パフォーマンスと信頼性のバランスを取りながら実現します。このセクションでは、実践的なメカニズム（課金とラベル、自動スケーリングの調整、割り当てとポリシー）、ワークロード固有の経済性（Cloud Run, GKE, データプラットフォーム）、そしてユーザーエクスペリエンスを損なうことなくアイドル状態の無駄と炭素への影響を削減する、持続可能性を意識した選択について詳述します。

コスト管理と可視性

請求アカウント、ラベル、コスト配分、予算、アラート、可視性
- 事業部門や資金源ごとに専用の請求アカウントを使用し、所有権を分離して、きめ細かな権限設定を可能にします。詳細な分析、予測、チャージバックのために、請求データを BigQuery にエクスポートします。
- ラベルは、コストを帰属させるためのリソース上のキーと値のペアです。ラベルキー（team, app, env, cost-center）を標準化し、組織のポリシーや CI チェックによって適用します。注意：ラベルは遡及的に適用されません。ラベル付けされていないリソースはレポートの精度を低下させます。
- 請求アカウントとプロジェクトのレベルで予算とアラートを使用します。しきい値（例：50, 90, 100 パーセント）と予測ベースのトリガーを組み合わせます。予算通知を Pub/Sub にルーティングし、Chat/Ops ツールに転送します。予算はアラートを出すだけで、強制力はありません。
- 共有プラットフォーム（例：GKE, BigQuery）では、名前空間ごとまたはジョブごとのラベルを使用し、それらをログや使用状況に添付して showback/chargeback を可能にします。

例：ラベルの追加 gcloud compute instances update web-01 –labels=team=payments,app=checkout,env=prod

割り当て、上限、消費量予測、キャパシティガバナンス
- 割り当てはサービスを保護し、コストの暴走を制限します。サービスの割り当てを定期的に見直し、プロジェクトごとに適切なサイズに調整し、ローンチ前に増加をリクエストします。予想されるピーク使用量を割り当てと比較するデプロイ前チェックを実装します。
- 請求データのエクスポートと製品利用のテレメトリ（Cloud Monitoring のメトリクス、ログベースのメトリクス）を使用して支出を予測します。シナリオ（予想される QPS、スキャンされるデータ量）をモデル化し、本番前環境で検証します。
- 障害モード：インシデントの最中や製品ローンチ時に割り当てに達すると、スロットリング（429/403）、部分的な停止、またはサイレントな機能低下につながります。過剰にプロビジョニングされた割り当ては、障害のあるジョブの爆発半径を増大させます。

例：Compute Engine の割り当てを一覧表示 gcloud services quota list
–service=compute.googleapis.com
–consumer=projects/$PROJECT_ID

弾力性とコンピューティングの経済性

ライトサイジング、オートスケーリング、リクエストベースの課金、確約利用、スポットキャパシティ
- Cloud MonitoringとRecommenderのインサイトを使用してvCPUとメモリをライトサイジングし、負荷テストで検証します。割り当てが過小だとレイテンシのスパイクやOOM/CPUスロットリングが発生し、過剰だと費用が無駄になります。
- オートスケーリングは、設備投資（capex）的な過剰プロビジョニングを、弾力的な運用コスト（opex）に変換します。GKEにはHPA/VPAを、サーバーレス（Cloud Run）にはリクエストごとのオートスケーリングを使用して、キャパシティを需要に合わせます。
- リクエストベースの課金（Cloud Run, Cloud Functions, GKE Autopilot）は、コストを使用量に連動させ、アイドル状態を削減します。リクエストごとのオーバーヘッドやコールドスタートに注意し、必要に応じて最小インスタンス数を調整します。
- 確約利用は、定常状態のベースライン向けです。Compute EngineにはリソースベースのCUDを、対象となるマネージド/サーバーレス製品にはフレキシブルCUDを使用します。変動の激しいワークロードを過剰にコミットしないでください。
- スポットキャパシティは、中断可能でフォールトトレラントなジョブのコンピューティングコストを削減します。常にグレースフルな終了ハンドラを実装し、冗長性と迅速なチェックポイント作成を維持します。短い通知でいつでも終了されることを想定してください。
Cloud Runの同時実行数と最小インスタンス数のトレードオフ
- 同時実行数は、1つのインスタンスが同時に処理できるリクエストの数を制御します。
  - 同時実行数を高くすると、使用率とコスト効率が向上しますが、コンテナ内でのヘッドオブラインブロッキングによりテールレイテンシが増加する可能性があります。
  - 同時実行数を1にするとリクエストが分離され（CPUバウンドまたはスレッドセーフでないコードに有用）、多くの場合インスタンス数とコストが増加します。
- 最小インスタンス数は、ベースラインの費用がかかる代わりに、コールドスタートを削減し、レイテンシを平滑化します。SLOで必要な場合にのみ使用し、需要パターンに基づいてその下限値を検証します。

例: Cloud Runの設定 (service.yaml) apiVersion: serving.knative.dev/v1 kind: Service metadata: name: img-api annotations: autoscaling.knative.dev/minScale: “2” spec: template: spec: containerConcurrency: 40 containers: - image: gcr.io/PROJECT/img-api resources: limits: memory: “512Mi”

GKEのリソースリクエストとリミット、Cluster Autoscalerの動作、アイドルリソースのクリーンアップ
- リクエストはスケジューリングを決定し、リミットはピーク使用量の上限を定めます。リクエストは観測された定常的な必要量に近い値を設定し、リミットは短期的なバーストを許容するためにそれより少し高い値を設定します。リミットが低すぎるとCPUスロットリングが、メモリリミットが低すぎるとOOMKilledが発生します。実態からかけ離れた高いリクエストは、キャパシティを遊休させ、スケジューリングを妨げます。
- Cluster Autoscalerは、スケジューリング不能なPod（集約されたリクエストの不足）に基づいてノードプールをスケールします。これはPodDisruptionBudgetsを尊重し、特定のPod（例: ローカルストレージを持つPodや制限の厳しいPDBを持つPod）を退去させることができないため、スケールダウンが妨げられることがあります。DaemonSetやノードのtaint/affinityも、スケーリング効率を妨げる可能性があります。
- Horizontal Pod Autoscalerは、CPU/メモリまたはカスタムメトリクスにスケーリングを連動させます。Vertical Pod Autoscalerは、時間経過とともにリクエストをライトサイジングします。オシレーション（振動）を避けるためにHPAとVPAを協調させ、必要に応じてVPAを推奨（recommend）モードまたは自動（auto）モードで使用します。
- アイドルリソースのクリーンアップ: 未使用のロードバランサ、永続ディスク、スナップショット、静的IPを削除します。Active Assistの推奨事項や自動化されたクリーンアップツールを使用して、アイドル状態のアセットを検出し、削除します。

例: リクエスト/リミットを設定したGKEデプロイメント apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 3 template: spec: containers: - name: api image: gcr.io/PROJECT/api:stable resources: requests: cpu: “500m” memory: “512Mi” limits: cpu: “1” memory: “768Mi”

データ、分析、ネットワークのコストガバナンス

ストレージクラス、ライフサイクル制御、データベースのスケーリング、ネットワークエグレスの設計
- アクセスパターンに応じて Cloud Storage のストレージクラスを選択: ホットデータには Standard、よりコールドなデータには Nearline、Coldline、または Archive。コールドな階層では、取得コストと早期削除の最低料金に注意してください。
- ライフサイクルルールは、移行と削除を自動化します。マルチリージョンのレイテンシが許容できる場合は、回復性のためにデュアルリージョンを使用します。エグレスとレイテンシを削減するために、コンピューティングとデータを同じ場所に配置します。
- データベースのスケーリング:
  - Cloud SQL: 垂直スケーリングは慎重に行います。読み取りにはリードレプリカを使用し、ストレージは自動スケーリングを利用します。クエリプランと接続プーリングを使用します。書き込みスループットが高い場合は、シャーディングまたは Spanner/Bigtable への移行が必要になる可能性があります。
  - Spanner: ノードを追加することによる水平スケーリング。可用性とグローバルな読み取りのためのマルチリージョン構成。負荷を分散させるためのスキーマとキーを設計します。
  - Bigtable: ホットスポットを回避するための行キーを設計します。クラスタノードとストレージを個別にスケーリングします。
- ネットワークエグレス: リージョン間のトラフィックを回避します。可能な限り、クライアントとデータを同じリージョンに配置します。インターネット規模のコンテンツには Cloud CDN を、ハイブリッド接続には Cloud Interconnect/Peering を、Google API にプライベートにアクセスするには Private Google Access または Private Service Connect を使用します。不要なゾーン間/リージョン間のトラフィックは、コストとレイテンシを増加させます。

例: Cloud Storage のライフサイクル

undefined

BigQuery のクエリ制御、データ保持、分析利用コスト
- スキャンされるバイト数を制御: 常にパーティション/クラスタキーでフィルタリングします。SELECT * を避けます。繰り返し実行されるクエリにはマテリアライズドビューと結果のキャッシュを使用します。可能な場合は概算集計を使用します。
- スキャンされる最大バイト数でスキャンコストに上限を設定し、緊急でない作業にはジョブの優先度をバッチに設定して、干渉とコストを削減します。
- 料金モデルの選択: 散発的なワークロードにはオンデマンド。安定した大容量のワークロードにはコミットメント付きの予約 (スロット)。チームを分離するために、予約と割り当てを分けます。
- データ保持: ガバナンスのためにデータセット/テーブルとパーティションの有効期限を設定します。アーカイブのために階層型ストレージを実装するか、エクスポートします。
- 障害モード: パーティション化されていない大規模テーブルはコストを急増させます。パーティションフィルタのないクエリはテーブル全体をスキャンします。過度に積極的な有効期限設定は必要なデータを削除してしまいます。過度なスロットの競合は SLA を低下させます。

例: クエリコストに上限を設定

undefined

組織ガバナンスと環境ハイジーン

組織のポリシー、リソースの命名、タグ付け、プロジェクトの分離
- 組織のポリシーを使用してガードレールを適用する：リソースのロケーション制限、外部IPの不許可、CMEKの要求、許可されたサービスの制限、VPCピアリングの制御、必要に応じたOS Loginの強制。階層構造を通じて例外をモデル化し、組織またはフォルダレベルで適用する。
- リソースの命名を標準化し、環境、プロジェクト、アプリ、リージョンをエンコードする（例：app-env-region-suffix）。CIチェックやPolicy as Codeを通じて強制する。
- 区別：
  - ラベル：課金/運用の属性付け。
  - タグ（ファーストクラス）：リソースにアタッチし、IAM Conditionsや組織のポリシーのターゲティングで使用する。
  - ネットワークタグ：Compute Engineのファイアウォールルール用。
- プロジェクトの分離：環境（本番、ステージング、開発）と機密性の高いワークロードを分離する。共有VPCを使用してネットワーキングを一元化し、最小権限のサービスプロジェクトを利用する。これにより、影響範囲が縮小され、IAMが簡素化される。
環境のライフサイクル、エフェメラルなテスト環境、クリーンアップの自動化
- IaC (Terraform) を介して環境をプロビジョニングし、PRごとのエフェメラルな環境を有効にする。TTLラベルを設定し、マージ後または非アクティブになった後に自動的に破棄されるようにする。
- Cloud SchedulerとCloud RunジョブまたはFunctionsを使用して、ラベル/経過時間に基づいて古いリソースを探索して削除する。Cloud Asset Inventoryを介してインベントリをエクスポートし、監査を推進する。
- 失敗モード：放棄されたサンドボックスはコストを発生させる。TTLやラベルがないとクリーンアップが妨げられる。過度に積極的なクリーンアップはアクティブなリソースを削除する可能性があるため、許可リストと猶予期間を追加する。
サステナビリティを意識したアーキテクチャと、コスト、パフォーマンス、信頼性のバランス
- マネージドサービスやサーバーレスサービスを優先し、アイドリングを削減してリソース使用率を向上させる。
- コンプライアンス要件を満たす範囲で、炭素強度の低いリージョンを選択する。可能であれば、カーボンフリーエネルギーの供給が多い時間帯にバッチワークロードをスケジュールする。
- データグラビティとキャッシングを最適化し、ネットワークのエネルギー消費を削減する。自動スケーリングと同時実行性を調整して、過小利用を減らす。プロファイリングを使用して、過剰なコンピューティングやI/Oを引き起こす無駄なコードパスを削除する。
- バランス：SLOで要求される場合にのみ、最小インスタンスまたはレプリカを追加する。テールレイテンシと同時実行性、冗長性とSpot VMの使用を評価する。SLOベースの負荷テストとコスト/パフォーマンスモデリングで検証する。

実践的な問題シナリオ

NimbusMarketはeコマース企業で、フラッシュセール中の突発的なトラフィックと、増大する分析費用に悩んでいます。顧客向けAPIはCloud Runで、バックグラウンドワーカーはGKEで、製品分析はBigQueryで実行しています。経営陣は、99.9%のAPI SLOを損なうことなく、25%のコスト削減を要求しています。

アプローチ：

コストの可視化とガードレールの確立
- 請求先アカウントに対して、60%、90%、100%での予測アラート付きの予算を作成し、Pub/Sub通知をオンコール担当者にルーティングする。
- ラベル（team, app, env, cost-center）を標準化し、Terraformプランに対するCIで強制する。リソースのロケーションを承認済みリージョンに制限する組織のポリシーを追加する。目的：予算は早期警告を提供し、ラベルはチームごとのレポートを可能にする。ポリシーは、意図しない高額な下り（外向き）トラフィック料金のリージョン利用を防ぎ、コンプライアンスを向上させる。
経済的なスケーリングのためにCloud Runを調整する
- プロファイリングで平均CPU時間が30msでノンブロッキングI/Oであることを確認した後、ステートレスAPIのcontainerConcurrencyを40に設定する。通常時間帯のコールドスタートを避けるためにminScale=2を設定し、夜間はminScaleを0に下げるスケジュールポリシーを構成する。目的：同時実行性を高めることで使用率が向上し、インスタンス数が削減される。最小限の常駐インスタンスは、オフピーク時に削除される限定的なベースラインコストでSLOを維持する。
GKEワークロードのライトサイジングと効率的なオートスケーリングの有効化
- プロファイリングに基づき、ワーカーポッドにrequestsとして500m CPU/512Mi、limitsとして1 CPU/768Miを適用する。キューの深さと処理レイテンシに基づいてHPAを有効にし、VPAを推奨モードで実行してrequestsを繰り返し調整する。PodDisruptionBudgetsがスケールダウンを許可することを確認する。ノードプールで複数の小規模ノードを使用してCluster Autoscalerを有効にする。目的：正確なrequestsは効果的なスケジューリングとオートスケーリングを促進する。HPAはキャパシティをバックログに合わせ、VPAはドリフトを防ぐ。複数の小規模ノードは遊休キャパシティを減らし、スケールイベントを高速化する。
フォールトトレラントなバッチ処理にSpotキャパシティを採用する
- 画像のサムネイル生成を、チェックポイント処理を備えたSpot VMを利用したノードプールに移行する。preStopフックを実装して処理中の作業をフラッシュし、中断されたジョブを再スケジュールするコントローラーを実装する。目的：サムネイル生成はべき等であり、時間に柔軟なため、ユーザーエクスペリエンスへの影響を最小限に抑えながらSpot VMによるコスト削減を実現するのに理想的である。
分析のスキャンコストを削減し、ワークロードを分離する
- イベントテーブルをevent_dateとcustomer_idでパーティション分割およびクラスタリングする。生のイベントには180日後にテーブルの有効期限を追加する。マーケティングアナリストをスロット上限付きの別のBigQuery予約に割り当てる。スケジュールされたクエリでmaximum_bytes_billedを強制する。夜間レポートをバッチ優先度に変換する。目的：パーティション分割とクラスタリングはクエリごとのバイト数を抑制する。有効期限はガバナンスを強制する。予約はノイジーネイバーを分離する。バッチ処理は緊急でないジョブの競合とコストを削減する。
ストレージのライフサイクルと下り（外向き）トラフィックを最適化する
- 製品画像を顧客に近いデュアルリージョンに保存する。30日間アクセスされなかった画像はライフサイクルルールを介してColdlineに移動し、Cloud CDNを介して配信する。Cloud RunサービスとCloud SQLを同じリージョンに配置し、Google APIへのPrivate Service Connectを有効にする。目的：CDNは下り（外向き）トラフィックとレイテンシを削減する。ライフサイクルはコールドコンテンツをより安価なストレージに移行する。同じリージョンへの配置は下り（外向き）トラフィックを最小化し、パフォーマンスを向上させる。
クリーンアップの自動化とサステナビリティチェックを実装する
- エフェメラルな環境にttl-hoursタグを付け、有効期限が切れたリソースを削除する夜間Cloud Runジョブを実行する。Carbon Footprintレポートを使用して、バッチジョブをより低炭素なリージョンに移動し、炭素排出量のオフピーク時間帯にスケジュールすることを検討する。目的：自動クリーンアップはコストの無駄遣いを防ぐ。炭素を意識したスケジューリングは、SLOに影響を与えることなく環境への影響を低減する。
SLOを意識した負荷テストとコストモデルで検証する
- フラッシュセールのパターンを再現する負荷テストを実行し、p95レイテンシとエラーバジェットを検証する。課金エクスポートのダッシュボードを使用して、変更前後のコストを比較する。目的：チューニングが信頼性目標を満たし、目標に沿った測定可能なコスト削減を実現することを確認する。