01_基礎

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

このファイルは 📘 基礎レベル。各サブトピックの「概念」と「サービスの役割」を理解することがゴールです。 設計判断やトレードオフは 02_応用.md で扱います。

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 信頼性と忠実性を考慮した設計

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

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

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

サービス 役割
Dataform BigQuery内のSQL変換（ELT）をバージョン管理・依存解決・テスト
Dataflow コードベースの柔軟な変換（バッチ/ストリーミング）
Cloud Data Fusion GUIでノーコード/ローコードの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 Service SaaS・他DWH → BigQuery Teradata/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

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

次は 02_応用.md で設計判断とトレードオフを学びます。