WEB問題集
ある製造業の分析基盤では、Dataflow ストリーミング パイプラインが IoT センサーからのイベントを BigQuery に書き込んでいます。SRE チームは、ウォーターマークの遅延が 5 分を超えた場合に即座にオンコール担当者へ通知し、ダッシュボードで過去 30 日のシステム状態を可視化したいと考えています。運用負荷を最小限に抑えつつ要件を満たす最適な構成はどれですか？
正解：D
正解の根拠
Cloud Monitoring は Dataflow の system_lag や data_watermark_age など主要メトリクスを自動収集します。アラート ポリシーを定義することで、しきい値超過時に PagerDuty などのオンコール ツールへ通知でき、組み込みダッシュボードで履歴も確認できます。コードを書かずに SLO 監視を実現できる点が運用負荷の最小化につながります。
サービス比較
| 項目 | Cloud Monitoring アラート | カスタム発行+関数 |
|---|---|---|
| 実装工数 | UI/IaC 設定のみ | 関数開発と保守 |
| メトリクス取得 | 自動収集 | 明示的発行が必要 |
| ダッシュボード | 組み込み | 別途構築 |
不正解の理由
- A: 独自実装が増え、関数障害時に検知漏れが発生する可能性があり保守負荷が上がります
- C: ログの grep はリアルタイム性が低く、構造化メトリクスより信頼性に欠けます
- B: BigQuery クエリ実行コストとレイテンシが発生し監視用途には不向きです
金融サービス企業が複数の BigQuery データセットに対して、データ品質ルール（NOT NULL、範囲チェック、参照整合性）を統一的に適用したいと考えています。ルール定義は YAML で管理し、毎日スキャン結果をダッシュボードで確認、違反時には監査ログに記録する必要があります。最適なソリューションはどれですか？
正解：A
正解の根拠
Dataplex Data Quality は YAML 形式でルールを宣言し、BigQuery テーブルに対してマネージドなスキャンを実行するサービスです。結果は自動的に BigQuery と Cloud Logging に出力され、Looker Studio ダッシュボードに統合可能です。違反時は Cloud Monitoring アラートと連携できるため、宣言的かつ運用負荷の低い品質管理が実現します。
サービス比較
| 項目 | Dataplex DQ | Composer 自作 |
|---|---|---|
| ルール定義 | 宣言的 YAML | Python コード |
| 結果保存 | 自動 BQ 出力 | 独自実装 |
| 監査ログ | 標準連携 | 追加開発 |
不正解の理由
- B: Composer は柔軟だがルールがコード化されガバナンス標準化が困難です
- C: スケジュールド クエリのみではルールの再利用や統合ダッシュボードが弱くなります
- D: Dataflow は処理基盤であり品質チェック専用としてはオーバーエンジニアリングです
ある E コマース企業のデータ分析チームは、BigQuery で発生したクエリエラーや高コストクエリを継続的に追跡したいと考えています。INFORMATION_SCHEMA.JOBS をローカルで都度確認するのは非効率なため、Cloud Logging を活用して構造化ログから自動的に分析可能にしたいです。最も適切なアプローチはどれですか？
正解：D
正解の根拠
Cloud Logging のログ シンク機能を使うと、BigQuery のデータアクセス監査ログを別の BigQuery データセットに自動エクスポートできます。SQL ビューを定義することで、エラー率や高額クエリの傾向を継続的に分析でき、Looker Studio で可視化も容易です。スキーマは Google が定義する標準形式のため、再現性の高い運用が可能です。
サービス比較
| 項目 | Log Sink → BQ | Logs Explorer 手動 |
|---|---|---|
| 自動化 | 継続的 | 都度操作 |
| SQL 分析 | 可能 | 限定的 |
| 履歴保持 | 長期 | 保持期間あり |
不正解の理由
- B: アプリ側実装はクライアント網羅性が低く、監査ログより信頼性が劣ります
- C: 手動ダウンロードは運用負荷が高くスケーラビリティもありません
- A: 都度実行は自動化されず、分析の継続性と再現性に欠けます
あるメディア企業は、複数のチームが BigQuery、Dataflow、Cloud Storage を組み合わせて 100 を超えるパイプラインを運用しています。データソースから最終ダッシュボードまでの依存関係を可視化し、列レベルの変更影響を分析できる仕組みを構築したいです。最適なサービスはどれですか？
正解：D
正解の根拠
Data Catalog Lineage（Dataplex の機能）は、BigQuery や Dataflow、Cloud Composer など対応サービスから系統情報を自動収集し、テーブルレベルおよびカラムレベルの依存関係をグラフで可視化します。変更影響分析や規制対応に有用で、API 経由でカスタム連携も可能です。手動メンテナンスを削減できる点が大規模運用での利点です。
サービス比較
| 項目 | Data Catalog Lineage | Composer DAG |
|---|---|---|
| 収集範囲 | 横断的サービス | DAG 内部のみ |
| カラム単位 | 対応 | 非対応 |
| 自動化 | マネージド | 定義依存 |
不正解の理由
- A: DAG ビューはタスク依存表示でデータ系統やカラム単位の追跡には不十分です
- C: 手動図面はパイプライン変更に追随できず、信頼性が低下します
- B: INFORMATION_SCHEMA からの抽出は SQL 内に限定され網羅性に欠けます
あるスタートアップは BigQuery のリソース構成（データセット、テーブル、IAM、スケジュールド クエリ）を全て Terraform で管理しています。プルリクエストごとに plan を自動生成し、main マージ時に apply を実行する CI/CD を構築したいです。最も Google Cloud ネイティブな構成はどれですか？
正解：C
正解の根拠
Cloud Build は GitHub や Cloud Source Repositories とネイティブに連携し、トリガー条件（PR・タグ・ブランチ）ごとにビルド ステップを切り替えられます。Terraform 公式イメージを用いて plan と apply を分離し、ステートを Cloud Storage に保存することで安全な IaC ワークフローが構築できます。マネージド サービスのため運用負荷も低くなります。
サービス比較
| 項目 | Cloud Build | Jenkins on GCE |
|---|---|---|
| 運用負荷 | マネージド | VM 保守必要 |
| 課金 | 従量 | 常時稼働費用 |
| IAM 統合 | ネイティブ | 独自設定 |
不正解の理由
- B: Jenkins は柔軟だが VM 管理とプラグイン保守の運用負荷が大きくなります
- A: Cloud Functions は実行時間制限と一時ストレージ制約があり Terraform 実行に不向きです
- D: ローカル実行は再現性と監査性に欠け、チーム運用に適しません