Amazon DEA-C01: データストレージとレイクアーキテクチャ — 学習ガイド
こちらの一部です： Amazon Data Engineer Associate DEA-C01 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.
このドメインでは、AWSのストレージサービスとデータベースエンジンが、現代のデータプラットフォームにおける大規模なデータ取り込み、耐久性のあるアーカイブ、クエリパフォーマンス、そして安全なガバナンスをどのようにサポートするかを扱います。データエンジニアは、S3、Lake Formation、Redshift、DynamoDBなどのサービスをパイプラインに統合する際に、コスト、アクセスレイテンシー、耐久性、そしてきめ細かなアクセス制御のバランスを取る必要があります。ストレージクラスのトレードオフ、ライフサイクルの自動化、マネージドストレージとローカルストレージの比較、パーティショニングパターンを理解することで、本番環境でのパフォーマンスやコストの予期せぬ問題を回避できます。
Amazon S3ストレージクラスとライフサイクルポリシー
S3は、コストとアクセスパターンを最適化するために、複数のストレージクラスとライフサイクルコントロールを提供します。ストレージクラスは、アップロード時に設定するか（コンソールまたはCLI:
undefined
）、バケットのライフサイクルルール（
undefined
）を使用して設定します。Intelligent-Tieringは、オブジェクトを頻繁アクセス階層と低頻度アクセス階層の間で自動的に移動させ、少額のモニタリング料金がかかります。アクセスパターンが不明または変化する場合に有効化します。ライフサイクルルールを使用して、オブジェクトを長期保存のためにGLACIERやDEEP_ARCHIVEに移行したり、古いバージョンを失効/削除したりします。
決定基準とトレードオフ：
- Intelligent-Tiering: 変動のあるアクセスに対して運用オーバーヘッドが低く、オブジェクトごとに月々のモニタリング料金がかかります。アクセスパターンが予測不可能な場合に最適です。
- Glacier vs Glacier Deep Archive: Glacierは、より高いストレージコストで、より高速な標準および迅速な取り出しオプションを提供します。Deep Archiveは、数時間単位のバルク/標準取り出し時間で、数年間の長期保存に最も安価です。
- Standard-IA vs Intelligent-Tiering: Standard-IAには30日間の最低料金と取り出し料金があります。頻繁にアクセスされるデータや短命なオブジェクトには使用を避けてください。
運用上の注意点：
- 不変性のためにバージョニング（
undefined
）とオブジェクトロック（
undefined
）を有効にします。MFA Deleteの有効化には、特別なCLI操作とMFAを持つバケット所有者アカウントが必要です。
- ライフサイクル移行はオブジェクトのバージョンに適用され、プレフィックス/タグでスコープを限定できます。ストレージのリークを避けるために、
abort-incomplete-multipart-uploadを使用します。
S3とLake Formationによるデータレイク設計
S3を中央オブジェクトストアとして、Lake Formationを中央集権的なアクセス制御とカタログ作成のために使用してデータレイクを設計します。S3のロケーションをLake Formationのリソースとして登録し、AWS Glueデータカタログをセットアップし、データベース/テーブルに対してLake Formationの許可を使用します（
undefined
）。Lake Formationは、LF-tagとデータフィルターをGlue/Athenaクエリに適用することで、列レベル、行レベル（フィルター式）、セルレベルのマスキングといった、きめ細かな制御を強制できます。
主要な設定とガバナンスのパターン：
- ロケーションの登録: Lake Formationコンソールを使用して
s3://bucket/pathを登録し、Lake Formationがクロール/読み取りを許可するIAMロールをアタッチします。 - きめ細かなポリシー: LF-tagを定義してテーブル/列にアタッチし、
column-listで許可を付与して列を制限し、行フィルター式を使用してプリンシパルに返される行を制限します。 - Lake Formationの権限は、Glue/Athenaのアクセスに対してIAM S3の権限を上書きまたはブロックする可能性があることを覚えておいてください。必要な場合は、Lake FormationとS3レベルの両方のアクセスを許可してください。
意思決定のポイント：
- 中央集権的なカタログ作成、LF-tag、複数の分析エンジンにまたがるきめ細かな強制が必要な場合は、Lake Formationを使用します。
- シンプルなアクセス制御や外部ツールからのアクセスには、S3バケットポリシーとIAMを検討しますが、注意が必要です。Lake Formationによって管理される分析エンジンは、IAMのみの許可を無視する場合があります。
Amazon Redshiftのアーキテクチャとストレージ
Redshiftは、RA3ノードではコンピューティングとマネージドストレージを分離しますが、DS2ノードではローカルSSDにバックアップされたストレージを使用します。RA3ノードはRedshift Managed Storage (RMS)を使用し、データはクラスターによって管理されるAmazon S3上に存在します。スケーラブルなストレージと一貫したクエリパフォーマンスが必要で、コンピューティングに個別課金したい場合はRA3を選択します。DS2ノードはインスタンスローカルディスクにデータを保存するため、データが増加する際には慎重なサイジングとリサイズが必要です。
設定と運用の詳細：
- コンソールまたはCLIでRA3クラスターを作成します:
undefined
。
- COPYコマンド: S3の読み取りアクセスを許可するIAMロールがアタッチされたクラスターで実行する必要があります。クラスター作成時にロールをアタッチするか、クラスターを変更してIAMロールを追加します。ロールのARN（
undefined
）は、COPYコマンドでcredentials 'aws_iam_role=arn:...'として参照されます。
- WLMキュー、ショートクエリアクセラレーション、自動VACUUMを監視し、SORT/ENCODEを使用してストレージとパフォーマンスを最適化します。
比較（RA3 vs DS2）：
- RA3: ストレージの分離、S3への自動データ階層化、ストレージ管理の低減、増大するデータセットに最適。
- DS2: ローカルSSDストレージ、ローカルデータに対する低レイテンシーですが、容量に制限があり、スケールが困難。
DynamoDBと目的別データベースの選択
DynamoDBは、1桁ミリ秒台のレイテンシーが要求される、大規模なキーバリューおよびドキュメントワークロードに選択します。テーブル設計は、パーティションキー（およびオプションのソートキー）の選択にかかっています。ホットパーティションを避けるために、カーディナリティが高く、十分に分散されたキーを使用します。シーケンシャルキーやタイムスタンプベースのキーには、ランダムなプレフィックス（シャーディング）を実装するか、UUIDを使用して書き込みを分散させます。プロビジョニングを避けるためにオンデマンドキャパシティを使用しますが、予測可能なワークロードにはオートスケーリング付きのプロビジョンドキャパシティを検討し、ホットパーティションでアダプティブキャパシティを活用します。
実践的な設定に関する注意点：
- テーブル作成CLI:
undefined
- 代替アクセスパターンにはGSIを使用し、自動失効にはTTLを有効にし、変更データキャプチャ（CDC）パターンにはDynamoDB Streams + Lambdaを使用します。
- 読み取り負荷の高いワークロードのキャッシングにはDAXを追加し、複雑なクエリやリレーショナルな要件には、クエリの複雑さと一貫性の要件に応じてAuroraまたはRedshift Spectrumを選択します。
エンジン選択の決定基準：
- 予測可能な単一テーブルのアクセスパターンと、低レイテンシーでの大規模なスケールにはDynamoDBを使用します。
- 複雑な分析と大規模なOLAPにはRedshiftを使用します。
- トランザクションを伴うリレーショナルワークロードにはAuroraを使用します。
一般的な落とし穴と決定基準
- 頻繁にアクセスされるデータにS3 Standard-IAを使用する — Standard-IAには最低30日間の課金があります。存続期間が短い、または頻繁にアクセスされるオブジェクトには、StandardまたはIntelligent-Tieringを使用します。
- Glue/Athenaに対してLake Formationの権限がIAM S3の権限を上書きすることを忘れる — Glue/Athenaを使用する際は、Lake FormationとS3の両方のアクセス権を付与し、Lake Formationコンソールで有効な権限を確認します。
- RedshiftのCOPYは、ユーザー権限だけでなく、クラスターにアタッチされたIAMロールを必要とする — S3アクセス用のIAMロールをクラスターにアタッチし、COPY操作でそのARNを参照します。
- シーケンシャルキーによるDynamoDBのホットパーティション — 単調増加キーを避け、ハッシュ化されたキー、ランダムなプレフィックス、またはUUIDを使用し、オンデマンドまたはオートスケールされたプロビジョンドキャパシティを検討します。
- S3オブジェクトロックとMFA削除を誤って有効にする — オブジェクトロックはバージョニングの有効化と適切な権限が必要です。MFA削除は、MFAを使用してCLIでのみ有効/無効にでき、厳格なバケット所有者要件があります。
- 取り出しコストと時間をテストせずに不適切なライフサイクル移行を行う — Glacierクラスの取り出しワークフローをテストして、予期せぬ取り出しレイテンシーと料金を回避します。
実践的な問題：ユースケースシナリオ
Acme Media社は、50TBの生ビデオデータを取り込み、変換されたメタデータへのクエリアクセスをアナリストに提供し、異なる事業部門に対して行レベルおよび列レベルのアクセスを強制しながら、ストレージコストを最小限に抑える必要があります。
- マルチパートアップロードを使用して生のビデオをS3に取り込み、取り込み日とデータセットでオブジェクトにタグを付け、初期の不明なアクセスパターンにはIntelligent-Tieringを使用します。
- 設定可能な保持期間後にメディアをGLACIERまたはDEEP_ARCHIVEに移行するライフサイクルルールを設定します（Standard-IAを検討する場合は、30日以上の期間と整合性を確認します）。
- S3のロケーションをLake Formationに登録し、Glueクローラーを構築してデータカタログを作成し、事業部門にLFタグベースの行レベルおよび列レベルの権限を付与します。
- 分析用にキュレートされたメタデータをRedshift RA3に保存します。S3からのCOPYのためにクラスターにIAMロールをアタッチし、メンテナンスウィンドウでVACUUM/ANALYZE操作を使用します。
- ビデオマニフェストの高スループットなルックアップテーブルには、ハッシュ化されたUUIDキーを持つDynamoDBを使用し、トラフィックの急増に対応するためにオンデマンドキャパシティを有効にします。
論理的根拠：このアプローチは、Glacierクラスでコールドストレージのコストを分離し、不明なパターンにはIntelligent-Tieringを使用し、分析エンジン全体で安全かつきめ細かなアクセス制御を行うためにLake Formationを適用し、スケーラブルな分析ストレージとしてRA3を選択する一方で、DynamoDBが低レイテンシーの運用ルックアップを処理します。
← データの取り込みと収集 · すべてのドメイン · データカタログ化とメタデータ管理 →
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →