Google PCD: アプリケーションデータ、状態、ストレージパターン — 学習ガイド

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

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

概要

Google Cloud 上の最新のアプリケーションでは、レイテンシ、整合性、スケーラビリティ、コスト、運用の複雑さのバランスを取るために、複数のデータストアを組み合わせて使用することが日常的に行われています。目的に合ったサービスとパターンを選択し、それらの障害モードを理解することは、回復力のある設計の中心となります。このセクションでは、Cloud SQL、Cloud Spanner、Firestore、Bigtable、Memorystore、Cloud Storage に関する実践的なガイダンスを要約し、移行、パーティショニング、データ保護について説明します。

Cloud SQL 上のリレーショナルデータ

Cloud SQL は、使い慣れた RDBMS のセマンティクスを持つ、マネージドの MySQL、PostgreSQL、SQL Server を提供します。

プライベート接続
- プライベート IP を使用して、データベーストラフィックを VPC 内に留めます。これにより、パブリックな Ingress ルールや IP 許可リストが不要になり、NAT Egress の複雑さを回避できます。
- ルートとファイアウォールルールが VPC からインスタンスへのトラフィックを許可していることを確認してください。プライベート IP の名前解決は、プライベート IP が有効になっている場合に自動的に処理されます。
- サーバーレス (Cloud Run, App Engine, Cloud Functions) の場合は、プライベート IP を使用している場合でも、IAM 認証と TLS を処理する Cloud SQL コネクタの使用を推奨します。
高可用性とレプリカ
- リージョン HA は、プライマリとスタンバイを異なるゾーンに配置し、同期ディスクレプリケーションを行います。フェイルオーバー時には短い接続切断が予想されるため、アプリケーションは一時的なエラーをリトライし、再接続する必要があります。
- 読み取りレプリカは非同期であり、読み取りトラフィックをオフロードします。DR (障害復旧) と読み取りの近接性のためにクロスリージョンレプリカを使用しますが、レプリカは結果整合性であることを理解しておく必要があります。
- 復旧や計画的なロールスワップのために、読み取りレプリカを昇格させます。昇格手順は定期的にテストしてください。
バックアップとポイントインタイムリカバリ
- 自動バックアップとトランザクション/PITR ログを有効にします。IO 競合を減らすために、オフピーク時にバックアップをスケジュールします。
- 複数のコピーを保持し、別のインスタンスへのリストアを定期的に検証します。リストアできないバックアップは、運用上、バックアップがないのと同じです。
接続プールと上限
- Cloud SQL は最大接続数を強制します。過剰な短命の接続は、CPU スラッシングとレイテンシを引き起こします。アプリケーション側でのプーリング (例: HikariCP, PgBouncer, ProxySQL) を使用してください。
- プールのサイズは、インスタンスのメモリだけでなく、CPU コアとワークロードの同時実行性に基づいて決定します。小さく始めて、経験的にスケールさせてください。
- エフェメラル/サーバーレスコンピューティングの場合、言語固有の Cloud SQL コネクタがリビジョンごとにプールを維持しますが、コールドスタート後の接続ストームを避けるために、同時実行数には上限を設けてください。
データパーティショニングとパフォーマンス
- 大規模なマルチテナントスキーマは、顧客やリージョンごとにシャーディングして競合を減らします。可能であれば、アクセスが集中するテナント (ホットなテナント) は分離してください。
- カバーリングインデックスは慎重に作成してください。インデックスが多すぎると、書き込みが遅くなり、ストレージが増加します。カーディナリティと述語の選択性を確認してください。
- アクセスが集中する行 (ホットな行) には、オプティミスティックロックまたは SELECT FOR UPDATE を使用します。持続的な書き込みワークロードに対しては、autovacuum (PostgreSQL) や InnoDB の設定 (MySQL) をチューニングしてください。

一般的な障害モードと緩和策:

VM/ノード再起動後のサンダーリングハード (殺到): プールサイズに上限を設け、指数バックオフを使用します。
read-your-writes (ライト後の読み取り) でのレプリカ遅延: セッション整合性が必要な場合は、読み取りをプライマリに固定します。
ノイジーネイバーやメンテナンスによる HA フェイルオーバーのフラッピング: べき等性を持たせた接続およびトランザクションのリトライを実装します。

Cloud Spanner による地球規模のリレーショナル

Cloud Spanner は、グローバルな整合性オプションを備えた水平方向のスケーラビリティを提供します。

整合性とトランザクション
- 強整合読み取りと読み書きトランザクションは、TrueTime を使用して厳密な外部整合性を提供します。コミットは線形化可能性を保証するために短時間待機します。
- ステイル読み取りと有界ステイルネス読み取りは、データの新鮮さをわずかに緩和できる場合に、読み取り負荷の高いワークロードのレイテンシを低減し、可用性を向上させます。
- 読み取り専用トランザクションは、ロックなしで単一のタイムスタンプで複数の読み取りを実行します。整合性のある分析スナップショットに使用します。
リージョン性、可用性、レイテンシ
- リージョンインスタンスは、リージョン内で高可用性を提供します。マルチリージョン構成 (例: nam-asia-eur1) は、大陸をまたいで非常に高い可用性と低レイテンシなローカル読み取りを実現し、グローバルに整合性のある書き込みを提供します。
- ユーザーの地理的位置に合わせたインスタンス構成を選択してください。書き込みレイテンシは、大陸間のクォーラムサイズが大きくなるにつれて増加します。
スケーラビリティとスキーマ設計
- Spanner は、主キーの範囲によってデータをスプリットに分割し、ノード間に分散させます。ホットスポットは、キーが単調増加する場合に発生します。先頭に自動増分 ID や常に増加するタイムスタンプのようなキーを使用することは避けてください。
- 書き込みを分散させる複合主キー (例: customer_hash, customer_id, reverse_timestamp) を使用します。
- インターリーブテーブルは、親行と子行を同じ場所に配置して、局所性を高め、効率的な結合を実現します。子のカーディナリティとアクセスが親と強く相関する場合に使用します。セカンダリインデックスで補完し、テーブルのルックアップを減らすために STORING 句を検討してください。
- CPU、ストレージ、高優先度オペレーションとベストエフォートオペレーションを監視し、P95 レイテンシの下でヘッドルームを維持するようにノードをスケールします。
運用パターン
- クライアントはセッションプールを使用します。セッション作成ストームを避けるために、最小/最大セッション数をチューニングします。リトライは限定的かつべき等であるべきです。ABORTED の場合は、バックオフ付きで読み書きトランザクションをリトライします。
- バックアップは軽量で整合性があります。別のインスタンスへのリストアを検証してください。変更ストリームと CDC 連携により、ダウンストリームシステムにデータを提供できます。

トレードオフ:

強整合のグローバルな書き込みはコミット待機を追加します。UX が重要で、読み取りが中心のパスにはステイル読み取りを使用します。
インターリーブは局所性を向上させますが、書き込み負荷を集中させる可能性があります。本番に近いトラフィックでテストしてください。

NoSQL オペレーショナルストア: Firestore と Bigtable

クエリパターンとスループットプロファイルに合った NoSQL モデルを選択します。

Firestore (ドキュメント)
- データモデル: コレクションはドキュメントを含み、ドキュメントはサブコレクションを持つことができます。クエリパターンを中心にモデル化し、単一の「ホット」なドキュメントへの深いファンアウト書き込みは避けます。
- アクセスとトランザクション: Native モードでは、ドキュメントの読み取りとクエリは強整合性を持ちます。複数のドキュメントにまたがる最大1回の原子性を確保するにはバッチ書き込みを、競合チェックを伴う読み取り-変更-書き込みにはトランザクションを使用します。
- インデックス: 単一フィールドのインデックスは自動的に作成されます。複数の範囲/不等式フィルタやソート順を使用する場合は、複数フィールドの複合インデックスを定義する必要があります。クエリをインデックスのみで完結させるために、非正規化が一般的に行われます。
- クライアント同期: リアルタイムリスナーが変更をストリーミングします。オフラインキャッシュは、最終書き込み優先 (last-write-wins) のセマンティクスで調整されます。無制限のリスナーファンアウトから保護し、クエリカーソルとフィルタを優先します。
- 制限と障害モード: 単一ドキュメントへの書き込みレートはシリアル化されます。1つのドキュメントへの持続的な高 QPS 更新は競合を引き起こします。N個のサブドキュメントを持つシャーディングされたカウンタを使用し、読み取り時に集計します。
Cloud Bigtable (ワイドカラム)
- 行キーの設計が最も重要です。Bigtable は行を辞書順にパーティション分割します。キーの先頭部分がホットスポットを決定します。タイムスタンプを先頭にするようなシーケンシャルキーや、シャーディングされていないユーザーIDは避けてください。
- パターン:
  - 時系列データの読み取りには、キー内でタイムスタンプを逆順にします: key = device#hash(device_id)#reverse_ts。
  - 書き込みを分散させるために、最初のコンポーネントをハッシュ化またはバケット化します: bucket = crc32(user_id) % 128。
- 小さく、多数の列を持つセルを格納します。タブレットをまたぐような大きな行は避けてください。アクセス制御とGCポリシーの分離のために、複数のカラムファミリを活用します。
- スループットとサービング:
  - レプリケーションとリージョン内での読み取り近接性のために複数のクラスタを使用します。クラスタ間の書き込みは結果整合性になります。
  - アプリプロファイルとルーティングを調整し、クライアント側のスレッドプールとチャネルプールを十分に確保します。
- GC と TTL: バージョンベースおよび時間ベースのGCは、古いセルを非同期に削除します。データはコンパクションまで永続化されるため、規制上の期限のために即時削除に依存しないでください。

キャッシュとオブジェクトストレージのパターン

Memorystore (Redis/Memcached)
- キャッシュ戦略:
  - リードスルー: アプリケーションはキャッシュから取得します。ミスした場合は、ソースからロードしてキャッシュに格納します。
  - ライトスルー: 書き込みはキャッシュとソースに同期的に行われます。
  - ライトビハインド: 書き込みをキャッシュにバッファリングし、非同期にフラッシュします。データ損失のリスクがあるため、注意して使用してください。
- 有効期限と無効化:
  - データの陳腐化許容度に応じたTTLを適用します。Source-of-truth (信頼できる情報源) の変更時にキーを無効化します。集約キャッシュの場合は、スタンピードを避けるためにバージョン管理されたキーを使用します。
  - 人気のあるキーに対するキャッシュスタンピードを防ぐために、ミューテックスまたは single-flight を使用します。
- セッション: 一時的なセッションデータをTTL付きで保存します。機密情報の場合は、値を暗号化するか、不透明なトークンのみを保存します。
- Redis によるレート制限:
  - 固定ウィンドウ: IDごとのキーに対して INCR と EXPIRE を使用します。
  - よりスムーズな制限のためには、スライディングウィンドウまたはトークンバケットを使用します。原子性を確保するために Lua スクリプトを検討してください。
- 可用性: ベーシックティアにはフェイルオーバーがありません。スタンダードティアはリージョンHAを提供します。キャッシュは揮発性のものとして扱い、決して信頼できるストレージとして扱わないでください。
例: シンプルな固定ウィンドウのレート制限
- コマンド:

undefined

Cloud Storage
- オブジェクトと整合性: 読み取り、書き込み、上書き、削除、および一覧表示に対して、強力なグローバル整合性を持ちます。オブジェクトは不変であり、更新は新しい世代を作成します。
- 署名付き URL: アプリケーションをプロキシせずに、クライアントとバケット間で直接、大規模なアップロード/ダウンロードをオフロードします。短い有効期限を設定し、メソッド、パス、およびコンテンツヘッダーを制限します。
- 再開可能なアップロード: 5MBを超えるファイルや信頼性の低いネットワークで使用します。5xx/429エラーは、切り捨て指数バックオフと再開トークンで処理します。
- ライフサイクル: ストレージクラスの移行、古いバージョンの削除、および保持期間の強制を行うルールを定義します。ロールアウト中の安全性を確保するために、オブジェクトのバージョニングと組み合わせます。
- 通知: オブジェクトの作成完了/削除時にダウンストリーム処理をトリガーするために Pub/Sub 通知を統合し、競合状態から保護するために前提条件 (ifGenerationMatch) を含めます。
例: ローカルファイルのアップロード

undefined

移行、一貫性、パーティショニング、データ保護

データベース移行
- オンライン vs オフラインの選択: ダウンタイムを最小限に抑えるにはDatabase Migration Serviceを使用したオンライン移行を選択します。メンテナンスウィンドウが許容できる場合は、シンプルさからオフライン移行を選択します。
- スキーマファースト: 型と制約を調整します。Spannerの場合、MySQL/PostgreSQLのスキーマとデータをマッピングするためのツールを検討し、その後、分散のためにキーとインデックスを調整します。
- デュアルランとカットオーバー: オンライン移行中は、デュアルライトまたは変更ログのレプリケーションを行います。最終的なカットオーバーの前に、行数、チェックサム、および重要なクエリの動作を検証します。
スキーマ移行とロールバック
- CI/CDの一環として、バージョン管理された自動化された移行（例えば、移行ツールを使用）を利用します。追加的で後方互換性のある変更を設計します。つまり、列とインデックスを追加し、バックフィルを行い、新旧両方を読み書きするコードをデプロイし、その後、非推奨のアーティファクトを削除します。
- データ変換を伴うロールバックを計画します。コードのデプロイが失敗した場合に備え、新しい書き込みを無効にし、フィーチャーフラグに依存できるように準備します。ロールバックを妨げる破壊的な移行は避けます。
トランザクションワークフローと結果整合性ワークフロー
- 不変条件を同期的に維持する必要がある場合（資金移動、在庫の減少など）は、ACIDトランザクションを使用します。
- 読み取りが主で、レイテンシが重要なユーザー向け機能（フィード、検索、カウンターなど）では、結果整合性を優先します。べき等キー、アウトボックス/Sagaパターン、およびバックオフ付きのリトライを実装します。
- 組み合わせ: トランザクションストアに信頼できる状態をコミットし、結果整合性を持つプロジェクションのためにイベントを公開します。
データパーティショニングと接続管理
- テナント、地理、またはワークロードタイプによってパーティション分割し、ホットスポットを分離します。BigtableとSpannerでは、パーティションキーをプライマリキーにエンコードします。Cloud SQLでは、テナントごとのスキーマ、またはルーターを使用したテーブルシャーディングを使用します。
- 接続の管理:
  - Cloud SQL: プーリングして再利用し、同時実行数を制限し、コールドスタートをずらします。
  - Spanner: セッションを再利用し、起動時にプールをウォームアップし、リトライを制限します。
  - Memorystore: TCP接続を再利用し、リクエストごとの接続は避けます。
データ保護、アーカイブ、復元検証、削除の動作
- バックアップとアーカイブ:
  - Cloud SQL: 自動バックアップ + PITR。復元をテストします。
  - Spanner: マネージドバックアップ。非本番環境への復元をテストします。
  - Firestore: Cloud Storageへのスケジュールされたエクスポート。インポートを検証します。
  - Bigtable: バックアップとスナップショット。クローンと復元をテストします。
  - Cloud Storage: ガバナンスのための保持ポリシー、オブジェクトホールド、バケットレベルの均一なアクセス。ライフサイクルを通じてよりコールドなクラスにアーカイブします。
- 復元検証: 定期的に分離された環境に復元し、検証クエリとアプリのスモークテストを実行します。ポリシーに対するRTO/RPOを追跡します。
- 削除の動作:
  - BigtableのGCとライフサイクルは非同期です。即時の消去を約束しないでください。
  - Cloud Storageのバージョニングは、ライフサイクルがそれらを削除するまで世代を保持します。
  - FirestoreのTTLとエクスポートベースの削除は非同期です。
  - 厳格な削除SLAのためには、削除マークを付けてキューに入れ、削除を検証し、監査ログを残すプロセスを設計します。

実践的な問題シナリオ

Aurora Outfittersは、モノリシックなeコマースプラットフォームをGoogle Cloudに移行しています。彼らは次のことを行う必要があります: 1) リスクを軽減するためにMySQLをリフトアンドシフトする、2) アプリに過負荷をかけずに500MBの製品メディアアップロードを処理する、3) 製品カタログの読み取りスループットをスケールさせる、4) ピークセール時にユーザーごとのレート制限を強制する。

アプローチ:

MySQLをプライベートIPとリージョンHAを備えたCloud SQLに移行する
- 根拠: プライベートIPにより、パブリックへの公開とIP許可リストが不要になり、GKEやCompute Engineからの安全な接続が簡素化されます。リージョンHAはゾーン障害から保護します。フェイルオーバー時には短い接続断が予想されるため、アプリはリトライ可能なトランザクションと再接続ロジックを実装します。
自動バックアップとPITRを有効にし、復元を検証する
- 根拠: 自動バックアップとトランザクションログにより、ユーザーまたはアプリケーションのエラーからのポイントインタイムリカバリが可能になります。毎週、非本番インスタンスへのスケジュールされた復元を実行することで、バックアップが使用可能であることを検証し、RTOを測定します。
カタログ読み取り用にリードレプリカを追加する
- 根拠: カタログクエリをリードレプリカに移動することで、プライマリでの競合が減少します。アプリは、書き込み後の読み取りが必要な場合（カート/チェックアウト）はプライマリから読み取り、カタログ閲覧にはレプリカから読み取ります。この際、レプリカラグのトレードオフを理解しておく必要があります。
アプリケーション側の接続プーリングを導入し、同時実行数を制限する
- 根拠: PgBouncer/HikariCPは接続を制限して再利用し、オートスケーリングやHAフェイルオーバー中の接続ストームを回避します。プールは最大ポッド数ではなくCPUコアに合わせてサイズ設定され、過負荷を防ぎます。
署名付きURLと再開可能なアップロードを使用して、メディアのアップロードをCloud Storageにオフロードする
- 根拠: アプリは、クライアントが直接アップロードするための短命の署名付きURLを発行します。再開可能なアップロードは、信頼性の低いネットワークに対応します。メディアサービスはPub/Subのファイナライズ通知をリッスンして、処理をトリガーします。事前条件ヘッダー（ifGenerationMatch）は、上書きの競合から保護します。
ページキャッシュ、セッション、レート制限のためにMemorystore for Redisを実装する
- 根拠: リードスルーキャッシュは、更新頻度に合わせたTTLを持つ製品ページのデータベース負荷を削減します。セッションデータは短いTTLでRedisに一時的に保持され、アプリケーションの状態はCloud SQLに残ります。固定ウィンドウのトークン戦略では、INCR/EXPIREを使用してユーザーごとのリクエスト上限を設定します。キャッシュは非権威的なものとして扱われ、アプリはキャッシュの損失を許容し、ミス時に再生成します。
高スループットのカタログ閲覧機能のために、Cloud Bigtableへの段階的な移行パスを準備する
- 根拠: トラフィックが増加するにつれて、非正規化され、読み取りに最適化されたカタログビューをBigtableに移行します。行キーは、ホットスポットを発生させずに書き込みを分散させ、時間順のリストをサポートするために、bucket#category#reverse_tsとして設計されます。
スキーマ移行とロールバックの手順を確立する
- 根拠: 移行は追加的に行います。列/インデックスを追加し、べき等なジョブでバックフィルし、新旧両方を読み書きするコードをデプロイし、後で古いフィールドを削除します。フィーチャーフラグは新しいパスを保護し、ロールバックは破壊的なDDLなしで新しいフィールドへの書き込みを無効にします。
データのライフサイクルと保護ポリシーを設定する
- 根拠: Cloud Storageバケットは、ライフサイクルルールを使用してサムネイルをよりコールドなストレージに移行し、古い一時アップロードを削除します。Cloud SQLのバックアップと（採用された場合の）Spanner/Bigtableのバックアップは、検証のために定期的に復元されます。監査ログは削除ワークフローをキャプチャし、BigtableのGCはコンプライアンスドキュメントで非同期であることが認められています。
クライアントとサーバーのリトライを切り捨て指数バックオフで実装する
- 根拠: Cloud Storageはスパイク時に429/5xxを返す可能性があります。バックオフは負荷を平滑化し、エラー率を低減します。データベースとキャッシュの操作では、特にフェイルオーバーやネットワークの瞬断時に安全なリトライを保証するために、べき等性キーを使用します。