PDE 合格対策

セクション1：データ処理システムの設計

データ基盤の上流の設計判断を扱うセクション。IAM・暗号化・DLP・ACID・DR・データ移行など、「誰が・どのデータに・何をできるか」と「データが壊れない・止まらない・正しい」を担保する設計の型を学びます。

出題 ~22% 📘 基礎 🔧 応用 🎯 要点と暗記
🔑 TL;DR — このセクションの要約 セキュリティは多層で考える：IAM（誰が何を）＋暗号化（データ保護）＋VPC Service Controls（境界）＋DLP（PII）。信頼性は「ACIDか結果整合性か」の判断と冗長化・DRが核。柔軟性はBigLake / BigQuery Omniとオープンフォーマット、ガバナンスはDataplex。データ移行は5サービスの決定木（DMS / Datastream / BigQuery Data Transfer / Transfer Appliance / Storage Transfer Service）を暗記し、必ず検証フェーズを設計に入れる。

🎯 学習目標

このセクションの達成度0 / 0





※ チェック状態はこのブラウザに保存されます。

📖 学習コンテンツ

各サブトピックの「概念」と「サービスの役割」を理解することがゴール。設計判断やトレードオフは「🔧 応用」タブで扱います。

1.1 セキュリティとコンプライアンスを考慮した設計 📘 基礎

データ基盤は「誰が・どのデータに・何をできるか」を最初に設計します。GCPのセキュリティは多層（IAM＝アクセス制御、暗号化＝データ保護、ネットワーク境界＝持ち出し防止）で考えます。

① IAM（Identity and Access Management）

「誰が(プリンシパル)・何に(リソース)・何を(ロール)できるか」 を管理する仕組み。

プリンシパル（ユーザー/グループ/サービスアカウント） │ に ▼ ロール（権限の束）を付与 │ 対象は ▼ リソース（プロジェクト/データセット/バケット）

② 組織ポリシー（Organization Policy）

組織・フォルダ・プロジェクトに制約を強制する仕組み。IAMが「許可」を与えるのに対し、組織ポリシーは「禁止・制限」を上から課す。

③ 暗号化と鍵管理

GCPは保存時(at rest)・転送時(in transit)とも自動で暗号化されます。鍵の管理方法で3段階：

方式鍵の管理者使いどころ
デフォルト暗号化Google特別な要件がなければこれでよい（自動）
CMEK（顧客管理鍵）あなた（Cloud KMSで管理）鍵のローテーション/無効化を自分で制御したい
CSEK（顧客提供鍵）あなた（鍵を持ち込む）鍵をGCPに預けたくない厳格な要件

④ プライバシーと PII の取り扱い

PII（個人を特定できる情報） = 氏名・住所・電話番号・クレカ番号など。

⑤ リージョン考慮（データ主権）

データ主権 (Data Sovereignty) = データを特定の国・地域内に保存・処理する法的要件（例：EUのデータはEU内に）。

⑥ データガバナンス：プロジェクト/データセット/テーブル設計

アクセス制御と請求を意識した階層設計を行う。

組織 └── フォルダ（部門など） └── プロジェクト（請求・権限の境界） └── BigQueryデータセット（IAM付与の単位） └── テーブル / ビュー

⑦ マルチ環境（開発 vs 本番）

開発(dev)・ステージング・本番(prod)を別プロジェクトに分離するのが基本。事故防止・権限分離・コスト可視化に有効。

1.2 信頼性と忠実性を考慮した設計 📘 基礎

「データが壊れない・止まらない・正しい」を担保する設計です。

① データの準備とクレンジング

取り込んだ生データを、分析に使える品質に整える工程。担当サービス：

サービス役割
DataformBigQuery内のSQL変換（ELT）をバージョン管理・依存解決・テスト
Dataflowコードベースの柔軟な変換（バッチ/ストリーミング）
Cloud Data FusionGUIでノーコード/ローコードのETL

② 監視とオーケストレーション

パイプラインを「順番に・依存関係を守って」実行し、状態を監視する。

③ 災害復旧（DR）と耐障害性

障害が起きてもデータを失わず・早く復旧する設計。

④ ACID 準拠と可用性の判断

ACID = 原子性・一貫性・独立性・永続性。トランザクションの正しさの保証。

要件選ぶべきストレージ
強いACID・トランザクションが必須Cloud SQL / AlloyDB / Spanner
結果整合性で良い・超低レイテンシ大量処理Bigtable / Firestore
💡 イメージ 「銀行残高」はACID必須、「IoTセンサーの大量書き込み」は結果整合性でOK、というイメージ。

⑤ データ検証

取り込んだデータが期待どおりか確認する。スキーマ検証、件数チェック、重複・NULL検出など。Dataformのアサーションやパイプライン内のバリデーションで実施。

1.3 柔軟性とポータビリティを考慮した設計 📘 基礎

将来の変化に強い設計をします。

① ビジネス要件のマッピング

現在だけでなく将来の要件（データ量の増加、新しい分析、規制変更）を見越してアーキテクチャを選ぶ。

② ポータビリティ（移植性）

特定環境にロックインされず、他クラウドやオンプレでも動かせる設計。

③ データのステージング・カタログ化・プロファイリング・ディスカバリ

データガバナンスの一部。「どこに・何のデータがあるか」を管理し、発見可能にする。

1.4 データ移行の設計 📘 基礎

既存システムからGoogle Cloudへデータを移す計画を立てます。

① 現状分析と移行計画

ステークホルダー・ユーザー・既存プロセス・技術を分析し、現状(As-Is)→目標(To-Be)の移行計画を作る。

② 移行サービスの使い分け

サービス用途選ぶ条件
BigQuery Data Transfer ServiceSaaS・他DWH → BigQueryTeradata/Redshift/SaaSの定期取り込み
Database Migration Service (DMS)DB → Cloud SQL/AlloyDBデータベースの移行（最小ダウンタイム）
Datastream継続的なCDC（変更データ複製）リアルタイムにDB変更をBQ/GCSへ
Transfer Appliance物理装置でオフライン転送数十TB〜PB級、ネットワークが非現実的
Storage Transfer Serviceオンライン大容量転送S3/オンプレ → GCS
移行サービス選択の早見: DBを移したい ────────────► DMS DB変更を継続的に複製 ─────► Datastream 他DWH/SaaSから定期取込 ──► BigQuery Data Transfer Service 巨大データをオフラインで ─► Transfer Appliance 他クラウド/オンプレ→GCS ─► Storage Transfer Service

📌 このセクションの基礎まとめ

🔑 基礎まとめ
  • セキュリティは多層：IAM（誰が何を）＋暗号化（データ保護）＋VPC SC（境界）＋DLP（PII）
  • 信頼性はACIDか結果整合性かの判断と、冗長化・DRが核
  • ポータビリティはBigLake/Omniとオープンフォーマット、ガバナンスはDataplex
  • 移行は5つのサービスの使い分けを暗記

次は「🔧 応用」タブで設計判断とトレードオフを学びます。

🔧 実践（中堅）と🎯 発展（シニア）レベル。「どう設計判断するか」「トレードオフは何か」「試験のひっかけ」に焦点を当てます。

1.1 セキュリティとコンプライアンスの設計判断 🔧 実践

🔧 IAM 設計のベストプラクティス

🔧 VPC Service Controls（VPC SC）

⚠️ 試験頻出 「IAMで権限を絞っても情報漏洩を防げない。追加すべきは？」→ VPC Service Controls

🔧 CMEK vs CSEK の判断

観点CMEKCSEK
鍵の保管場所Cloud KMS（GCP内）自分で持つ（GCP外）
ローテーションKMSで自動化可自分で管理
運用負荷中高
使う場面一般的なコンプライアンス要件鍵をGCPに一切預けられない厳格要件

🎯 PII 保護の設計パターン 🎯 発展

⚠️ 試験頻出 「アナリストに集計だけ見せ、個人情報は隠したい」→ 承認済みビュー＋列レベルセキュリティ

🎯 データ主権・規制対応 🎯 発展

1.2 信頼性と忠実性の設計判断 🔧 実践

🔧 ストレージのACID/整合性選定（最重要の判断）

強整合 + グローバル分散 + 無停止スケール ──► Spanner 強整合 + リージョナル + 一般的なRDB ──────► Cloud SQL / AlloyDB 結果整合 + 超低レイテンシ + 大量書き込み ──► Bigtable 結果整合 + モバイル同期 + ドキュメント ────► Firestore
⚠️ ひっかけ 「グローバルで強整合なトランザクション」→ ほぼSpanner一択／「ペタバイト級の時系列、ミリ秒読み取り」→ Bigtable

🔧🎯 DR戦略（RPO/RTOで構成を変える）

要件構成例
RPO/RTO厳しい（ほぼゼロ）Spannerマルチリージョン、Cloud SQL HA＋クロスリージョンレプリカ
RPO数分許容リードレプリカ、Datastreamで別リージョンへ複製
コスト優先・RPO数時間定期バックアップ/エクスポートをGCSマルチリージョンへ

🎯 データ検証の作り込み 🎯 発展

1.3 柔軟性とポータビリティの設計判断 🎯 発展

🎯 マルチクラウド戦略

⚠️ ひっかけ 「データをコピーせずマルチクラウドで分析」→ BigQuery Omni / BigLake

🔧 ガバナンスの設計

1.4 データ移行の設計判断 🔧 実践

🔧 移行サービス選定（決定木）

質問1: DBそのものを移す？ YES → ダウンタイム最小化が必要？ → DMS（継続レプリケーション付き移行） 質問2: DB変更を継続的にBQ/GCSへ流す？ YES → Datastream（サーバーレスCDC） 質問3: 他のDWH/SaaSから定期的に取り込む？ YES → BigQuery Data Transfer Service 質問4: データ量が巨大でネットワーク転送が非現実的？ YES → Transfer Appliance（オフライン物理転送） 質問5: 他クラウド/オンプレのファイルをGCSへ？ YES → Storage Transfer Service

🎯 移行戦略（ビッグバン vs 段階的） 🎯 発展

🎯 統合シナリオ演習（考え方の練習） 🎯 発展

📋 シナリオ 多国籍小売企業。①各国の購買データ（PII含む）を②グローバルで分析したいが、③EUデータはEU内保存が必須。④オンプレの500TBの履歴データを移行。⑤分析者にはPIIを見せない。

設計の骨子（解答例）

  1. EUデータ用にEUリージョンのプロジェクト/データセットを分離（データ主権）→ 組織ポリシーで誤配置防止
  2. 500TBはネットワーク転送が非現実的 → Transfer Appliance
  3. 取り込み時にCloud DLPでPIIをトークン化
  4. 分析は承認済みビュー＋ポリシータグで列マスキング
  5. グローバル分析は各リージョンのBigQueryをAnalytics Hubで共有、またはBigQuery Omniで越境せず分析
  6. データ持ち出し防止にVPC Service Controlsで境界を設定
💡 ポイント この「複数の要件を各サービスに割り当てる」思考が本番の設計問題そのものです。

まとめ：このセクションの設計判断の型

🔑 設計判断の型
  • セキュリティはIAM＋VPC SC＋DLP＋暗号化の組み合わせで多層に
  • 整合性要件がSpanner/CloudSQL vs Bigtable/Firestoreを分ける
  • マルチクラウドはOmni/BigLake、ガバナンスはDataplex
  • 移行は5サービスの決定木を暗記し、必ず検証フェーズを設計に入れる

「🎯 要点と暗記」タブで記憶を固めましょう。

試験直前の総ざらい用。暗記すべき表と一問一答でセクション1を固めます。

🔑 暗記必須テーブル 🎯 暗記

暗号化の3方式

方式鍵管理キーワード
デフォルトGoogle何もしなくても暗号化される
CMEK顧客（KMS）鍵のローテーション/失効を制御
CSEK顧客（持ち込み）鍵をGCPに預けない

セキュリティ層の役割分担

課題解決サービス
誰が何にアクセスできるかCloud IAM
組織全体に制約を強制組織ポリシー
データの外部持ち出し防止VPC Service Controls
PIIの検出・マスキングCloud DLP
暗号鍵の管理Cloud KMS
列レベルアクセス制御ポリシータグ
元テーブル非公開で結果共有承認済みビュー

整合性とストレージ

要件ストレージ
強整合・グローバル分散Spanner
強整合・リージョナルRDBCloud SQL / AlloyDB
結果整合・大量低レイテンシBigtable
結果整合・ドキュメント/同期Firestore

移行サービス

用途サービス
DB移行（低ダウンタイム）Database Migration Service
継続的CDCDatastream
他DWH/SaaS定期取込BigQuery Data Transfer Service
巨大データのオフライン転送Transfer Appliance
他クラウド/オンプレ→GCSStorage Transfer Service

✅ 一問一答（確認テスト）

Q1. IAMで権限を最小化したが、認証情報漏洩によるデータ持ち出しを防ぎたい。追加すべきは？

A. VPC Service Controls（サービス境界を作り、境界外へのデータ移動をブロック）

Q2. 鍵をGoogle Cloudに一切預けず、自社で完全に保持したい暗号化方式は？

A. CSEK（顧客提供暗号鍵）

Q3. グローバル規模で強整合なトランザクションが必要なRDBは？

A. Cloud Spanner

Q4. アナリストに集計結果だけ見せ、元の個人情報テーブルへの直接アクセスは与えたくない。使う機能は？

A. 承認済みビュー（Authorized View）。加えて列レベルはポリシータグ、行レベルは行レベルセキュリティ。

Q5. オンプレの800TBの履歴データをGoogle Cloudへ移行したい。ネットワーク帯域が限られる。最適な方法は？

A. Transfer Appliance（物理アプライアンスでオフライン転送）

Q6. オンプレのMySQLの変更をリアルタイムにBigQueryへ複製し続けたい。使うサービスは？

A. Datastream（サーバーレスCDC）

Q7. EUの顧客データはEU域内に保存する法的要件がある。設計上のポイントは？

A. データセット/リソースのロケーションをEUに固定（BigQueryデータセットは作成後変更不可）。組織ポリシーで誤配置を防止。

Q8. IoTセンサーから毎秒数百万件の書き込み、ミリ秒での読み取りが必要。結果整合性で良い。ストレージは？

A. Bigtable

Q9. BigQuery内のSQL変換をバージョン管理し、依存関係とテストを宣言的に管理したい。使うツールは？

A. Dataform

Q10. データをGCPに移動せず、AWS S3上のデータをBigQueryで分析したい。使う機能は？

A. BigQuery Omni（マルチクラウド分析。BigLakeも関連）

🎯 ひっかけ注意ポイント

❌ ひっかけ注意
  • 「IAMで十分」と思わせて実はVPC SCが答え（境界防御）
  • 「自前で暗号化実装」よりCMEK/CSEK（マネージド鍵管理）
  • 「大量データを通常のネットワークで転送」よりTransfer Appliance（オフライン）
  • 「データをコピーして各所に配る」よりAnalytics Hub / BigQuery Omni（コピー不要）
  • BigQueryデータセットのロケーションは後から変えられない点を突く問題

📝 セルフチェック

← ホームに戻る セクション2：データの取り込みと処理 → 📝 問題集を解く