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(추출-변환-로드) 작업을 조율하고, 종속성을 관리하며, 장애를 처리하고, 이벤트 기반 프로세스를 통합합니다. 이 도메인에서는 배치 ETL, 복잡한 DAG, 서버리스 상태 머신, 이벤트 스케줄링을 위한 AWS 관리형 옵션을 다룹니다. 각 옵션은 서로 다른 실행 의미 체계, 내구성, 확장성 트레이드오프를 가집니다. AWS Glue Workflows, MWAA, Step Functions, EventBridge Scheduler를 언제 사용해야 하는지, 그리고 오류 처리 및 관찰 가능성을 어떻게 구성하는지 이해하는 것은 예측 가능한 파이프라인과 운영 비용 관리에 매우 중요합니다.

AWS Glue Workflows 및 트리거

AWS Glue Workflows는 Glue 작업, 크롤러, 트리거를 종속성 그래프로 그룹화하여 조정된 ETL을 실행할 수 있게 해줍니다. 콘솔이나 CLI(aws glue create-workflow –name MyWorkflow)를 통해 워크플로를 생성합니다. 트리거는 워크플로에 연결되며, 스케줄, 온디맨드, 조건부의 세 가지 유형이 있습니다. 스케줄 트리거에 대한 CLI 생성 예시:

undefined

조건부 트리거는 작업 이름과 상태(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 워크플로는 파이프라인이 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와 Express 워크플로 중에서 선택합니다:

Standard Workflows: 장기 실행(수개월에서 수년)되고 내구성 있는 상태 머신을 위해 설계되었으며, 정확히 한 번(exactly-once) 실행 의미 체계, 내장된 실행 기록, 실행별 추적/로깅 기능을 갖추고 있습니다. aws stepfunctions start-execution --state-machine-arn arn:... --input '{"key":"value"}'로 시작합니다.
Express Workflows: 높은 처리량, 짧은 지연 시간, 짧은 기간의 처리에 최적화되어 있으며 대규모 환경에서 비용 효율적입니다. 최소 한 번(at-least-once) 실행 의미 체계를 사용하므로 작업은 멱등성을 갖거나 중복 제거 패턴을 사용해야 합니다.

사용 사례 및 결정 기준:

장기간 실행될 수 있고 한 번만 실행되는 의미 체계가 필요한 내구성 있고 감사 가능한 워크플로가 필요할 때 Standard를 사용합니다.
짧은 기간과 비용 효율성이 중요하고, 멱등성 있는 작업을 설계하거나 다운스트림에서 중복을 제거할 수 있는 초당 수천 건의 실행이 있는 이벤트 기반 마이크로 오케스트레이션에는 Express를 사용합니다.

오류 처리 및 통합 패턴:

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 및 일회성 작업을 위한 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나 폴링 계층을 고려하십시오.
일회성, 애드혹(ad-hoc) 미래 호출 및 반복 스케줄에는 EventBridge Scheduler를 사용하십시오. Scheduler는 시간대와 대상별 유연한 재시도 설정을 지원하며, 전달할 수 없는 호출을 위해 데드-레터 SQS 대기열을 구성할 수 있습니다.
고가용성 파이프라인을 위해서는 Step Functions, Lambda 또는 SQS와 같은 대상을 연결하고 대상별 재시도 정책 및 DLQ를 구성하십시오. 예를 들어, put-targets는 SQS 대기열의 Arn이 포함된 DeadLetterConfig를 허용합니다.

오류 처리: 대상별 재시도 횟수와 백오프를 구성하고, 실패한 전달을 위해 DLQ를 사용하며, 복잡한 오류 처리 및 보상 트랜잭션을 위해 EventBridge를 Step Functions와 결합하십시오.

일반적인 함정과 의사결정 기준

실수: 멱등성이 없는(non-idempotent) 작업에 Express Workflows 사용. 올바른 접근 방식: 멱등성을 설계하거나(중복 제거 키, 멱등성 있는 Lambda) 정확히 한 번(exactly-once) 실행 의미론을 위해 Standard 워크플로 사용.
실수: Glue 조건부 트리거가 실패 시 실행될 것이라고 가정. 올바른 접근 방식: 명시적으로 FAILED 트리거를 생성하거나 트리거의 Predicate에 State=FAILED를 포함하여 오류 라우팅.
실수: MWAA를 퍼블릭 서브넷에 배포하거나 NAT 없이 배포. 올바른 접근 방식: MWAA를 프라이빗 서브넷에 배치하고 필요한 서비스 액세스를 위해 NAT 게이트웨이 또는 VPC 엔드포인트 제공.
실수: EventBridge 스케줄이 분 단위 미만일 것으로 기대. 올바른 접근 방식: EventBridge 규칙의 최소 간격은 5분임을 기억하고, 5분 미만의 요구사항에는 Step Functions 또는 Lambda 타이머 사용.
실수: 여러 서비스에 걸친 중앙 집중식 재시도/catch 전략 부재. 올바른 접근 방식: 재시도/백오프(ASL Retry, EventBridge 재시도 구성, Airflow 재시도)를 표준화하고, 실패한 이벤트를 수동/자동 복구를 위해 보존하도록 DLQ 사용.
실수: 과도한 데이터 처리 작업으로 MWAA 워커에 과부하 유발. 올바른 접근 방식: MWAA에서는 오케스트레이션만 수행하고, 무거운 변환 작업은 Glue/EMR/EKS에서 실행하며 작업 간에 포인터(S3 경로) 전달.

실전 문제: Acme Retail의 스파이크가 있는 시간별 ETL

Acme Retail은 원시 데이터 수집을 위한 Glue 작업을 실행하고, Python 연산자로 구성된 복잡한 보강(enrichment) DAG를 처리하며, 빈번한 재고 이벤트에 응답해야 하는 단기 SKU 집계를 수행하는 시간별 ETL이 필요합니다. 이들은 강력한 재시도 및 실패 캡처 기능을 요구합니다.

EventBridge를 사용하여 전체 파이프라인을 조정하는 Step Functions Standard 워크플로를 호출하는 시간별 스케줄 규칙을 트리거합니다.
Step Functions에서 장기 실행 Glue 작업(StartJobRun)을 Retry 및 Catch 핸들러로 오케스트레이션합니다. 실패 시 Catch 블록을 통해 SQS DLQ와 복구 Lambda로 라우팅합니다.
복잡한 보강 DAG를 MWAA에 배포하고, Step Functions에서 Airflow REST API를 사용하거나 SQS에 DAG 실행 메시지를 보내 호출합니다. 예상 동시성을 기반으로 celery.worker_autoscale 설정을 통해 MWAA 워커 크기를 조정하고 CloudWatch 지표를 모니터링하여 조정합니다.
빈번한 재고 이벤트의 경우, EventBridge 이벤트 패턴 규칙을 사용하여 멱등성 키와 SQS 기반 DLQ가 있는 Express Step Function 또는 Lambda로 푸시하여 급증하는 트래픽을 흡수합니다.
중앙 집중식 모니터링(CloudWatch Logs/Metrics, Step Functions용 X-Ray)을 구현하고, DLQ 증가 및 작업 재시도 소진에 대한 경보를 설정합니다.

근거: 이 설계는 각 요구사항에 맞는 올바른 도구를 사용합니다 — 내구성 있는 서비스 간 오케스트레이션 및 오류 처리를 위한 Step Functions, 복잡한 DAG 로직을 위한 MWAA, 관리형 ETL을 위한 Glue, 스케줄링 및 반응형 이벤트를 위한 EventBridge. AWS 모범 사례에 부합하는 탄력적이고 관찰 가능한 파이프라인을 위해 멱등성과 DLQ를 적용합니다.

← 데이터 변환 및 처리 · 모든 도메인 · 데이터 쿼리 및 분석 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →