WEB問題集
ある製造業の企業が、世界 12 拠点の工場から 1 秒あたり合計 80 万件の IoT センサーイベントを集約し、5 秒以内の異常検知ダッシュボードと、長期保管した生データに対する月次の機械学習バッチ学習の両方を実現したいと考えています。運用チームの人員が限られており、クラスタの容量計画やスケーリングに時間を割けません。Google Cloud で最適なアーキテクチャはどれですか。
解説
正解の根拠
Pub/Sub はグローバルにスケールするフルマネージドのメッセージングで、パーティションの事前設計なしに毎秒 80 万件規模のイベントを受け止め、購読側が遅れてもメッセージを保持します。Dataflow のストリーミング ジョブは負荷に応じてワーカー数を自動調整するため、クラスタの容量計画をせずに秒単位のウィンドウ集計で異常を判定できます。12 拠点からのイベントは同一のグローバルなエンドポイントへ発行できるため、拠点ごとにブローカーを立てて管理する必要がありません。出力は BigQuery へ書き込んで 5 秒以内のダッシュボード集計に使い、同じパイプラインから Cloud Storage へ並行して書き出すことで、月次バッチ学習が読む長期の生データ保管も同時に満たせます。
サービス比較
| 項目 | 正解 (Pub/Sub + Dataflow) | 不正解 (Dataproc 永続) |
|---|---|---|
| 運用 | サーバーレス・自動スケール | クラスタ管理が必要 |
| 低レイテンシ | 秒オーダー | 調整次第 |
| ML 用長期保管 | Cloud Storage 連携 | HDFS は永続性に課題 |
不正解の理由
- A: Kafka と Spark を Compute Engine 上に自前構築すると、ブローカー台数やエグゼキュータ数をピークに合わせて設計し、増設や障害復旧も自分で行うことになり、容量計画に時間を割けないという前提と矛盾します。
- B: Cloud SQL は単一プライマリのトランザクション DB で、毎秒 80 万件の書き込みは書き込み上限を超えます。リードレプリカを足しても書き込みは分散されず、全件走査の分析にも向きません。
- D: 永続クラスタはピークに合わせたノードを 24 時間確保するためアイドル時間も課金され、スケーリング調整やパッチ適用を運用チームが担うことになります。
金融系の顧客が、過去 7 年分の取引履歴 (約 600 TB) をオンプレミスから Google Cloud に移行します。データはまず生のまま保持し、その後 BigQuery で分析しますが、規制上、生データには 7 年間の改ざん防止 (WORM) が要求されます。同時に分析側では取り込み後 1 時間以内にクエリ可能な状態にしたい場合、最も適切な設計はどれですか。
解説
正解の根拠
Cloud Storage の保持ポリシーは、指定した保持期間が経過するまでオブジェクトの削除と上書きを拒否します。さらに Bucket Lock でポリシーをロックすると、以後は管理者でも保持期間の短縮やポリシーの解除ができなくなるため、7 年間の改ざん防止（WORM）を構成として強制できます。生データはこのバケットに原本のまま置き、同じオブジェクトからBigQuery へロードジョブを実行すれば取り込み後まもなくクエリ可能になり、1 時間以内に分析したいという要件も満たせます。保管クラスに Coldline や Archive を選べば、600 TB 規模でも長期保管の費用を抑えられます。保持ポリシーは各オブジェクトの作成時刻を起点に適用され、期間中は同名での上書き保存も拒否されるため、記録を差し替える形の改変も成立しません。
サービス比較
| 項目 | 正解 (Cloud Storage + Bucket Lock) | 不正解 (BigQuery スナップショット) |
|---|---|---|
| WORM | 保持ポリシーで強制 | 削除可能で不適 |
| 容量・コスト | Coldline/Archive で安価 | BigQuery ストレージ価格 |
| 原本性 | 生データを直接保持 | 派生コピー |
不正解の理由
- B: テーブルスナップショットは元テーブルとは独立に残せますが、スナップショット自体を削除でき保持期限も後から変更できるため改ざん防止を強制できません。保持されるのも取り込み後の派生データで、生データの原本性を担保できません。
- A: Persistent Disk のスナップショットには削除を拒否する保持ポリシーがなく、権限があれば消せてしまいます。読み出しにもディスクへの復元と VM 経由の取り出しが必要で、1 時間以内にクエリ可能という要件も満たせません。
- D: Cloud SQL は 600 TB の履歴を保持する容量とコストに見合わず、行の更新・削除を拒否する保持ポリシーも持たないため、WORM 要件を満たせません。
大手 EC 企業が新規データ基盤を設計しています。トランザクション処理は OLTP として 24/365 で 99.999% の可用性を持ち、地理的に離れた複数リージョンで強整合性を必要とします。月次の分析は別途 BigQuery で行います。OLTP 層に採用すべきサービスはどれですか。
解説
正解の根拠
Spanner のマルチリージョン構成は、TrueTime と Paxos による同期レプリケーションで複数リージョンのレプリカ間の合意を取ってからコミットするため、地理的に離れたリージョンをまたいでも外部整合性のあるトランザクションを提供します。リージョン単位の障害が起きても残るレプリカでクォーラムを維持できるので、マルチリージョン構成には 99.999% の可用性 SLA が適用され、24/365 の OLTP 要件を満たせます。リレーショナル スキーマと SQL を保ったままスプリット分割で水平にスケールし、分析側の BigQuery へはフェデレーテッド クエリや変更ストリームで連携できます。
サービス比較
| 項目 | 正解 (Spanner マルチリージョン) | 不正解 (Cloud SQL HA) |
|---|---|---|
| 整合性 | 外部整合性 | 単一リージョン強整合 |
| SLA | 99.999% | 99.95% |
| 地理分散 | マルチリージョン対応 | 単一リージョン |
不正解の理由
- A: Cloud SQL HA は単一リージョン内のフェイルオーバーで、別リージョンへは非同期レプリケーションのため、マルチリージョンの強整合性要件を満たしません。
- C: Bigtable はクラスタ間レプリケーションが結果整合で、複数行にまたがる SQL トランザクションも持たないため OLTP 用途に不適です。
- D: Firestore はドキュメント DB で、正規化した関係を JOIN する処理には不向きです。
ある通信事業者が既存の Hadoop / Hive 資産を Google Cloud に移行します。HiveQL ジョブが約 200 本あり、最小限のコード変更で移行したいと考えています。同時に長期的には BigQuery に統合したい計画です。短期的な移行戦略として最適なのはどれですか。
解説
正解の根拠
Dataproc は Hadoop / Hive エコシステムをほぼそのまま実行できるマネージドサービスです。Dataproc Metastore へ Hive メタストアを移行することで、既存 HiveQL ジョブを最小限の変更で稼働させられます。短期的にリフト&シフトを実現し、長期的には Hive テーブルを BigLake / BigQuery 外部テーブル化して BigQuery 統合へ移行できる段階的アプローチが取れます。
サービス比較
| 項目 | 正解 (Dataproc + Metastore) | 不正解 (BigQuery 即時書換) |
|---|---|---|
| 移行コスト | 低 (HiveQL 流用) | 高 (200 本書換) |
| 互換性 | Hadoop 互換 | SQL 方言差異あり |
| 段階移行 | 可能 | ビッグバン |
不正解の理由
- B: 200 本の HiveQL を一括書換するのは時間とリスクが大きく、最小コードでの移行要件に反します。
- C: PySpark 書換と Dataflow 移植は工数が大きく、Hive エコシステム維持に不適です。
- D: Cloud Run functions は短時間のイベント処理用途で、HiveQL バッチ処理には適しません。
あるヘルスケア企業が患者の電子カルテを分析基盤に取り込みます。データには氏名、生年月日、保険証番号などの個人情報が含まれ、分析者には匿名化後の状態でのみアクセス許可する必要があります。さらに分析環境は外部ネットワークへ流出しない設計が必須です。適切な設計要素を 2 つ選択してください。(2 つ選択)
解説
正解の根拠
Cloud DLP は氏名・生年月日・保険証番号といった PII を検査で検出し、決定論的トークン化や日付シフトなどの変換を適用できます。取り込みの過程で変換してから BigQuery へ書き込めば、分析者が参照できるのは匿名化済みの値だけになり、原本を渡さずに分析を継続できます。VPC Service Controls は BigQuery や Cloud Storage への API 呼び出しにサービス境界を設け、境界の外側へのコピーやエクスポートを API のレベルで拒否するため、権限を持つ利用者による持ち出し経路も塞げます。内容の匿名化と境界での流出防止という二層でこの要件を満たします。
サービス比較
| 項目 | DLP | VPC SC |
|---|---|---|
| 役割 | PII 検出・匿名化 | API 境界防御 |
| 適用層 | データ内容 | ネットワーク + API |
| 補完関係 | 内容の保護 | 外部持出防止 |
不正解の理由
- B: Authorized View は元テーブルの権限を渡さずにクエリ結果を共有するための仕組みで、値そのものを変換する機能はなく、原本を社内全員へ公開すれば氏名や保険証番号がそのまま返ってしまいます。
- D: Editor を分析者全員に付与すると、読み取りに加えてエクスポートやジョブ実行まで可能になり、匿名化前のデータを他のプロジェクトや外部へ書き出す経路を自ら開くことになります。