Amazon DEA-C01: データの取り込みと収集 — 学習ガイド

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

こちらの一部です： Amazon Data Engineer Associate DEA-C01 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

このドメインでは、生データをデータプラットフォームに信頼性高く大規模に取り込むために使用されるパターン、AWSサービス、および運用の詳細について説明します。データエンジニアは、バッチとストリーミングのエントリポイントを選択し、データのカタログ化と発見可能性を確保し、スループット、リプレイ可能性、および障害モードを考慮して設計する必要があります。主要なAWSの構成要素は、バッチ用のS3とGlue、ストリーミング用のKinesisとFirehose、データベース移行とCDC用のDMS、そしてアドホックおよびプッシュベースの取り込み用のAPI/イベント駆動コンポーネント（API Gateway, Lambda, SNS, SQS, S3イベント）です。

AWS GlueとS3によるバッチ取り込み

Glueは、S3およびデータカタログへのバッチ取り込みのための主要なマネージドETLおよびメタデータソリューションです。典型的なパターンは、生ファイルをS3に配置し（raw/zoneなどのプレフィックスで分離）、Glueクローラーを実行してスキーマを推論しGlueデータカタログに登録し、その後Glue ETLジョブ（Spark）を実行して変換、パーティショニング、カラムナフォーマット（Parquet/ORC）への変換を行い、最適化されたデータをS3に書き戻すというものです。クローラーには適切な分類子（組み込みのCSV/JSON/Parquetまたはカスタムのgrok/regex）を設定し、s3:GetObject/s3:ListBucketおよびglue:*catalog*権限を持つIAMロールを付与します。これらの権限の欠落は、よくある運用上の誤りです。

Glueジョブとクローラーを設定する際は、以下のコンソール/CLIパターンとトグルを使用します。

クローラーの作成: aws glue create-crawler --name my-crawler --role GlueRole --database-name raw_db --targets '{"S3Targets":[{"Path":"s3://bucket/raw/"}]}' で作成し、aws glue start-crawler --name my-crawler で開始します。
Glueジョブ: aws glue create-job --name etl-job --role GlueRole --command '{"Name":"glueetl","ScriptLocation":"s3://bucket/scripts/job.py"}'; 再処理を避けるためにジョブブックマークを有効にします。 Glueと代替案の決定基準:
マネージドなSpark ETL、スキーマ検出、Athena/Redshift Spectrumとのカタログ統合が必要な場合はGlueを使用します。
特化したクラスターチューニング、カスタムライブラリ、または長時間実行クラスターが必要な場合はEMRを使用します。
小さなファイルの軽量な変換には、シンプルなLambdaまたはGlueオンデマンドを使用します。

Kinesis Data StreamsとFirehoseによるストリーミング取り込み

Kinesis Data Streams (KDS)は、リプレイ、コンシューマー制御、きめ細かなスケーリングを備えたリアルタイム取り込みのためのサービスです。Kinesisのシャードは、1MB/秒または1,000レコード/秒の書き込みキャパシティと、2MB/秒の読み込みキャパシティを提供します。aws kinesis create-stream --stream-name my-stream --shard-count 4 を使用し、aws kinesis put-record --stream-name my-stream --partition-key key --data fileb://payload でデータを投入します。パーティションキーがシャードへの割り当てを決定します。パーティションキーのカーディナリティが低いとホットシャードが発生するため、キーのエントロピーを高めるか、ハッシュ値をサフィックスとして付加することで回避します。シャードのスケーリングは aws kinesis update-shard-count を使用するか、自動スケーリングのためにオンデマンドモードを有効にします。

Firehoseは、ニアリアルタイム配信（S3, Redshift, OpenSearch, Splunk）に最適化された配信ストリームサービスで、組み込みのバッファリング、圧縮、およびオプションのLambda変換機能を備えています。バッファリングは BufferingHints の buffer_size (MB) と buffer_interval (秒) で設定し、配信レイテンシーとコストのバランスを調整します。圧縮（GZIP, Snappy）を有効にし、レコードレベルの変換のために処理用のLambdaを設定します。主な違いは以下の通りです。

Kinesis Data Streams:
- リアルタイム、複数コンシューマーをサポート、保持データのリプレイ、明示的なシャード管理
- シャードごとのスループット（1MB/1k書き込み）、パーティションキーの設計が必須
Kinesis Data Firehose:
- 宛先へのマネージドな配信、自動リトライ/バックオフ、配信済みレコードのリプレイは不可
- バッファリング（サイズ/時間）、圧縮、Lambdaによる変換、RedshiftロードのためのS3ステージングをサポート

リプレイ、強力なコンシューマー制御、または複数のダウンストリームコンシューマーが必要な場合はKDSを選択し、S3/Redshift/OpenSearchへのシンプルな配信と変換を最小限の運用オーバーヘッドで実現したい場合はFirehoseを選択します。

DMSによるデータベース移行とCDC

AWS DMSは、同種/異種間のデータベース移行および継続的レプリケーション（CDC）に使用されます。スループットに合わせてサイジングされたレプリケーションインスタンス（aws dms create-replication-instance --replication-instance-class dms.r5.large --allocated-storage 100）をデプロイします。サイジングの決定は、変更レート、フルロードのボリューム、タスクの並列度に基づいて行います。DMSのタスクタイプは以下の通りです。

full-load: 既存データのみをコピー
cdc: 進行中の変更をストリーミング
full-load + cdc: 初期ロード後、変更のストリーミングを継続エンドポイントに適切なエンジン設定（JDBC/接続文字列）を行い、ソース側で追加ロギングやプラグインを有効にし、テーブルをフィルタリング/インクルードするためのJSONテーブルマッピングを提供します。MySQLベースのソースの場合、DMS CDCはソース側でバイナリロギング（binlog）が有効になっており、適切なbinlog_format（ROWを推奨）が設定されている必要があります。PostgreSQLの場合は、論理レプリケーションとwal2jsonのようなプラグインを有効にするか、レプリケーションスロットを使用する必要があります。タスクはCloudWatchメトリクスとタスクログで監視し、スループット向上のためにbatchApplyEnabledとmaxFullLoadSubTasksを調整します。

full-loadとCDCの決定基準: ダウンタイムを最小限に抑えた移行が必要な場合はfull-load+CDCを使用します。別のメカニズムで初期ロードが完了した後の継続的なレプリケーションには、CDCのみを使用します。常にスキーマのマッピングを検証し、代表的なデータ量でテスト移行を実行してください。

APIベースおよびイベント駆動型の取り込みパターン

APIとイベントは、プッシュベースの取り込みとオーケストレーションのためのものです。一般的なパターンは次のとおりです。

API Gateway -> Lambda -> Firehose/Kinesis: クライアントがJSONイベントをプッシュする場合に適しています。API GatewayのスロットリングとLambdaの同時実行制御を使用して、バックプレッシャーを提供し、べき等性ヘッダーを強制します。
S3イベント通知: コンソールまたはaws s3api put-bucket-notification-configurationを使用して、オブジェクト作成イベントをLambda、SQS、またはSNSに送信するようにバケット通知を設定します。プレフィックス/サフィックスフィルターを使用してトリガーを制限します。ファンアウトのためには、S3 -> SNSトピック -> 複数のSQSキュー/Lambdaサブスクライバーへとルーティングし、同じイベントを結合することなく複数のコンシューマーに配信します。
耐久性のある、疎結合な取り込みのためのSQSとSNS: SQSは可視性タイムアウトを持つプルベースのワーカー処理に、SNSはプッシュ型のファンアウトに使用します。

運用上の考慮事項とCLIパターン:

Lambda/SQSの障害にはDLQを使用し、SNSサブスクリプションにはリトライポリシーを設定します。
APIからの高スループットストリーミングでは、APIクライアントをブロックしないように、同期的なダウンストリームへの書き込みよりも、KinesisまたはFirehoseへのバッチ処理を優先します。

よくある落とし穴と判断基準

Kinesis Data Streams（リプレイ可能、シャード管理）とFirehose（マネージド配信、リプレイ不可）の混同: リプレイや複数のコンシューマーが必要な場合はKDSを選択し、単純な配信パイプラインにはFirehoseを選択します。
GlueクローラーのIAM権限を忘れる: クローラーがデータカタログを入力できるように、s3:GetObject/s3:ListBucketおよびglue:CreateTable/UpdateTable/DeleteTableを許可するIAMロールを常にアタッチします。
DMS CDCのためのバイナリロギング/論理レプリケーションの欠落: CDCタスクを開始する前に、MySQLでbinlog（ROW形式）を有効にするか、PostgreSQLで論理レプリケーションとwal2jsonを有効にします。
パーティションキーのカーディナリティが低いためにホットシャードが発生する: ハッシュ化によってパーティションキーのカーディナリティを上げる、カーディナリティの高い属性を含める、またはシャード数を増やします。Put/Getのスロットリングメトリクスを監視します。
Firehoseの過剰なバッファリングや不適切なバッファ設定による高レイテンシー: 許容レイテンシーとリクエスト量に基づいてbuffer_sizeとbuffer_intervalを調整します。
DLQやリトライなしでS3イベント通知に依存する: イベントの欠落を避け、耐久性のあるファンアウトを確保するために、SNS/SQSファンアウトまたはDLQ付きのLambdaを使用します。

実践的な問題：ユースケースシナリオ

RetailCoは、モバイルのクリックストリーム（大容量、リアルタイム）と夜間の製品カタログファイルを収集しており、リアルタイムダッシュボードと統合された分析レイクを必要としています。

ユーザーセッション＋ハッシュ化されたシャードサフィックスから派生したパーティションキーを使用して、クリックストリームをKinesis Data Streamsに取り込みます。リアルタイム処理のために、Kinesis Data AnalyticsまたはLambda/Kinesis Client Libraryを使用してコンシューマーを作成します。
変換Lambdaを備えたKinesis Data Firehoseを使用して、エンリッチされたストリーミング出力をS3（Parquet）に永続化し、Snappyで圧縮し、オプションで分析のためにRedshift Spectrumにロードします。
夜間のカタログファイルをS3のraw/に配置し、スケジュールされたGlueクローラーを実行してGlueデータカタログを更新します。その後、Glue ETLジョブを実行して、キュレート済みゾーンにパーティション化されたParquetとして変換します。
S3イベント通知 -> SNS -> Lambdaを使用して、軽量なメタデータ更新やキャッシュの無効化をトリガーします。耐久性のあるダウンストリーム処理のために、配信をSQSにルーティングします。
Kinesisのシャードメトリクス（IncomingBytes、IncomingRecords、PutRecords.Success）を監視し、UpdateShardCountまたはオンデマンドストリームを使用して増加に対応します。CloudWatchアラームを有効にします。

AWSのベストプラクティスの論理的根拠: リアルタイムパスとバッチパスを分離し、リプレイとコンシューマーの分離が必要な場合はKinesis Data Streamsを使用し、S3/送信先へのマネージド配信にはFirehoseを使用し、Athena/Redshiftとの検出およびクエリ統合のためにGlueデータカタログを維持します。

すべてのドメイン · データストレージとレイクアーキテクチャ →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →