Section 4 Overview
Section 4 の全体像と学習ポイント
試験ガイドに基づく出題範囲と、モダナイゼーションがなぜビジネスに不可欠かを理解しましょう。
4.1 クラウドのモダナイゼーションと移行
7つのR移行戦略・CAMP フレームワーク・ワークロードの評価と分類。Rehost / Replatform / Refactor の違いが頻出。
移行戦略
4.2 クラウドにおけるコンピューティング
Compute Engine・GKE・Cloud Run・App Engine・Cloud Functions の選択基準と使い分け。Spot VM のコスト最適化も必須。
サービス選択
4.3 コンテナとオーケストレーション
VM とコンテナの違い・Kubernetes の概念・GKE Autopilot vs Standard の使い分け。マイクロサービスのビジネス価値。
コンテナ
4.4 API の戦略的価値
Apigee API Management による収益化・セキュリティ・レガシーシステムの抽象化。エコシステム構築の考え方。
API管理
4.5 ハイブリッド＆マルチクラウド
GKE Enterprise（旧Anthos）による統合管理・複数クラウドを選ぶビジネス上の理由・オンプレとクラウドの接続方法。
ハイブリッド
4.6 SRE と DevOps の原則
DevOps 文化・CI/CD パイプライン・SLO/SLA/SLI の概念・エラーバジェット・DORA メトリクスの理解。
DevOps
📌 試験の重要ポイント：Section 4 は試験全体の約 17% を占めます。「なぜそのサービスを選ぶのか」という選択の根拠と、移行戦略の各手法（7つのR）の違いが特に重要です。
4.1 Migration Strategy
クラウドのモダナイゼーションと移行戦略
7つのR・CAMP フレームワーク・移行の判断基準を体系的に理解しましょう。
なぜモダナイゼーションが必要か
俊敏性の欠如
新機能リリースに数ヶ月かかり、ビジネスチャンスを逃す。テスト・デプロイが手動で時間がかかる。
スケーラビリティの限界
トラフィック増加に対応できずサービス停止。ハードウェアの調達期間が必要で機動力がない。
高い運用コスト
老朽インフラのメンテナンスに多大なリソース。使っていないサーバーの維持費も固定コストとして発生。
7つのR移行戦略最重要
| 戦略名 | 別名 | 内容 | コード変更 | 適用ケース |
|---|---|---|---|---|
| Rehost（リホスト） | Lift & Shift | コードを変えずそのままクラウドへ移行。VMをGCE上にそのまま展開する。 | なし | レガシー移行・DC契約満了の迅速な移行 |
| Replatform（リプラットフォーム） | Lift & Optimize | アーキテクチャを維持しつつ一部をマネージドサービスへ置き換え。例：自社PostgreSQL → Cloud SQL。 | 一部 | 運用負荷削減・コード変更最小化 |
| Refactor（リファクタリング） | Move & Improve | クラウドネイティブ機能を活用するためアーキテクチャを再設計。モノリス→マイクロサービス化。 | 大規模 | スケーラビリティ・俊敏性の最大化 |
| Rebuild / Re-architect | Reimagine | 既存コードを破棄して最新技術でゼロから再構築。長期的に最大の価値を生み出す。 | 完全 | コードベースが陳腐化・完全刷新が必要 |
| Repurchase（再購入） | Drop & Shop | 自社システムを廃止してSaaS（Google Workspace・Salesforce等）に移行する。 | 不要 | 既製SaaSで要件を満たせる場合 |
| Retire（廃止） | — | 価値を生み出していない・重複しているシステムを安全にシャットダウン。コスト削減に直結。 | 不要 | 利用率が極めて低いシステム |
| Retain（保持） | Revisit | 現時点でのクラウド移行が見合わないワークロードをオンプレに残す。将来の再評価を前提とする。 | 不要 | データ主権規制・レガシーHW依存 |
⚠️ 試験頻出の違い：「Retain（保持）」はデータ主権や規制上の理由でクラウドに移行できない場合に意図的にオンプレに残す戦略です。「諦め」ではなく戦略的な選択です。 一方「Retire（廃止）」は価値がないシステムを削除することでコスト削減する積極的な手法です。
CAMP（Cloud Application Modernization Program）
CAMP の 4 フェーズ
評価（Assess）
StratoZone・CAST・mFit・migVisor などのツールで IT 資産を自動ディスカバリし、クラウド適合性を分析する。
分析（Analyze）
依存関係・ビジネス価値・技術的負債を評価し、各ワークロードへの最適な移行戦略（7つのR）を決定する。
計画と実行（Plan & Execute）
優先度に基づいた段階的な移行。ビッグバンではなく小さなウェーブで反復的に実施し、リスクを最小化する。
測定と反復（Measure & Iterate）
DORA メトリクスなどで効果を測定し、継続的に改善サイクルを回す。モダナイゼーションは一度で終わらない。
🎯 モダナイゼーションの 3 段階
Stage 1 — リフト＆シフト：オンプレ VM をそのままクラウドへ。最速・最低リスク。
Stage 2 — クラウド最適化：マネージドサービス・コンテナ化・オートスケーリングを活用。
Stage 3 — クラウドネイティブ：マイクロサービス・サーバーレス・DevOps・CI/CD で最大の価値。
✅ ベストプラクティス：移行戦略の選択
- まず Stage 1（Rehost）で素早くクラウドへ移行し Quick Win を獲得する。
- ビジネス価値の高いシステムから優先的に Stage 3（クラウドネイティブ）へ移行する。
- 移行前に必ず Retire（廃止）できるシステムを特定してコストを削減する。
- データ主権・規制上の制約があるシステムは Retain 戦略を明示的に採用する。
4.2 Computing Options
コンピューティングサービスの選択最重要
制御要件・アーキテクチャ構造・チームのスキルセットに基づいて最適なサービスを選択します。
コンピューティング選択デシジョンツリー
コンピューティングサービス比較表
| サービス | 抽象化レベル | 管理負荷 | スケーリング | 課金モデル | 主な用途 |
|---|---|---|---|---|---|
| 🖥️ Compute Engine | IaaS（VM） | 高（OS管理必要） | 手動＋MIG | VM稼働時間（秒単位） | レガシー移行・GPU・特殊OS |
| ☸️ GKE Standard | CaaS（コンテナ） | 中（ノード管理） | Kubernetes自動 | ノードVM+管理プレーン | 複雑なマイクロサービス・GPU ML |
| 🤖 GKE Autopilot | CaaS（マネージド） | 低（Google管理） | Kubernetes自動 | Pod リソース単位 | K8s を楽に使いたい・小規模チーム |
| 🚀 Cloud Run | サーバーレスコンテナ | 最低 | 自動（0〜N） | リクエスト処理時のみ | HTTP API・Web アプリ・マイクロサービス |
| ⚡ Cloud Run Functions | FaaS（関数） | 最低 | 自動（0〜N） | 実行時のみ完全従量課金 | イベント処理・Webhook・軽量タスク |
| 📱 App Engine | PaaS | 低 | 自動 | インスタンス稼働時間 | 既存Webアプリ・モバイルバックエンド |
Spot VM によるコスト最適化頻出
❌ Preemptible VM（非推奨・旧方式）
- 最大 24 時間で強制終了される
- Google がリソース必要時に 30 秒前通知でシャットダウン
- 標準価格から最大 80% 割引
- 段階的に非推奨化・Spot VM へ移行推奨
✅ Spot VM（現在推奨）
- 24 時間制限を撤廃（リソースがあれば無期限稼働）
- Google がリソース必要時に 30 秒前通知でシャットダウン
- 標準価格から最大 91% 割引
- フォールトトレラントなワークロードに最適
💡 Spot VM に適したワークロード：HPC・機械学習バッチトレーニング・CI/CD ビルドジョブ・ゲノム解析・大規模データ処理パイプライン。 処理途中で終了しても再開できる「チェックポイント設計」と組み合わせることが必須のベストプラクティスです。
Managed Instance Group（MIG）
オートスケーリング
CPU 使用率・リクエスト数に応じて VM 数を自動増減。ピーク時の急増に対応しつつ、閑散期のコストを最小化。
自動ヒーリング
ヘルスチェックで異常 VM を検知して自動削除・再作成。人間が介入しなくてもサービス稼働を維持。
リージョナル MIG
複数ゾーンに VM を分散配置。1 ゾーンが障害になっても他ゾーンで継続稼働。本番環境の必須設定。
ローリングアップデート
新バージョンへの更新を順次実施。サービスを停止せずに無停止アップデートが可能。
✅ ベストプラクティス：Compute Engine
- 本番 VM はリージョナル MIG + ヘルスチェック + ロードバランサーの組み合わせで高可用性を確保する。
- 安定したワークロードには Committed Use Discount（CUD）を適用（最大 57% 割引）。
- バッチ処理・ML 学習・CI/CD ビルドジョブは Spot VM でコストを最大 91% 削減。
- 開発環境の VM は Instance Schedules で業務時間外（夜間・週末）に自動停止してコスト削減。
- Recommender の提案を定期的に確認して過剰プロビジョニングを修正する（右サイズ化）。
4.3 Containers & Kubernetes
コンテナと GKE（Google Kubernetes Engine）
VM とコンテナの違い・Kubernetes の役割・GKE の 2 つのモードを理解しましょう。
VM とコンテナの比較頻出
🖥️ 仮想マシン（VM）
物理サーバー上にハイパーバイザーを構築し、各VMが独自のゲスト OS を持つ仮想化技術。
- ⏱️ 起動に数分かかる
- 💾 数GB のサイズ（ゲストOS込み）
- 🔒 完全な分離（強固なセキュリティ）
- ⚙️ OS レベルの完全制御が可能
📦 コンテナ
ホスト OS のカーネルを共有しつつ、アプリと依存関係のみをパッケージ化した軽量な実行環境。
- ⚡ 起動がミリ秒単位（超高速）
- 🪶 数 MB〜数百 MB（軽量）
- 🌍 環境の一貫性（どこでも同じ動作）
- 📦 高密度デプロイ（リソース効率化）
マイクロサービスアーキテクチャのビジネス価値
独立したデプロイ
各サービスを他に影響なく個別にデプロイ・更新できる。リリースの頻度と速度が劇的に向上する。
部分的なスケーリング
需要が高いサービスのみをスケールアウト。例：EC サイトの決済サービスだけをセール時に拡張。
障害の局所化
あるサービスが障害でも他のサービスは動き続ける。システム全体のダウンリスクが大幅に低下。
GKE Autopilot vs Standard最重要
🤖 GKE Autopilot
Google 推奨ノードのプロビジョニング・スケーリング・アップグレード・セキュリティをすべて Google が管理。開発者は Pod だけを意識すればよい。
✅ 向いているケース
- ›インフラ管理工数を最小化したい
- ›少人数チーム・スタートアップ
- › GKE のベストプラクティスに自動準拠
課金: Pod が消費する vCPU / メモリ / ストレージ単位
⚙️ GKE Standard
細粒度制御ユーザーがノードプールを直接管理。特殊なハードウェア設定やカスタム OS が必要な場合に選択。
✅ 向いているケース
- ›GPU ノードプールが必要（ML 学習）
- ›カーネルパラメータを細かく調整が必要
- ›大規模チームが専用の CI/CD パイプライン運用
課金: ノード VM の稼働時間 + 管理プレーン
⚠️ 試験頻出の引っかけ：「GPU を使った ML モデル学習を GKE で実行し、ノードプールを細かく設定したい」→GKE Standard が正解です。Autopilot は GPU の詳細設定が限定的で、 ノード管理を完全に Google に委任するため GPU ノードプールの細かな制御には向きません。
✅ ベストプラクティス：GKE
- 新規プロジェクトはAutopilot をデフォルトで選択し、特別な要件がある場合のみ Standard へ。
- Workload Identity を使用してサービスアカウントキーをコンテナ内に置かない（最重要セキュリティ対策）。
- 本番はリージョナルクラスタ（3ゾーン分散）で耐障害性を確保する。
- Non-Critical ワークロードに Spot ノードプールを活用してコストを最大 60% 削減する。
- Liveness/Readiness Probe を必ず設定して異常 Pod を自動検知・排除する。
4.3 Serverless Computing
サーバーレスコンピューティング
Cloud Run・Cloud Functions・App Engine の違いと適切な選択基準を理解します。
推奨デフォルト
Cloud Run
コンテナをサーバーレスで実行するフルマネージドプラットフォーム。HTTP/gRPC/WebSocket に対応。任意の言語で動作。
主な特徴：
- ゼロスケール（アイドル時コストゼロ）
- トラフィック分割でカナリアデプロイ
- Cloud Run Jobs でバッチ処理も対応
Web APIML推論Webhook
Cloud Run Functions
イベント駆動の FaaS（Function as a Service）。特定のイベント発生時のみ単一の関数を実行する。旧 Cloud Functions の後継。
トリガー種別：
- Cloud Storage（ファイルアップロード）
- Pub/Sub（メッセージ受信）
- HTTP・Firebase・Eventarc
画像処理通知送信データ変換
App Engine
10年以上の実績を持つ Web アプリ向けの PaaS。ソースコードをアップロードするだけでデプロイ可能。Standard / Flexible 環境を提供。
環境の選択：
- Standard: 特定言語ランタイム・超高速スケール
- Flexible: Docker コンテナで任意ランタイム
既存WebアプリモバイルBE
⚡ Cloud Run と Cloud Functions の使い分け（試験頻出）
Cloud Run を選ぶとき
- コンテナ化された HTTP API / Web アプリ
- 複数エンドポイントを持つアプリ
- 常時起動・WebSocket・gRPC が必要
Cloud Functions を選ぶとき
- 特定イベント（ファイル保存・メッセージ受信）への反応
- 単一の処理・「接着剤」的な役割
- 完全にオンデマンド・ゼロスケール優先
✅ ベストプラクティス：サーバーレス
- 新規アプリケーションのデプロイにはCloud Run をデフォルトの選択肢として検討する（Google も推奨）。
- Cold Start が問題の場合は最小インスタンス数を 1 以上に設定（コストはかかるがレイテンシを安定させる）。
- Cloud Run Jobs でスケジュールバッチを実装し、常時起動 VM を不要にする。
- シークレット（API キー等）はコードに直書きせずSecret Manager から環境変数として注入する。
- Cloud Functions は「1 関数 = 1 タスク」の単一責務の原則を守り、複雑な処理は Cloud Run へ。
4.4 Networking
ネットワークサービスとハイブリッド接続頻出
VPC・ロードバランサー・CDN・Cloud VPN・Cloud Interconnect の役割と選択基準を理解します。
VPC（Virtual Private Cloud）の基本
Google Cloud VPC の特徴
他社クラウドと異なり、1 つの VPC がグローバルに広がる。東京リージョンと大阪リージョンの VM が同じ VPC 内でプライベート通信可能。
- サブネットで IP アドレス範囲を分割（本番・開発・テストの分離）
- ファイアウォールルールで送受信トラフィックを細かく制御
- Private Google Access で外部 IP なしで GCP サービスにアクセス
Shared VPC（共有 VPC）
ホストプロジェクトの VPC を複数のサービスプロジェクトで共有。ネットワーク管理を中央集権化しながら各チームは独立して開発できる。
メリット：
- ファイアウォールポリシーをセキュリティチームが一元管理
- 各プロジェクトは独立したコスト管理を維持
オンプレミスとの接続方法の選択最重要
🔒 Cloud VPN
低コストインターネット経由で IPsec 暗号化トンネルを作成。HA VPN は冗長トンネルで SLA 99.99% を実現。
- 物理専用線不要・低コスト・迅速な設定
- インターネット品質に依存（帯域保証なし）
- 大量データ転送・低レイテンシ要件には不向き
→ 小規模・テスト・非クリティカルなハイブリッド接続
🔗 Cloud Interconnect
エンタープライズオンプレと Google Cloud を物理的な専用線で接続。Dedicated（直接）と Partner（キャリア経由）の 2 種類。
- 低レイテンシ・高帯域・安定した専用線品質
- アウトバウンドデータ転送コストが安価
- コストが高い・設定に時間がかかる
→ 大容量・ミッションクリティカル・金融・医療系
⚠️ 試験頻出の選択問題：「金融機関が 1 日に数十 TB を転送、低レイテンシ・安定性が必要」→Cloud Interconnect（Dedicated）が正解。 「小規模企業がオンプレとクラウドをコストを抑えてつなぎたい」→Cloud VPN（HA VPN）が正解。
Cloud Load Balancing の種類
グローバル外部
HTTP(S) LB
世界中のユーザーへ最低レイテンシ配信。Google Premium Tier。SSL 終端・URL マッピング・Cloud Armor 統合。
グローバルWebアプリ
内部
HTTP(S) LB
VPC 内部のトラフィックのみを分散（外部から見えない）。マイクロサービス間通信の負荷分散に最適。
マイクロサービス
外部 TCP/UDP
NLB
L4 での高性能ロードバランシング。HTTP 以外のプロトコル（ゲームサーバー等）・超低レイテンシが必要な場合。
ゲームサーバー
Cloud CDN
100 以上のエッジロケーションでキャッシュ配信。レイテンシを最大 95% 削減し、オリジンサーバー負荷を大幅軽減。
静的コンテンツ
✅ ベストプラクティス：ネットワーク
- VM には原則として外部 IP を付与せず、Cloud NATでアウトバウンドのみを許可する（攻撃面を最小化）。
- グローバルな Web アプリにはグローバル HTTP(S) LB + Cloud CDN + Cloud Armorを組み合わせて配信。
- マイクロサービス間通信には内部 HTTP(S) LBで外部に公開しない安全な負荷分散を実現する。
- Shared VPC でネットワーク管理を中央集権化し、各チームのセキュリティポリシーを統一する。
- VPC Flow Logs を有効化してネットワークトラフィックを記録し、セキュリティ監査の基盤を整える。
4.5 Hybrid & Multi-Cloud
ハイブリッド＆マルチクラウド管理
GKE Enterprise（旧 Anthos）によるマルチ環境統合管理の仕組みを理解しましょう。
マルチクラウド戦略を選ぶ理由
ベンダーロックイン回避
特定プロバイダーへの過度な依存を防ぎ、価格交渉力を維持する。大規模障害時のビジネス継続性（BDR）も確保できる。
データ主権とコンプライアンス
個人情報・金融データを法規制により自国の自社データセンターに保持（Retain）しつつ、新システムはクラウドで構築する。
既存投資の保護
既存 DC への大規模な設備投資（CAPEX）の減価償却が完了するまで活用しつつ、新アプリはクラウドで展開。投資対効果を最大化。
GKE Enterprise（旧 Anthos）によるサイロの打破最重要
GKE Enterprise
オンプレ・Google Cloud・AWS・Azure のコンテナワークロードを単一の管理画面（Single Pane of Glass）から一元管理する統合コントロールプレーン
アイデンティティの標準化
Connect Gateway で AWS・Azure 上のクラスタへのアクセス認証を Google Cloud IAM に統一。環境ごとに異なるアクセス管理を一元化する。
Anthos Config Management（GitOps）
Git リポジトリからすべてのクラスタにセキュリティポリシー・RBAC・設定を自動同期。環境間の設定ドリフトとコンプライアンス違反を防止する。
統一された CI/CD パイプライン
インフラの差異を GKE Enterprise が抽象化するため、開発チームは単一のパイプラインでどのクラウド環境にもデプロイできる。
Anthos Service Mesh（サービスメッシュ）
Istio ベースのサービスメッシュでマイクロサービス間通信を可視化・制御。mTLS で全通信を自動暗号化し、ゼロトラストネットワークを実現。
💡 Google Distributed Cloud：Google のインフラ・ソフトウェアをそのまま自社データセンターに設置するオプション。 工場・病院・銀行など、データをオンプレに置く必要があるユースケースや、 超低レイテンシが必要なエッジコンピューティングシナリオに対応します。
✅ ベストプラクティス：ハイブリッド / マルチクラウド
- ハイブリッド環境の複雑さを増やす前に、各環境に残すビジネス上の明確な理由を定義する。
- Anthos Config Management でセキュリティポリシーを Git で一元管理し、全クラスタに均一に適用する。
- Connect Gateway でアクセス認証をIAM に統一し、環境ごとの認証管理のサイロを排除する。
- クロスクラウドの通信には暗号化を必須とし、Anthos Service Mesh の mTLS を活用する。
4.6 DevOps & SRE
DevOps と SRE の原則頻出
CI/CD パイプライン・SLO/SLA/SLI・エラーバジェット・DORA メトリクスを理解します。
CI/CD パイプライン（継続的インテグレーション / 継続的デリバリー）
Google Cloud の CI/CD ツールチェーン
Secure Source Manager（ソース管理）
GitHub 互換の Git リポジトリ。IAM で GCP 権限と統合。Cloud Build と緊密に統合されたマネージドソースコード管理。
Cloud Build（自動ビルド・テスト）
コミットをトリガーに自動ビルド・ユニットテスト・セキュリティスキャン・コンテナイメージ作成を実行。
Artifact Registry（イメージ保管）
コンテナイメージを安全に保管。脆弱性スキャンを自動実行し、Binary Authorization でセキュアなイメージのみデプロイを許可。
Cloud Deploy（継続的デリバリー）
dev → staging → production のデプロイパイプライン。本番前の人間による承認ワークフロー・カナリアデプロイ・自動ロールバック。
🔄 DevOps の本質
開発（「早く新機能をリリース」）と運用（「安定性を維持」）の壁を打破し、自動化・継続的フィードバック・責任の共有を通じてソフトウェアのデリバリーを加速させる文化的ムーブメント。
DORA 4 つのキーメトリクス
- 📊 デプロイ頻度 — 本番へのデプロイ回数（高いほど良い）
- ⏱️ 変更リードタイム — コミットから本番まで（短いほど良い）
- ❌ 変更失敗率 — デプロイが失敗する割合（低いほど良い）
- 🔧 平均復旧時間 (MTTR) — 障害から回復まで（短いほど良い）
SRE の重要概念頻出
SLI
Service Level Indicator（指標）
実際に測定するメトリクス。エラー率・レイテンシ・可用性の実測値。「実際に何%稼働していたか」。
SLO
Service Level Objective（目標）
組織内部の目標値。SLA より高い基準に設定。例：「内部目標は 99.95% 可用性」。
SLA
Service Level Agreement（契約）
ユーザーへの公式な約束・契約。SLO より低く設定。例：「99.9% を下回った場合は返金する」。
Error
Budget
Budget
エラーバジェット（許容停止量）
SLO が 99.9% なら 0.1% = 月間約 43 分まで停止が許容される「予算」。残っていれば新機能デプロイ可、枯渇しそうなら安定化優先。
💡 SRE と DevOps の関係：「
class SRE implements interface DevOps」。 SRE は DevOps の抽象的な理念を、具体的なソフトウェアエンジニアリングの実践を通じてシステム運用に適用したものです。 両者は競合する戦略ではなく、同じコインの裏表です。✅ ベストプラクティス：DevOps / CI/CD / SRE
- 本番デプロイは必ずCloud Deploy の承認ワークフローを通じて実施し、手動デプロイを排除する。
- Artifact Registry の脆弱性スキャンと Binary Authorization でセキュアなイメージのみデプロイを許可（Shift-Left Security）。
- SLO を設定し、エラーバジェットに基づいてリリース速度と安定性のバランスをデータで管理する。
- Infrastructure as Code（Terraform）でインフラをコード化し、GitOpsで設定変更を管理する。
- DORA メトリクスを定期的に測定し、組織のソフトウェアデリバリー能力を継続的に改善する。
4.4 API Management
API の戦略的価値と Apigee
API をビジネス資産として捉え、Apigee による収益化・セキュリティ・ガバナンスを理解します。
API のビジネス価値
API は単なる技術インターフェースではなく、データやサービスを収益化可能な「デジタル資産」として活用できます。
- ›エコシステム拡大：外部開発者・パートナーが API を使って新アプリを構築 → 自社ビジネスエコシステムが成長
- ›レガシーの抽象化：古いバックエンドを API でラップ → フロントエンドを中断せずにバックエンドを段階的に移行
- ›収益化：API 利用量に応じた従量課金モデルやレベニューシェアを実装
Apigee の主な機能
50 種類以上の組み込みポリシーで API トラフィックをプロキシレイヤーで制御。バックエンドにコード変更不要。
🔐 セキュリティ
- OAuth 2.0・API キー認証
- レート制限・クォータ管理
- ML ボット検出（Advanced API Security）
💰 収益化
- 従量課金 Rate Plans の設定
- レベニューシェア機能
- 開発者ポータル（自動オンボーディング）
🔐 WAAP（Web Application and API Protection）：Apigee + Cloud Armor（OWASP Top 10 防御・DDoS 緩和）+reCAPTCHA Enterprise を組み合わせることで、 エッジからアプリケーション層まで多層防御の API セキュリティアーキテクチャを構築できます。
✅ ベストプラクティス：API 管理
- レガシーシステムをいきなり廃止しようとせず、Apigee で API ファサードを設けてフロントエンドを守りながら段階移行する。
- Advanced API Security でシャドウ API（管理外の API）を発見し、組織の脆弱性を可視化する。
- 開発者ポータルで外部パートナーのセルフサービスオンボーディングを実現し、API エコシステムを拡大する。
- API 利用統計を分析して使われていない API の廃止と収益性の高い API の投資優先度付けを行う。
Cost Optimization
コスト最適化の実践（FinOps）
クラウドコストを可視化・最適化・継続管理するためのツールとベストプラクティス。
適切なサービス選択
IaaS より PaaS・サーバーレスでインフラ管理コストを削減。適切なマシンタイプで過剰スペックを回避。
適切なサイジング
Recommender が実際の使用量を分析して最適化提案を自動表示。過剰プロビジョニングを解消する。
需要に合わせたスケーリング
オートスケーリングで使用量に応じて増減。開発 VM は夜間・週末に Instance Schedules で自動停止。
最適な価格モデル
CUD（最大57%割引）・Spot VM（最大91%割引）・SUD（自動適用・最大30%）を組み合わせる。
⚠️ FinOps の重要性：クラウドコストの管理は IT 部門だけの問題ではありません。FinOps（Finance + DevOps）では、技術・財務・ビジネスチームが共同でクラウドコストを管理する文化を醸成します。 すべてのリソースにラベル（env・team・cost-center）を付与し、BigQuery でチーム別コストを可視化することが基本です。
Exam Preparation
試験直前チェックリスト＆頻出パターン
CDL 試験 Section 4 の重要ポイントを確認し、頻出問題パターンで理解を深めましょう。
Section 4 チェックリスト
移行戦略・モダナイゼーション
- 7つのR（Rehost/Replatform/Refactor/Rebuild/Repurchase/Retire/Retain）を具体例で説明できる
- Retain（保持）とRetire（廃止）の違いを明確に説明できる
- 「Lift & Shift ＝ Rehost」と「Move and Improve ＝ Refactor」の対応関係を理解している
- CAMP フレームワークの 4 フェーズを説明できる
- モダナイゼーションの 3 段階（Stage 1-3）を説明できる
コンピューティング
- コンピューティングサービス選択のデシジョンツリーを即答できる
- VM とコンテナの違いをビジネス価値を含めて説明できる
- GKE Autopilot vs Standard の使い分け（GPU が必要→Standard）を説明できる
- Spot VM が「最大 91% 割引・中断可能ワークロード向け」であることを説明できる
- Cloud Run と Cloud Functions の違いと使い分けを説明できる
ネットワーク・ハイブリッド
- Cloud VPN（安価・インターネット経由）と Cloud Interconnect（専用線・高コスト）の選択基準を説明できる
- Shared VPC の目的（ネットワーク中央集権化）を説明できる
- GKE Enterprise（旧 Anthos）がマルチクラウドを「単一の管理画面」で統合管理することを説明できる
- マルチクラウドを選ぶ 3 つのビジネス理由（ロックイン回避・データ主権・投資保護）を説明できる
DevOps / SRE / API
- CI/CD パイプライン（Cloud Build → Artifact Registry → Cloud Deploy）を説明できる
- SLI・SLO・SLA・エラーバジェットの違いを説明できる（SLA < SLO の関係）
- DORA の 4 つのメトリクスを説明できる
- Apigee がレガシーシステムの「API ファサード」として機能することを説明できる
頻出問題パターンと解法
01
コンピューティングサービスの選択
「急激なトラフィックの増減があるモバイルアプリの API バックエンドを構築したい。Node.js コンテナで開発。インフラ管理工数を最小化したい。」
- Node.js コンテナ → コンテナサービスを使用
- インフラ管理を最小化 → サーバーレス
- HTTP API + 急激な増減 → Cloud Run の 0〜N スケーリングが最適
答え：Cloud Run（サーバーレスコンテナ）
02
ハイブリッド接続の選択
「金融機関が基幹システム（オンプレ）と Google Cloud の分析基盤を接続したい。1日に数十 TB のデータを転送。低レイテンシ・高帯域・安定性が必要。」
- 大量データ（数十 TB）→ 高帯域が必要
- 低レイテンシ・安定性 → インターネット経由は不適切
- 物理専用線 → Dedicated Interconnect が正解
答え：Dedicated Interconnect
03
移行戦略の選択
「オンプレの PostgreSQL データベースをクラウドへ移行したい。アーキテクチャはそのままで、OS やパッチ管理の運用負荷を削減したい。」
- アーキテクチャはそのまま → 大規模なコード変更なし
- マネージドサービスへの置き換え → Cloud SQL
- 運用負荷削減 = Replatform（一部最適化）
答え：Replatform（Lift & Optimize）
04
GKE モードの選択
「ML エンジニアチームが GPU を使ったモデル学習ジョブを GKE で実行したい。GPU ノードプールの設定を細かく制御する必要がある。」
- GPU ノードが必要 → 特殊なノード設定が必要
- 細かいノード制御 → Autopilot では制限がある
- カスタムノードプール管理 → Standard が必要
答え：GKE Standard（細粒度制御）
混同しやすいポイントの整理
| 混同パターン | ✅ 正しい理解 |
|---|---|
| Cloud Run = Cloud Functions | Cloud Run はコンテナ化されたアプリ全体、Cloud Functions はイベント駆動の関数（コード片）。HTTP API → Cloud Run、ファイルアップロード処理 → Cloud Functions |
| Autopilot = サーバーレス | Autopilot はノード管理を Google に委任するが Kubernetes を使用。Cloud Run がサーバーレス。Autopilot はコンテナを常時稼働できる |
| Cloud VPN = Cloud Interconnect | VPN はインターネット経由（安価・低帯域）、Interconnect は物理専用線（高コスト・高帯域・低レイテンシ）。大量データ・低レイテンシ → Interconnect |
| Anthos = GKE | GKE は Google Cloud 上の Kubernetes サービス。Anthos（GKE Enterprise）はオンプレ・AWS・Azure も含む多環境を統合管理するプラットフォーム |
| SLO = SLA | SLO は組織内目標（高い）、SLA はユーザーへの契約（SLO より低く設定）。SLA を破ると返金等のペナルティが発生する |
| Retire（廃止）= Retain（保持） | Retire はビジネス価値のないシステムを削除してコスト削減。Retain はデータ主権・規制上の理由で意図的にオンプレに残す戦略的選択 |
| Rehost = Refactor | Rehost（Lift & Shift）はコード変更なしのそのまま移行。Refactor（Move & Improve）はクラウドネイティブになるようアーキテクチャを再設計する |