Google PCD: パフォーマンス、スケーラビリティ、回復性エンジニアリング — 学習ガイド

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

こちらの一部です： Google Professional Cloud Developer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Google Cloud におけるパフォーマンス、スケーラビリティ、レジリエンスのエンジニアリングは、変動する負荷の下で低レイテンシかつコスト効率の高いサービスを維持し、SLO に違反することなく障害を許容することに重点を置いています。設計では、オートスケーリングのシグナルをワークロードの特性に合わせ、テールレイテンシを最小限に抑えるようにデータとコンピューティングを配置し、連鎖的な障害を避けるために過負荷制御、リトライ、フェイルオーバーを実装する必要があります。このセクションでは、コンピューティング、ネットワーキング、データレイヤーにわたるアプリケーション開発者にとって重要なパターン、制御、トレードオフについて詳しく説明します。

スケーリングと負荷分散

水平スケーリングと垂直スケーリング

• 水平スケーリングは、インスタンスや Pod を追加してキャパシティとレジリエンスを向上させます。ステートレスなサービスや、迅速な弾力性が必要な場合に適しています。Managed Instance Groups (MIGs)、Cloud Run のリビジョン、または GKE の Deployment を使用します。
• 垂直スケーリングは、マシンのサイズを大きくします。シングルスレッドまたはメモリバウンドなワークロード、あるいはノード間の調整を減らす場合に役立ちますが、拡張の余地が限られ、再起動時間が長くなります。
• 同時実行数: CPU バウンドか I/O バウンドかのプロファイルに合わせて、リクエストの同時実行数を調整します。Cloud Run はリビジョンごとの同時実行数をサポートします。GKE の Pod は、ランタイムがノンブロッキングであれば複数のリクエストを処理できます。厳密な分離のためには、同時実行数を 1 に設定します。

オートスケーリングのシグナルとウォームキャパシティ

• MIG のオートスケーリングは、CPU 使用率、ロードバランシング使用率、および Cloud Monitoring を介したカスタム指標をサポートします。バースト的なトラフィックに対しては、CPU ではなくリクエスト指標（rps、キューの深さ）に基づいてスケーリングを行います。
• GKE の Horizontal Pod Autoscaler (HPA) は、CPU、メモリ、またはカスタム/外部指標（例: Pub/Sub のキューの長さ）に基づいてスケーリングできます。ライトサイジングには Vertical Pod Autoscaler (VPA) を使用しますが、急速にスケーリングするフロントエンドでの VPA のライブアップデートは、チャーン（頻繁な入れ替え）を防ぐために避けてください。
• Cloud Run は、同時リクエスト負荷と、オプションでカスタム指標に基づいてスケーリングします。ウォームキャパシティを維持することでコールドスタートを避けます。具体的には、最小インスタンス数を設定し、アイドル時の同時実行数を低く保ち、必要に応じて合成ヘルスピングを介して事前にウォームアップします。
• MIG の予測オートスケーリングや、Deployment/リビジョンで最小レプリカ数を設定することは、日中のピーク時のプロビジョニングレイテンシを隠蔽するのに役立ちます。

負荷分散、グローバルなトラフィック分散、ヘルスチェック、フェイルオーバー

• グローバルな外部アプリケーション ロードバランサを使用して、世界規模のエニーキャスト VIP、HTTP/2 と HTTP/3、および Cloud CDN によるエッジでの終端を実現します。バックエンドには、インスタンスグループ、ゾーン/リージョン NEG、サーバーレス NEG (Cloud Run/Functions)、または GKE Ingress を使用できます。
• ヘルスチェックは、非正常なバックエンドからトラフィックを遠ざけます。ダウンストリームの障害発生時に循環的な障害が発生するのを避けるため、ヘルスチェックのエンドポイントでは依存関係を限定的に（例: プロセスと重要なローカルリソース）検証するようにしてください。
• ファイアウォールの許可リストで、ヘルスチェッカーを許可する必要があります。ポート 80 へのチェックが失敗する場合は、Google の IP 範囲を許可します: gcloud compute firewall-rules create allow-lb –network load-balancer –allow tcp –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
• フェイルオーバー: プライマリ/バックアップのバックエンドサービス、またはヘルスチェックの失敗時に代替リージョンに誘導するトラフィックポリシーを設定します。DNS レベルのフェイルオーバーには、非 HTTP エンドポイント用のヘルスチェックを備えた Cloud DNS ポリシーを使用します。

レイテンシと効率

レイテンシバジェット

• 階層（クライアント、エッジ、アプリ、データ）ごとにエンドツーエンドのレイテンシバジェットを割り当てます。平均値ではなく、p95/p99 を監視します。Cloud Trace を使用して、サービス間のレイテンシ要因やヘッドオブラインブロッキングを見つけます。RPC にデッドラインを適用し、上流でのキャンセルによってキャパシティが解放されるようにします。

キャッシュと CDN の利用

• キャッシュの階層化: クライアント/ブラウザキャッシュ、CDN エッジ (Cloud CDN)、リージョン/メモリキャッシュ (Memorystore またはインプロセス)。キャッシュキーと vary ヘッダーを慎重に選択します。データの鮮度と古いデータになるリスクに基づいて TTL を設定し、安全な場合は 404 エラーに対するネガティブキャッシュを検討します。
• Cloud CDN の背後にある Cloud Storage から静的アセットを配信し、オリジンの負荷とテールレイテンシを削減します。アクセスを制御するために、署名付き URL/ヘッダーを使用します。

接続の再利用

• 多重化とヘッダー圧縮のために、HTTP/2 または gRPC を優先します。keep-alive とコネクションプーリングを有効にして、ハンドシェイクのオーバーヘッドを削減します。NAT ポートの枯渇に注意し、クライアントのコネクションプールとアイドルタイムアウトを調整し、該当する場合は VM ごとに Cloud NAT のポート数を設定します。

ペイロードの効率

• バイナリエンコーディング（例: protobuf）を使用し、特定のサイズしきい値を超えるテキストペイロードは圧縮（gzip/brotli）します。リクエスト/レスポンスのフィールドを慎重に設計し、ページネーション、サーバーサイドでのフィルタリングを行い、過剰なデータ取得を避けます。ETag と条件付きリクエスト（If-None-Match）を使用して、冗長な転送を回避します。Cloud Storage では、generation の事前条件と部分的なコンテンツ取得のための Range read を使用します。

過負荷と回復性のパターン

レート制限、バックプレッシャー、キューイング、バッチ処理

• エッジ（IP/地域/サービスベースのレート制限には Cloud Armor）とAPIレイヤー（Apigee のクォータ、APIクライアントごとのトークン）でレート制限を適用します。サーバーサイドでトークンバケットまたはリーキーバケットアルゴリズムを実装し、公平な共有を実現します。
• バックプレッシャー：ダウンストリームの処理能力を超えないようにします。キュー（at-least-once（最低1回）のイベント配信には Pub/Sub、キューごとおよびターゲットごとのスロットリング、スケジューリング、リトライには Cloud Tasks）を使用します。429 Too Many Requests または Retry-After ヘッダー付きの 503 を伝播させて、クライアントにプッシュバックします。
• バッチ処理は、スループットを向上させ、呼び出しごとのオーバーヘッドを削減できます（例：データベースへの一括変更、Pub/Sub の一括確認応答）。効率性と引き換えにレイテンシの増加を許容します。バッチサイズと最大待機時間を調整します。

過負荷保護

• すべてのRPCにタイムアウトとデッドラインを適用します。サーキットブレーカーを使用して、障害が発生している依存関係への処理送信を停止し、高速なフォールバックを可能にします。キューの深さ、CPU、またはレイテンシSLO違反に基づいてロードシェディングを実装し、コア機能を保護します。

回復性のあるリトライ、エクスポネンシャルバックオフ、ジッター、べき等性、重複処理

• 安全な場合にのみリトライします：ネットワークタイムアウト、5xx、またはドキュメントに記載されたリトライ可能なコード（例：Cloud Storage の 429/5xx）。指定がない限り、400/401/403 のような 4xx エラーでは決してリトライしません。
• リトライの同調を避けるため、ジッター付きのトランケートされたエクスポネンシャルバックオフを使用します。フルジッターを推奨します。 例：

undefined

• べき等性を確保します。べき等キー（例：一意のオペレーションID）とアップサート/条件付き書き込みを使用して、重複を許容します。Pub/Sub の場合、messageId またはアプリケーションキーを使用して重複排除を行います。ハンドラは at-least-once（最低1回）配信に対して安全であるように設計します。Cloud Storage への書き込みでは、generation-match 事前条件を使用して上書きを避けます。

休止状態リソースのランプアップ

• 一部のサービスは適応型の上限を適用します。Cloud Storage では、以前はアイドル状態だったバケットに対してリクエストレートを徐々に上げることで、突然のスパイク時に発生する一時的な 429/5xx エラーを削減します。フルロードの前に、プロデューサーをスロットリングし、制御されたトラフィックでバケットをウォームアップします。

高可用性、データ、DR、およびテスト

マルチゾーン、リージョン、マルチリージョン。アクティブ/アクティブ vs アクティブ/パッシブ

• 障害ドメインをまたいでデプロイします。ゾーン障害への耐性のために、リージョンMIGまたはリージョンGKEクラスタを使用します。グローバルサービスには、グローバルロードバランサを使用して複数のリージョンに展開します。
• アクティブ/アクティブはRTOとレイテンシを削減しますが、競合のないデータと慎重な整合性管理が求められます。アクティブ/パッシブは書き込みセマンティクスを簡素化しますが、RTOが高くなり、コールドキャパシティが発生する可能性があります。

RTO、RPO、バックアップ、リストア、および災害復旧テスト

• ワークロードごとにRTO（サービス復旧までの時間）とRPO（許容可能なデータ損失）を定義し、プラットフォームの機能にマッピングします。
  • Cloud Spanner: 99.999%の可用性を備えたマルチリージョン構成と、ゼロに近いRPOを実現する同期レプリケーション。
  • Cloud SQL: リージョン内での高可用性。DRにはクロスリージョンレプリカを使用し、PITRを有効にし、フェイルオーバー/フェイルバックのランブックを検証します。
  • FirestoreとBigtableはリージョンおよびマルチリージョンのオプションを提供します。RTO/RPOを満たすように選択します。
  • Cloud Storageのデュアルリージョンまたはマルチリージョンバケットは地理的冗長性を提供します。リストア手順と署名付きURLの再発行を検証します。
• DRのテスト: 定期的にフェイルオーバー訓練を実施します。分離された環境にリストアしてバックアップを検証し、DNS/トラフィックのフェイルオーバーをリハーサルし、実際のRTO/RPOを測定します。

データベースとストレージのパフォーマンス、インデックス設計、ホットキー、および競合

• Cloud Spanner: ホットスポットを引き起こす単調増加のプライマリキーを避けます。局所性のためにインターリーブテーブルを、読み取りパターンのためにセカンダリインデックスを、ロック競合を減らすためにバウンドトランザクションを使用します。QPSとストレージに合わせてノードをサイジングし、本番環境のクォーラムとヘッドルームのために少なくとも3つのノードを維持します。
• Cloud SQL: クエリを分析し、カバーリングインデックスを追加し、長いトランザクションを避け、コネクションプーリングを使用します。InnoDBまたはPostgresの設定を慎重にチューニングし、読み取り負荷の高いワークロードにはリードレプリカをスケールさせます。
• Bigtable: 負荷を均等に分散させるように行キーを設計します（ソルティングやフィールドの反転など）。利用可能な場合は、リージョンをまたいだ高可用性のためにマルチクラスタルーティングを使用します。
• Firestore: 複数フィールドのクエリには複合インデックスを使用します。多くの書き込みが同じドキュメントパスをターゲットにする場合のホットスポットに注意してください。
• Cloud Storage: 新しいオブジェクトに対しては強力な書き込み後読み取り整合性があります。スループット向上のために並列アップロードとチャンク化を使用します。アイドリング状態のバケットへのトラフィックは徐々に増やします。ホットな読み取りにはCDNエッジを優先します。多数のVMが同じ大規模な読み取り専用データセットを必要とする場合、読み取り専用モードで永続ディスクを複数のインスタンスにアタッチすることで、低コストで高速なローカルアクセスを実現します。

負荷テスト、カオス実験、障害注入、および容量計画

• 負荷テスト: 現実的なトラフィック形状とデータ分布をシミュレートします。キャッシュとオートスケーラーをウォームアップし、負荷時およびスケーリングイベント中のp95/p99レイテンシをテストします。本番環境の複雑さで動作を検証するために、ライブトラフィックのわずかな割合をシャドウスタックにミラーリングします。
• カオス実験と障害注入: ポッド/VMを強制終了させ、ゾーンを隔離し、サービスメッシュ（例: Envoy/Istio）でレイテンシ/エラーを注入して、影響範囲と回復力を観察します。サーキットブレーカーとリトライが意図通りに動作することを確認します。
• 容量計画: 過去の需要と計画されたイベントを使用して予測します。N+1の障害とリバランスのためのヘッドルームを維持します。オートスケーラーのクールダウン期間と最大レートを予測されるスパイクに合わせ、予測可能なピーク時には事前にプロビジョニングします。

マネージドサービスとカスタムアーキテクチャ間の可用性のトレードオフ

• コンピューティング: Cloud Runは迅速なスケールトゥゼロと低い運用オーバーヘッドを提供しますが、コールドスタートとリクエストの同時実行数に制約があります。GKEは、より高い運用コストで、きめ細かい制御とポータビリティを提供します。Compute Engine VMは、最高の運用負担で最大の制御を提供します。
• データ: Cloud Spannerは、より高いコストと厳格なスキーマを要求しますが、グローバルな整合性と高可用性を提供します。Cloud SQLは、よりシンプルな運用で従来のRDBMSに適していますが、HA/スケーラビリティには制限があります。Bigtableは、低レイテンシで大規模なキーバリュー/時系列データに優れています。Firestoreは、強力な整合性とグローバルオプションを備えた柔軟なスキーマを提供します。
• ネットワーキング: グローバルロードバランサとCloud CDNは高可用性を備え、Googleのエッジで動作します。自作のプロキシはカスタマイズ性を提供しますが、運用上および障害のリスクを生み出します。
• より高いベースラインの可用性とDDoS耐性のためにマネージドサービスを優先しますが、設計においてはクォータ、コールドスタート、およびサービス固有のセマンティクスを考慮に入れます。

実践的な問題シナリオ

グローバルなeコマース企業であるNimbusMartは、北米、ヨーロッパ、アジア太平洋のユーザー向けに、99.999%の可用性を持ち、読み取りレイテンシを最小限に抑えた低レイテンシの製品カタログAPIを必要としています。書き込みはグローバルで一貫性がなければなりません。フラッシュセール中はトラフィックが急増し、過去のインシデントにはカスケードリトライやオリジンの過負荷が含まれます。

アプローチ:

1. nam-asia-eur1を使用して、少なくとも3つのノードを持つマルチリージョンのCloud Spannerインスタンスをプロビジョニングします。

• 理由: 99.999%の可用性でグローバルに一貫した読み取り/書き込みを提供し、ユーザーの近くにレプリカを配置して読み取りレイテンシを削減します。最低3つのノードは、クォーラムの堅牢性とリバランスのためのヘッドルームを提供します。

2. グローバル外部アプリケーションロードバランサの背後にある複数のリージョンに、ステートレスなAPIレイヤーを実装します。

• 理由: Anycast VIPとグローバルルーティングにより、接続設定時間が短縮され、ユーザーを最も近い正常なリージョンに誘導します。ステートレスサービスは、水平スケーリングとフェイルオーバーを容易にします。

3. ロードバランサが到達できるように、ヘルスチェックとファイアウォールルールを設定します。

• 理由: ヘルスチェックは、異常なバックエンドへのルーティングを防ぎます。チェックが成功するように、GoogleのヘルスチェックIP範囲を許可します:

undefined

4. ウォームキャパシティを備えた、リクエストメトリクスに基づくオートスケーリングを実装します。

• 理由: フラッシュセールのトラフィックに対応するために、CPUではなくQPS/レイテンシに基づいてMIGまたはGKE HPAをスケールさせます。コールドスタートを避け、既知のイベントの前に予測オートスケーリングを有効にするために、リージョンごとに最小レプリカ数を維持します。

5. Cloud Storageに保存されている静的な製品メディア用にCloud CDNを追加します。

• 理由: エッジキャッシングはオリジンの負荷を軽減し、テールレイテンシを削減し、アプリケーション層とストレージ層でのバースト増幅を緩和します。署名付きURLと適切なキャッシュキー/TTLを使用します。

6. エッジとサービスで過負荷保護とレート制限を強制します。

• 理由: 悪意のあるスパイクを吸収するためにCloud Armorのレート制限を設定します。サービス内では、クライアントごとにトークンバケット制限を使用し、レイテンシSLOが脅かされた場合には優先度の低いリクエストを破棄します。すべてのダウンストリームコールにデッドラインを適用します。

7. 切り捨て指数バックオフと完全なジッターを備えた回復力のあるリトライを使用し、オペレーションIDでべき等性を確保します。

• 理由: 部分的な障害発生時のサンダーリングハードと重複書き込みを防ぎます。べき等性キーは安全な再実行を保証します。ストレージ操作には、条件付きの事前条件を使用します。

8. 許容できる場合は、バーストの平滑化と非同期処理のために書き込みキューを導入します。

• 理由: Pub/Subは、重要でない書き込み（例: 分析イベント）の突然のスパイクをバッファリングし、プロデューサーをSpannerから切り離し、主要な書き込みパスを過負荷から保護します。

9. SLOとレイテンシバジェットを定義し、トレースとダッシュボードを整備します。

• 理由: 階層ごとのバジェットは最適化の指針となります。エラーバジェット付きのCloud Monitoring SLOとCloud Traceは、p99レイテンシに対するリージョン間およびデータレイヤーの寄与を明らかにします。

10. DRランブックを確立し、フェイルオーバーをテストします。

• 理由: マルチリージョンSpannerとマルチリージョンコンピューティングを使用して、リージョン退避訓練を実践します。トラフィックのドレインとランプアップのタイムラインでRTOを検証し、フェイルオーバー中にオートスケーラーとCDNが正しく動作することを確認します。

この設計は、コンピューティングとデータのトポロジを整合させ、過負荷制御を強制し、実績のあるスケーラビリティと回復力を提供するマネージドサービスを使用することで、グローバルな可用性と低レイテンシの目標を満たします。

← 可観測性、デバッグ、サイト信頼性オペレーション · すべてのドメイン · テスト、品質エンジニアリング、安全なリリースマネジメント →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →