WEB問題集
あるメディア企業はクリックストリームログを毎秒約 5 万件発生させており、SageMaker でリアルタイム推論を行うパーソナライズモデルへ低レイテンシで連携したいと考えています。生データは S3 にも保管し、後続の特徴量再生成で利用します。最も運用負荷を抑えつつ要件を満たす構成はどれでしょうか。
正解：D
正解の根拠
Kinesis Data Streams は秒単位でのスケーラブルな取り込みが可能で、Lambda コンシューマーから SageMaker エンドポイントを呼び出せばストリーム上で推論を完結させられます。同じストリームを Firehose で購読すれば、コードを書かずに S3 へ生データを並行配信でき、特徴量の再生成にも利用できます。
| サービス | 役割 | 特性 |
|---|---|---|
| Kinesis Data Streams | 取り込み | ミリ秒レイテンシ |
| Lambda | 推論呼び出し | サーバーレス |
| Kinesis Firehose | S3 永続化 | 自動配信 |
不正解の理由
- A: SQS は順序保証が標準では弱く、夜間バッチではリアルタイム要件を満たせません。
- B: MSK と Spark の自前運用は管理コストが高く、運用負荷を最小化できません。
- C: DMS は DB 変更データ用途で、クリックストリーム取り込みには適合しません。
ある保険会社は契約者属性データを Snowflake に保有し、SageMaker Studio から特徴量探索と前処理を視覚的に行いたいと考えています。SQL を書かずに数十種類の変換を試し、その後フローを処理ジョブに変換して S3 に書き出したい場合、最も適した方法はどれでしょうか。
正解：B
正解の根拠
SageMaker Data Wrangler は Snowflake をはじめ多数のソースをネイティブサポートし、300 以上のビルトイン変換を GUI で適用できます。完成したフローはワンクリックで SageMaker Processing ジョブにエクスポートでき、本番化までの開発体験が一貫しています。
| ツール | 主用途 | 連携 |
|---|---|---|
| Data Wrangler | 特徴量設計 | Processing 出力 |
| DataBrew | クレンジング | レシピ単位 |
| Glue Studio | 汎用 ETL | SageMaker 直結ではない |
不正解の理由
- A: Glue Studio は ETL 向けで、特徴量探索の試行錯誤や Processing 出力には最適ではありません。
- C: DataBrew は Snowflake 直結のレシピを Processing にエクスポートする機能が提供されていません。
- D: PySpark を手書きする方式は GUI 探索の要件を満たさず、開発効率が大きく低下します。
ある E コマース企業は SageMaker Feature Store に商品特徴量を保存し、リアルタイム推論で個々のユーザーの直近行動と組み合わせて使いたいと考えています。同時にバッチ学習用には数か月分の履歴も必要です。最適なストア構成はどれでしょうか。
正解：C
正解の根拠
SageMaker Feature Store は Feature Group ごとにオンラインとオフラインの両ストアを有効化でき、PutRecord ではオンラインへ即時、オフラインへバッファ書き込みを並行実行します。これによりミリ秒レイテンシのリアルタイム取得と、長期履歴を用いたバッチ学習を一貫した特徴量で実現できます。
| ストア | 用途 | レイテンシ |
|---|---|---|
| Online | リアルタイム推論 | ミリ秒 |
| Offline | バッチ学習・分析 | S3 ベース |
不正解の理由
- A: オンラインストア単体は履歴を全件保持する用途に向かず、コストも膨らみがちです。
- B: 自前で DynamoDB へコピーするのは Feature Store の機能を再実装する冗長設計となります。
- D: オフライン単独では推論の低レイテンシ要件を満たせず Athena 経由は応答が遅すぎます。
ある研究機関は CSV 形式で蓄積した数 TB のセンサーログを Athena で頻繁に分析したいが、クエリコストとスキャン量を削減する必要があります。データは時系列で日次に追加されます。最も効果的な対策はどれでしょうか。
正解：A
正解の根拠
Athena は列指向の Parquet/ORC を読む際に必要列のみをスキャンし、述語プッシュダウンとパーティション枝刈りでスキャン量を大幅に削減します。日付パーティションを設けることで、特定期間のクエリは該当パーティションのみを読みます。
| 形式 | 圧縮率 | 列スキャン |
|---|---|---|
| CSV+gzip | 中 | 不可 |
| Parquet | 高 | 可 |
| ORC | 高 | 可 |
不正解の理由
- B: gzip CSV は行指向のままのためスキャン量を削減できず、コスト効果が限定的になります。
- C: workgroup の分割は可視化に有効ですが、スキャン量自体は削減できないので逆効果です。
- D: RDS 経由は Federated Query 起動コストが増え、本来の S3 直読より割高になりがちです。
ある銀行のデータレイクは Lake Formation で管理されており、機械学習チームは部署ごとに参照可能なテーブルや列が異なります。テーブル単位のグラント運用は数百テーブルで限界に達しました。最も拡張性の高いアクセス制御戦略はどれでしょうか。
正解：A
正解の根拠
LF-Tags (タグベースアクセス制御) は属性に基づき多数のリソースをまとめて制御でき、テーブル増加に対して O(1) の管理コストを保てます。列レベルまでタグ付与でき、部署プリンシパルへ一度許可するだけでスケールします。
| 方式 | 粒度 | スケール性 |
|---|---|---|
| LF-Tags | 列まで | 高い |
| 名前付きグラント | 列まで | テーブル数依存 |
| S3 ポリシー | プレフィックス | 低い |
不正解の理由
- B: バケットポリシーは Glue Catalog の列レベル制御を提供できず要件を満たしません。
- C: 数百テーブル分のロール作成は管理運用が破綻しやすく持続性を欠きます。
- D: ネットワーク経路では列単位アクセス制御は実現できず権限管理にもなりません。