AWS DEA-C01 문제로 공부하기 — Day 02
Glue 워크플로, Redshift Data API, Athena 작업 그룹, FLEX 실행 클래스, S3 이벤트 알림까지 — 5문제로 Domain 1 심화 개념을 정리합니다.
AWS Glue 워크플로(Workflow)는 Glue 크롤러·ETL 작업·트리거를 하나의 파이프라인으로 묶어 오케스트레이션하는 기능입니다. Step Functions이나 MWAA 없이 Glue 안에서 모든 것을 해결할 수 있어 비용과 운영 부담이 가장 낮습니다.
데이터 엔지니어링 팀이 AWS Glue를 기반으로 ETL 파이프라인을 구축하고 있습니다. 이 파이프라인은 온프레미스 SQL Server 데이터베이스를 크롤링하여 스키마를 탐색하고, 추출한 데이터를 변환한 후 Amazon S3에 적재해야 합니다. 팀은 이 일련의 단계를 자동화하여 순서대로 실행되도록 관리하는 솔루션도 필요합니다. 가장 비용 효율적인 방법은 무엇일까요?
-
AAWS Step Functions 상태 머신을 생성하여 Glue 크롤러와 ETL 작업의 실행 순서를 제어합니다.❌ AWS Step Functions — 상태 머신(State Machine) 기반 워크플로 서비스. 요리 레시피 관리자. Lambda·EMR·Glue 등 다양한 서비스를 연결하는 범용 오케스트레이터. 기능은 강력하지만 Glue 전용이 아니라 추가 비용과 설정 부담 발생. Glue만 쓰는 파이프라인엔 과함.
-
BAWS Glue 워크플로를 구성하여 크롤러, ETL 작업, 트리거를 하나의 파이프라인으로 묶어 관리합니다.✅ AWS Glue 워크플로(Workflow) — Glue 크롤러·ETL 작업·트리거를 하나의 DAG(방향 비순환 그래프)로 묶는 내장 오케스트레이션 기능. 공장 라인 전체를 한 콘솔에서 관리. 별도 서비스 없이 Glue 내에서 완결되므로 추가 비용 없음.
-
CAWS Glue Studio의 시각적 편집기로 크롤러와 ETL 작업 흐름을 디자인하고 실행합니다.❌ AWS Glue Studio — 드래그앤드롭 GUI로 ETL 작업을 시각적으로 만드는 작업 편집기. ETL 작업을 만들 때 쓰는 것이지, 여러 작업을 순서대로 실행하는 오케스트레이션 도구가 아님.
-
DAmazon MWAA(Managed Workflows for Apache Airflow)를 사용해 Glue 작업 실행 순서를 DAG로 정의합니다.❌ Amazon MWAA — 완전 관리형 Apache Airflow. 강력하지만 환경 구성 비용 + 시간당 요금이 발생. Glue만 오케스트레이션하는 단순 케이스엔 비용 대비 과도한 선택.
| 서비스 | 비유 | Glue 전용? | 추가 비용 | 적합도 |
|---|---|---|---|---|
| Glue Workflow | 🏭 공장 내장 라인 컨트롤러 | ✓ 전용 | 없음 | ✓ 최적 |
| Step Functions | 📋 범용 레시피 관리자 | 범용 | 상태 전환당 요금 | 과함 |
| MWAA (Airflow) | 🏗️ 대형 현장 소장 | 범용 | 시간당 환경 요금 | 비용 과다 |
| Glue Studio | 🎨 ETL 작업 편집기 | 편집 도구 | 없음(오케스트레이션 아님) | 용도 다름 |
Glue 파이프라인만 오케스트레이션 → Glue Workflow (무료, 내장)
멀티 서비스 복잡한 워크플로 → Step Functions
대규모 Python DAG 관리 → MWAA (Airflow)
Glue Studio = 작업 만드는 편집기 ≠ 오케스트레이션
Amazon Redshift Data API는 JDBC/ODBC 드라이버 없이 HTTP 요청만으로 Redshift에 쿼리를 실행할 수 있는 서비스입니다. 웹·모바일 앱처럼 비동기·단기 연결이 필요한 환경에서 운영 부담 없이 Redshift와 연동할 수 있어 DEA-C01에서 자주 출제됩니다.
한 핀테크 기업이 금융 데이터를 Amazon Redshift에 저장하고 있습니다. 트레이더들이 사용하는 웹 기반 거래 플랫폼은 이 데이터에 대해 실시간 쿼리를 실행해야 하며, 애플리케이션 내에서 직접 Redshift를 조회할 수 있어야 합니다. 운영 오버헤드를 최소화하는 가장 적합한 연결 방식은 무엇일까요?
-
A웹 애플리케이션과 Amazon Redshift 간에 WebSocket 연결을 구성합니다.❌ WebSocket — 클라이언트-서버 간 양방향 실시간 통신 프로토콜. Redshift는 WebSocket 연결을 네이티브로 지원하지 않음. 별도 중간 서버(예: API Gateway + Lambda)가 필요해 운영 오버헤드가 증가.
-
BAmazon Redshift Data API를 사용하여 애플리케이션에서 HTTP 기반으로 쿼리를 실행합니다.✅ Amazon Redshift Data API — HTTP 기반 비동기 쿼리 실행 API. 카페 무인 주문기처럼 앱에서 버튼 누르면 주문(쿼리)이 접수되고 결과를 나중에 가져오는 방식. JDBC 드라이버·영구 DB 연결·VPC 설정 없이 AWS SDK/HTTP 호출만으로 Redshift 쿼리 가능. 웹앱 연동에 최적.
-
CJDBC(Java Database Connectivity) 드라이버를 사용하여 애플리케이션과 Redshift 간 영구 연결을 설정합니다.❌ JDBC(Java Database Connectivity) — Java 애플리케이션이 DB에 연결하는 표준 드라이버 인터페이스. 영구적인 DB 커넥션이 필요해 웹앱에서 연결 관리·풀링·VPC 설정 등 운영 오버헤드가 높음.
-
D자주 조회되는 데이터를 Amazon S3로 내보내고, Amazon S3 Select로 실시간 쿼리를 처리합니다.❌ Amazon S3 Select — S3 객체 내에서 SQL로 원하는 데이터만 필터링해 가져오는 기능. 데이터를 Redshift에서 S3로 복사해야 하고 실시간성이 낮고 데이터 이중화 문제 발생.
| 방식 | 비유 | 연결 방식 | 웹앱 적합? |
|---|---|---|---|
| Redshift Data API | ☕ 무인 주문기 | HTTP 비동기, 드라이버 불필요 | ✓ 최적 |
| JDBC | 🔌 유선 직통 전화 | 영구 TCP 연결, 드라이버 필요 | ✗ 오버헤드 큼 |
| ODBC | 🔌 유선 직통 전화(범용) | 영구 TCP 연결, 드라이버 필요 | ✗ 오버헤드 큼 |
| WebSocket | 📡 양방향 무전기 | Redshift 미지원, 중간 서버 필요 | ✗ 지원 안 함 |
"웹앱 + Redshift + 운영 최소화" → Redshift Data API
JDBC / ODBC = 드라이버·영구연결 필요 → 서버 백엔드에 적합
Data API = HTTP 비동기, 드라이버 없음 → 웹앱·Lambda·서버리스에 적합
Amazon Athena 작업 그룹(Workgroup)은 사용자·팀·애플리케이션별로 쿼리 실행과 쿼리 이력을 격리하는 기능입니다. IAM 정책과 태그를 조합해 쿼리 프로세스와 이력 접근 권한을 세밀하게 분리할 수 있어 DEA-C01 거버넌스·보안 도메인에서 자주 출제됩니다.
한 기업이 Amazon Athena를 사용해 S3에 저장된 데이터를 임시 분석합니다. 여러 팀과 애플리케이션이 동일한 AWS 계정 내에서 Athena를 사용하고 있으며, 각 팀의 쿼리 실행 기록과 쿼리 이력이 서로 노출되지 않도록 격리해야 합니다. 이 요구 사항을 가장 잘 충족하는 방법은 무엇일까요?
-
A팀별로 S3 버킷을 생성하고, 각 IAM 사용자에게 해당 버킷에 대한 접근 권한을 버킷 정책으로 부여합니다.❌ S3 버킷 정책은 데이터 파일 접근을 제어하는 것. 쿼리 프로세스 분리나 쿼리 이력(Query History) 격리는 불가능. 문제 요건의 절반만 해결함.
-
B각 팀별로 Athena 작업 그룹을 생성하고, 태그 기반 IAM 정책으로 작업 그룹 접근 권한을 제어합니다.✅ Athena 작업 그룹(Workgroup) — 도서관의 개별 열람실. 팀마다 열람실이 달라 서로의 대출 이력(쿼리 이력)을 못 봄. 작업 그룹별로 쿼리 실행 격리 + 쿼리 이력 분리 + 결과 저장 위치 분리 + 비용 추적이 모두 가능. 태그 기반 IAM 정책으로 그룹별 접근 권한 세밀하게 제어.
-
C팀별 IAM 역할을 생성하고, 각 역할에 Athena 접근 권한을 부여합니다.❌ IAM 역할로 데이터 접근 권한은 제어 가능하지만 쿼리 이력 격리는 불가능. 같은 Athena 환경에서 실행하면 이력이 공유됨. 작업 그룹 없이는 완전한 분리가 안 됨.
-
DAWS Glue 데이터 카탈로그 리소스 정책을 생성하여 Athena에서 접근 가능한 테이블을 팀별로 제한합니다.❌ Glue Data Catalog 리소스 정책 — 메타데이터 카탈로그(테이블·데이터베이스 정의)에 대한 접근 제어. 데이터 카탈로그 접근은 제한 가능하지만 Athena 쿼리 프로세스와 이력 분리는 해결 안 됨.
| 격리 대상 | Workgroup으로 가능? | S3 버킷 정책으로? | IAM 역할만으로? |
|---|---|---|---|
| 데이터 파일 접근 | ✓ | ✓ | ✓ |
| 쿼리 실행 격리 | ✓ | ✗ | ✗ |
| 쿼리 이력 분리 | ✓ 핵심 | ✗ | ✗ |
| 결과 저장 위치 분리 | ✓ | 부분 | ✗ |
| 팀별 비용 추적 | ✓ | ✗ | ✗ |
"Athena 쿼리 프로세스 + 이력 격리" → Athena Workgroup
S3 버킷 정책 = 데이터 파일 접근만 제어
IAM 역할 = 권한 제어, 이력 격리 안 됨
Workgroup = 쿼리 실행 + 이력 + 결과 위치 + 비용 모두 격리
AWS Glue FLEX 실행 클래스는 유휴 AWS 인프라를 활용해 표준 요금보다 저렴하게 Glue 작업을 실행하는 옵션입니다. 특정 완료 시각이 중요하지 않은 비긴급 배치 작업에 적합하며, DEA-C01에서 "Glue 비용 절감" 키워드와 함께 자주 출제됩니다.
데이터 엔지니어가 AWS Glue 작업 묶음을 매일 실행하는 파이프라인을 구성해야 합니다. 이 작업들은 정해진 시간에 완료되어야 하는 SLA(서비스 수준 계약)가 없으며, 완료 시각에 유연성이 있습니다. Glue 컴퓨팅 비용을 가장 효과적으로 줄일 수 있는 설정은 무엇일까요?
-
AGlue 작업 속성에서 실행 클래스를 FLEX로 설정합니다.✅ FLEX 실행 클래스(FLEX Execution Class) — AWS의 여유 컴퓨팅 자원(스팟처럼)을 활용해 실행되는 Glue 전용 절약 옵션. 심야 할인 택시처럼 언제 배차될지 정확하지 않지만 요금이 저렴. STANDARD 대비 약 34% 저렴. "완료 시각에 유연성이 있다"는 조건과 완벽하게 부합.
-
BGlue 작업에 EC2 스팟 인스턴스 유형을 지정하여 비용을 절감합니다.❌ 스팟 인스턴스(Spot Instance) — EC2 유휴 용량을 저렴하게 사용하는 옵션. Glue 작업 속성에 스팟 인스턴스 유형 선택 항목은 없음. 스팟 인스턴스는 EMR 클러스터 구성에서 선택하는 것. 존재하지 않는 옵션을 고르는 함정 보기.
-
CGlue 작업 속성에서 실행 클래스를 STANDARD로 유지합니다.❌ STANDARD 실행 클래스 — Glue의 기본(정가) 실행 옵션. 예측 가능한 실행 시간과 성능이 보장되지만 가장 비쌈. "비용 절감"이라는 조건과 반대.
-
DGlue 작업의 GlueVersion 필드를 최신 버전으로 설정하여 성능과 비용 효율을 높입니다.❌ GlueVersion — Glue 런타임 버전(예: 4.0). 최신 버전을 쓰면 성능이 향상될 수 있지만 비용을 직접 절감하는 옵션이 아님. 버전 선택은 비용 최적화와 무관.
| 실행 클래스 | 비유 | 비용 | 실행 시간 보장 | 적합 워크로드 |
|---|---|---|---|---|
| FLEX | 🌙 심야 할인 택시 | 저렴 (~34%↓) | 보장 안 됨 | 비긴급 배치, 야간 처리 |
| STANDARD | 🚕 일반 택시 | 정가 | 보장됨 | 시간 민감한 작업 |
"Glue 비용 절감 + 완료 시각 무관" → FLEX 실행 클래스
FLEX = 심야 할인 택시 (저렴, 언제 올지 모름)
STANDARD = 일반 택시 (정가, 예측 가능)
Glue에 스팟 인스턴스 옵션은 없음 → EMR에서 쓰는 개념!
S3 이벤트 알림(Event Notification)은 객체 업로드·삭제 등 이벤트 발생 시 Lambda·SNS·SQS를 자동으로 실행하는 기능입니다. 이벤트 유형과 접미사 필터를 조합하면 .csv 파일 업로드 시에만 Lambda를 직접 트리거할 수 있으며, DEA-C01 이벤트 기반 처리 유형에서 자주 출제됩니다.
팀에서 CSV 파일을 Apache Parquet 형식으로 자동 변환하는 AWS Lambda 함수를 배포했습니다. 이 함수는 사용자가 특정 S3 버킷에 CSV 파일을 업로드할 때만 실행되어야 하며, 다른 파일 형식이나 이벤트에는 반응하지 않아야 합니다. 운영 오버헤드를 최소화하는 방법은 무엇일까요?
-
A이벤트 유형을 s3:ObjectCreated:*로, 접미사 필터를 .csv로 설정한 S3 이벤트 알림을 생성하고, 대상으로 Lambda 함수의 ARN을 지정합니다.✅ s3:ObjectCreated:* — PUT·POST·COPY·멀티파트 업로드 완료 등 객체 생성 이벤트 전체를 포함. 접미사 필터(.csv) — 확장자로 이벤트를 걸러내는 규칙. ARN(Amazon Resource Name) — AWS 리소스의 고유 식별자. S3 → Lambda 직접 연결로 중간 서비스 없이 운영 오버헤드 최소화.
-
Bs3:ObjectTagging:* 이벤트 유형으로 알림을 설정하고, .csv 태그가 지정된 객체에 대해서만 Lambda 함수를 실행합니다.❌ s3:ObjectTagging:* — 객체에 태그를 붙이는 이벤트. 파일 업로드(ObjectCreated)와 완전히 다른 이벤트. 사용자가 .csv를 업로드해도 자동으로 태그가 붙지 않으면 Lambda가 실행되지 않음. 업로드 감지 자체가 안 됨.
-
C이벤트 유형을 s3:*로 설정하고, 접미사 필터를 .csv로 지정하여 Lambda 함수와 연결합니다.❌ s3:* — S3의 모든 이벤트(업로드, 삭제, 복사, 태그 변경 등 전부). 접미사 필터로 .csv는 걸러지지만 삭제·복사 등 불필요한 이벤트에도 Lambda가 실행될 수 있음. 정확한 이벤트 유형(ObjectCreated)을 지정하는 A보다 범위가 너무 넓음.
-
D이벤트 유형을 s3:ObjectCreated:*, 접미사 필터를 .csv로 설정한 알림을 생성하되, 대상을 Amazon SNS 토픽으로 지정하고 SNS에 Lambda 함수를 구독시킵니다.❌ S3 → SNS → Lambda 경로는 기술적으로 작동하지만, Amazon SNS(Simple Notification Service) — 방송 스피커(Pub/Sub) 서비스 — 를 중간에 끼면 불필요한 레이어 추가 = 운영 오버헤드 증가. 단일 Lambda 트리거엔 직접 연결(A)이 최적.
| 선택지 | 이벤트 유형 | 필터 | 대상 | 문제점 |
|---|---|---|---|---|
| A (정답) | ObjectCreated:* | .csv 접미사 | Lambda 직접 | ✓ 완벽 |
| B | ObjectTagging:* | 태그 | Lambda 직접 | 업로드 감지 안 됨 |
| C | s3:* (전체) | .csv 접미사 | Lambda 직접 | 이벤트 범위 과다 |
| D | ObjectCreated:* | .csv 접미사 | SNS → Lambda | 불필요한 SNS 레이어 |
"파일 업로드 감지" → s3:ObjectCreated:*
"확장자 필터" → 접미사(suffix) 필터 .csv
"단일 Lambda 트리거" → S3 → Lambda 직접 연결 (SNS 불필요)
S3 → SNS → Lambda = 여러 곳에 동시 팬아웃(fan-out)할 때만 사용
