WEB問題集
ある小売企業は POS から 1 日あたり 80 億行のトランザクションを BigQuery に取り込み、分析チームは常に過去 90 日のデータを店舗 ID と商品カテゴリで絞り込むレポートを作成します。テーブルサイズは 50 TB を超え、スキャンコストが課題となっています。コストとパフォーマンスを両立する最適な物理設計はどれですか？
正解：A
正解の根拠
BigQuery では時系列フィルタが頻出する場合に取引日のパーティション分割が有効で、パーティションプルーニングによりスキャン量を 90 日分に限定できます。さらに店舗 ID と商品カテゴリでクラスタリングすると、ブロック単位でデータが並び替えられ追加の絞り込みが効率化されます。両者の併用はコストと性能のバランスが最良となります。
サービス比較
| 項目 | 正解 (パーティション+クラスタ) | 不正解 (クラスタのみ) |
|---|---|---|
| スキャン削減 | パーティション単位で除外可能 | 常に全パーティションを評価 |
| 運用 | 自動メンテナンス | クラスタ再構成負荷あり |
不正解の理由
- B: 店舗 ID は高カーディナリティでパーティションキーに不適、上限 4000 に抵触するリスクがあります
- C: BigQuery は単一カラムによる時間/整数パーティションのみ対応で複合不可です
- D: クラスタ単独では古い 90 日以前のデータもスキャン対象となりコスト削減効果が限定的です
金融サービスを運営する企業は、ユーザー操作ログを Bigtable に蓄積しています。1 秒あたり 50 万書き込みのピーク時にホットスポットが発生し、特定ノードの CPU が 95% に達しレイテンシが劣化しました。書き込みパターンはタイムスタンプを先頭に置いた行キーです。最も適切な改善策はどれですか？
正解：A
正解の根拠
Bigtable のホットスポットは行キーの順序性に起因することがほとんどで、タイムスタンプ先頭の設計は同じタブレットへの書き込み集中を生みます。ユーザー ID のハッシュ値などをプレフィックスとして付与すると、書き込みがタブレット間に分散し、全ノードを均等に活用できるためレイテンシが安定します。Key Visualizer での確認も推奨されます。
サービス比較
| 項目 | 正解 (キー分散) | 不正解 (ノード増加) |
|---|---|---|
| 根本対応 | 偏りの解消 | 偏りは残る |
| コスト | 変化なし | 2 倍に増加 |
不正解の理由
- B: ノード増設は均等分散には寄与せず、ホットなタブレットの偏りは残り続けてしまいます
- C: カラムファミリは書き込み分散とは無関係で、行キー設計のみがホットスポットを左右します
- D: HDD は低レイテンシ用途に不適でスループットも低下し、状況が悪化するだけです
グローバル展開する EC プラットフォームは、在庫管理データベースを構築中です。在庫数は世界中で同時更新され、強整合性、リージョン障害耐性、SQL インターフェース、スケールアウト書き込み (1 万 TPS) が必須要件です。最適な Google Cloud サービスはどれですか？
正解：C
正解の根拠
Cloud Spanner は TrueTime を用いた外部一貫性 (strong consistency) をグローバル規模で提供し、水平スケールにより数万 TPS の書き込みを処理できます。マルチリージョン構成では複数リージョンに同期レプリケートし RPO=0、RTO ≈ 0 のディザスタリカバリを実現します。SQL インターフェースも備え、グローバル在庫など要件を満たします。
サービス比較
| 項目 | 正解 (Spanner) | 不正解 (Cloud SQL) |
|---|---|---|
| 書き込みスケール | 水平拡張 | 単一プライマリ |
| 整合性 | 外部一貫性 | 同期/非同期選択 |
不正解の理由
- A: Cloud SQL はプライマリが単一でスケールアウト書き込みができず、1 万 TPS は到達困難です
- B: Firestore は SQL 非対応で、複雑なトランザクション要件と相性が悪い設計となります
- D: Bigtable は NoSQL で SQL 非対応、強整合性も単一クラスタ内に限定される制約があります
ある気象解析企業は、20 年分の気象観測データ (300 TB の Parquet) を Cloud Storage に保管しています。データサイエンスチームは BigQuery でこのデータを直接分析し、Spark ジョブからもアクセスしたい一方、ガバナンスのため行・列レベルのアクセス制御を BigQuery と同等に適用したい要件があります。最適な実装はどれですか？
正解：B
正解の根拠
BigLake テーブルは Cloud Storage 上のオープンフォーマット (Parquet/ORC/Avro) を BigQuery と Spark の双方から統一的に参照可能とし、行レベルセキュリティや列レベルセキュリティ、Data Catalog のポリシータグを適用できます。アクセス委任モデルにより、エンドユーザに直接 Cloud Storage 権限を付与せずに済み、ガバナンスを強化できます。
サービス比較
| 項目 | 正解 (BigLake) | 不正解 (外部テーブル) |
|---|---|---|
| 行レベル制御 | 対応 | 非対応 |
| Spark 連携 | BigLake Connector | 直接参照不可 |
不正解の理由
- A: 300 TB の重複保管はコスト過大で、Spark からの直接参照要件も満たせない設計となります
- C: 旧来の外部テーブルは行レベル制御や Spark 委任アクセスを欠き、ガバナンス要件を満たしません
- D: Dataproc Metastore は BigQuery からの統一アクセスや列レベル制御を提供できない構成です
あるメディア企業はユーザー視聴ログを Cloud Storage に保管しています。直近 30 日は頻繁に分析され、31〜365 日は月数回、それ以降は規制対応で 7 年保持しますがアクセスはほぼありません。コスト最適化のため適切なライフサイクル管理を設計してください (2 つ選択)。
（2つ選択）
正解：A, B
正解の根拠
Cloud Storage のストレージクラスは Standard (頻繁)、Nearline (月 1 回程度)、Coldline (四半期 1 回程度)、Archive (年 1 回未満) に対応します。アクセス頻度に応じて段階的に移行すると、各クラスの最小保管期間を満たしつつコストを最小化できます。ライフサイクルルールで自動化することで運用負荷もかかりません。
サービス比較
| 項目 | 正解 (段階移行) | 不正解 (直接 Archive) |
|---|---|---|
| 取得コスト | 必要時のみ | 頻発で高額 |
| 保管最適化 | 最適 | 過剰最適化 |
不正解の理由
- C: 7 年分すべてを Standard で保管すると保管コストが Archive の約 24 倍となり経済的に非合理です
- D: 30 日後に Archive 直行は 31〜365 日帯の取得料金と最小保管期間 365 日の制約で割高になります