セクション1 応用：データ処理システムの設計 🔧🎯
このファイルは 🔧 実践（中堅） と 🎯 発展（シニア） レベル。 「どう設計判断するか」「トレードオフは何か」「試験のひっかけ」に焦点を当てます。基礎概念は 01_基礎.md を参照。
1.1 セキュリティとコンプライアンスの設計判断
🔧 IAM 設計のベストプラクティス
- 個人ではなくGoogleグループに権限付与：異動・退職時の管理が容易
- 基本ロールは使わない：本番では事前定義ロール、足りなければカスタムロール
- サービスアカウント：鍵ファイルの配布は避け、Workload Identity連携を優先（鍵漏洩リスクを排除）
- BigQueryのアクセス制御の粒度：プロジェクト → データセット → テーブル/列（ポリシータグ）→ 行（行レベルセキュリティ）
🔧 VPC Service Controls（VPC SC）
- IAMが正しくても、認証情報の漏洩や内部不正でデータが外部に持ち出されるリスクは残る
- VPC SCは**サービス境界（perimeter）**を作り、境界外へのデータ移動をブロック
- 例：「BigQueryのデータを、許可したVPC内からしかアクセスできないようにする」
- ⚠️ 試験頻出：「IAMで権限を絞っても情報漏洩を防げない。追加すべきは？」→ VPC Service Controls
🔧 CMEK vs CSEK の判断
| 観点 | CMEK | CSEK |
|---|---|---|
| 鍵の保管場所 | Cloud KMS（GCP内） | 自分で持つ（GCP外） |
| ローテーション | KMSで自動化可 | 自分で管理 |
| 運用負荷 | 中 | 高 |
| 使う場面 | 一般的なコンプライアンス要件 | 鍵をGCPに一切預けられない厳格要件 |
🎯 PII 保護の設計パターン
- 取り込み時にDLPでスキャン → マスキング/トークン化してからBigQueryへ（生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マルチリージョンへ |
- BigQuery：マルチリージョンデータセットで地理冗長、タイムトラベル(7日)＋スナップショットで論理破損に対応
- Pub/Sub：シーク機能で過去メッセージを再処理（データ欠損・破損のリカバリ）
- Dataflow：スナップショットでストリーミング状態を保存し復元
🎯 データ検証の作り込み
- Dataformのアサーションでnull/一意性/参照整合性を宣言的にテスト
- パイプラインにデッドレターキューを設け、不正レコードを隔離して処理を止めない
1.3 柔軟性とポータビリティの設計判断
🎯 マルチクラウド戦略
- BigQuery Omni：データをGCPに移動せず、AWS S3/Azure上でその場で分析（データ移動コスト・主権要件を回避）
- BigLake：オープンフォーマット（Parquet/Iceberg）でストレージとコンピュートを分離し、ロックインを軽減
- ⚠️ 「データをコピーせずマルチクラウドで分析」→ BigQuery Omni / BigLake
🔧 ガバナンスの設計
- Dataplexでドメイン（レイク/ゾーン）を定義し、横断的に品質・セキュリティを適用
- Dataplex Catalogでデータ資産を検索可能にし、シャドーデータを削減
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 段階的）
- ビッグバン移行：一度に切り替え。小規模・許容停止時間が長い場合
- 段階的移行：並行稼働しながら徐々に移行。大規模・無停止要件。Datastreamで新旧同期しつつ検証
- 移行後は必ず検証フェーズ（件数・チェックサム・サンプリング比較）を計画に含める
🎯 統合シナリオ演習（考え方の練習）
シナリオ：多国籍小売企業。①各国の購買データ（PII含む）を②グローバルで分析したいが、③EUデータはEU内保存が必須。④オンプレの500TBの履歴データを移行。⑤分析者にはPIIを見せない。
設計の骨子（解答例）
- EUデータ用にEUリージョンのプロジェクト/データセットを分離（データ主権）→ 組織ポリシーで誤配置防止
- 500TBはネットワーク転送が非現実的 → Transfer Appliance
- 取り込み時にCloud DLPでPIIをトークン化
- 分析は承認済みビュー＋ポリシータグで列マスキング
- グローバル分析は各リージョンのBigQueryをAnalytics Hubで共有、またはBigQuery Omniで越境せず分析
- データ持ち出し防止にVPC Service Controlsで境界を設定
この「複数の要件を各サービスに割り当てる」思考が本番の設計問題そのものです。
まとめ：このセクションの設計判断の型
- セキュリティはIAM＋VPC SC＋DLP＋暗号化の組み合わせで多層に
- 整合性要件がSpanner/CloudSQL vs Bigtable/Firestoreを分ける
- マルチクラウドはOmni/BigLake、ガバナンスはDataplex
- 移行は5サービスの決定木を暗記し、必ず検証フェーズを設計に入れる
→ 03_要点と暗記.md で記憶を固めましょう。