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.

オーケストレーションとワークフロー管理は、信頼性と保守性の高いデータプラットフォームを構築する上で中心的な役割を果たします。これらは、ETL（extract-transform-load）ジョブの調整、依存関係の管理、障害処理、イベント駆動型プロセスの統合を行います。このドメインでは、バッチETL、複雑なDAG、サーバーレスステートマシン、イベントスケジューリングのためのマネージドなAWSオプションを扱います。それぞれ実行セマンティクス、耐久性、スケーリングのトレードオフが異なります。AWS Glue Workflows、MWAA、Step Functions、EventBridge Schedulerをいつ使用するか、そしてエラーハンドリングとオブザーバビリティをどのように設定するかを理解することは、予測可能なパイプラインと運用コストの管理に不可欠です。

AWS Glue ワークフローとトリガー

AWS Glue Workflowsは、Glueジョブ、クローラー、トリガーを依存関係グラフにグループ化し、協調したETLを実行できるようにします。ワークフローは、コンソールまたはCLI（aws glue create-workflow –name MyWorkflow）で作成します。トリガーはワークフローにアタッチされ、スケジュール型、オンデマンド型、条件付き型の3種類があります。スケジュール型トリガーのCLI作成例：

• aws glue create-trigger –name hourly-trigger –workflow-name MyWorkflow –type SCHEDULED –schedule “cron(0 * * * ? *)” –actions ‘[{“JobName”:“etl-job”}]’

条件付きトリガーは、ジョブ名と状態（SUCCEEDED、FAILED）を参照するPredicateを使用します。PredicateのJSON例：{“Logical”:“AND”,“Conditions”:[{“JobName”:“prev-job”,“State”:“SUCCEEDED”}]}。デフォルトでは、Glueの条件付きトリガーは成功時に起動します。障害を処理するには、State=FAILEDで条件を設定するか、エラーを修正ジョブやSNSアラートにルーティングするための明示的なFAILEDトリガーを作成します。

運用パターンと判断基準：

• ネイティブなGlueジョブ/クローラーのオーケストレーションとリネージが必要な場合は、Glue Workflowsを使用します。cronスケジューリングや完了時にジョブを連鎖させる場合はトリガーを選択します。
• アドホックな呼び出しには、aws glue start-workflow-run –name MyWorkflowを使用するか、オンデマンドトリガーに対してstart-triggerを使用します。
• 複雑な分岐やGlue以外のタスクには、Step FunctionsやMWAAが適しています。Glue Workflowsは、パイプラインがGlue中心である場合に最適です。

エラーハンドリング：FAILEDトリガーを追加し、ジョブの成功/失敗に関するCloudWatchメトリクスを出力し、自動リトライや調査のためにLambdaを介して障害をSQS/SNSデッドレターキューにプッシュします。

複雑なDAGのためのAmazon MWAA (Managed Airflow)

MWAAは、複雑なDAG、タスクの依存関係、センサー、カスタムオペレーターを表現するためのマネージドなApache Airflow環境を提供します。aws mwaa create-environment –name MyEnv –airflow-configuration-options Key=core.executor,Value=CeleryExecutorで環境を作成し、DAGのS3パスと実行ロールを指定します。重要なサイジングとネットワーキングの詳細：

• MWAAは、プライベートサブネットとインターネットアクセス用のNATゲートウェイを持つVPCを必要とします。パブリックサブネットのみの構成はサポートされていません。
• ワーカーとスケジューラーの動作は、環境作成時に提供されるAirflow設定オプション（AirflowConfigurationOptions）を通じて制御されます。タスクの同時実行性とDAGの複雑さに合わせて、celery.worker_concurrency、celery.worker_autoscale、およびスケジューラーの設定を調整します。
• CloudWatchメトリクス（SchedulerHeartbeat、TasksFailed、TasksRunning、QueuedTasks）を監視し、キューの増加が見られる場合はワーカーのオートスケールを調整するか、最大ワーカー数を増やします。

判断基準：

• 複雑なDAG、豊富なオペレーター、DAG間の依存関係、SLA/タスク実行漏れのセンサー、カスタムPythonロジックといったAirflowの機能が必要な場合は、MWAAを使用します。
• タスクが短命で非常に高いスループットを要求される場合は、サーバーレスのStep Functions ExpressやマネージドETL操作のためのGlueが適しています。
• 重くて長時間のタスクはマネージドコンピューティング（Glue/EMR/EKS）で実行し、MWAAタスクはオーケストレーションのみに使用します。MWAAワーカー自体で大規模なデータ変換を実行することは避けてください。

Airflowでのエラーハンドリング：DAG定義でタスクのリトライとretry_delayを使用し、on_failure_callbackを設定して通知したりSQSデッドレターキューにプッシュしたりします。また、タスクレベルのSLAハンドリングを設定して修正用のDAGをトリガーします。

サーバーレスオーケストレーションのためのAWS Step Functions

Step Functionsは、JSONベースのAmazon States Languageを使用したステートフルなオーケストレーションを提供し、AWSサービスと幅広く統合されています。標準ワークフローとエクスプレスワークフローのいずれかを選択します。

• 標準ワークフロー（Standard Workflows）：長期間（数ヶ月から数年）実行される、耐久性のあるステートマシンのために設計されており、厳密に1回（exactly-once）の実行セマンティクス、組み込みの実行履歴、実行ごとのトレース/ロギングを備えています。aws stepfunctions start-execution –state-machine-arn arn:… –input ‘{“key”:“value”}‘で開始します。
• エクスプレスワークフロー（Express Workflows）：高スループット、低レイテンシー、短時間の処理に最適化されており、大規模な場合にコスト効率が高くなります。少なくとも1回（at-least-once）の実行セマンティクスを使用するため、タスクはべき等であるか、重複排除パターンを使用する必要があります。

ユースケースと判断基準：

• 長期間実行される可能性があり、1回限りのセマンティクスを必要とする、耐久性があり監査可能なワークフローが必要な場合は、標準ワークフローを使用します。
• 短時間でコスト効率が重要であり、べき等なタスクを設計するか下流で重複排除できる、毎秒数千の実行があるイベント駆動型のマイクロオーケストレーションには、エクスプレスワークフローを使用します。

エラーハンドリングと統合パターン：

• ASLのRetryブロックを使用して、ErrorEquals、IntervalSeconds、BackoffRate、MaxAttemptsでリトライを定義します。
• Catchブロックを使用して、障害を代替ブランチやFail/Success状態にリダイレクトし、診断のためにResultPathにエラー詳細を格納します。
• 非同期のデッドレタリングには、失敗したメッセージをSQS/SNSにプッシュするか、エラーペイロードをオフライン処理のためにSQS DLQに送信するStep Functionsパターンを設計します。オブザーバビリティのために、LoggingConfigurationとTracingConfigurationを介してCloudWatch LogsとX-Rayトレースを有効にします。

EventBridge Schedulerとイベント駆動型パイプライン

EventBridgeは、豊富なイベントルーティングと、cronおよび1回限りのタスクのためのScheduler機能を提供します。スケジュールベースのルールは aws events put-rule --name dailyRule --schedule-expression "cron(0 2 * * ? *)" で作成し、ターゲットは aws events put-targets でアタッチします。イベント駆動型（パターン）ルーティングの場合、put-rule に --event-pattern '{"source":["aws.s3"],"detail-type":["Object Created"]}' を指定して、S3イベントをLambda、Step Functions、またはSQSにルーティングします。

主な運用上のポイント：

• EventBridgeはスケジュール式（cronおよびrate）をサポートしています。rate式を使用する場合、EventBridgeルールには5分間の最小間隔があることに注意してください。より細かい粒度が必要な場合は、Step Functionsまたはポーリングレイヤーを検討してください。
• 1回限りのアドホックな将来の呼び出しや定期的なスケジュールには、EventBridge Schedulerを使用します。Schedulerはタイムゾーンとターゲットごとの柔軟なリトライ設定をサポートし、配信不能な呼び出しのためにデッドレターSQSキューを設定できます。
• 高信頼性パイプラインには、Step Functions、Lambda、SQSなどのターゲットをアタッチし、ターゲットごとのリトライポリシーとDLQを設定します。例えば、put-targetsはSQSキューのArnを持つDeadLetterConfigを受け入れます。

エラーハンドリング：ターゲット固有のリトライ試行とバックオフを設定し、配信失敗にはDLQを使用し、複雑なエラーハンドリングや補償トランザクションにはEventBridgeとStep Functionsを組み合わせます。

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

• 間違い：べき等でないタスクにExpressワークフローを使用する。正しいアプローチ：べき等性（重複排除キー、べき等なLambda）を設計するか、Standardワークフローを使用してexactly-onceセマンティクスを確保する。
• 間違い：Glueの条件付きトリガーが失敗時に発火すると仮定する。正しいアプローチ：明示的にFAILEDトリガーを作成するか、トリガーのPredicateにState=FAILEDを含めてエラーをルーティングする。
• 間違い：MWAAをパブリックサブネットやNATなしでデプロイする。正しいアプローチ：MWAAをプライベートサブネットに配置し、必要なサービスアクセスにはNATゲートウェイまたはVPCエンドポイントを提供する。
• 間違い：1分未満のEventBridgeスケジュールを期待する。正しいアプローチ：EventBridgeルールには5分間の最小間隔があることを覚えておく。5分未満の要件にはStep FunctionsまたはLambdaタイマーを使用する。
• 間違い：サービス横断での集中管理されたリトライ/キャッチ戦略がない。正しいアプローチ：リトライ/バックオフ（ASLのRetry、EventBridgeのリトライ設定、Airflowのリトライ）を標準化し、DLQを使用して失敗したイベントを保持し、手動または自動での修復に備える。
• 間違い：MWAAワーカーに重いデータ処理を過負荷させる。正しいアプローチ：MWAAではオーケストレーションのみを行い、重い変換処理はGlue/EMR/EKSで実行し、タスク間ではポインタ（S3パス）を渡す。

実践的な問題：Acme Retail社のスパイクのある毎時ETL

Acme Retail社は、生データの取り込みのためのGlueジョブ、Pythonオペレーターを含む複雑なエンリッチメントDAG、そして高頻度の在庫イベントに応答する必要がある短時間のSKU集計を実行する、毎時ETLを必要としています。彼らは堅牢なリトライと障害キャプチャを要求しています。

1. EventBridgeを使用して、パイプライン全体を調整するStep FunctionsのStandardワークフローを呼び出す、毎時実行のスケジュールルールをトリガーします。
2. Step Functions内で、長時間実行されるGlueジョブ（StartJobRun）をRetryおよびCatchハンドラでオーケストレーションします。失敗時には、Catchブロックを介してSQS DLQと修復用Lambdaにルーティングします。
3. 複雑なエンリッチメントDAGをMWAAにデプロイし、Step FunctionsからAirflow REST APIを使用するか、SQSにDAG実行メッセージを配置して呼び出します。MWAAワーカーは、予想される同時実行数に基づいてcelery.worker_autoscale設定でサイジングし、CloudWatchメトリクスを監視して調整します。
4. 高頻度の在庫イベントには、EventBridgeのイベントパターンルールを使用して、べき等性キーを持つExpress Step FunctionまたはLambdaにプッシュし、SQSをバックエンドとするDLQでバーストを吸収します。
5. 集中監視（CloudWatch Logs/Metrics、Step Functions用のX-Ray）を実装し、DLQの増加やタスクリトライの枯渇に対してアラートを設定します。

論理的根拠：この設計は、各要件に対して適切なツールを使用しています — 耐久性のあるサービス間オーケストレーションとエラーハンドリングにはStep Functions、複雑なDAGロジックにはMWAA、マネージドETLにはGlue、スケジューリングとリアクティブなイベントにはEventBridgeです。これにより、AWSのベストプラクティスに沿った、回復力と可観測性を備えたパイプラインのためのべき等性とDLQが強制されます。

← データ変換と処理 · すべてのドメイン · データクエリと分析 →

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

Amazonを閲覧 →