WEB問題集
あるグローバル EC 企業は、世界中の Web サーバから 1 秒あたり最大 50 万件のクリックストリームイベントを Google Cloud に取り込みます。発行元と購読側で順序保証が必要なのは、同一ユーザー単位での行動分析を行うときだけで、グローバルな順序は不要です。また、過去 7 日間のメッセージは再処理可能とし、購読側 Dataflow が一時的に停止しても消失しない設計が求められます。最適な構成は次のどれですか？
正解：D
正解の根拠
Pub/Sub の順序指定キーを使うと、同じキーを持つメッセージは発行順に配信されます。ユーザー ID をキーにすることでユーザー単位の順序保証が得られ、グローバル順序を強制しないためスループットも維持できます。メッセージ保持期間を 7 日に設定すれば、購読側障害時にもシーク機能で再処理が可能です。
サービス比較
| 項目 | Pub/Sub 順序キー (B) | Pub/Sub Lite (A) |
|---|---|---|
| スケール | 自動、グローバル | 事前にパーティション容量を設計 |
| 順序単位 | キー単位 | パーティション単位 |
| 保持 | 最大 7 日 | 容量ベース |
不正解の理由
- A: Pub/Sub Lite はゾーンリージョン製品で容量管理が必要、グローバル要件と運用負荷で不利です。
- C: Dataflow 側だけのグルーピングでは取り込み順が崩れる場合があり、ユーザー単位の順序保証になりません。
- B: Cloud Storage バッチは秒次の取り込みやリアルタイム再処理要件を満たせず、要件不一致です。
製造業の IoT プラットフォームでは、毎秒 20 万件のセンサーメッセージが Pub/Sub に届きます。下流の Dataflow ジョブはまれにスキーマ不一致で個別メッセージの処理に失敗します。失敗したメッセージは廃棄せず、原因調査と再投入のために別の場所に保管したいと考えています。Google Cloud で推奨される構成はどれですか？
正解：C
正解の根拠
Pub/Sub の Dead Letter Topic を有効にすると、配信試行回数の上限を超えたメッセージは自動的に別トピックへ転送されます。これにより本流パイプラインを停止させずに障害メッセージを隔離でき、別ジョブで原因分析や再処理が可能です。Dataflow との組み合わせで運用負荷を最小化できます。
サービス比較
| 項目 | Dead Letter Topic (B) | 無限再試行 (C) |
|---|---|---|
| 処理影響 | 本流は継続 | 同一メッセージで詰まる |
| 調査性 | 別トピックで保管 | 蓄積で監視困難 |
| 運用 | Pub/Sub 機能で完結 | 手動介入が必要 |
不正解の理由
- A: ログ書き出しだけでは再投入経路がなく、メッセージ本体を保持できないため要件を満たしません。
- B: Ack 取消は同じ失敗メッセージで再試行ループに入り、本流のレイテンシが大きく悪化します。
- D: Pub/Sub は Cloud Storage を直接購読できず、構成自体が成立しません。
あるメディア企業は、オンプレ Hadoop クラスタで毎日 30 TB のログを Spark で処理しています。クラスタは利用率が低い時間帯がありコスト超過です。既存の PySpark スクリプトをほぼそのまま使い、ジョブ単位で短命クラスタを起動して停止する構成に移行したいと考えています。最適な Google Cloud サービスはどれですか？
正解：A
正解の根拠
Dataproc は Hadoop と Spark をマネージドで実行できるサービスで、PySpark スクリプトをほぼそのまま実行できます。Workflow Templates を使うと、ジョブ送信時にクラスタを起動し、完了後に自動削除する ephemeral 運用が可能で、コストを大幅に最適化できます。移行コストが低く要件に合致します。
サービス比較
| 項目 | Dataproc (C) | Dataflow (A) |
|---|---|---|
| 互換性 | 既存 Spark/Hadoop 流用 | Beam へ書き換え必須 |
| クラスタ管理 | Workflow で自動化 | サーバレス |
| 移行コスト | 低 | 高 |
不正解の理由
- C: Dataflow への移行は Beam SDK 書き換えが必要で、既存スクリプト流用の要件に反します。
- B: BigQuery への完全書き換えは PySpark ロジックを SQL に再設計する必要があり大規模な変更となります。
- D: GKE Spark Operator は運用負荷が高く、Dataproc Workflow より複雑で要件に合いません。
あるグローバル小売企業は、複数の ETL を毎日決まった時刻に実行し、依存関係に従って BigQuery テーブルを更新したいと考えています。タスクは Dataflow、Dataproc、Cloud Functions、外部 API 呼び出しなど多様で、失敗時の再試行やバックフィルが必要です。最も適した Google Cloud サービスはどれですか？
正解：B
正解の根拠
Cloud Composer はマネージド Apache Airflow で、複雑な依存関係を持つ DAG を Python で記述できます。Dataflow、Dataproc、BigQuery、HTTP など豊富な Operators が標準で用意され、リトライ・SLA・バックフィルといった ETL オーケストレーション要件を満たします。多様なタスク種別を一元管理できる点が最大の強みです。
サービス比較
| 項目 | Cloud Composer (B) | Cloud Workflows (C) |
|---|---|---|
| 用途 | データ ETL オーケストレーション | サービス間ステートマシン |
| バックフィル | 標準機能 | 非対応 |
| Operators | BigQuery/Dataflow 等多数 | HTTP 中心 |
不正解の理由
- A: Scheduler だけでは依存関係制御やバックフィル機能がなく、複雑な ETL には不十分です。
- C: Workflows はサービス間連携向けで、バックフィルやデータ系 Operator が不足し ETL に不向きです。
- D: スケジュールクエリは BigQuery 内で完結する用途向けで、多様なタスクを統合管理できません。
マーケティング部門は ETL コードを書ける人材が少なく、GUI でデータパイプラインを設計したいと希望しています。ソースは Salesforce や MySQL、宛先は BigQuery です。プラグインを追加して新コネクタを増やしたい場合があり、内部的には Dataproc が動く方式でも構いません。最適なサービスはどれですか？
正解：A
正解の根拠
Cloud Data Fusion は CDAP ベースのノーコード/ローコード ETL サービスで、ブラウザ上でドラッグ&ドロップでパイプラインを設計できます。Salesforce、各種 RDB、BigQuery などのコネクタが豊富で、内部で Dataproc を起動して実行します。プラグイン拡張も可能で、コーディング負荷を抑えつつ柔軟性も両立できます。
サービス比較
| 項目 | Data Fusion (C) | Composer (A) |
|---|---|---|
| UI | GUI 中心 | コード (Python) |
| コネクタ | 豊富、プラグイン拡張 | Operator 開発が必要 |
| 実行基盤 | Dataproc 内部利用 | Operator 委譲 |
不正解の理由
- C: Composer は Python によるコーディングが前提で、GUI で設計したい要件に合致しません。
- B: Dataflow テンプレートはパラメータ実行のみで、ETL の視覚的設計やコネクタ拡張には弱いです。
- D: Data Transfer Service は対応ソースが限定的で、Salesforce や柔軟な ETL には対応できません。