セクション5：データワークロードの保守と自動化
運用フェーズの中心テーマ。ビジネス要件を満たしつつコストを最小化し、ワークフローを自動化・再現可能にし、監視で問題を切り分け、障害に備える——実運用そのものを問う出題範囲です。
出題 ~18%
SECTION 5
📘 基礎
🔧 実践
🎯 発展
🔑 TL;DR（このセクションの核）
- コスト最適化：必要なときだけ起動（ephemeral Dataproc + GCS）／中断OKなら安いVM（Spot＝セカンダリワーカー）／使い方に合う課金（オンデマンド⇔Editions）
- 自動化：Composer(DAG) + 冪等性が核。軽量はWorkflows、定期トリガーだけはScheduler
- キャパシティ：Editions + 予約分離 + コミットメント/autoscaling、急がない大量処理はバッチクエリ
- 監視：Monitoring(メトリクス) + Logging(ログ) + INFORMATION_SCHEMA + 管理チャート、クォータ/課金も対象
- 耐障害性：冗長レベル（ゾーン⇔リージョン）とサービス別の復旧機能（タイムトラベル/シーク/スナップショット/HA/レプリカ）を暗記
🎯 学習目標チェックリスト
📖 学習コンテンツ
📘 基礎 各サブトピックの「概念」と「サービスの役割」を理解することがゴール。運用判断やトレードオフは「応用」タブで扱います。
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/レプリカ） を暗記
🔧 実践（中堅） 🎯 発展（シニア） 「どう運用判断するか」「トレードオフは何か」「試験のひっかけ」に焦点を当てます。
5.1 リソース最適化の判断
🔧 Dataproc：永続 vs ジョブ単位（ephemeral）の判断
判断の軸
ジョブが断続的（夜間バッチ等）＋ アイドル時間が長い ──► ephemeral クラスタ（完了後破棄）
クラスタを常に対話的に使う ＋ ほぼ常時稼働 ─────────► 永続クラスタも検討
- コスト最小化の定番解答 = ephemeral クラスタ + データはGCS。クラスタ内HDFSにデータを置くと破棄時に消えるため、ストレージとコンピュートを分離する。
- 永続クラスタでもコストを抑えるなら：オートスケーリングポリシーでワーカーを増減、セカンダリワーカーをSpot/プリエンプティブルにする。
⚠️ 注意
「Dataprocのコストを下げたい」→ まず ephemeral + GCS。次に Spotワーカー。
🔧 プリエンプティブル / Spot VM を使ってよいか
| 使ってよい | 使ってはいけない |
|---|
| 再実行可能なバッチ（冪等） | ステートフルな低レイテンシ処理 |
| Dataprocのセカンダリワーカー | 単一障害で全体が止まる構成 |
| 大量並列で一部中断を許容 | ストリーミングの主役・本番DB |
⚠️ 注意
プライマリワーカーやマスターをプリエンプティブルにしてはいけない（クラスタが不安定化）。セカンダリワーカーのみが定石。
🔧🎯 BigQuery：オンデマンド vs 容量ベース（Editions/予約）
| 観点 | オンデマンド | 容量ベース（Editions + 予約） |
|---|
| 課金 | スキャン量（TB単位） | 確保したスロット時間 |
| 予算の読みやすさ | 読みにくい（クエリ次第） | 読みやすい（固定/上限） |
| 向くケース | 散発的・小〜中量・読めない | 大量・継続・予測可能 |
| コスト暴走リスク | 大きなスキャンで急増 | 上限スロットで頭打ちにできる |
⚠️ 注意
- 「毎月のBigQueryコストが変動して読めない/高い」→ 容量ベース（Editions + コミットメント） で定額化＋上限設定。
- 逆に 「たまにしか使わない」のに定額を買うと無駄。散発的ならオンデマンドが安い。
🎯 発展
混在運用：基本はオンデマンド、特定の重いワークロードだけ予約、も可能。組織のニーズに合わせて割り当てる。
🎯 ビジネスクリティカル処理へのリソース確保
- 予約（reservation）を用途別に分離し、重要ジョブが他の負荷でスロット枯渇しないようにする（例：
prod-etl 予約と adhoc-analytics 予約を分ける）。
- アイドルスロットの共有設定：予約に空きがあれば他予約に貸す（
ignore idle slots をオフにして余剰を融通）。
⚠️ 注意
「重要なETLが、アナリストのアドホッククエリでリソース不足になる」→ 予約を分けて割り当てる。
5.2 自動化と再現性の設計判断
🔧 Composer DAG 設計のベストプラクティス
- 冪等に設計する：再実行で二重書き込みが起きないよう、パーティション上書き / MERGE / WRITE_TRUNCATE を使う。
- タスクは小さく・依存は明示：1タスク1責務にし、
set_upstream/downstream で依存を明確化。
- リトライとタイムアウト：
retries / retry_delay / execution_timeout を設定し、一時障害に自動対応。
- Sensor / Deferrable Operator：上流データの到着を待ってから後続を実行（ファイル到着待ち等）。
- 冪等な日付パラメータ化：
execution_date（論理日付）を使い、過去日付の バックフィル を安全にする。
⚠️ 注意
DAG定義ファイル自体で重い処理をしない（パース毎に走る）。処理はオペレータ内で。
🔧 Composer / Workflows / Cloud Scheduler の使い分け
質問1: 多数タスクの複雑な依存・分岐・リトライ・バックフィルが要る？
YES ──► Cloud Composer（Airflow / DAG）
質問2: 数個のAPI/サービスを順番に呼ぶ軽量な編成？
YES ──► Workflows（サーバーレス・YAML/JSON）
質問3: 「定期的にトリガーする」だけ？
YES ──► Cloud Scheduler（cron）
⚠️ 注意
- 「軽量なAPI連携なのにComposer」はオーバースペック（Composer環境は常時課金）。Workflowsの方が安く軽い。
- 逆に 複雑な依存・バックフィルが要るのにScheduler+スクリプトで頑張るのはアンチパターン → Composer。
🎯 発展
組み合わせも頻出：Scheduler が Workflows/Composer をキックする、Composer が Dataflow/BigQuery/Dataprocジョブを起動する。
🎯 再現性（reproducibility）の作り込み
- コードとしての構成：DAG・Dataflowテンプレート・Terraform をバージョン管理し、CI/CD（Cloud Build）でデプロイ。
- Flex Templates / Classic Templates（Dataflow）：パイプラインをテンプレ化し、同一ジョブを再現可能に起動。
- 環境分離：dev/prod でComposer環境・予約・バケットを分ける。
5.3 ワークロード編成の判断
🔧 インタラクティブ vs バッチ クエリの判断
| 状況 | 選択 |
|---|
| ダッシュボード/対話分析、すぐ結果が要る | インタラクティブ（デフォルト） |
| 夜間の大量集計、急がない | バッチ（スロット空き次第） |
| 同時実行上限/スロット競合を避けたい | バッチに回して平準化 |
⚠️ 注意
「インタラクティブの同時実行クォータに当たる大量ジョブ」→ バッチクエリにしてキュー実行。
🔧🎯 Editions の選択とコミットメント
Standard ────► まず使う・基本分析・小規模
Enterprise ──► 一般企業・機能とコミットメントが必要
Enterprise Plus ► 最高水準の機能・コンプライアンス・DR要件
- コミットメント（年/3年）で単価を下げる。継続的に一定量を使うことが前提。
- Autoscaling：baseline（常時確保）＋ max（上限）で、急なスパイクに対応しつつ上限でコストを抑える。
⚠️ 注意
「需要に波があるが、ピークで枯渇させたくない / 谷で無駄も出したくない」→ baseline + autoscaling の組み合わせ。
🎯 発展
エディションは予約単位で選ぶ。要件（CMEK必須・DR・特定機能）が上位エディション限定なら、その予約だけ上位にする。
5.4 監視とトラブルシューティングの判断
🔧 何で何を見るか（切り分けの型）
メトリクス（傾向・閾値） ──► Cloud Monitoring（CPU/スロット/スループット/エラー率）＋ アラート
ログ（個別事象・原因） ───► Cloud Logging（エラーメッセージ/スタック/監査）
BigQuery固有の分析 ──────► INFORMATION_SCHEMA / 管理リソースチャート
コスト ──────────────────► 予算アラート / 請求のBigQueryエクスポート
🔧 BigQuery トラブルシュートの定番
| 症状 | 調べ方 / 対処 |
|---|
| クエリが遅い | INFORMATION_SCHEMA.JOBS でスキャン量・スロット・ステージを確認。パーティション/クラスタリング・スロット不足を疑う |
| コストが高い | スキャン量の多いクエリを特定、SELECT * を避ける、パーティションプルーニング、容量ベースへ移行 |
| スロット待ちで詰まる | 予約のスロット不足。autoscaling/コミットメント増、バッチ化、予約分離 |
| ジョブが失敗 | エラーメッセージ＋クォータ（同時実行/APIレート）を確認 |
🔧 クォータ・課金・エラーの切り分け
- クォータ超過：
Quota exceeded 系エラー → コンソールで使用量確認 → 上限引き上げ申請、またはリトライ/レート制御。
- 課金問題：予算アラート＋請求エクスポートで どのサービス/プロジェクト/ラベルが高いか を特定。
- 権限エラー：IAM不足（運用範囲外だが、ジョブ失敗原因として頻出）。
⚠️ 注意
試験では 「ジョブが断続的に失敗。原因の調べ方は？」→ Cloud Logging のエラー + クォータ確認 が定番。
🎯 計画使用量の監視（capacity planning）
- 予約スロットの 使用率（utilization） を継続監視し、慢性的に上限張り付き → 増量、低稼働 → 縮小やオンデマンド回帰を判断。
- ラベルでチーム別コストを可視化し、チャージバック/最適化につなげる。
5.5 障害軽減（DR）の設計判断
🔧 冗長レベルの選び方（RPO/RTOで決める）
| 要件 | 構成例 |
|---|
| RPO/RTO ほぼゼロ（無停止） | Spannerマルチリージョン、Cloud SQL HA + クロスリージョンリードレプリカ、BigQueryマルチリージョン |
| RPO数分許容 | リードレプリカ昇格、Datastreamで別リージョン複製 |
| コスト優先・RPO数時間 | 定期バックアップ/エクスポートをGCSマルチリージョンへ |
⚠️ 注意
「ゾーン障害に耐えたい」→ マルチゾーン（Cloud SQL HA）。「リージョン障害に耐えたい」→ マルチリージョン/クロスリージョンレプリカ。レベルを取り違えさせるひっかけに注意。
🔧 Cloud SQL：HA とリードレプリカの違い
| HA構成 | リードレプリカ |
|---|
| 目的 | 可用性（自動フェイルオーバー） | 読み取りスケール / DR |
| 配置 | 同一リージョンの別ゾーン（スタンバイ） | 同一/別リージョン |
| 自動切替 | あり | なし（手動で昇格 = promote） |
⚠️ 注意
「読み取り負荷を分散したい」→ リードレプリカ。「プライマリ障害で自動的に切り替えたい」→ HA構成。両者は目的が違う。
🎯 発展
リージョン災害対策は クロスリージョンのリードレプリカを別リージョンに置き、災害時に昇格。
🔧 Memorystore (Redis) の冗長
- Standard Tier：レプリカを持ち、プライマリ障害時に自動フェイルオーバー（Basic Tierはレプリカなし＝冗長性なし）。
- Redis クラスタ（Cluster）：シャーディングで水平スケール＋各シャードにレプリカで可用性。大容量・高スループット向け。
⚠️ 注意
「キャッシュの可用性を高めたい」→ Standard Tier / Redisクラスタ（Basicは不可）。
🎯 データ破損・欠損への備え（サービス別カード）
誤って大量削除/更新した（BigQuery） ──► タイムトラベル(7日) で復元、超過分はスナップショットで保護
ストリーミングを取りこぼした（Pub/Sub） ──► シークで過去タイムスタンプへ巻き戻し再配信
Dataflowのストリーミング状態を保持/移行 ──► スナップショットから復元
DBを特定時点へ戻したい（Cloud SQL） ──► 自動バックアップ + PITR
GCSのオブジェクト上書き/削除 ──► バージョニングで復元
⚠️ 注意
- BigQueryタイムトラベルは7日固定。それ以上の保護が要るなら テーブルスナップショットやエクスポートを併用。
- Pub/Subの「メッセージを再処理したい」は シーク（スナップショット/タイムスタンプへ）。リプレイ要件で頻出。
🎯 統合シナリオ演習（考え方の練習）
シナリオ
あるEC企業の運用課題。①毎晩、Spark変換ジョブを実行しているがDataprocの常時稼働クラスタのコストが高い。②BigQueryの月額費用が変動して読めず、重要なETLがアナリストのアドホッククエリでスロット不足になることがある。③ETLは多数のタスクが依存し、失敗時に手動でやり直していて再現性がない。④本番DB（Cloud SQL）がゾーン障害で一度停止した。⑤先週、分析者が誤って本番テーブルを上書きし、復旧に苦労した。⑥ジョブが時々失敗するが原因がすぐ分からない。
設計の骨子（解答例）
- Dataprocコスト：常時稼働を廃止し、ジョブ単位（ephemeral）クラスタ + データはGCSに。セカンダリワーカーをSpot VMに。完了後に自動削除。
- BigQueryコストとETL確保：容量ベース（Editions + コミットメント）で月額を固定・上限化。予約を
prod-etl と adhoc に分離し、重要ETLのスロットを確保。アドホックは別予約 + 急がないものはバッチクエリ。
- 再現性：手作業をやめ、Cloud Composer の DAGでオーケストレーション。冪等設計（パーティション上書き/MERGE） + リトライ/タイムアウトで、失敗時に安全に再実行・バックフィル。
- DB可用性：Cloud SQLをHA構成（別ゾーンにスタンバイ→自動フェイルオーバー）に。リージョン災害対策としてクロスリージョンのリードレプリカも配置。
- データ破損復旧：BigQueryタイムトラベル(7日)で即時復元、重要テーブルはスナップショットで7日超も保護。
- 可観測性：Cloud Monitoringでスロット使用率・エラー率にアラート、Cloud Loggingで失敗ジョブのエラーを追跡、INFORMATION_SCHEMAで高コスト/低速クエリとクォータを分析。
💡 ポイント
この「運用課題を、コスト最適化・自動化・キャパシティ・DR・監視の各カードに割り当てる」思考が本番の運用問題そのものです。
📌 このセクションの運用判断の型
- コスト最適化は ephemeral Dataproc + GCS / Spotワーカー / 課金モデルの最適化（オンデマンド⇔Editions）
- 自動化は Composer(DAG) + 冪等性。軽量はWorkflows、起動だけはScheduler。オーバースペックに注意
- キャパシティは Editions + 予約分離 + コミットメント/autoscaling、急がない大量処理は バッチクエリ
- 監視は Monitoring/Logging/INFORMATION_SCHEMA/管理チャート を症状で使い分け、クォータ/課金も切り分け対象
- DRは 冗長レベル（ゾーン/リージョン）の取り違えに注意し、HA⇔リードレプリカの目的差とサービス別復旧機能を押さえる
🎯 要点と暗記 試験直前の総ざらい用。暗記すべき表と一問一答でセクション5を固めます。
🔑 暗記必須テーブル
Dataproc クラスタの選択
| 方式 | コスト | 使いどころ |
|---|
| 永続（long-running） | 高（アイドルも課金） | 常時対話・常時ジョブ |
| ジョブ単位(ephemeral) | 低（必要時のみ） | バッチ中心。推奨形 |
🔑 鉄則
ephemeralの鉄則：データはHDFSではなくGCS（コンピュートとストレージを分離）。
安いVMの使い分け
| VM | 特徴 | 使ってよい |
|---|
| プリエンプティブル/Spot | 大幅安だが中断され得る | 冪等なバッチ、Dataprocのセカンダリワーカー |
| 通常VM | 安定 | マスター/プライマリワーカー、低レイテンシ処理 |
BigQuery 課金モデル
| モデル | 課金 | 向くケース |
|---|
| オンデマンド | スキャン量(TB) | 散発的・読めない・小〜中量 |
| 容量ベース（Editions/予約） | スロット時間 | 大量・継続・予測可能・コスト固定 |
BigQuery Editions
| エディション | 位置づけ |
|---|
| Standard | 入門・基本分析 |
| Enterprise | 一般企業・コミットメント対応 |
| Enterprise Plus | 最上位・高度な機能/コンプラ/DR |
キャパシティ用語
| 用語 | 意味 |
|---|
| スロット | クエリ実行の計算単位 |
| 予約（Reservation） | 確保スロットの枠 |
| 割り当て（Assignment） | 予約をプロジェクトに紐付け |
| コミットメント | 期間契約で単価を下げる |
| Autoscaling | baseline + max で自動増減 |
オーケストレーションの使い分け
| サービス | 役割 |
|---|
| Cloud Composer | 複雑な依存・多数タスク（DAG/Airflow） |
| Workflows | 軽量なAPI/サービス連携 |
| Cloud Scheduler | 定期トリガー（cron）だけ |
監視サービスの役割分担
| 課題 | サービス/手段 |
|---|
| メトリクスの監視・アラート | Cloud Monitoring |
| ログ・エラー・監査 | Cloud Logging |
| BigQueryのジョブ/スロット分析 | INFORMATION_SCHEMA |
| スロット/予約の可視化 | 管理リソースチャート |
| 利用上限の管理 | クォータ |
| コスト超過の通知 | 予算とアラート |
冗長レベル
| レベル | 守れる障害 |
|---|
| マルチゾーン（リージョナル） | ゾーン障害 |
| マルチリージョン | リージョン障害 |
データベースの冗長
| HA構成 | リードレプリカ |
|---|
| 目的 | 可用性（自動フェイルオーバー） | 読み取りスケール/DR |
| 配置 | 同一リージョン別ゾーン | 同一/別リージョン |
| 自動切替 | あり | なし（手動昇格） |
データ破損・欠損の復旧カード
| サービス | 復旧機能 |
|---|
| BigQuery | タイムトラベル(7日) + スナップショット |
| Pub/Sub | シーク（巻き戻して再配信） |
| Dataflow | スナップショット |
| Cloud SQL | バックアップ + PITR |
| GCS | オブジェクトのバージョニング |
| Memorystore (Redis) | Standard Tier / Redisクラスタ（フェイルオーバー） |
✅ 一問一答（確認テスト）
Q1. Dataprocのコストを最小化したい。バッチジョブは夜間のみ。どう構成する？
A. ジョブ単位（ephemeral）クラスタ + データはCloud Storage。ジョブのたびに起動し完了後に破棄。さらにセカンダリワーカーをSpot/プリエンプティブルに。
Q2. プリエンプティブル/Spot VMをDataprocで使うとき、どのノードに使うべきか？
A. セカンダリワーカーのみ。マスターやプライマリワーカーに使うとクラスタが不安定化する。
Q3. BigQueryの月額コストが変動して読めず高い。クエリ量は多く継続的。どうする？
A. 容量ベース（Editions + コミットメント）に移行し、スロット予約で定額化・上限設定。散発的ならオンデマンドの方が安い点に注意。
Q4. 重要なETLが、アナリストのアドホッククエリのせいでスロット不足になる。対策は？
A. 予約（reservation）を用途別に分離して割り当てる（例：prod-etlとadhocを分離）。急がないものはバッチクエリに回す。
Q5. 多数のタスクが依存し、失敗時に手動でやり直している。再現性を持たせるには？
A. Cloud ComposerのDAGでオーケストレーション。冪等設計（パーティション上書き/MERGE）＋リトライで、安全に再実行・バックフィルできるようにする。
Q6. 数個のAPIを順に呼ぶだけの軽量な処理。Composerはオーバースペック。何を使う？
A. Workflows（サーバーレスなAPI/サービス連携）。単なる定期トリガーだけなら Cloud Scheduler。
Q7. ジョブの再実行で二重書き込みが起きないようにしたい。設計の概念は？
A. 冪等性（idempotency）。INSERT追記ではなく、パーティションのDELETE/上書きやMERGE、WRITE_TRUNCATEを使う。
Q8. BigQueryクエリが遅い/高い。原因を分析する手段は？
A. INFORMATION_SCHEMA.JOBS でスキャン量・スロット・実行時間を分析。パーティション/クラスタリング、SELECT *回避、スロット不足を疑う。管理リソースチャートも併用。
Q9. ジョブが断続的に失敗する。原因の調べ方は？
A. Cloud Loggingでエラーメッセージを確認 + クォータ超過（同時実行/APIレート）をチェック。クォータが原因なら上限引き上げかレート制御。
Q10. 本番Cloud SQLがゾーン障害で停止した。自動的に切り替わる構成にしたい。
A. HA構成（同一リージョンの別ゾーンにスタンバイ→自動フェイルオーバー）。読み取り負荷分散が目的ならリードレプリカ（目的が違う）。
Q11. リージョン全体の災害に備えたい。Cloud SQLでどうする？
A. クロスリージョンのリードレプリカを別リージョンに配置し、災害時に昇格（promote）。HA構成は同一リージョン内なのでリージョン障害は守れない。
Q12. 分析者が誤って本番BigQueryテーブルを上書きした。復旧方法は？
A. タイムトラベル（過去7日間）で上書き前の状態を参照・復元。7日を超える保護が要るならテーブルスナップショットやエクスポートを併用。
Q13. Pub/Subで取りこぼしたメッセージを再処理したい。使う機能は？
A. シーク（Seek）。過去のタイムスタンプやスナップショットへ巻き戻して再配信する。
Q14. Dataflowのストリーミングパイプラインの状態を保存し、復元/移行したい。
A. Dataflowスナップショット。ストリーミング状態を保存し、そこから復元・更新できる。
Q15. Memorystore (Redis) のキャッシュ可用性を高めたい。
A. Standard Tier（レプリカで自動フェイルオーバー）またはRedisクラスタ。Basic Tierはレプリカなしで冗長性がない。
🎯 ひっかけ注意ポイント
❌ 取り違え厳禁
- 「Dataprocのコスト」= ephemeral + GCS が第一手。永続クラスタを最適化する選択肢に誘導されない
- プリエンプティブル/Spotは セカンダリワーカーのみ。マスター/プライマリに使う選択肢は誤り
- オンデマンド⇔容量ベースは使用量の予測可能性で決める。散発的なのに定額、継続大量なのにオンデマンドは×
- Composer ⇔ Workflows ⇔ Scheduler のオーバースペック/アンダースペックを突く問題
- HA ⇔ リードレプリカ は目的が違う（可用性 vs 読み取りスケール）。混同させる
- マルチゾーン ⇔ マルチリージョン は守れる障害レベルが違う（ゾーン障害 vs リージョン障害）
- BigQueryタイムトラベルは7日固定。それ以上はスナップショット/エクスポート
- 「メッセージ再処理」= Pub/Subシーク、「ストリーミング状態」= Dataflowスナップショット（取り違え注意）
- ジョブ失敗の原因に クォータ超過 を疑う視点（IAM/同時実行/APIレート）
📝 セルフチェック
💡 直前チェック
- 暗記テーブル（Dataproc/VM/課金/Editions/キャパシティ/オーケストレーション/監視/冗長/復旧）を白紙から再現できる
- 一問一答を全問即答できる
- ephemeral + GCS、予約分離、冪等性、HA⇔リードレプリカ、復旧カードを口頭で説明できる
- 問題集セクション5 で80%以上取れた
🧭 次に進む