Google ACE: コスト管理、パフォーマンス、容量の最適化 — 学習ガイド

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

概要

Google Cloudにおけるコスト管理とパフォーマンス/キャパシティの最適化には、継続的な可視性、適切なサイジングの決定、そしてリソース使用率をビジネス目標に合致させるガバナンスが求められます。効果的な実践には、財務的コントロール（予算、割り当て）、技術的手段（オートスケーリング、予約、ライフサイクルポリシー）、アーキテクチャ上の選択（データの局所性、レプリケーション）、そして運用上のフィードバック（テレメトリ、負荷テスト）が組み合わされます。このセクションでは、コンピューティング、ストレージ、データ処理、ネットワーキング、データベース、割り当て、パフォーマンスエンジニアリングにわたる主要なツール、トレードオフ、および障害モードについて詳述します。

コストの可視性、予算、割り当て

• 請求レポートとエクスポート:

  • 迅速な傾向分析とSKUの内訳にはCloud Billingレポートを使用します。詳細でクエリ可能なコストと使用状況データを取得するには、Cloud BillingデータのエクスポートをBigQueryに対して有効にします。これにより、標準SQLを使用して日次/月次の予測、異常検出、複数プロジェクトの集計が可能になります。
  • 料金表のエクスポートは、定価とSKUコストおよびクレジットを照合するのに役立ちます。
  • 障害モード: コンソールビューのみを使用すると粒度が制限されます。BigQueryにエクスポートしないと、履歴モデリングや正確なショーバック/チャージバックが妨げられます。

• 予算とアラート:

  • 請求先アカウント、プロジェクト、フォルダ、サービス、またはラベル/タグフィルターにスコープを設定した予算を作成します。実績コストと予測コストに対してしきい値アラート（例: 50/90/100%）を設定します。Pub/Sub経由の通知チャネルを使用して、自動化されたアクション（例: 非本番環境の一時停止）をトリガーすることを検討します。
  • トレードオフ: 積極的な自動シャットダウンは支出を削減しますが、本番パスに適用されると信頼性を損なう可能性があります。

• 割り当てのためのラベルとタグ:

  • リソースラベルとResource Managerタグ（env, app, owner, cost-center）を一貫して適用します。タグは組織のポリシーをサポートし、堅牢な割り当てのために請求フィルタに表示されます。
  • ガバナンス: Organization Policy、デプロイメントテンプレート、CI/CDチェックを使用してラベル/タグポリシーを強制します。
  • 障害モード: キーの不整合やラベルの欠落は割り当てモデルを破壊します。ツールに一貫性がない場合、継承されたタグがすべてのリソースタイプに適用されないことがあります。

• コスト割り当てモデル:

  • ショーバック/チャージバックは通常、プロジェクト → サービス/SKU → ラベル/タグという階層を使用します。共有プラットフォームのコスト（例: ロードバランサ、VPC下り）は、ログ/メトリクスで測定されたリクエスト数、転送GB、CPU時間などのドライバーによって割り当てることができます。
  • トレードオフ: シンプルなモデル（均等分割）は実行が容易ですが、ヘビーユーザーのコストを誤って算定する可能性があります。詳細なモデルには、信頼性の高いテレメトリとより多くのオーバーヘッドが必要です。

簡単な例（コスト見積もりのためのBigQueryドライラン）:

undefined

コンピューティング効率とライフサイクル最適化

• 適切なサイジングとカスタムマシンタイプ:

  • Recommender API/コンソールを使用して、CPU/メモリ使用率のパーセンタイルに基づいてVMを適切なサイズに調整します。安定した、フレーバー未満のニーズ（例: 2 vCPU/10 GB RAM）にはカスタムマシンタイプを選択し、未使用のキャパシティに対する支払いを避けます。
  • 障害モード: レイテンシに敏感なサービスやバースト的なサービスをダウンサイジングすると、スロットリングが発生する可能性があります。負荷テストとバッファ用のヘッドルームで検証してください。

• 確約利用割引（CUDs）:

  • コンソールまたはCLIを介して、リソースベースのCUD（vCPU、メモリ、GPU）をリージョン単位で1年または3年契約で購入します。安定したベースラインキャパシティに最適です。バーストにはオートスケーリングを重ねて対応します。
  • トレードオフ: 確約は単価を下げますが、柔軟性に欠けます。過剰に確約すると支出が固定され、過小に確約すると割引を失います。

• Spot VMs:

  • フォールトトレラントで中断可能なワークロード（バッチ、CI、ステートレス層）にはSpot VMsを使用します。チェックポイント処理とプリエンプション処理（メタデータ/Pub/Sub経由で30秒前に通知）を実装します。
  • 障害モード: キャパシティはいつでも消失する可能性があります。ステートフルまたはクォーラムが重要なサービスをSpotのみに配置してはいけません。

• オートスケーリング、スケジューリング、ライフサイクル:

  • オートスケーリング（CPU、ロードバランサ、またはカスタムCloud Monitoringメトリクス）を備えたマネージドインスタンスグループ（MIGs）は、変動する負荷を処理します。振動を防ぐためにクールダウンとスケールインの制御を調整し、ヘルスチェックの初期遅延をアプリの準備完了状態に合わせます。
  • スケジューリング: 開発/テスト用VMを業務時間外に停止または一時停止します。Instance SchedulesまたはCloud SchedulerとCloud Functionsによる自動化を使用して、アイドルコストを最小限に抑えます。
  • ライフサイクルとメンテナンス: 高可用性のために自動再起動とホストメンテナンスの移行を有効にします。ライブマイグレーションはGPUやローカルSSDでは適用されない場合があることに注意してください。
  • アイドル状態のクリーンアップ: Recommenderを使用して、アタッチされていない永続ディスク、古いスナップショット、未使用の静的IPを回収します。
  • 障害モード: ヘルスチェックの遅延が短い、または準備完了シグナルがないと、過剰なプロビジョニングが発生します。積極的すぎるスケールインは接続を切断します。自動修復を無効にすると、障害が発生しているノードが隠蔽されます。

簡単な例:

undefined

undefined

ストレージとデータ処理の経済性

• Cloud Storageのクラスとライフサイクル:

  • アクセスパターンに応じてクラスを選択: Standard (ホット)、Nearline (30日以上の最低期間)、Coldline (90日以上の最低期間)、Archive (365日以上の最低期間)。ライフサイクルルールを適用して、スケジュールに従って階層化と削除を行う。
  • 取得のトレードオフ: 低コストのクラスでは、GBあたりの取得料金と最低ストレージ期間料金が課される。Coldline/Archiveでの頻繁な読み取りは、コスト削減効果をなくしてしまう。ピーク時の読み取りコストを考慮して、リストアのワークフローを計画する。
  • ガバナンス: コンプライアンスのためにリテンションポリシーとオブジェクトホールドを使用する。共有データセットにはリクエスタ支払いを有効にして、チーム間の予期せぬ請求を回避する。

• ライフサイクルポリシーの例 (階層化してから削除):

  • AgeベースのSetStorageClassアクションとDeleteアクションを定義して、古いデータの移行とクリーンアップを自動化する。

• BigQueryのコスト管理:

  • オンデマンドクエリは処理バイト数に応じて課金される。パーティションプルーニングとクラスタリングで最小化する。取り込み時間または日付カラムでパーティション分割し、カーディナリティ/選択性の高い最大4つのカラムでクラスタ化する。
  • ドライランを使用してコストを見積もり、ホットな集計にはマテリアライズドビューを使用し、テーブルデコレータで時間範囲を絞り込む。
  • 予約 (スロット) は、予測可能なパフォーマンスと費用を提供する。プロジェクト/フォルダごとに割り当てを使用し、短期的なスパイクにはフレックスコミットメントを検討する。
  • 失敗のパターン: 非パーティション化スキャン、幅の広いテーブルでのSELECT *、不適切な順序のクラスタリングは、大量のスキャンバイト数を生成する。有効期限が設定されていない一時的な中間テーブルは、ストレージを肥大化させる可能性がある。

短い例 (Cloud StorageライフサイクルのJSONスニペット):

• { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }

ネットワーキング、データベース、クォータを意識したスケール

• ネットワーク下り (エグレス) とアーキテクチャの影響:

  • インターネットへの下り、リージョン間、および外部IP経由の下りには料金が発生する。同一リージョン内の内部IP経由のトラフィックは通常無料。パフォーマンスを重視する場合はプレミアムネットワークティアを、レイテンシ/ジッターの要件が緩やかでコストを重視するワークロードには標準ティアを選択する。
  • ロードバランサ: L7 HTTP(S) と L4 TCP/UDP には、データ処理料金と転送ルール料金がある。リージョン間のLBは、リージョン間の下り料金が追加される場合がある。LBを統合すると固定費を節約できるが、影響範囲 (ブラスト半径) が広がる可能性がある。
  • 最適化: トラフィックをリージョン内に留める。リージョナルバケットとサービスを使用する。外部IP経由のヘアピンニングを避ける。静的アセットをエッジでキャッシュして、オリジンからの下りを削減する。
  • 失敗のパターン: 同じVPC内のサービス間で誤って外部IPを使用すると、不要な下り料金が発生する。マルチリージョンレプリケーションは、書き込みパスの下り料金を2倍にする。

• データベースのサイジング、レプリカ、可用性:

  • Cloud SQL: 95パーセンタイルの負荷に合わせてvCPU/RAMをサイジングする。ストレージの自動サイズ変更を有効にする。スケールアウトリードにはリードレプリカを使用する。HAはコンピューティングコストを2倍にするが、フェイルオーバーのRTOを短縮する。コネクションプーリングは、過剰な接続オーバーヘッドを回避する。
  • Spanner: 容量はノードまたは処理ユニットとしてプロビジョニングされる。マルチリージョン構成は可用性と読み取りレイテンシを向上させるが、コストと書き込みレイテンシが増加する。分割とホットスポットを慎重に計画する。
  • Bigtable: ノード数がスループットを決定する。オートスケーラーがトラフィックの追跡に役立つ。マルチクラスタレプリケーションは可用性とコストを追加する。キーが均等に分散するようにスキーマを設計する。
  • トレードオフ: レプリカは読み取りスループットと可用性を向上させるが、書き込み増幅と下り料金を増加させる。強整合性とマルチリージョン書き込みはレイテンシを増加させる。

• クォータ、レート制限、バックプレッシャー:

  • APIごとのクォータとサービスごとの同時実行数を理解する。429/5xxエラーに対しては、ジッター付き指数バックオフを実装する。Pub/SubとDataflowまたはCloud Runジョブを使用して、キューベースの負荷平準化を適用する。
  • 同時実行数の設定: Cloud Runでは、同時実行数を高くするとコストは削減されるが、テールレイテンシのリスクがある。安定したスループットのためには、リクエストごとのCPU割り当てを調整する。
  • バックプレッシャー: Pub/Subサブスクライバーのフロー制御、サーキットブレーカー、アドミッションコントロールを使用して、連鎖的な障害を防ぐ。
  • 失敗のパターン: クォータを無視すると突然のスロットリングにつながる。オートスケーリングは、バックプレッシャーがないと下流のサービスへの負荷を増幅させ、リトライを引き起こし、コストを増大させる可能性がある。

パフォーマンス測定と最適化のガバナンス

• 測定と負荷テスト:

  • レイテンシ、エラー率、サチュレーションに関するSLI/SLOを確立します。Cloud Monitoringのダッシュボード、稼働時間チェック、アラートを使用します。トレーシング（Cloud Trace）とプロファイリング（Cloud Profiler）を導入して、ホットパスやロック競合を特定します。
  • 現実的なトラフィックモデル、データカーディナリティ、シンクタイムを用いて負荷テストを実施します。オートスケーラーのパラメータ、ウォームアップ、準備ゲートを検証します。フェイルオーバーやカオスシナリオを含め、キャパシティのヘッドルームと復旧時間を確認します。
  • ボトルネックの診断：CPU、メモリ、ディスク、ネットワーク、ダウンストリームの依存関係にわたり、USEメソッド（使用率、サチュレーション、エラー）を使用します。ログやトレースと相関分析を行います。

• コスト、セキュリティ、信頼性のバランスをとるガバナンス:

  • FinOpsのガードレール：必須のラベル/タグ、予測アラート付きの予算、一元化された請求エクスポートとコストレビューの定例会。Recommenderの検出結果（アイドル状態のIP/ディスク、ライトサイジング）を、オーナーのSLAと共にバックログに組み込みます。
  • セキュリティ：プライベート接続（外部IPなし）を優先し、データ漏洩リスクにはVPC Service Controlsを使用します。プライベートパスが下り（egress）のパターンとコストを変更する可能性があることを認識します。保存時および転送中のデータを暗号化し、コストモデルにKMSの使用量を考慮に入れます。
  • 信頼性：CUDまたはBigQuery予約を介してベースラインキャパシティを予約し、SLOのためのバースト用ヘッドルームを確保します。定期的にゲームデーを実施します。クリティカルパスにおいてSpotまたは積極的なオートスケーリングが許容できない場合を文書化します。
  • 変更管理：コストに影響を与えるパラメータ（オートスケーラーの上限、BigQuery予約、LBトポロジー）を、レビューとロールバック計画を伴うコードとして扱います。

実践的な問題シナリオ

Contoso Mediaは、マルチリージョンの動画分析プラットフォームを運用していますが、コストの上昇と、トラフィックスパイク時の散発的なレイテンシSLO違反に直面しています。経営陣は、APIのp95レイテンシSLO 300msと、夜間バッチ完了に対する2時間のSLAを維持しつつ、20%のコスト削減を求めています。

1. コストとパフォーマンスのベースラインを確立する

• アクション：Cloud BillingからBigQueryへのエクスポートを有効にし、SKUコストとCloud MonitoringのSLI（レイテンシ、CPU、送信バイト数）を関連付けるダッシュボードを作成します。上位20件のクエリに対してbqのドライランを実行し、スキャンされるバイト数を見積もります。
• 根拠：ベースラインによって影響の大きいサービスを特定し、支出をパフォーマンスの要因に対応付けることで、的を絞った最適化が可能になります。

2. 割り当てのタグ付けと予算を強制する

• アクション：デプロイメントテンプレートを介してラベル/タグ（env、service、owner、cost-center）を必須とします。環境ごとに予算を設定し、予測アラートをFinOps用のPub/Subトピックに送信します。
• 根拠：完全な割り当てデータとプロアクティブなアラートにより、予算超過が発生する前に、迅速なオーナーシップの特定と是正措置が可能になります。

3. ベースラインコンピューティングのライトサイジングとコミットを行う

• アクション：定常的なサービスにRecommenderによるVMのライトサイジングを適用します。定常状態のキャパシティを1年間のリージョンCUDに変換します。スパイクに備えて、オートスケーラーの最大値に20〜30%のバッファを維持します。
• 根拠：ライトサイジングとコミットメントにより、予測可能な負荷に対する単価を下げつつ、SLOのためのヘッドルームを確保します。

4. オートスケーリングと準備性を最適化する

• アクション：MIGの場合、オートスケーリングのシグナルをリクエストベースまたはカスタムのQPS/レイテンシメトリクスに切り替え、クールダウンを120〜180秒に設定し、ヘルスチェックの初期遅延をアプリのウォームアップ時間に合わせます。急激なスケールダウンを防ぐためにスケールイン制御を有効にします。
• 根拠：ワークロードを意識したシグナルと安定化により、コストを増大させレイテンシを悪化させるスラッシングや過剰プロビジョニングを回避します。

5. ネットワークの下り（egress）とロードバランサーのオーバーヘッドを削減する

• アクション：サービス間の外部IP通信を排除します。すべてのEast-Westトラフィックが内部ロードバランシングを使用するようにします。通信量の多いサービスをリージョン内にまとめて配置します。静的アセットをエッジでキャッシュします。
• 根拠：内部パスは不要な下り（egress）をなくし、L7処理を削減するため、レイテンシとコストが改善されます。

6. ストレージのライフサイクルとアーカイブを行う

• アクション：Cloud Storageのライフサイクルルールを適用して、90日後にコールドなアーティファクトをColdlineに移動し、365日後に削除します。共有バケットにはリクエスタ支払いを設定します。アクセス頻度の低いデータに対する最低保管期間の影響を確認します。
• 根拠：階層化と保持ポリシーにより、コンプライアンスを維持しつつ、ストレージと取得のコストを削減します。

7. BigQueryのクエリとキャパシティをチューニングする

• アクション：大規模なファクトテーブルを日付でパーティショニングし、選択性の高い列でクラスタリングします。SELECT *を列の射影に置き換えます。上位の集計のためにマテリアライズドビューを導入します。ピーク時のETLウィンドウ用に少量の予約を購入し、バッチのスパイク時にはフレックススロットを使用します。
• 根拠：パーティショニングとクラスタリングはスキャンされるバイト数を削減します。キャパシティ予約は、クリティカルなワークロードのパフォーマンスとコストを安定させます。

8. データベースのスケールとレプリカを構成する

• アクション：読み取り負荷の高いCloud SQLサービスには、リードレプリカを追加します。コネクションプーリングをチューニングします。ストレージの自動サイズ変更を設定します。フェイルオーバーをテストしてRTO/RPOを検証します。Bigtableでは、オートスケーラーを有効にし、ホットスポットキーに対処します。
• 根拠：レプリカは読み取りをオフロードし、書き込みパスを保護します。オートスケーリングは、手動での過剰プロビジョニングなしに、スループットを需要に合わせて維持します。

9. クォータ、同時実行性、バックプレッシャーを管理する

• アクション：ジッター付きの指数バックオフを実装します。Pub/Subサブスクライバーのフロー制御を設定します。スループットとレイテンシのバランスをとるようにCloud Runの同時実行数を設定します。ダウンストリームの境界にサーキットブレーカーを追加します。
• 根拠：適切なバックプレッシャーは、SLOを低下させコストを増大させる連鎖的な障害や制御不能なリトライを防ぎます。

10. 継続的な検証とガバナンスを実施する

• アクション：毎月の負荷テストとカオスドリルを実行します。SLO/エラーバジェットを追跡します。Recommenderとコストの異常を、オーナーと期日と共にスプリント計画に統合します。
• 根拠：反復的な検証により、ワークロードが進化してもコスト削減が持続し、SLOがグリーンな状態を維持されることを保証します。

← 信頼性、バックアップ、災害復旧 · すべてのドメイン

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →