ブログ一覧

Google Cloud PCAの設計判断：Cloud Run・GKE・DB・HAを要件から選ぶ

· 約14分で読めます

Professional Cloud Architect向けに、受注APIの独自ケースで構成の選び方を練習する。Cloud RunとGKE、Cloud SQLとSpanner、HAとDR、費用管理を比較し、選定理由・不採用の条件・採用前の検証まで解説します。

PCAで学ぶ設計判断を、受注APIのケースで練習する

Google CloudのProfessional Cloud Architect（PCA）に向けて、サービスの機能は覚えたのに構成を選べない。そんなときは、要件を判断の根拠に変える練習をします。この記事では受注APIについて、実行基盤、業務DB、障害復旧、費用を順に選び、条件が変わったらどこを見直すかまで考えます。

最初に、必須条件と比較する条件を分ける

架空の6人チームが、既存MySQLを使う受注APIをGoogle Cloudへ移します。HTTPコンテナはローカルに永続データを持たず、Kubernetes固有の機能やゲストOSの変更も不要です。目的はキャンペーン中の受注を支えながら、基盤保守を減らすことです。

確認する要件今回の仮定判断への影響
負荷と応答ピーク200req/s。通常運用の有効な受注要求の95%以上を500ms以内で応答起動・DB待ちを含めて測定。障害中の目標は別に決める
互換性と更新既存MySQLのSQL・トランザクションを保ちたい。1つの書き込み先の能力で足りるかは未検証まず対応機能と代表的な更新負荷を確かめる
障害の範囲ゾーン障害に備える。リージョン停止時は30分以内の再開、データ損失は時間幅5分以内を目標HAとDRの両方が必要。RTOとRPOを別に評価
保存地域とアクセス正本・レプリカ・バックアップの許可地域を合意し、業務データへのアクセスを限定DR先も許可地域から選ぶ。接続経路と認証・認可を確認
体制と費用少人数で当番運用。月額の予算案はあるが正式な上限と優先順位は未合意運用の手間も比較。予算通知だけで費用上限を満たしたとしない

500msの測定はクライアント側のどこからどこまでか、失敗要求をどう数えるか、集計窓を何日にするかも決めます。必須条件に反する案を、安さや別項目の高得点で採用しないのが基本です。費用と品質が両立しなければ、必要な機能や目標を事業側と調整します。

今回のケースの判断順。候補の採用は検証後に確定する

事業目的と必須条件 → 実行基盤・DBの候補 → HA・DRと運用の設計 → 費用と検証結果で採否を決定

Cloud Run・GKE・Compute Engineは、必要な制御で比較する

今回のHTTP APIではCloud Runを最初の候補にします。基盤管理を減らせることがチームの目的に合うからです。ただし、コンテナが起動するだけでは採用は確定しません。Cloud Runの実行契約に照らし、ポート、要求の期限、終了処理、永続状態の置き場所を確認します。

候補評価を優先する条件引き受ける仕事
Cloud Run実行条件を満たすHTTPサービスやジョブで、基盤管理を減らしたいアプリ・権限・接続・観測・負荷設定
GKEKubernetes APIや配置・ポリシーなどの機能が必要アプリとKubernetesリソースの運用。Autopilotでも責任は残る
Compute EngineゲストOSやカーネル設定などの制御が必要OSの更新、容量、冗長化と復旧の管理

『コンテナだからGKE』『既存がVMだからCompute Engine』だけでは、このケースで増える運用を説明できません。逆に、既存のKubernetes運用基盤や必須の制御があればGKEを評価する理由になります。チームの経験も条件に含め、別の処理を同じ基盤へ無条件にそろえないようにします。

Cloud SQLとSpannerは、SQLの有無より互換性と書き込みで選ぶ

既存MySQLを保つ今回の候補はCloud SQL for MySQLです。使用しているバージョン、SQL、機能、接続方式を確認し、ピーク時の更新と競合を測ります。Spannerは水平な読み書き拡張と強い整合性を持つ分散DBの候補ですが、『将来伸びそう』だけで移行の変更量を引き受ける判断はしません。

比較軸Cloud SQLで確かめることSpannerで確かめること
互換性既存エンジンの機能・SQL・ドライバへの対応SQL・型・ドライバとトランザクション実装の変更量
書き込み必要な更新量、ロック競合、1つの書き込み先の余力キーの偏り、分散後の更新競合と拡張性
配置と遅延利用者とDBの距離、レプリカの役割構成と書き込み位置に対する遅延・費用
採用コスト容量変更、HA、移行・復旧の運用アプリ・スキーマ変更、移行・復旧の運用

Cloud SQLの読み取りレプリカは参照負荷を分けるもので、プライマリの書き込みを台数分に分散しません。SpannerのPostgreSQLインターフェースもPostgreSQLのすべての機能をそのまま使える意味ではありません。今回の比較は業務トランザクションDBの候補2つに絞っており、ほかのDBの評価まで不要になるわけではありません。

オートスケールの設定を、DBの容量と一緒に検証する

APIの台数が増えると、DB接続も増えます。接続プールは、使い終わった接続を再利用する仕組みです。アプリ側だけを増やしてもDBの更新能力が増えるとは限らず、接続待ちやロック待ちが先に悪化することがあります。

接続数を見積もる仮定の計算。製品の既定値でも推奨設定でもない
想定する同時稼働インスタンス = 20
インスタンス全体の接続プール上限 = 8
バッチ・管理など、ほかの接続 = 40

想定接続数 = 20 × 8 + 40 = 200
試験で決めた運用上の接続予算 = 240
この想定で残る差分 = 240 - 200 = 40

この240は架空の運用予算で、Cloud SQLの製品上限ではありません。20台も実際の稼働数の想定です。プロセスごとにプールがあるなら合算し、別のサービス、デプロイ中の接続、再接続時の増加も含めます。Cloud Runの最大インスタンス数は一時的に超過しうるため、台数設定だけでDBの接続上限を厳密に守れるとは扱いません。

HAとDRを分け、RTO・RPOを業務の再開まで測る

Cloud SQL for MySQLのリージョンHAは、同じリージョンの別ゾーンにプライマリとスタンバイを置きます。ゾーン・インスタンス障害への備えですが、リージョン全体の停止は別です。切り替えで既存接続は切れるため、アプリの再接続と受注の結果確認まで試します。

備える事象候補の仕組み確かめること
ゾーン・インスタンス障害同一リージョンのHA再接続、処理中の注文、回復後の容量
リージョン全体の停止別リージョンのレプリカとアプリ再開経路許可地域、昇格、切り替え、RTO・RPO
誤削除・誤更新バックアップや時点復旧必要な履歴への復元、注文の照合、再開までの時間

RTO（復旧時間目標）は障害から業務再開までに許容する時間、RPO（復旧時点目標）は許容するデータ損失の時間幅です。別リージョンの読み取りレプリカは非同期で更新されるため、昇格時に未反映の注文を失う可能性があります。レプリカがあるだけでは、RPOがゼロとも5分以内とも確定しません。

独自のDR予行の仮定。直列の所要時間は合計23分で、製品の復旧時間の保証ではない
  • 検知と切り替え判断: 4分
  • DB昇格と確認: 6分
  • アプリ・接続先の切り替え: 8分
  • 受注確認と業務再開: 5分

仮にこの予行が4 + 6 + 8 + 5 = 23分なら、30分の目標まで残るのは7分です。DB昇格の6分だけをRTOと数えません。担当者不在や制御操作の失敗も含めて測り直します。RPOは別に、予行で独立に記録したコミット済み注文と復旧した注文を照合して、失った範囲を調べます。平常時の複製遅延が短かったことだけで、障害時の損失上限を保証しないようにします。

  1. 切り替えの判断者と開始条件を決め、別リージョンのDB・アプリ・権限・接続経路を準備する。
  2. 元の地域から競合する書き込みを出さない手順で、新しい書き込み先を一つにする。利用するエンジン・エディションの昇格手順を確認する。
  3. アプリの接続先と経路を切り替え、代表的な受注・参照を試す。応答が途切れて結果不明になった注文は注文IDなどで照合してから再送する。
  4. 失われた注文の扱い、新しい構成での冗長性、元の地域への復帰を決める。誤削除の復元も別に試す。

費用は適正化・利用制御・CUDを別々に決める

安くするためにHAを外すと、今回の必須条件と衝突します。APIの実行費だけでなく、HAのDB、別地域のレプリカ、バックアップ、転送、ログ、運用の手間を同じ範囲で見積もります。まず未使用資源や過大設定を減らし、必要な品質を保てることを確認します。

仕組み役割このケースでの判断
通知だけの予算支出の傾向としきい値の通知通知先と対応者を決める。自動の支出上限とは扱わない
利用制御処理量や資源利用の制限本番停止の影響を合意。spend cap予算も対応サービスと範囲を確認
CUD（確約利用割引）一定の利用・支出の約束と引き換えの割引適正化後の安定部分で比較。不要になっても契約責任が残る

検証環境を必要な時間だけ動かす案と、本番の余力を削る案は影響が違います。CUDもピークの最大量へ即座に合わせず、実際の安定利用と適用条件から評価します。割引の契約は費用上限ではなく、予算通知も受注の可用性を守った利用制御を代行しません。

練習問題：条件が一つ変わったら、結論をどう変える？

次の3問はこの記事の独自問題です。まず自分で『条件→候補→今回選ばない理由→検証』の順に答え、その後で解説と比べてください。製品名を当てるだけで終えず、何を確かめれば採用できるかを一つ添えます。

変更・問い比較する案
1. HTTP APIの条件はそのままで、基盤保守を減らしたい。最初の候補は？A：Cloud Run、B：GKE Standard、C：ゲストOSから管理するVM
2. MySQL互換性が不要になり、強い整合性を保つ水平な書き込み拡張が必要と測定された。優先して評価するのは？A：Cloud SQLの参照レプリカ追加、B：Spannerの配置・キー・遅延、C：APIだけの台数追加
3. DB昇格が6分だったので、RTO 30分は達成済みと言える？A：言える、B：リージョンHAがあれば言える、C：障害発生から検知・業務再開まで測る必要がある
  1. 1はA。 実行条件を満たせばCloud Runが目的に合う候補。KubernetesやOS制御の要件は今回なく、その運用を増やす理由が弱い。起動とDB接続を含めて応答目標を測る。
  2. 2はB。 参照レプリカやAPI増設だけでは書き込みの分散要件を満たさない。Spannerでもキーの偏りと必要なトランザクション、遅延、費用を検証してから決める。
  3. 3はC。 昇格は復旧の一部。検知と判断、アプリと接続の切り替え、受注の確認まで測る。RPOの確認も別に必要。

選定理由を、検証と見直す条件まで一枚に残す

今回の暫定案はCloud RunとCloud SQL for MySQLのリージョンHAです。リージョン停止には、許可された別地域のレプリカとアプリ再開経路を追加して評価します。この案は、SQL互換性、200req/sでの品質、接続容量、30分のRTOと5分のRPO、費用の合意が通ることを採用条件にします。

設計判断の記録例。未実施の試験を合格扱いにしない
状態：暫定案。負荷・障害・復旧試験は未実施
目的：受注の品質を満たし、少人数での基盤保守を減らす
候補：Cloud Run + Cloud SQL for MySQL（リージョンHA）
DR：許可された別地域のレプリカとアプリ再開経路を検証
他案：GKE/VMの追加制御は現状不要。Spannerの移行負担を今は正当化できない
残る確認：SQL、接続、遅延、RTO/RPO、データ照合、権限、費用
見直す条件：書き込み容量不足、Kubernetes必須、損失ゼロ要求、保存地域の変更

最後にWell-Architected Frameworkの運用・セキュリティ・信頼性・性能・費用・持続可能性の観点で抜けを確認します。このケースでも、認証・認可、保存地域、監視と当番、移行の切り替えは採用までに具体化が必要です。『マネージドだから運用不要』で止めず、誰が何を検証し、条件が変わったらいつ見直すかまで説明できることが学習のゴールです。

一次資料と、次に深掘りするTips

この記事で深掘りしたTips