【DEA-C01】WEB問題集：データストア管理編

WEB問題集

DEA-C01#1(data-store)

ある企業では Amazon S3 上にデータレイクを構築する計画です。データのアクセス頻度はオブジェクトごとに大きく異なり、頻繁にアクセスするホットデータと、ほとんどアクセスしないコールドデータが混在しています。コスト最適化のため最も適切な S3 ストレージクラスはどれですか。

A. 全データを Standard クラスに保存し続け、アクセス速度を一律で優先する方針に統一します
B. 全データを Glacier Deep Archive に保存し、復元時のみ Standard へ戻す運用方針に切替えます
C. 自前バッチで月次スキャンしながら Standard と IA を手動で切替える運用スクリプトを構築します
D. S3 Intelligent-Tiering を採用し、アクセスパターンに応じてストレージ階層を自動移行させます

正解と解説ディスカッション 0

正解：D

正解の根拠

S3 Intelligent-Tiering はオブジェクト単位でアクセスパターンを自動監視し、Frequent / Infrequent / Archive Instant Access の各階層へ自動移行するストレージクラスです。最低保管期間や取得料金が階層ごとに異なる Standard / IA を手動で運用する代わりに、月額わずかなモニタリング料金のみで最適階層を維持できるため、アクセス頻度が予測困難なデータレイクに最適となります。

S3 ストレージクラス比較

クラス	取得遅延	最低保管期間	用途
Standard	ミリ秒	なし	頻繁アクセス
Intelligent-Tiering	ミリ秒〜数時間	なし (移行自動)	不規則なアクセス
Standard-IA	ミリ秒	30 日	低頻度アクセス
Glacier Instant Retrieval	ミリ秒	90 日	四半期程度のアクセス
Glacier Deep Archive	12 時間	180 日	長期アーカイブ

Intelligent-Tiering 設定例

aws s3api put-object   --bucket my-data-lake   --key data/2026/file.parquet   --body file.parquet   --storage-class INTELLIGENT_TIERING

不正解の理由

A: 全データを Standard で保持するとコールドデータの保管コストが過大となり、データレイク用途には不適です。
B: 全 Glacier Deep Archive はホットデータの取得に 12 時間かかるため、業務利用に支障が出てしまいます。
C: 手動切替えはスクリプト保守と判定ロジックの運用負荷が高く、誤判定時の影響も大きくなります。

参考：Amazon S3 ストレージクラス

DEA-C01#2(data-store)

ある企業では Amazon Redshift でデータウェアハウスを運用しています。クラスター構築にあたり RA3 ノードタイプを選択する主な利点を 2 つ選んでください。

（2つ選択）

A. コンピュートとストレージを分離して個別にスケーリングできる Redshift Managed Storage を提供します
B. ストレージはローカルディスクに保持され、コンピュート障害でデータが失われるシンプル構成となります
C. クラスター単位で Compute と Storage を必ず一緒に増減する仕様であり、設計が単純化される構成です
D. Data Sharing 機能で他クラスターとライブデータを共有でき、コピーレスでデータ活用を促進できます
E. ノードタイプ変更には 24 時間以上のダウンタイムが必須となるため、計画的な移行が必要となります

正解と解説ディスカッション 0

正解：A, D

正解の根拠

RA3 ノードタイプは Redshift Managed Storage (RMS) と組合せて動作するアーキテクチャであり、(A) コンピュートとストレージを独立してスケーリングできる利点と、(D) Data Sharing 機能によりコピーレスで他クラスターとライブデータを共有できる利点を備えています。これによりストレージ容量に縛られないノード選定や、複数チームでの並列分析が効率化されます。

Redshift ノードタイプ比較

ノード	ストレージ	分離	Data Sharing
RA3	RMS (S3 ベース)	Compute / Storage 分離	対応
DC2	ローカル SSD	Compute と Storage 一体	非対応
Serverless	RMS (S3 ベース)	分離	対応

Data Sharing の SQL 例

-- Producer 側
CREATE DATASHARE sales_share;
ALTER DATASHARE sales_share ADD SCHEMA public;
GRANT USAGE ON DATASHARE sales_share TO ACCOUNT '123456789012';

-- Consumer 側
CREATE DATABASE sales_db FROM DATASHARE sales_share OF ACCOUNT '111111111111';

不正解の理由

B: RMS は S3 ベースの永続ストレージで自動バックアップされるため、コンピュート障害でデータが失われることはありません。
C: Compute と Storage を必ず一緒に増減するのは DC2 ノードの仕様で、RA3 はその逆の分離アーキテクチャです。
E: ノードタイプ変更は Elastic Resize で短時間 (数分〜数十分) で完了するため、24 時間ダウンタイムは発生しません。

参考：Redshift クラスタータイプ

DEA-C01#3(data-store)

ある企業では変動する分析ワークロード対応として Amazon Redshift の利用を検討しています。日中は重い分析クエリが集中する一方、夜間はほとんど利用がありません。運用負荷を最小化しコスト最適化したい場合、最適な選択肢はどれですか。

A. Redshift Serverless を採用し、利用量に応じて自動でキャパシティを供給する構成に切替えます
B. プロビジョンド型 Redshift で常時最大ノード数を確保しておき、夜間も同じ構成で運用します
C. 夜間にクラスターを自動 Pause、日中に Resume するスクリプトを EventBridge で実行する運用にします
D. 日中はオンプレ DWH を併用し、夜間だけ Redshift にデータを集約する複合構成に切替えます

正解と解説ディスカッション 0

正解：A

正解の根拠

Redshift Serverless はクラスター管理を意識せず、ワークロードに応じて RPU (Redshift Processing Unit) を自動でスケールするサービスです。利用していない時間は課金されず、Base Capacity と Max Capacity を設定するだけで運用可能となります。日中ピーク・夜間ゼロのような大きな利用変動があるワークロードでは、運用負荷とコストの両面で大きな利点が得られます。

Provisioned vs Serverless

項目	Provisioned	Serverless
キャパシティ単位	ノード数	RPU (8 RPU 単位)
課金	ノード稼働時間	RPU-hour (秒単位)
アイドル時課金	あり	なし
Pause/Resume	手動	自動
運用負荷	中 (ノード設計必要)	低 (Base/Max のみ)

Serverless 作成例

aws redshift-serverless create-workgroup   --workgroup-name analytics-wg   --namespace-name analytics-ns   --base-capacity 32   --max-capacity 256

不正解の理由

B: 常時最大ノード固定は夜間の過剰プロビジョンとなり、コスト効率が大きく悪化してしまいます。
C: Pause/Resume スクリプトは実装可能ですが、起動遅延と運用スクリプト管理の負荷が継続的に発生します。
D: ハイブリッド構成は分析データの分断と運用複雑化を招き、Associate レベルの最適解とは言えません。

参考：Amazon Redshift Serverless

DEA-C01#4(data-store)

AWS のデータベースサービスの中で、ミリ秒以下の低レイテンシで大量の読み書きを行うキー・バリュー型ストアが必要なユースケースに、最適な選択肢はどれですか。

A. Amazon RDS for PostgreSQL を採用し、Hstore 拡張でキー値型のテーブル設計を構築する方式で運用します
B. Amazon Redshift を採用し、キー値構造を模した分析テーブルとして格納する設計に切替えます
C. Amazon ElastiCache for Memcached を Persistent ストレージ代わりに使い、キー値データを保持する方式にします
D. Amazon DynamoDB を採用し、ミリ秒以下の応答性能で大規模なキー・バリュー読み書きを実現します

正解と解説ディスカッション 0

正解：D

正解の根拠

DynamoDB はミリ秒以下の応答性能を持つフルマネージドな NoSQL キー・バリューストアです。Partition Key (オプションで Sort Key) によるアクセスパターンに最適化されており、テーブルサイズや TPS に応じて自動でパーティション分割・スケールします。Global Tables、DAX キャッシュ、Streams 連携など、低レイテンシかつ大規模なキー・バリューワークロードに必要な機能が標準で揃っているため、本問の要件に最適な選択肢となります。

主要 DB サービスのレイテンシと設計

サービス	モデル	レイテンシ	用途
DynamoDB	Key-Value / Document	1 桁ミリ秒	低レイテンシ NoSQL
RDS PostgreSQL	RDB	数〜数十ミリ秒	OLTP / 関係モデル
Redshift	列指向 DWH	秒〜分	OLAP / 分析
ElastiCache	インメモリ	マイクロ秒〜ミリ秒	揮発キャッシュ

DynamoDB 操作例 (boto3)

import boto3
table = boto3.resource('dynamodb').Table('Users')
table.put_item(Item={'user_id': 'U001', 'name': 'Taro', 'score': 95})
resp = table.get_item(Key={'user_id': 'U001'})

不正解の理由

A: RDS PostgreSQL は RDB であり、ミリ秒以下のキー・バリュー特化用途では DynamoDB に劣る性能特性です。
B: Redshift は OLAP 用途の DWH のため、低レイテンシ Key-Value ストアとしては設計目的が異なります。
C: ElastiCache は揮発性キャッシュであり、永続ストレージとしての利用は設計思想に反するアンチパターンです。

参考：Amazon DynamoDB の概要

DEA-C01#5(data-store)

DynamoDB のキャパシティモードについて、Provisioned と On-Demand の違いと適切な使い分けに関する記述で、正しい組合せはどれですか。

A. Provisioned はリクエスト単位で課金し、On-Demand はキャパシティ単位の固定課金となる仕様です
B. On-Demand はピークキャパシティを事前設定する必要があり、予測困難な負荷には不向きとなる仕様です
C. Provisioned は事前設定キャパシティで予測可能な負荷向け、On-Demand は予測困難な負荷向けの仕組みとなっています
D. 両モードとも自動スケールする動作は同じで、課金単位だけが異なる単純な切替え機能となります

正解と解説ディスカッション 0

正解：C

正解の根拠

DynamoDB の Provisioned モードは事前設定した RCU/WCU 単位で課金される方式で、安定したワークロードに対して低コストとなります。一方 On-Demand モードはリクエスト単位課金 (per-request pricing) で、キャパシティの事前設定が不要となるため、突発的な負荷や予測困難なトラフィックに最適です。本問では (C) のとおり「Provisioned = 予測可能な負荷」「On-Demand = 予測困難な負荷」が正しい使い分けとなります。

キャパシティモード比較

項目	Provisioned	On-Demand
課金単位	RCU/WCU 時間	リクエスト数
事前設定	必要	不要
自動スケール	Auto Scaling 設定時のみ	標準で自動
適性	予測可能で安定	変動が大きく予測困難
コスト目安	稼働率 70% 超で割安	低稼働率や急変動で割安

モード切替 CLI

aws dynamodb update-table   --table-name Orders   --billing-mode PAY_PER_REQUEST

不正解の理由

A: 課金単位の説明が逆転しており、Provisioned がキャパシティ単位、On-Demand がリクエスト単位となります。
B: On-Demand はキャパシティの事前設定が不要であり、自動スケールが標準で動作するモードです。
D: Provisioned は事前設定値に基づき動作するため、Auto Scaling を別途有効化しない限り自動スケールしません。

参考：DynamoDB のキャパシティモード