Google PCA: コスト、パフォーマンス、持続可能なクラウド設計 — 学習ガイド

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

概要

コスト、パフォーマンス、そして持続可能なクラウド設計は、相互に最適化される分野です。Google Cloud 上で効率的なアーキテクチャを構築するには、財務的な可観測性、需要に追随する弾力的なキャパシティ、厳格なデータライフサイクル管理、情報に基づいたネットワークの配置とキャッシュ、そして継続的な測定が必要です。このセクションでは、信頼性、セキュリティ、パフォーマンスを犠牲にすることなく無駄を削減する設計および運用パターンを説明し、コストのかかる不測の事態を避けるための障害モードとトレードオフに焦点を当てます。

コストアーキテクチャと財務上のアカウンタビリティ

プラットフォームのベースラインの一部として、財務管理を確立します。

請求の分析と割り当て
- 請求データを BigQuery にエクスポートし、プロジェクト、サービス、SKU、ラベルごとにクエリ可能でほぼリアルタイムの支出分析を可能にします。スケーラブルなクエリのために日次でパーティション分割し、財務およびエンジニアリングのステークホルダー向けにデータセットのアクセス制御を設定します。
- アラートのしきい値を設定した予算を使用して、支出のずれを防ぎます。予算アラートを Pub/Sub にルーティングし、レスポンスを自動化します（例：重要でないワークロードの一時停止）。アラートはトランザクショナルではなく、レポートに遅延が生じる可能性があることに注意してください。暴走するジョブに対する唯一の制御として依存してはいけません。
ラベル、タグ、およびコストの帰属
- 組織全体でラベル（cost_center, env, owner, app）を標準化し、デプロイテンプレートや policy-as-code を用いてプロビジョニング時にそれらを強制します。
- チャージバック/ショーバックモデルを反映させるために、階層的なタグとフォルダ/プロジェクト構造を使用することを推奨します。正確な割り当てを実現するために、ラベル（リソースレベル）とタグ（ポリシーおよび請求スコープ）の両方を使用します。
予算のガードレールと異常検出
- プロジェクトごと、ポートフォリオごとに予算を設定し、複数のしきい値（例：50、80、100パーセント）と「予測」アラートを設定して、プロアクティブなアクションを可能にします。
- Recommender の分析情報（アイドル状態の VM、アタッチされていないディスク、IP、未使用のコミットメント）を使用して、継続的に無駄を削減します。
実践例
- 作成時にラベルを適用する：

undefined

CI/CD チェックを通じてコンプライアンスを徹底するため、請求エクスポートに対してラベル未適用の支出をクエリします。

一般的な障害モードとトレードオフ：

ラベルに一貫性がないとコスト割り当てが破綻します。組織のポリシーとパイプラインでの検証によって強制します。
チームごとの予算がない一元的な請求は、アカウンタビリティを妨げます。チームまたはプロダクトレベルで予算を作成します。
予算アラートの遅延は、急激なスパイクが予算を超過する可能性があることを意味します。可能な限り上限や割り当てを階層的に設定します。

コンピューティングの効率とパフォーマンス

ワークロードのプロファイルに合わせてリソースを調整し、弾力性を自動化し、安定したベースロードに対しては予約または割引を利用します。

ライトサイジングとカスタムマシンタイプ
- CPU、メモリ、ディスク IOPS、ネットワーク使用率を継続的に分析してライトサイジングを行います。カスタムマシンタイプを使用して、vCPU とメモリをアプリの実際のニーズに適合させ、アイドル状態のメモリに対する支払いを回避します。
- ヘッドルームに注意してください。持続的な CPU 使用率を 60～75 パーセントに目標設定し、GC やスパイクに対応できる十分なメモリヘッドルームを確保します。過度に積極的なライトサイジングは、スロットリングや OOM (Out of Memory) のリスクを高めます。
オートスケーリングとライフサイクルスケジューリング
- 関連するシグナル（CPU、ロードバランサーのキャパシティ、またはカスタムキューの深さ）に基づいて、マネージドインスタンスグループのオートスケーリングを使用します。ウォームアップ期間とスケールイン制御を設定して、スラッシングを防ぎます。
- 24時間365日稼働ではない環境では、VM、GKE ノードプール、または Cloud Run の最小インスタンスの開始/停止をスケジュールして、アイドル時の支出を回避します。簡単な第一歩として、Cloud Scheduler を使用して Cloud Run ジョブをトリガーし、開発インスタンスを毎晩停止させることが挙げられます。
割引オプション
- 確約利用割引：コミットメントの対象となる定常的な使用量に対して、1～3年のコミットメントを行います。コミットメントのサイズは、過去の使用量とビジネス予測とのバランスを取ります。過剰なコミットメントは無駄なコストになります。
- Spot VM：フォールトトレラントなバッチワークロードや分散ワークロードに最適です。いつでもプリエンプト（中断）される可能性があるため、チェックポイント処理と、オンデマンドへのフォールバックを備えた複数のインスタンスグループを実装します。
  - 例：

undefined

キャパシティ予約：重要なフリートのためにゾーンまたはリージョンのキャパシティを予約し、リージョンでのリソース不足時のスケールアップ失敗を軽減します。
- 例：

undefined

使用率メトリクスとパフォーマンスチューニング
- Cloud Monitoring、Profiler、Trace を使用して計測します。p50/p95 レイテンシ、CPU スティール、GC 時間、キューのバックログを測定します。スケールアウトする前に、ホットなコードパスを最適化します。
- パフォーマンスに敏感なワークロードは、適切な CPU プラットフォームを備えたリージョンやゾーンに固定し、必要に応じて高スループットの永続ディスクや Hyperdisk の使用を検討します。

障害モードとトレードオフ：

無制限のオートスケーリングは、割り当てやコスト目標を超える可能性があります。事前に割り当てを引き上げ、最大レプリカ数を設定し、既知のピークに対しては予測オートスケーリングを使用します。
Spot VM は、フリートの一部でチャーン（頻繁な入れ替え）を引き起こす可能性があります。ゾーンを多様化し、正常な終了処理のフックを実装します。
CUD の過剰なコミットメントや十分に活用されていない予約は、サンクコスト（埋没費用）を生み出します。コミットメントは四半期ごとに見直します。

ストレージ、データベース、分析のコストパフォーマンス

アクセスパターン、保持期間、パフォーマンスSLOを反映したストレージクラスとデータベース容量モデルを選択します。

ストレージクラスとライフサイクルポリシー
- ホットデータにはStandard、月次アクセスにはNearline、四半期ごとのアクセスにはColdline、長期の稀なアクセスにはArchiveを使用します。下り（外向き）トラフィックを避けるため、データとコンピューティングは同じリージョンに保持します。
- ライフサイクル管理を適用して、オブジェクトを自動的に移行または削除します。最小ストレージ期間と取得料金に注意してください。時期尚早なクラス移行は、節約額よりもコストが高くなる可能性があります。
- ライフサイクルポリシーの例（90日より古いものを削除）:

undefined

- gsutil lifecycle set lifecycle.json gs://my-backups

データ転送とアーカイブ
- リージョン間のアクセスは、しばしば下り（外向き）トラフィック料金を発生させます。プロデューサーとコンシューマーを同じ場所に配置してください。安全でコストを意識したGoogle APIへのアクセスには、Private Google AccessとVPC-SCを使用します。長期アーカイブの場合、高額な取得料金を防ぐために、Archiveからの頻繁な取得は避けてください。
データベースのサイジングとパフォーマンス
- リレーショナル：メモリに常駐するワーキングセット、IOPS、リードレプリカに合わせてサイジングします。ストレージの自動増量を有効にし、レプリケーションラグを監視します。ラグがRPO/RTOを脅かす場合は、垂直スケーリング（スケールアップ）または水平スケーリング（シャーディング）を行います。
- NoSQL/時系列：高スループット、低レイテンシの取り込みにはBigtableを使用し、ホットスポットを避けるために適切な行キーを設計します。
BigQueryのコスト管理と容量モデル
- オンデマンド（スキャンされたTBあたり）：迅速に開始できますが、コストが急増するリスクがあります。容量ベースの予約：予測可能な支出、同時実行性とスループットの制御が可能です。Flexコミットメントは短期的な急増を吸収します。
- パーティショニングとクラスタリングでクエリを最適化します。フルテーブルスキャンを防ぐためにパーティションフィルタを必須にします：
  - bq update –require_partition_filter=true myds.mytable
- ジョブあたりの最大課金バイト数を設定して支出を制限します：
  - bq query –use_legacy_sql=false –maximum_bytes_billed=100000000000 ‘SELECT …’
- マテリアライズドビュー、結果キャッシュ、近似集計を使用し、本番環境でのSELECT *の使用を避けます。ストレージとコンピューティングは同じリージョンに保持します。

障害モードとトレードオフ：

ホットオブジェクトをColdline/Archiveに移動すると、取得コストと早期削除料金が発生します。
BigQueryのオンデマンドを制御なしで使用すると、フィルタなしのスキャンによってコストが暴走する可能性があります。最大課金バイト数とパーティションフィルタを強制してください。
データベースを過剰にシャーディングすると運用が複雑になります。分割する前にベンチマークを実施してください。

ネットワーク、スループット、割り当て、およびサステナブルな設計

データの移動と同時実行性の設計は、コストとパフォーマンスに大きな影響を与えます。サステナビリティの選択は、配置とスケジューリングをさらに洗練させます。

ネットワーク下り（egress）、リージョン間トラフィック、CDN、およびキャッシュ
- リージョン間のホップを最小限に抑え、ユーザーとの近接性やコンプライアンス要件がある場合にのみデータを複製します。Cloud CDN を使用して、静的コンテンツとキャッシュ可能な動的コンテンツをオフロードします。高いヒット率を実現するために、キャッシュキー、TTL、署名付き URL を調整します。
- クライアントの近く（CDN）、VPC のエッジ（プロキシキャッシュ）、およびサービス内（Memorystore のようなインメモリキャッシュ）でキャッシュします。古いデータ（stale data）や無効化の嵐（invalidation storm）に注意し、明示的な cache-control ヘッダーを定義します。
パフォーマンス測定、負荷テスト、およびスケーリング
- SLO を確立し、Cloud Monitoring、Uptime checks、Cloud Trace、Profiler を使用して測定します。p95/p99 レイテンシと飽和シグナルを追跡します。
- 現実的なデータとシンクタイムを使用して負荷テストを実施します。グローバルなレート制限のトリガーを避けるためにテストを段階的に行い、一時的な割り当て（クォータ）の引き上げをリクエストします。
- 水平レプリカ、シャーディングされたキュー、パーティション化されたトピック、およびバックログメトリクスに基づくオートスケーラーを使用してスループットをスケールします。可能な限り非同期パイプラインを優先します。
割り当て（クォータ）、同時実行性、レート制限、およびバックプレッシャー
- サービスごとの割り当てをリージョン別に棚卸しします。429/5xx レスポンスに対しては、クライアント側でジッター付き指数バックオフを強制します。依存関係を保護するために、アドミッションコントロールとキューベースのバックプレッシャーを実装します。
- Pub/Sub のフロー制御（最大未処理メッセージ数/バイト数）、バッチ処理、並列処理を調整します。Cloud Run と GKE では、CPU とメモリに合わせて同時実行性を適切なサイズに調整し、テールレイテンシの増大を防ぎます。
サステナビリティを意識した設計
- 高い使用率を持つサーバーレスおよびマネージドサービスを優先します。レイテンシとコンプライアンスが許す場合は、カーボンフリーエネルギーの割合が高いリージョンを選択します。
- 低炭素の時間帯にバッチジョブや柔軟なジョブをスケジュールします。Carbon Footprint レポートを使用して影響を追跡します。
- エネルギー効率の高いマシンタイプを使用し、互換性がある場合は ARM ベースのコンピューティングを検討して、ワットあたりのパフォーマンスを向上させます。
信頼性、セキュリティ、パフォーマンス、コストのバランスをとるガバナンス
- アーキテクチャのガードレールを定義します：必須ラベル、予算アラート、組織のポリシー（例：外部 IP の制限）、SLO/エラーバジェット、コスト SLO。
- エンジニアリング、セキュリティ、財務の各部門と定期的にコストパフォーマンスレビューを実施します。Recommender とカスタムダッシュボードを統合し、修正ランブックを構築します。
- トレードオフを明示的にバランスさせます：マルチリージョン対リージョン（耐久性とレイテンシ対コストと下り（egress））、暗号化およびインスペクションレイヤー（セキュリティ対 CPU とレイテンシ）、積極的なオートスケーリング（パフォーマンス対割り当てと支出リスク）。

典型的な障害モードとトレードオフ：

単一リージョンのデータセットに対するクロスリージョン分析が、持続的な下り（egress）を発生させる。コンピューティングを複製または再配置する。
CDN の設定ミスが低いヒット率をもたらす。キャッシュヒットとオリジンの下り（egress）を監視して、コスト削減効果を検証する。
部分的な障害時にバックプレッシャーがないと、障害が増幅される。サーキットブレーカーを実装し、負荷を適切に軽減する (shed load)。

実践的な問題シナリオ

オンライン教育企業である Acme Learn は、ライブイベント中に予測不能な夜間のスパイクを経験しています。クロスリージョンの BigQuery クエリ、オートスケーリングの急増、静的アセットからの下り（egress）により、コストが急激に上昇しています。経営陣はまた、ユーザーエクスペリエンスを低下させることなく、二酸化炭素排出量の影響を削減したいと考えています。

アプローチ：

課金情報の可視性を統合し、コスト配分を徹底する
- デプロイメントテンプレートで標準化されたラベルとタグを使用して、BigQuery への課金データのエクスポートと、プロダクト、環境、リージョンごとにセグメント化されたダッシュボードを作成します。
- 根拠：ほぼリアルタイムの可視性により、支出を担当チームに結びつけ、予算に対する説明責任を可能にします。ラベルは、詳細なチャージバックと異常検知を強化します。
分析アーキテクチャを再設計し、コンピューティングとストレージを同じ場所に配置する
- イベント分析データセットとスケジュールされたクエリを、ストリームプロセッサと同じリージョンに移動します。BigQuery については、高トラフィックのチームをオンデマンドから、ピーク時の同時実行性に合わせてサイズ設定され、小さな柔軟なバッファを持つキャパシティ予約に切り替えます。
- 根拠：同じ場所への配置により、リージョン間の下り（egress）が排除されます。キャパシティベースの BigQuery は、パフォーマンスを維持しながら、負荷時のコストを安定させます。
エッジキャッシュでコンテンツ配信を最適化する
- 静的および半動的なレッスンアセットの前に Cloud CDN を配置し、プレミアムコンテンツには明示的な cache-control ヘッダーと署名付き URL を設定します。コンテンツの変更頻度に基づいて TTL を調整します。
- 根拠：高いキャッシュヒット率により、トラフィックがオリジンからエッジにシフトし、ピーク時のレイテンシを改善しながら、下り（egress）とオリジンのコンピューティングコストを削減します。
ライブイベントのためにオートスケーリングと予約を強化する
- API 層にリージョンマネージドインスタンスグループを追加し、CPU とリクエストのバックログの両方をオートスケーラーのターゲットにします。イベント中のバースト用のヘッドルームを保証するために、小さなゾーンキャパシティ予約を作成します。スケジュールされたセッションの前に予測オートスケーリングを有効にします。
- 根拠：デュアルシグナルのオートスケーリングは、使用率と需要の両方に反応します。一方、予約と予測的なウォームアップにより、コールドスタートレイテンシとキャパシティ不足を回避します。
コンピューティングの組み合わせを適用する：ベースロードはコミットメント、バーストはスポットで対応
- ベースラインの API およびデータ処理ワークロードに対して 1 年間のコミットメントを購入します。バッチのトランスコードおよびエンリッチメントジョブを、チェックポイント処理とマルチゾーンインスタンスグループを備えた Spot VM 上で構成します。
- 根拠：コミットメントは定常状態のコストを削減します。Spot VM は、ユーザートラフィックを危険にさらすことなく、中断可能なワークロードに対して低コストの弾力性を提供します。
ストレージのライフサイクルとリージョン配置を確立する
- ホットなコースメタデータとサムネイルは、サービングするコンピューティングに近いリージョンの Standard ストレージに保持します。ログと生のクリックストリームは 30 日後に Nearline に移行し、180 日後に削除します。コンプライアンス用のアーカイブには、文書化された取得 SLA を持つ Archive を使用します。
- 根拠：ストレージクラスをアクセスパターンに合わせることで、保持ポリシーを遵守しながら継続的なコストを削減します。
BigQuery の使用にガードレールを設ける
- 大規模なテーブルにはパーティションフィルタを必須とし、プロジェクトレベルのジョブのデフォルトとして最大課金バイト数を設定します。一般的な集計やパーティション分割された取り込みパターンのために、マテリアライズドビューを導入します。
- 根拠：偶発的なフルスキャンを防ぎ、支出を安定させ、頻繁なクエリを高速化します。
バックプレッシャーと割り当てを用いてスループットを設計する
- レート制限されたワークフローのために Cloud Tasks を統合し、フロー制御を持つ Pub/Sub サブスクライバーを構成します。サードパーティ API に対してジッター付き指数バックオフを実装し、Cloud Run でサービスごとの同時実行数の上限を設定します。
- 根拠：需要を制御して割り当てを遵守し、急増時に依存関係を保護し、連鎖的な障害を回避します。
サステナビリティを運用に組み込む
- 可能な場合はサーバーレスを優先し、分析にはカーボンフリーエネルギーの割合が高いリージョンを選択し、緊急でないバッチジョブは低炭素の時間帯にスケジュールします。Carbon Footprint で排出量を追跡し、四半期レビューに含めます。
- 根拠：ユーザー向けのトレードオフを最小限に抑えながら、ワットあたりの