設計の判断
Well-Architected Framework
選択肢がどれも技術的に動くとき、答えを決めるのは Well-Architected Framework の 6 つの柱です。問題文から優先する柱を見つけ、譲る柱をはっきりさせて選びます。
PCA の選択肢は、たいていどれを選んでも一応は動きます。1 つに絞る基準が Google Cloud Well-Architected Framework で、試験ガイドは冒頭でこれへの習熟を「この役割の重要な要件」と書いています。問題文には優先する柱を決める一文がたいてい入っているので、それを見つけ、譲る柱を決めてから選択肢を読みます。
6 つの柱と、柱をまたぐ原則
公式のフレームワークは、非機能の関心ごとを 6 つの柱に分けています。柱とは別に、AI と ML、金融サービスという 2 つの横断の視点もあります。
試験で「運用負荷を減らしたい」とあれば、フルマネージドを使う原則が答えを決めることが多くあります。
柱ごとに正解を分ける判断
運用の優秀性
試験ガイドのセクション 6.1 が名指しで出題範囲に入れている柱です。本番に出す前に SLO を決めて SLI で測り、負荷試験でボトルネックを見つけ、割り当て (quota) とサービスの上限を確かめておきます。「手作業のデプロイで障害が起きた」とあれば、IaC と CI/CD で変更を自動化する選択肢を選びます。監視は可観測性と信頼性の運用、自動化はIaC とデリバリーで扱います。
セキュリティ
原則は 7 つで、フレームワーク自身が対応する製品を挙げています。ゼロトラストには Identity-Aware Proxy (IAP) と Chrome Enterprise Premium、シフトレフトには Cloud Build、Artifact Registry、Binary Authorization、AI の保護には Model Armor、規制への対応には Assured Workloads と組織ポリシーです。Google が守るのはインフラまでで、IAM の設定やデータの扱いは利用者の責任に残ります (責任共有)。個々の統制はセキュリティの設計で扱います。
信頼性
ユーザーが満足する程度に、ちょうど十分な信頼性で設計します。フレームワークは 100% を目標にしないよう書いています。目標と 100% の差がエラーバジェットで、リリースやリスクのある変更に使える「失敗してよい量」です。冗長化の度合いは、障害の影響と RTO、RPO を比べて決めます。要件がリージョン障害への備えを求めていないのに全部をマルチリージョンにする選択肢は、コストの柱に反するので外します。構成は可用性と災害復旧で扱います。
パフォーマンス
「速くしたい」は、フロントエンドの p95 レイテンシ、API の処理件数、バッチの完了時刻のように、層と数字に分けてから構成を選びます。負荷が変動するなら、ピークに合わせた固定の確保より自動スケールを選びます。負荷の少ない時間帯に縮むので、コストの柱とも両立します。
コスト
勧めているのは単価より TCO を下げることで、手段としてマネージドサービスとサーバーレスを優先します。VM 上のデータベースより Cloud SQL、VM 上のコンテナより GKE Autopilot です。VM は安く見えても、管理の手間で TCO が上がることがあります。「部門ごとの費用を把握したい」には、ラベルと請求データの分析を選びます。詳しくはコストの最適化で扱います。
持続可能性
試験に出やすいのはリージョンの選び方です。リージョンごとの炭素を出さない電力の比率 (CFE%) と「Low CO2」の表示を見て、長く動かすワークロードを CFE% の高いリージョンに置きます。組織ポリシーのリソースのロケーション制約で in:us-low-carbon-locations のような値グループを使えば、それ以外のリージョンにリソースを作れなくできます。急がないバッチや ML の学習は、クリーンな電力の比率が高い時間帯にずらせます (time-shifting)。ただし、データの所在の規制とユーザーへのレイテンシは炭素より優先します。Google Cloud Region Picker で、炭素、料金、レイテンシを並べて比べられます。
柱どうしがぶつかったら、譲る柱を明記する
判断を説明するときは、取った柱、譲った柱、譲ってよい理由を 1 行で書きます。
| 判断 | 取る柱 | 譲る柱 | 譲ってよい条件 |
|---|---|---|---|
| DB をリージョン間で複製する | 信頼性 | コスト | RTO と RPO がリージョン障害への備えを求めている |
| 鍵を顧客管理 (CMEK) にする | セキュリティ | 運用の優秀性 | 規制や契約が鍵の管理を求めている |
| バッチを低炭素の時間帯に回す | 持続可能性 | パフォーマンス | 翌朝までに結果が出れば業務に支障がない |
| Spot VM でバッチを動かす | コスト | 信頼性 | 中断されても再実行できる |
下のシミュレーターで、優先する柱を入れ替えて推奨の構成がどう変わるかを確かめます。点数はこのページの判断を数値にした目安で、公式の値ではありません。
試験で問われる判断
以下は、このカリキュラム用に作った例です。
「運用担当はいない。トラフィックは日によって 10 倍変わる」。運用の優秀性とコストの柱から、VM を自分で管理せず Cloud Run のようなサーバーレスを選びます。
「業務時間内に 1 時間止まっても業務は回るが、データは失いたくない」。RTO は緩く RPO は厳しいので、マルチリージョンのアクティブ構成ではなく、バックアップとゾーンの冗長化で足ります。
「データの所在の規制はなく、経営が環境負荷の削減を掲げている」。CFE% の高いリージョンを選び、組織ポリシーのロケーション制約で強制します。
次のページでは、問題文から要件を読み取る手順を扱います。