03_要点と暗記

セクション5 要点と暗記：データワークロードの保守と自動化 🎯

試験直前の総ざらい用。暗記すべき表と一問一答でセクション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はレプリカなしで冗長性がない。

🎯 ひっかけ注意ポイント

📝 セルフチェック