Section 6
Scaling with Google
Cloud Operations
財務ガバナンス・SRE・モニタリング・ロギング・信頼性・サステナビリティを網羅した初学者向け完全解説
財務ガバナンスと
クラウドコスト管理
クラウドを安全・効率的に使うための「お金の管理術」。誰がいくら使っているかを把握し、予期せぬ請求を防ぎます。
クラウド財務ガバナンスとは？ 基本概念
クラウドは「使った分だけ払う（Pay as you go）」モデルのため、管理を怠ると請求が予想外に膨らむリスクがあります。財務ガバナンスとは、コストの可視化・制御・最適化を組織全体で仕組み化することです。
Google Cloud の請求構造 アーキテクチャ
リソース使用料はプロジェクト単位で発生し、請求先アカウント（Billing Account）に集約されます。
コスト管理ツール一覧 サービス
| ツール・機能 | 役割 | 主な用途 |
|---|---|---|
| Cloud Billing レポート | コストの可視化 | サービス別・プロジェクト別のコスト確認 |
| 予算 & アラート (Budgets & Alerts) | 支出監視・通知 | 月次予算を設定し、閾値超過でメール通知 |
| コスト表 (Cost Table) | 詳細なコスト分析 | SKU・ラベル・サービス別の細かい内訳確認 |
| BigQuery Billing Export | データ分析基盤 | SQL でのカスタム分析・ダッシュボード作成 |
| ラベル (Labels) | コストの分類 | チーム・環境・アプリ別にコストを仕分け |
| Recommender | コスト最適化提案 | 使用率が低いVMのサイズ変更などを提案 |
コスト最適化の主要戦略 最適化
コミットメント割引 (CUDs)
1年または3年の使用をコミットすることで、Compute Engine のコストを最大57%削減。予測可能なワークロードに最適。
持続利用割引 (SUDs)
月の利用時間が長いほど自動的に割引が適用される仕組み。設定不要で、月の25%以上使用すると自動的に割引開始。
Spot VM（スポット VM）
余剰リソースを最大91%割引で利用できるが、Google のキャパシティ需要によりいつでも停止される可能性がある。バッチ処理・ML に最適。
適切なサイジング
AI Recommender が使用率の低いリソースを検出し、より小さいインスタンスタイプへの変更を提案。オーバープロビジョニングを排除。
自動コスト制御アーキテクチャ 実装パターン
予算超過時にリソースを自動停止したい場合、以下のアーキテクチャが必要です。
ベストプラクティス：財務ガバナンス
- すべてのリソースにラベル（team / env / cost-center）を付与してコストを部門別に可視化する
- プロジェクトごとに予算アラートを 50% / 90% / 100% の3段階で設定する
- Cloud Billing データをBigQuery にエクスポートしてカスタムダッシュボードを構築する
- 定常ワークロードはCommitted Use Discounts（CUDs）を活用してコストを最大57%削減
- AI Recommender の提案を定期的にレビューしてアイドルリソースを削除または縮小する
- DDoS 攻撃によるオートスケール過多を防ぐためCloud Armor とMIG の最大台数上限を設定する
SRE 原則と
運用の卓越性
Googleが生み出したSite Reliability Engineering（SRE）の考え方を理解することは、Cloud Digital Leaderとして必須の知識です。
SRE（Site Reliability Engineering）とは？基本概念
SRE は Google が考案したソフトウェアエンジニアリングのアプローチを運用（Ops）に適用する手法です。手作業を自動化し、システムの信頼性を高めることを目指します。
- DevOps の具体的な実装方法として位置づけられる（目標は同じ、手法が具体的）
- 「エラーは避けられない」という現実を受け入れ、どれだけ許容するかを設計する
- オペレーション作業を50% 以下に抑え、残りは開発・自動化に充てるルールがある
- インシデント後はブレームレスな事後分析（Blameless Postmortem）で根本原因を分析
SLI / SLO / SLA / エラーバジェット重要概念
| 用語 | 定義 | 具体例 |
|---|---|---|
| SLI | 実際に計測するサービスの品質指標（メトリクス） | 「過去30日間のリクエスト成功率 = 99.95%」 |
| SLO | SLI に対して設定する内部目標値。SLA より高く設定する | 「リクエスト成功率を 99.9% 以上に保つ」 |
| SLA | 顧客と合意した正式な契約上の目標値。未達時はペナルティ発生 | 「99.5% を下回った場合はクレジット返金」 |
| Error Budget | SLO = (1 - SLO目標) × 期間。許容できる障害時間の総量 | SLO 99.9% → 月間 43.8 分のダウンタイムが許容量 |
Toil（トイル）の概念SRE 固有概念
Toil（トイル）とは、手作業・繰り返し・自動化できる運用作業のことです。SRE の核心的な考え方の一つで、Toil を減らすことが SRE の主要なミッションです。
Toil の特徴
- 手作業で繰り返し発生する
- 自動化できるが自動化していない
- 長期的な価値を生まない
- サービス成長に比例して増える
Toil 削減の方法
- 自動化スクリプトの作成
- IaC（Terraform 等）の導入
- CI/CD パイプラインの構築
- マネージドサービスへの移行
ベストプラクティス：SRE と運用の卓越性
- SLO を先に定義してから監視・アラートを設計する（CPU 80%より「ユーザー体験に直結する SLO 監視」が重要）
- エラーバジェットを使ってリリース判断を行う（バジェット残量が多い→新機能優先 / 少ない→信頼性改善優先）
- インシデント後は必ずブレームレス Postmortemを実施して同じ障害が再発しないよう仕組みを改善する
- SRE の作業時間の50% 以上を Toil に費やしていないか定期的にレビューする
Cloud Monitoring
モニタリングの全体像
システムの「今何が起きているか」を数値で把握するためのサービス群。問題が起きる前に検知し、自動で対応できる体制を整えます。
Cloud Monitoring とは？ 概要
Cloud Monitoring は Google Cloud のインフラとアプリケーションのメトリクスを収集・可視化・アラートを設定するフルマネージドサービスです。Google Cloud リソースのメトリクスは自動収集されますが、VM 内部（メモリ等）は Ops Agent の追加インストールが必要です。
オブザーバビリティ（可観測性）の4シグナル重要概念
Metrics（メトリクス）
何が・どれだけ起きているかの定量的な数値。CPU使用率・リクエスト数・エラーレートなど。→ Cloud Monitoring
Logs（ログ）
いつ・何が起きたかのイベント記録。エラーメッセージ・アクセスログ・監査ログなど。→ Cloud Logging
Traces（トレース）
どこで遅延が発生しているかの分散トレース。マイクロサービス間の処理経路を可視化。→ Cloud Trace
Profiles（プロファイル）
なぜ遅いかのコードレベル分析。どの関数が CPU/メモリを消費しているかを継続的に計測。→ Cloud Profiler
Google Cloud モニタリングサービス群サービス一覧
| サービス | 役割 | 主な特徴 |
|---|---|---|
| Cloud Monitoring | メトリクス収集・可視化・アラート | ダッシュボード作成、SLO 監視、アップタイムチェック |
| Ops Agent | VM 内部メトリクス収集 | メモリ・ディスク使用率など GCE デフォルトで取得できないメトリクスを収集 |
| Managed Service for Prometheus | Kubernetes メトリクス | Prometheus 互換 API でメトリクスを収集、運用オーバーヘッドなし |
| Cloud Trace | 分散トレーシング | リクエストがサービスをまたぐ処理経路とレイテンシを可視化 |
| Cloud Profiler | 継続的プロファイリング | 本番環境への影響を最小化しながらCPU/メモリの消費関数を特定 |
| Error Reporting | エラー集約・通知 | アプリケーションの例外を自動集計・グループ化し、新規エラーを即時通知 |
Ops Agent の重要性 試験頻出
Compute Engine VM のデフォルト状態では取得できるメトリクスに制限があります。
| メトリクス | エージェントなし | Ops Agent あり |
|---|---|---|
| CPU 使用率 | ✓ 自動取得 | ✓ 取得可能 |
| ネットワーク I/O | ✓ 自動取得 | ✓ 取得可能 |
| メモリ使用量 | ✗ 取得不可 | ✓ 取得可能 |
| ディスク使用率 | ✗ 取得不可 | ✓ 取得可能 |
| アプリケーションログ | ✗ 取得不可 | ✓ 取得可能 |
ベストプラクティス：Cloud Monitoring
- すべての Compute Engine VM にOps Agent をインストールしてメモリ・ディスクを監視する
- CPU アラートよりSLO ベースのアラートを優先する（ユーザー体験に直結）
- GKE のメトリクスにはManaged Service for Prometheusを使用して運用負荷を最小化
- アラートには対応手順（Runbook）へのリンクを含めて受信者が迷わず対応できるようにする
- ダッシュボードはサービス別・チーム別に整理して障害時に素早く状況把握できるようにする
Cloud Logging
ログ管理と監査
「誰がいつ何をしたか」を記録し、問題発生時の調査・コンプライアンス対応・セキュリティ監査の基盤を整えます。
Cloud Logging とは？ 概要
Cloud Logging は Google Cloud 上のあらゆるサービスからログを収集・保存・検索・エクスポートするフルマネージドのログ管理サービスです。GCP サービスのログは自動的に収集され、VM 内のアプリログは Ops Agent 経由で収集します。
監査ログ（Audit Logs）の3種類試験最頻出
監査ログは「誰がいつ何をしたか」を記録するセキュリティ・コンプライアンス上の最重要ログです。
| ログ種別 | 記録内容 | デフォルト有効 | 料金 |
|---|---|---|---|
| 管理アクティビティ (Admin Activity) | リソースの作成・削除・設定変更、IAM ポリシー変更 | ✓ 常に有効 | 無料 |
| データアクセス (Data Access) | Cloud Storage オブジェクト読み取り、BigQuery テーブルへのクエリなど | ✗ デフォルト無効 | 有料 |
| システムイベント (System Event) | Google による自動操作（ライブマイグレーションなど） | ✓ 常に有効 | 無料 |
ログのエクスポート先と用途 ルーティング
BigQuery へのエクスポート
長期保存 + SQL 分析が必要なログに最適。監査ログのカスタム分析・ダッシュボード作成・コスト分析などに活用。
Cloud Storage へのエクスポート
低コストの長期アーカイブが目的の場合に最適。Coldline ストレージと組み合わせて7年以上の保管コストを最小化。
Pub/Sub へのエクスポート
リアルタイム処理が必要なログに最適。SIEM ツールへのストリーミング、Cloud Functions によるアラート自動化に活用。
ベストプラクティス：Cloud Logging
- 監査ログはBigQuery にエクスポートしてコンプライアンス・セキュリティ調査の基盤を構築する
- 機密データを扱う API（BigQuery・Cloud Storage・Secret Manager）はデータアクセス監査ログを有効化する
- 長期保管が必要なログはCloud Storage の Coldlineにシンクして保管コストを最小化する
- アプリケーションは 構造化ログ（JSON形式） で出力して Cloud Logging での検索・集計を効率化する
- ログ保持期間のデフォルト（30日）では不十分な場合はカスタムバケットで保持期間を延長する
信頼性・可用性の
設計原則
障害が起きても止まらないシステムを設計するための考え方とGoogle Cloudの具体的なサービスを学びます。
信頼性の重要概念 基本概念
| 用語 | 意味 | Google Cloud の実装例 |
|---|---|---|
| 高可用性 (HA) | システムが継続的に稼働し続ける能力。99.9% 以上のアップタイムが目標。 | Cloud SQL の HA 構成、リージョナル MIG、GKE マルチゾーン |
| フォールトトレランス | 一部のコンポーネントが障害を起こしても、サービスを継続できる設計 | 複数ゾーンへの冗長デプロイ、Load Balancer によるヘルスチェック |
| RPO (目標復旧時点) | 障害発生時に「どこまで遡ってデータを復元するか」の目標時点 | Cloud SQL: PITR（ポイントインタイムリカバリ）でRPOを最小化 |
| RTO (目標復旧時間) | 障害発生から「サービス復旧まで何時間以内にするか」の目標値 | Cloud SQL HA でフェイルオーバー約数十秒、DR サイトで複数分 |
| ディザスタリカバリ | 大規模障害（リージョン障害等）からのシステム復旧計画 | クロスリージョンレプリカ、マルチリージョンのCloud Storage |
インシデント管理フロー 運用プロセス
インシデント（サービス障害）への対応には標準化されたプロセスが必要です。
DevOps と SRE の関係 考え方
DevOps（開発 + 運用の統合）
開発と運用のサイロを壊し、協力してサービスを素早くデリバリーする文化・考え方。CI/CD・自動化・フィードバックループが核心。
SRE（DevOps の具体的実装）
DevOps の価値観をソフトウェアエンジニアリングで具体化した実践手法。エラーバジェット・Toil削減・SLO設計などが特徴。
ベストプラクティス：信頼性設計
- 本番データベースは必ずHA（高可用性）構成 で構築し、RPO・RTO を事前に定義する
- ロードバランサにヘルスチェックを設定して異常なバックエンドを自動的に除外する
- 複数ゾーンへのリージョナル MIG（Managed Instance Group）でゾーン障害に備える
- DR（ディザスタリカバリ）手順は定期的に訓練（Chaos Engineering）して実際に機能することを確認する
- インシデント後は48時間以内に Postmortem を実施して学びを組織に残す
サステナビリティと
グリーンクラウド
Google Cloud の環境への取り組みと、クラウドを活用した IT システムのサステナビリティ（持続可能性）向上について学びます。
Google の環境への取り組み 企業の責任
Google は、企業活動における環境負荷を最小限に抑えるための野心的な目標を掲げています。
| マイルストーン | 達成・目標内容 |
|---|---|
| 2007 年 | 大手企業として初めてカーボンニュートラル達成年（実質的な温室効果ガス排出ゼロ） |
| 2017 年 | グローバルな事業運営において再生可能エネルギー 100% マッチング達成年（消費電力量と同等量の再生可能エネルギーを購入） |
| 2030 年 (目標) | 全拠点で 24/7 カーボンフリーエネルギー目標年（すべての時間帯・地域でカーボンフリーエネルギーだけで事業を運営する目標） |
Carbon Footprint（カーボンフットプリント）レポート Google Cloud ツール
Carbon Footprint は、Google Cloud の利用に伴う温室効果ガス（GHG）排出量を測定、報告、削減するためのツールです。
- 利用料金のダッシュボードのように、クラウドプロジェクトごとの炭素排出量を可視化
- 企業の ESG 報告（環境・社会・ガバナンス）に必要なデータを提供
- GCP の推奨事項（Active Assist）と連携し、不要なリソース（アイドル状態の VM など）を削除して排出量とコストの両方を削減する提案を行う
| 排出カテゴリ (GHGプロトコル) | 定義と Google Cloud の対応 |
|---|---|
| Scope 1 | 自社での燃料使用による直接排出（社用車や自社工場の燃料など） |
| Scope 2 | 購入した電力・熱・蒸気の製造に伴う間接排出。Google Cloud は、お客様の Scope 2 排出量を Scope 3 (Google の排出) として報告します。 |
| Scope 3 | サプライチェーン全体でのその他の間接排出（出張、廃棄物、データセンターの建設など） |
クラウド移行で環境負荷を削減できる理由 メリット
オンプレミスから Google Cloud へ移行するだけで、IT インフラの二酸化炭素排出量を大幅に削減できます。
高いサーバー稼働率
仮想化とマルチテナント技術により、オンプレミスの単一目的サーバーよりもリソースを効率的に使用。
再生可能エネルギー
Google のデータセンターは、100% 再生可能エネルギーで電力をマッチング（将来的には 24/7）。
高効率な冷却システム
機械学習を活用した PUE（電力使用効率）の最適化により、冷却に使用する電力を極限まで削減。
ハードウェアの効率化
カスタム設計のサーバー（TPUなど）と、ハードウェアの寿命延長・リサイクルを通じた循環型経済の実践。
ベストプラクティス：サステナビリティ
- Carbon Footprint ツールを有効化し、定期的に排出量モニタリングを行う
- サーバーレスやオートスケーリングを活用し、必要な時だけリソースを稼働させる
- アーキテクチャ設計時に、再生可能エネルギー比率の高いリージョン（例:
europe-west4や一部の US リージョン。コンソール上で葉っぱマーク🌱が付いているリージョン）を優先的に選択する - Active Assist の推奨事項に従い、アイドル VM・ディスクの削除や過剰なプロビジョニングを修正する
試験対策
チェックリスト
Section 6 の出題頻度が高いポイントと、間違えやすい引っかけ問題をまとめました。試験直前の確認にご活用ください。
頻出問題パターン TOP 10 試験対策
「予算の上限に達したらどうなるか？」
✅ 正解：通知が届くだけでリソースは停止しない。自動停止には Pub/Sub + Cloud Functions が必要。
「VM のメモリ使用量を監視するために必要なものは？」
✅ 正解：Ops Agent のインストール。CPU/ネットワークは自動収集だが、メモリはエージェントが必要。
「Cloud Storage のオブジェクト読み取りを記録したい」
✅ 正解：データアクセス監査ログを手動で有効化する。デフォルトでは無効（有料のため）。
「SLO と SLA の違いは？」
✅ 正解：SLO は内部目標値（より高い）、SLA は顧客との契約値（より低い）。SLO 未達でも SLA 内なら違約金は発生しない。
「コストを最小化しながらログを7年間保管したい」
✅ 正解：Cloud Storage の Coldline へのシンク設定。BigQuery は分析向きで割高。
「SRE において Toil とは何か？」
✅ 正解：手作業・繰り返し・自動化できる運用作業。SRE は Toil を 50% 以下に保ち、残りを自動化・開発に充てる。
「Google Cloud 利用のCO₂排出量を確認するツールは？」
✅ 正解：Carbon Footprint ツール（Cloud Console 内）。プロジェクト・リージョン・サービス別に可視化できる。
「バッチ処理のコストを最大限に削減したい」
✅ 正解：Spot VM の使用（最大91%割引）。停止されてもよいバッチ・ML トレーニングが適用対象。
「DevOps と SRE の関係を最もよく表しているのは？」
✅ 正解：「SRE は DevOps の具体的な実装（クラス）である」。DevOps が目標・文化、SRE がその実現手法。
「エラーバジェットを使い果たしそうな時、SRE チームはどうすべきか？」
✅ 正解：新機能のリリースを停止して信頼性改善に集中する。バジェットが残っている間は機能開発を優先できる。
Section 6 キーワードマップ まとめ
| カテゴリ | 重要キーワード | 重要度 |
|---|---|---|
| 財務ガバナンス | 予算アラート、Committed Use Discounts、Spot VM、ラベル、BigQuery エクスポート、Recommender | ★★★ |
| SRE | SLI / SLO / SLA / Error Budget、Toil、Blameless Postmortem、DevOps との関係 | ★★★ |
| Cloud Monitoring | Ops Agent、メトリクス・ログ・トレース・プロファイル、Cloud Trace、Error Reporting | ★★★ |
| Cloud Logging | 管理アクティビティ / データアクセス / システムイベント監査ログ、Log Router、シンク先 | ★★★ |
| 信頼性 | RPO / RTO、HA、フォールトトレランス、DR、インシデント管理、Postmortem | ★★☆ |
| サステナビリティ | Carbon Footprint ツール、Scope 1/2/3、カーボンニュートラル 2007年、CFE 24/7 | ★★☆ |