セクション5 基礎：データワークロードの保守と自動化 📘
このファイルは 📘 基礎レベル。各サブトピックの「概念」と「サービスの役割」を理解することがゴールです。 運用判断やトレードオフは 02_応用.md で扱います。
5.1 リソースの最適化（コスト最小化）
運用フェーズの大きなテーマは 「ビジネス要件を満たしつつコストを最小化する」 こと。GCPのデータ処理コストは大きく コンピュート（処理） と ストレージ（保存） に分かれ、それぞれ削減の打ち手が違います。
コスト最適化の2大領域
コンピュート ──► 使った分だけ / 必要なときだけ起動 / 中断OKなら安いVM
ストレージ ───► アクセス頻度でクラス分け / 不要データの自動削除（ライフサイクル）
① Dataproc：永続クラスタ vs ジョブ単位（ephemeral）クラスタ
Dataproc はマネージドな Spark / Hadoop クラスタ。コスト最適化の最重要トピックです。
| 方式 | 説明 | コスト | 使いどころ |
|---|---|---|---|
| 永続クラスタ（long-running） | 常時起動しっぱなし | 高い（アイドル時も課金） | 対話的に使い続ける/常時ジョブがある |
| ジョブ単位クラスタ（ephemeral） | ジョブのたびに起動→完了で破棄 | 低い（必要なときだけ） | バッチジョブ中心。試験の推奨形 |
- ephemeral クラスタの鉄則：データは クラスタ内のHDFSではなく Cloud Storage（GCS）に置く。クラスタを破棄してもデータが残る（ストレージとコンピュートの分離）。
- ジョブ完了後にクラスタを自動削除する 自動削除（auto-delete / max-idle / max-age） 設定が使える。
ephemeral クラスタの流れ
GCSにデータ ──► クラスタ起動 ──► ジョブ実行 ──► 結果をGCSへ ──► クラスタ破棄
（計算リソースは使った時間だけ課金）
② プリエンプティブル VM / Spot VM
通常VMより大幅に安い（最大60〜91%引き）が、Googleの都合でいつでも停止され得るVM。
- 耐障害性のあるバッチ処理（途中で止まっても再実行できるジョブ）に向く
- Dataprocの セカンダリワーカー に使うのが定番。プライマリワーカーは通常VMで安定性を確保
- ⚠️ 状態を持つ処理・低レイテンシ要件・ストリーミングの主役には不向き
- Spot VM はプリエンプティブルVMの後継。最大実行時間の制限がない点が主な違い
③ BigQuery：オンデマンド vs 定額（容量ベース）
BigQueryのクエリ課金は2つのモデル。スロット（Slot） = クエリ実行の計算単位。
| モデル | 課金 | 向くケース |
|---|---|---|
| オンデマンド | スキャンしたデータ量（TBあたり） | クエリが散発的・量が読めない・小〜中規模 |
| 容量ベース（Editions / 予約） | 確保したスロット時間 | クエリ量が多く予測可能・コストを固定したい |
- オンデマンドは「使った分だけ」だが、スキャン量が増えると高くなる
- 容量ベースは「枠を買う」イメージ。大量・継続利用なら定額の方が安く、予算も読める
- ストレージ課金はクエリモデルと独立（アクティブ/長期ストレージで自動的に単価が変わる）
④ ストレージのコスト最適化
| 打ち手 | 内容 |
|---|---|
| GCSストレージクラス | Standard / Nearline / Coldline / Archive をアクセス頻度で選ぶ |
| オブジェクトライフサイクル管理 | N日後に低頻度クラスへ移動/削除を自動化 |
| BigQueryパーティション/クラスタリング | スキャン量を減らしオンデマンドのコストを削減 |
| BigQuery長期ストレージ | 90日変更のないテーブルは自動で単価が約半額に |
5.2 自動化と再現性の設計
データ処理は 「毎日同じ手順で・依存関係を守って・失敗したらやり直せる」 ことが重要。手作業をなくし、再現可能にするのが自動化の目的です。
① Cloud Composer（マネージド Airflow）と DAG
Cloud Composer は Apache Airflow のマネージドサービス。複雑な依存関係を持つワークフローを DAG（有向非巡回グラフ / Directed Acyclic Graph） で定義します。
DAG（タスクの依存関係を矢印で表現。循環しない）
抽出(extract) ──► 変換(transform) ──► ロード(load) ──► 通知(notify)
│
└──► 品質チェック(validate)
- タスク（Task）：DAG内の処理の単位（オペレータで定義）
- オペレータ（Operator）：何をするか（BigQueryクエリ、Dataflow起動、GCS操作など）
- スケジュール：cron式などで定期実行（例：毎日2時）
- 再実行（backfill / clear / retry）：失敗タスクや過去日付の再処理ができる
② 冪等性（idempotency）
自動化で最重要の設計概念。冪等 = 同じ処理を何回実行しても結果が同じになる性質。
- 再実行（リトライ）しても二重に書き込まれない・壊れないようにする
- 例：「INSERTで追記」ではなく 「特定パーティションをDELETE/上書きしてからINSERT」 や MERGE にする
- DAGが途中で失敗→再実行しても安全、を担保するのが冪等設計
③ オーケストレーションの選択肢
| サービス | 役割 | 使いどころ |
|---|---|---|
| Cloud Composer | DAGで複雑な依存関係を管理（Airflow） | 多数のタスク・分岐・依存がある本格的なワークフロー |
| Workflows | サーバーレスなAPI/サービスの順次実行（YAML/JSON） | 軽量なサービス連携・HTTP/API呼び出しの編成 |
| Cloud Scheduler | cronベースのジョブトリガー | 「定期的に何かをキックする」だけのシンプルな起動 |
ざっくり使い分け
複雑な依存・多数タスク ──► Cloud Composer
軽量なサービス連携 ──────► Workflows
定期トリガーだけ ────────► Cloud Scheduler
5.3 ビジネス要件に基づくワークロードの編成
「重要な処理に必要なリソースを確保しつつ、全体のコストを抑える」ためのキャパシティ管理です。BigQueryを中心に問われます。
① BigQuery Editions（容量ベースの3エディション）
容量ベース課金で使う3段階のエディション。上位ほど機能とSLAが手厚い。
| エディション | 位置づけ | 主な特徴 |
|---|---|---|
| Standard | 入門・基本分析 | 低価格。基本的な分析機能 |
| Enterprise | 一般的な企業利用 | より多くの機能・コミットメント対応 |
| Enterprise Plus | 最上位・高度な要件 | 最高レベルの機能・コンプライアンス・DR向け機能 |
- エディションは 予約（reservation） とセットで使う。スロットの枠を確保する仕組み。
② スロット予約（Reservations）とコミットメント
| 用語 | 説明 |
|---|---|
| スロット（Slot） | クエリ実行の計算単位 |
| 予約（Reservation） | 確保したスロットを、プロジェクト/フォルダ等に割り当てる枠 |
| 割り当て（Assignment） | どのプロジェクト/組織が、どの予約を使うかの紐付け |
| コミットメント（Commitment） | 一定容量を期間（年/3年）契約し単価を下げる |
| Autoscaling（自動スケール） | 需要に応じてスロットを自動増減（baseline＋max） |
キャパシティの階層
コミットメント（容量を購入）
└── 予約（枠を切り出す：例 dataeng用 2000スロット）
└── 割り当て（その枠を使うプロジェクトを指定）
③ インタラクティブ（対話的）vs バッチ クエリ
BigQueryのクエリジョブには2つの優先度がある。
| 種類 | 説明 | 特徴 |
|---|---|---|
| インタラクティブ（interactive） | すぐ実行（デフォルト） | レイテンシ重視。ダッシュボード・対話分析向け |
| バッチ（batch） | スロットに空きが出たら実行 | 急がない大量処理向け。リソース競合を避けられる |
- バッチクエリは即時性を犠牲に、リソースの効率利用とコスト平準化に役立つ
5.4 プロセスの監視とトラブルシューティング
「動いているか・遅くないか・コストは想定内か」を見える化（可観測性 / Observability）し、問題を切り分けます。
① 可観測性の3本柱とサービス
| サービス | 役割 | 見るもの |
|---|---|---|
| Cloud Monitoring | メトリクスの監視・アラート・ダッシュボード | CPU・スロット使用率・スループット・エラー率 |
| Cloud Logging | ログの収集・検索・分析 | 実行ログ・エラーメッセージ・監査ログ |
| Cloud Trace / Error Reporting | レイテンシ追跡・エラー集約 | 遅延の内訳・例外の集約 |
- アラートポリシー：閾値（例：エラー率5%超）を超えたら通知
- 監査ログ（Audit Logs）：誰がいつ何をしたかの記録（Cloud Logging内）
② BigQuery の監視手段
| 手段 | 説明 |
|---|---|
| 管理リソースチャート（Administrative Resource Charts） | スロット使用量・予約の消費・ジョブ実行状況を可視化 |
| INFORMATION_SCHEMA | ジョブ・スロット・ストレージ・予約のメタデータをSQLで分析 |
| BigQuery 管理パネル（Admin/Monitoring） | プロジェクト/組織横断の利用状況を確認 |
INFORMATION_SCHEMA.JOBSで 高コストクエリ・スキャン量・実行時間 を分析できる
③ クォータと上限
| 用語 | 説明 |
|---|---|
| クォータ（Quota） | APIリクエスト数・同時実行数などの利用上限（プロジェクト単位） |
| 上限引き上げ | コンソールから増量をリクエスト可能 |
| 計画使用量の監視 | 予約/クォータに対し、どれだけ使っているかを継続監視 |
- ⚠️ ジョブ失敗の原因が クォータ超過 であることは多い（同時クエリ数・APIレート等）
④ 課金（コスト）の監視
| 手段 | 説明 |
|---|---|
| 予算とアラート（Budgets & Alerts） | 予算超過を通知 |
| コスト内訳レポート / BigQueryへの請求エクスポート | コストを詳細に分析（プロジェクト/サービス/ラベル別） |
| ラベル（Labels） | リソースにタグ付けし、コストを按分・可視化 |
5.5 障害の認識と影響の軽減
「障害が起きる前提」で、データを失わず・早く復旧する設計です。設計セクション(1.2)のDRを、運用の具体策に落とし込みます。
① 冗長性のレベル
ゾーン障害に耐える ──► マルチゾーン（同一リージョン内の複数ゾーン）
リージョン障害に耐える ──► マルチリージョン / クロスリージョンレプリカ
| レベル | 守れる障害 | 例 |
|---|---|---|
| シングルゾーン | （なし） | 開発・非重要 |
| マルチゾーン（リージョナル） | ゾーン障害 | Cloud SQL HA、Dataprocの高可用構成 |
| マルチリージョン | リージョン障害 | BigQueryマルチリージョン、Spannerマルチリージョン |
② 耐障害性とリスタート（ジョブの再実行）
- 冪等性（5.2）を前提に、失敗したジョブを安全に再実行できるようにする
- チェックポイント / スナップショット：途中状態を保存し、そこから再開
- デッドレターキュー（DLQ）：処理できない不正レコードを隔離し、処理全体を止めない
③ データベースのHAとレプリケーション
| サービス | 高可用 / 冗長の仕組み |
|---|---|
| Cloud SQL | HA構成（同一リージョンの別ゾーンにスタンバイ→自動フェイルオーバー）、リードレプリカ（読み取り分散・別リージョン可）、自動バックアップ + PITR |
| Memorystore (Redis) | Redisクラスタ / Standard Tier（レプリカで自動フェイルオーバー）。シャーディングで容量・可用性を確保 |
| Spanner | マルチリージョン構成で地理冗長・自動フェイルオーバー |
| AlloyDB | リージョン内冗長 + クロスリージョンレプリケーション |
- ⚠️ HA = 可用性（止まらない）。リードレプリカ = 読み取りスケール（兼DR）。目的が違う。
④ データ破損・欠損への備え（サービス別の復旧機能）
| サービス | 復旧機能 | 何ができるか |
|---|---|---|
| BigQuery | タイムトラベル（7日間） + スナップショット | 誤更新/削除前の状態を参照・復元 |
| Pub/Sub | シーク（Seek） | 過去のタイムスタンプ/スナップショットへ巻き戻して再配信 |
| Dataflow | スナップショット | ストリーミングパイプラインの状態を保存し復元・移行 |
| Cloud SQL | 自動バックアップ + PITR（特定時点復元） | 任意の時点へ復元 |
| GCS | オブジェクトのバージョニング | 上書き/削除されたオブジェクトを復元 |
「壊れた/消えた」への定番カード
BigQueryのデータ ──► タイムトラベル(7日) / スナップショット
Pub/Subの取りこぼし ──► シークで再配信
Dataflowの状態 ──► スナップショットから復元
Cloud SQLのDB ──► バックアップ + PITR
📌 このセクションの基礎まとめ
- コスト最適化は 「必要なときだけ起動（ephemeral Dataproc）」「中断OKなら安いVM（Spot）」「使い方に合う課金（オンデマンド/Editions）」
- 自動化は Composer(DAG) + 冪等性 が核。軽量ならWorkflows、定期トリガーはScheduler
- キャパシティは Editions + 予約 + コミットメント、クエリは インタラクティブ vs バッチ
- 監視は Monitoring(メトリクス) + Logging(ログ) + INFORMATION_SCHEMA + 管理チャート、クォータ/課金も監視対象
- 耐障害性は 冗長レベル（ゾーン/リージョン） と サービス別の復旧機能（タイムトラベル/シーク/スナップショット/HA/レプリカ） を暗記
次は 02_応用.md で運用判断とトレードオフを学びます。