設計の判断
要件からアーキテクチャを組む
設計は要件を数字に直すところから始まります。機能要件と非機能要件を分け、非機能要件を数字に、ビジネスの言葉を技術の制約に読み替えてから選択肢を外します。
PCA の問題文は長く、答えを決める要件はたいてい 1 文に埋もれています。サービスを選ぶ前に要件を機能と非機能に分け、非機能要件を数字に直し、ビジネスの言葉を技術の制約に読み替えます。この順で読むと、4 つの選択肢のうち 2 つは要件に合わない理由で外せます。試験ガイドのセクション 1.1 と 1.5 の範囲です。
非機能要件は数字にしてから使う
機能要件は「何をするか」、非機能要件は「どのくらいうまくやるか」です。選択肢を分けるのはほとんどが非機能要件で、問題文では曖昧な言葉で書かれます。
| 問題文の書き方 | 置き換える数字 | 左右される判断 |
|---|---|---|
| 「止まると売上に直結する」 | 可用性の SLO (99.9% など) | ゾーン冗長か、リージョン冗長か |
| 「直前の注文を失えない」 | RPO (許容できるデータ損失の時間) | 同期レプリケーションか、定期バックアップか |
| 「世界中のユーザーが使う」 | 地域ごとのレイテンシ目標 | グローバルなロードバランサ、CDN、マルチリージョンの DB |
| 「データは国内に置く」 | 許可するリージョンの一覧 | 組織ポリシーのロケーション制約、Assured Workloads |
| 「アクセスは年末に 20 倍」 | ピークの処理量と期間 | 自動スケール、割り当て (quota) の事前の引き上げ |
数字が問題文にないときは業務への影響から推定します。「数時間止まっても手作業で回せる」なら、マルチリージョンは過剰です。数字の決め方は可用性と災害復旧で扱います。
ビジネス要件は技術の制約に読み替える
「市場投入を早めたい」と「運用チームが小さい」は、マネージドサービスとサーバーレスを優先する理由です。「初期投資を抑えたい」は CapEx を OpEx に移すことで、従量課金のサービスを選びます。「既存の商用ライセンスを使い続けたい」は、持ち込みライセンス (BYOL) と単一テナントノードを検討する理由です。「データから新しい収益源を作りたい」は、データを BigQuery のような分析基盤に集める設計を求めています。
成功の測り方 (KPI、ROI) も設計の前に決めます。KPI は、購入の完了率や 1 取引あたりのクラウド費用のような事業の指標と、p95 レイテンシや SLO の達成率、デプロイの頻度 (DORA の指標) のような技術の指標を組み合わせます。ROI は利用料だけでなく、運用の人手や保守契約を含めた TCO で比べます。VM の利用料がマネージドサービスより安くても、パッチ適用と監視に人を割くなら TCO は逆転します。
ワークロードごとに build、buy、modify、deprecate を決める
既存システムは、ワークロードごとに処遇 (workload disposition) を決めます。廃止できるものと買えるものを先に外すほど、移行の費用とリスクが下がります。
経費精算やメールのようにどの会社でも同じ業務は buy、独自の推薦エンジンのような競争力の源泉は build、モノリスをコンテナ化して Cloud Run に載せるのが modify の例です。modify のやり方 (rehost、replatform、refactor) は移行の計画で扱います。
外部システムとの連携は、相手の都合で型を選ぶ
| 相手の都合 | 型 |
|---|---|
| 自社の API を取引先に公開し、利用量を制限したい | Apigee を前に置く |
| 相手が不定期に止まる、ピークが合わない | Pub/Sub で非同期にする |
| Google Cloud で起きた変化で処理を動かす | Eventarc |
| オンプレミスの DB の変更を BigQuery に流し続ける | Datastream (変更データキャプチャ) |
| 夜間に大量のファイルを受け渡すだけ | Cloud Storage を受け渡し場所にする |
「取引先のシステムが止まるたびに受注処理が失敗する」なら、同期呼び出しのリトライを増やすより、メッセージキューで疎結合にします。
捨てた選択肢を記録し、変えやすく作る
要件どうしはぶつかります。取った案、捨てた案、捨てた理由、再検討する条件を ADR (アーキテクチャの決定記録) のような短い文書に残します。「Cloud SQL を選んだ。Spanner は複数リージョンに広げられるが、今の利用者は国内だけで費用が見合わない。海外展開が決まったら再検討する」で十分です。
将来の要件 (セクション 1.5) は今すべて作り込まず、後から変えても作り直しにならない形にします。疎結合ならサービスを入れ替えられ、ステートレスならリージョンを増やすときに状態の移行で悩みません。「将来は海外にも展開する」とあれば、今は 1 リージョンでも、後からマルチリージョンに広げられるデータベースとロードバランサを選びます。
試験で問われる判断
以下は、このカリキュラム用に作った例です。
「IT 部門は少人数。経費精算は自社運用、需要予測は他社との差別化の柱」。経費精算は buy で SaaS に置き換え、人手を build の需要予測に集めます。
「取引先 300 社の利用量を API ごとに制限し、利用状況を請求に使いたい」。Apigee を前に置き、制限と分析を任せます。
次のページでは、セキュリティに関わる要件をどの統制で満たすかを扱います。