セクション5 応用：データワークロードの保守と自動化 🔧🎯
このファイルは 🔧 実践（中堅） と 🎯 発展（シニア） レベル。
「どう運用判断するか」「トレードオフは何か」「試験のひっかけ」に焦点を当てます。基礎概念は 01_基礎.md を参照。
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⇔リードレプリカの目的差とサービス別復旧機能を押さえる
→ 03_要点と暗記.md で記憶を固めましょう。