Google PCA: データストレージ、データベース、分析アーキテクチャ — 学習ガイド

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

オペレーショナルデータストアとキャッシュ

Cloud SQL

高可用性: スタンバイへの同期レプリケーションを伴うリージョン HA。自動フェイルオーバーは通常数秒から数分。インスタンスエンドポイントは変わらないため、アプリの変更は最小限に抑えられます。
リードレプリカ: リージョン内またはクロスリージョン、非同期。読み取りのスケールアウトと DR に適しています。ラグを監視してください。古い読み取りは正確性に影響を与える可能性があります。
バックアップと PITR: スケジュールされたバックアップに加え、トランザクションログを使用したポイントインタイムリカバリ（通常、エンジンに応じて最大 7 日間のウィンドウ）。リストアを定期的にテストしてください。
プライベート接続: VPC ピアリングによるプライベート IP は、公開範囲とレイテンシを削減します。IP 範囲の重複を避けるように計画してください。
移行: Database Migration Service は、オンプレミスや他のクラウドからの低ダウンタイムでの移行をサポートします。大容量のリンクには、パケットロスとレイテンシを削減するため、VPN よりも Dedicated Interconnect または Partner Interconnect を推奨します。

トレードオフと障害モード

HA フェイルオーバーは接続をリセットします。アプリケーションはバックオフ付きで再試行する必要があります。メンテナンスウィンドウ中はパフォーマンスが一時的に低下することがあります。
長時間実行されるトランザクションは、レプリケーションラグと PITR のリカバリ時間を増加させます。
ストレージの過剰プロビジョニングは安価な備えとなります。IOPS のプロビジョニング不足は、ピーク時に潜在的な障害を引き起こします。

Cloud Spanner

グローバルスケールと整合性: TrueTime と 2 フェーズコミットを使用し、リージョンをまたいで強整合性のある読み取り/書き込みを実現します。書き込みレイテンシを最小化するにはリージョン構成を、より高い可用性とグローバルな読み取りにはマルチリージョン構成を選択します。
トランザクション: 行やテーブルをまたいで外部整合性と完全な ACID を提供します。読み取り専用トランザクションはレプリカ間でスケールします。
スキーマ設計: ホットスポットを避けるプライマリキーを選択します。局所性のためにインターリーブテーブルを使用します。セカンダリインデックスの書き込み増幅とバックフィル動作を考慮してください。
リージョン構成: リーダーリージョンの配置が書き込みレイテンシを決定します。マルチリージョン構成はクォーラムコストとコミットレイテンシを追加します。

トレードオフ

書き込みレイテンシは地理的な範囲とともに増加します。可用性とグローバルな分散がそれを正当化しない限り、マルチリージョン構成は避けるべきです。
ベースラインコストはシングルノードの VM データベースよりも高くなります。キャパシティプランニングは SLO と成長に合わせて行う必要があります。

Firestore、Bigtable、Memorystore、およびその選択

Firestore: モバイル/Web バックエンド向けのドキュメントデータベース。単一ドキュメントに対する強整合性、きめ細かなセキュリティ、自動インデックス作成。頻繁に更新されるドキュメントでの競合に注意し、分散カウンタとバッチ書き込みを使用してください。
Bigtable: ワイドカラム型、ペタバイトスケール、超低レイテンシの時系列データや IoT 向け。ホットスポットを避けるように行キーを設計します（例: ハッシュ化やソルティング）。ノードとクラスタでスケールし、可用性のためにマルチクラスタルーティングを使用します。レプリケーションは非同期で、強整合性はクラスタ単位です。
Memorystore for Redis: インメモリキャッシュ。ベーシックティアはシングルインスタンス（HA なし）。スタンダードティアはレプリカと自動フェイルオーバーを提供します（短い切断が発生する可能性あり）。正系のソースではなくキャッシュとして扱ってください。永続化機能は揮発性を低減しますが、データベースのバックアップを代替するものではありません。

ワークロード主導の選択

ワークロード	選択肢
結合/ACID を伴うリレーショナルで中程度のスケール	Cloud SQL
水平スケールと外部整合性を備えたグローバルなリレーショナル	Cloud Spanner
高スループットの時系列/テレメトリまたは非常に大きなキーバリュー	Bigtable
階層的なクエリを持つアプリ中心のドキュメントモデル	Firestore
一時的な高速化とレート制限	Memorystore

分析、取り込み、処理

BigQuery

データセット: 論理的なセキュリティと課金の境界。ドメインとライフサイクルステージによる命名規則を採用します。
パーティショニング: 取り込み時間または列ベースで時間的なフィルタリングを行います。整数範囲パーティショニングも可能です。event_ts には時間単位のパーティショニングを使用してスキャンを削減します。
クラスタリング: 最大 4 つの列で関連データをストレージ上で同じ場所に配置します。選択的なクエリのパフォーマンスとコストを改善します。
予約: 予約と割り当てを通じて専用スロットを管理します。突発的な実験にはフレックススロットを使用します。枯渇を避けるため、重要なワークロードは分離してください。
アクセス制御: プロジェクトおよびデータセットレベルでの IAM。行レベルのポリシーとポリシータグによるテーブル/列の制御。承認済みビューとルーチンを介してキュレーションされたデータを共有します。

便利な例:

undefined

トレードオフと障害モード

不適切なパーティショニングは、フルテーブルスキャンとコストの暴走につながります。
クラスタリングは、フィルタや結合にクラスタ化された列が含まれる場合にのみ役立ちます。頻繁な再シャッフルは利点を減少させる可能性があります。
スロットのプロビジョニング不足はジョブをキューに入れます。過剰プロビジョニングはコストを増加させます。スロット使用率とシャッフルのスピルを監視してください。

データの取り込みと処理

Pub/Sub: グローバルで永続的な at-least-once 配信。順序付けキーは、スループットとのトレードオフでキーごとの順序を保証します。べき等なコンシューマを設計してください。
Dataflow: 自動スケーリング、exactly-once のステートフル処理、ウィンドウ処理、トリガーを備えた統合バッチおよびストリーミング。Streaming Engine が状態をオフロードします。デッドレタートピックとリプレイ可能なソースを使用してください。
Dataproc: 既存のコードとエコシステムのためのマネージド Spark/Hadoop。エフェメラルクラスタまたは自動スケーリング。ML ライブラリを使用する場合や、移植コストが高い場合に使用します。

バッチとストリーミングのトレードオフ

ストリーミングはレイテンシを削減し、リアルタイムをサポートしますが、複雑さ（状態、ウォーターマーク、遅延データ）と継続的なコストが増加します。
バッチは正確性とコスト管理を簡素化します。SLA が遅延を許容できる場合に受け入れられます。
ハイブリッドパターン: 生のイベントを Cloud Storage に配置し、集計された KPI を BigQuery にストリーミングし、夜間のバッチ再計算を実行して精度を確保します。

ウェアハウスのパターン

パターン	説明
ウェアハウス	分析システムとしての BigQuery。BI 提供のためにマテリアライズドビューとスケジュールされたクエリを使用。
レイクハウス	オープンフォーマットで Cloud Storage のデータを管理。一貫したセキュリティで BigLake を介して BigQuery に公開。

ガバナンス、保護、パフォーマンス

データガバナンスとセキュリティ

メタデータとリネージ: Data Catalogを技術メタデータとビジネスメタデータに使用します。Dataflow、BigQuery、Dataprocからのリネージキャプチャを有効にして、依存関係を追跡します。
品質: Dataplexのデータ品質機能でルールを適用し、ComposerまたはDataformでチェックをオーケストレーションします。不正なレコードは隔離します。
アクセス境界: BigQueryとCloud Storageの周囲にVPC Service Controlsを配置してデータ漏洩リスクを低減します。コンテキストアウェアなアクセスにはIAM Conditionsを、暗号化制御にはCMEKを、列レベルの制限にはポリシータグを使用します。
保持: Cloud Storageバケットの保持期間、BigQueryテーブルのタイムトラベル（最大7日まで設定可能）、データセット/テーブルの有効期限を法的要件に合わせます。

バックアップ、PITR、削除保護

バックアップの検証: 定期的にCloud SQLとSpannerのバックアップを隔離された環境にリストアし、チェックサムとアプリケーションレベルの検証を実行します。
Bigtable: PITRを有効にして、設定された保持期間内のタイムスタンプに復旧できるようにします。テーブルレベルまたはクラスターレベルのリストアをテストします。
Spanner: ディザスタリカバリにバックアップを使用します。監査クエリには、バージョン保持期間内のステイルリードを活用します。
Cloud Storage: オブジェクトのバージョニングとバケット保持ロックを有効にして、偶発的な削除から保護します。オペレーターエラーの分離のために、別のプロジェクトにレプリケートします。
BigQuery: タイムトラベルとテーブルスナップショットを使用します。本番データセットでのDROP操作は、必要な承認とデータセットレベルの削除保護によって回避します。

データパフォーマンスとコスト管理

ホットキーの回避: Bigtableの行キーを分散させ（ハッシュプレフィックス）、Spannerのプライマリキーはリーダー選出をランダム化するものを選択し、Firestoreのカウンターをシャーディングします。
インデックス: 必要なSQLおよびNoSQLインデックスを維持します。BigQueryでは、共通のフィルターでクラスタリングします。Cloud SQLでは、低速クエリを監視し、Postgresのvacuum/analyzeを定期的に実行します。
キャパシティプランニング: 負荷テストでベースラインを設定します。SLOとエラーバジェットを設定します。BigQueryのスロット使用率、BigtableのCPU/read-modify-writeレイテンシ、Cloud SQLのCPU/IOPS、Pub/Subのバックログを監視します。
コスト管理: 安定したワークロードにはBigQueryのスロットコミットメントを、Cloud StorageにはAutoclassを使用します。Bigtableテーブルを圧縮し、ブルームフィルターを調整します。古いパーティションとデータセットを期限切れにし、チームごとの予算とアラートを実装します。

実践的な問題シナリオ

Acme Retail Groupは、統一された低レイテンシのクリックストリームおよび注文分析プラットフォームを必要としています。要件は、10秒以内のリアルタイムKPI、SQLによる5年間の履歴分析、1時間未満のリカバリ目標、米国内での厳格なデータレジデンシー、および偶発的なデータ損失の防止です。

生イベントの配置と永続的な取り込みの実装

生データゾーンとキュレート済みゾーン用に、デュアルリージョンのus-central1/us-east1にCloud Storageバケットを作成します。生データにはAutoclassとオブジェクトのバージョニングを有効にします。
理由: デュアルリージョンは耐久性とレジデンシー要件を満たします。バージョニングは不適切なバックフィルから保護します。Autoclassはストレージコストを自動的に最適化します。

Pub/SubとDataflowによるイベントの信頼性の高いストリーミング

クリックストリームと注文イベントを、user_idごとの順序付けキーを付けてPub/Subトピックにパブリッシュします。Dataflowストリーミングパイプラインを実装して、検証、重複排除、エンリッチを行い、出力をBigQuery（ホットKPI）とCloud Storage（キュレート済みゾーンにParquet形式）に分岐させます。
理由: Pub/Subはグローバルで永続的なat-least-once配信を提供します。Dataflowはexactly-onceのステートと自動スケーリングを提供します。分岐により、再処理のためのレイクハウスパターンが維持されます。

BigtableとRedisによるリアルタイム機能の提供

エンリッチされたイベントのサブセットを、ソルト付きのuser_id#timestamp行キーでBigtableに書き込みます。最新のセッションのフロントキャッシュとしてMemorystore for Redisを使用します。
理由: Bigtableは時系列データに対して低レイテンシ、高スループットの書き込みを実現します。ソルティングはホットスポットを回避します。Redisはライブパーソナライゼーションのテールレイテンシを削減します。

BigQueryでのウェアハウス化とクエリの最適化

event_dateでパーティション分割し、user_id、channelでクラスタリングしたデータセットを作成します。KPIにはマテリアライズドビューを、小規模ファイルのロードにはスケジュールされたコンパクションを使用します。バーストに対応するため、ベースラインのスロット予約と少量のフレックススロットバッファを購入します。
理由: パーティショニングとクラスタリングはスキャンをプルーニングし、コストを削減します。マテリアライズドビューはダッシュボードを高速化します。予約はコストを抑制し、重要なワークロードをキューイングから保護します。

アクセスの統制とデータ漏洩の防止

アナリストグループにはデータセットレベルのIAMを適用します。ポリシータグを使用してPII列を制限し、ベンダーアクセスには承認済みビューを使用します。BigQueryとCloud Storageの周囲にVPC Service Controlsを適用します。規制対象のデータセットにはCMEKを使用します。
理由: データセットおよび列レベルでの最小権限。VPC SCはデータ漏洩リスクを低減します。CMEKは暗号化制御の要件を満たします。

バックアップ、PITR、リストアテストの実装

BigtableのPITRを7～14日間有効にします。トランザクション用の注文ストアには、SpannerまたはCloud SQLのバックアップを週次で作成します。重要なBigQueryテーブルは毎日スナップショットを作成し、ミスに対してはタイムトラベルに依存します。四半期ごとに隔離されたプロジェクトへのリストア訓練を実施します。
理由: 階層化されたリカバリオプションは、論理エラーと災害に対応します。定期的な訓練により、RPO/RTOとランブックが検証されます。

データ保持とライフサイクルの管理

ライフサイクルルールを適用して、生オブジェクトは30日後、キュレート済みオブジェクトは5年後にパージします。コンプライアンスを満たすバケットレベルの保持ポリシーをロックします。一時的なデータセットには、BigQueryのデータセット/テーブルのデフォルト有効期限を設定します。
理由: 自動的な適用は運用リスクを低減します。保持ロックは、偶発的または不正なポリシーの弱体化を防ぎます。

パフォーマンスとコストの監視、ホットスポットの緩和

BigQueryのスロット使用率、スキャンされたバイト数、BIクエリの同時実行数を追跡します。BigtableのCPUとread-modify-writeレイテンシを監視します。Pub/Subのバックログについてアラートを設定します。user_idのホットスポットが発生した場合は、ソルトの幅を広げ、Dataflowを介してキーをバックフィルします。
理由: 継続的なテレメトリはボトルネックを早期に発見します。プロアクティブなキーストラテジーの変更は、全面的な再設計なしにSLOを維持します。

プライベート接続と分離の提供

ハイブリッドの依存関係には、Partner InterconnectまたはDedicated InterconnectをCloud Routerと共に使用します。IP範囲が重複しないようにします。マネージドサービスのエンドポイントにはPrivate Service Connectを使用します。
理由: プライベートパスはレイテンシとパケットロスを削減します。明確なIP計画とPSCは、分離と予測可能なルーティングを強制します。

信頼性の運用化

カナリアDataflowパイプラインとブルー/グリーンBigQueryビューを有効にします。Data Catalogの承認を介してスキーマの進化を強制します。デッドレターキューをインシデント対応と統合します。
理由: 制御されたロールアウトは影響範囲を限定します。統制されたスキーマ変更はデータ品質を維持します。DLQはインシデント中にデータが失われないことを保証します。

← コンピュート、アプリケーションプラットフォーム、ワークロードアーキテクチャ · すべてのドメイン · ネットワーキング、ハイブリッド接続、トラフィックアーキテクチャ →

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