AWS DEA-C01 문제로 공부하기 — Day 17
MWAA DAG Glue 크롤러+EMR(복수), Hive 메타스토어 Glue 카탈로그, Glue Data Quality 규칙, WAF 로그 CloudWatch Logs Insights, Airflow → MWAA 최소 리팩터링 — 5문제 핵심 정리.
MWAA(Apache Airflow) DAG에서 일별 300GB 변환은 Glue 크롤러로 스키마 탐지 후 처리, 테라바이트 규모 일회성 아카이브 변환은 EMR이 적합합니다. 일별 소규모 데이터에는 Athena·Redshift보다 Glue 크롤러가, 대규모 일회성에는 EMR이 비용 효율적입니다.
ML을 위해 S3 데이터 레이크에서 두 가지 변환 작업을 오케스트레이션합니다. ① 매일 예약 시간에 도착하는 다양한 형식의 데이터 300GB를 변환합니다. ② S3의 테라바이트 규모 아카이브 데이터를 일회성으로 변환합니다. MWAA(Apache Airflow) DAG에 예약할 태스크 조합은 무엇일까요?
- A일별 수신 데이터의 경우 AWS Glue 크롤러를 사용하여 스키마를 스캔하고 식별합니다.✅ Glue 크롤러 — 다양한 형식의 일별 데이터를 자동 스키마 탐지 + 카탈로그 등록. 서버리스로 300GB 규모 일별 처리에 비용 효율적. MWAA의 GlueCrawlerOperator로 DAG에 통합 가능.
- B일별 수신 데이터의 경우 Amazon Athena를 사용하여 스키마를 스캔하고 식별합니다.❌ Athena는 이미 카탈로그에 등록된 데이터를 SQL로 쿼리하는 서비스. 스키마 탐지·등록은 Glue 크롤러의 역할. Athena가 스키마를 스캔하는 기능은 없음.
- C일별 수신 데이터의 경우 Amazon Redshift를 사용하여 변환을 수행합니다.❌ Redshift는 데이터 웨어하우스. 일별 S3 데이터 변환에 Redshift 클러스터를 상시 운영하는 것은 과도한 비용. Glue ETL 또는 크롤러가 더 비용 효율적.
- D일별 데이터 및 아카이브 데이터 모두에 Amazon EMR을 사용하여 데이터 변환을 수행합니다.✅ Amazon EMR — 테라바이트 규모 일회성 아카이브 변환에 최적화된 분산 처리 플랫폼. 대규모 배치 처리에 Spark/Hive 등 활용 가능. MWAA의 EmrOperator로 DAG 통합. 일회성 대용량 처리에 비용 효율적.
- E아카이브 데이터의 경우 Amazon SageMaker를 사용하여 데이터 변환을 수행합니다.❌ SageMaker는 ML 모델 구축·훈련·배포 플랫폼. 범용 데이터 변환(ETL)보다는 ML 파이프라인에 특화. 테라바이트 규모 일반 ETL에는 EMR이 더 적합.
| 데이터 규모 | 빈도 | 적합 서비스 |
|---|---|---|
| 수백 GB (일별) | 정기적 | Glue ETL / 크롤러 |
| 테라바이트+ (일회성) | 일회성 | Amazon EMR |
| SQL 분석 | 온디맨드 | Athena (변환 아님) |
MWAA DAG 태스크 선택:
일별 소규모 스키마 탐지 → Glue 크롤러
대용량 일회성 변환 → Amazon EMR
Athena = 쿼리 (스키마 탐지 아님)
SageMaker = ML 특화 (범용 ETL 아님)AWS Glue 데이터 카탈로그는 Hive 호환 완전관리형 메타스토어입니다. 여러 EMR 클러스터·AWS 서비스·AWS 계정에서 동시에 접근 가능하고 고가용성이 내장되어 있어 EC2·RDS 기반 메타스토어보다 운영 오버헤드가 낮습니다.
영구적이고 신뢰할 수 있는 Apache Hive 메타스토어를 호스팅해야 합니다. 여러 임시 EMR 클러스터, 다양한 AWS 서비스, 여러 AWS 계정이 동시에 접근할 수 있어야 합니다. 항상 가용 상태를 유지해야 합니다. 운영 오버헤드를 최소화하는 솔루션은 무엇일까요?
- A메타스토어로 AWS Glue 데이터 카탈로그를 사용합니다.✅ AWS Glue 데이터 카탈로그 — Apache Hive 메타스토어 호환. 완전관리형으로 별도 서버 운영 없음. 여러 EMR 클러스터·Athena·Redshift Spectrum·LakeFormation이 동시 접근 가능. 멀티 계정 접근 지원. AWS가 고가용성·내구성을 보장. 최소 오버헤드로 모든 요건 충족.
- BMySQL을 메타스토어로 실행하는 외부 Amazon EC2 인스턴스를 사용합니다.❌ EC2 인스턴스 + MySQL 직접 관리 = 패치·백업·고가용성·확장 모두 직접 구성. 운영 오버헤드가 가장 높음.
- CAmazon RDS for MySQL을 메타스토어로 사용합니다.❌ RDS는 관리형이지만 여전히 DB 인스턴스 구성·유지보수·멀티 AZ 설정이 필요. Glue 카탈로그보다 설정·관리 부담이 더 높음.
- DAmazon S3를 메타스토어로 사용합니다.❌ S3는 객체 스토리지. Hive 메타스토어로 직접 사용하는 표준 패턴이 아니며, 트랜잭션 지원이 없어 메타데이터 일관성·동시 접근 보장이 어려움.
| 방법 | 관리형? | 멀티 서비스·계정? | 고가용성? |
|---|---|---|---|
| Glue 데이터 카탈로그 | 완전관리형 | ✓ | ✓ 내장 |
| RDS for MySQL | 관리형 DB | 직접 구성 | Multi-AZ 설정 필요 |
| EC2 + MySQL | 직접 관리 | 직접 구성 | 직접 구성 |
| Amazon S3 | - | - | 메타스토어 부적합 |
"영구 Hive 메타스토어 + 멀티 계정·서비스 + 최소 오버헤드"
→ AWS Glue 데이터 카탈로그
Hive 호환 + 완전관리형 + 멀티 EMR·Athena·Redshift 동시 접근
EC2/RDS = 직접 운영 필요 → 오버헤드 높음AWS Glue Data Quality는 ETL 파이프라인에서 데이터 품질 검사를 자동화하는 기능입니다. 사용자 정의 규칙 세트로 특정 비즈니스 요건에 맞는 검증 규칙을 구체적으로 정의할 수 있습니다. 작업 북마크는 증분 처리, 데이터 카탈로그는 메타데이터 관리 용도로 품질 검사와 다릅니다.
리테일 회사가 고객 주문 데이터셋을 AWS Glue로 ETL 처리합니다. 데이터 정확성과 일관성을 보장하기 위해 구체적인 검증 규칙을 구현해야 합니다. 이 요건을 충족하는 솔루션은 무엇일까요?
- AAWS Glue 작업 북마크를 사용하여 데이터의 정확성과 일관성을 추적합니다.❌ Glue 작업 북마크 — 이전 처리 지점을 추적해 증분 데이터만 처리하는 기능. 데이터 품질 검증(정확성·일관성 규칙)과 무관.
- B사용자 정의 AWS Glue Data Quality 규칙 세트를 생성하여 구체적인 데이터 품질 검사를 정의합니다.✅ AWS Glue Data Quality 사용자 정의 규칙 세트 — DQDL(Data Quality Definition Language)로 특정 컬럼 범위, 완결성, 유일성, 패턴 등 비즈니스 요건에 맞는 구체적 검증 규칙을 정의. ETL 작업과 통합해 자동 검사. 규칙 위반 시 알림·파이프라인 중단 가능.
- C표준 데이터 품질 검증을 위해 기본 제공 AWS Glue Data Quality 변환을 사용합니다.❌ 기본 제공 변환은 일반적인 표준 검사. "구체적인 검증 규칙"이라는 요건에는 사용자 정의 규칙 세트(B)가 더 적합. 비즈니스 특화 규칙은 직접 정의해야 함.
- DAWS Glue 데이터 카탈로그를 사용하여 중앙 집중식 데이터 스키마와 메타데이터 리포지토리를 유지 관리합니다.❌ Glue 데이터 카탈로그는 스키마·메타데이터 관리 도구. 데이터 품질 검사(정확성·일관성 규칙 실행) 기능은 없음.
| 기능 | 역할 | 품질 검사? |
|---|---|---|
| Data Quality 규칙 세트 | DQDL로 검증 규칙 정의 | ✓ |
| 작업 북마크 | 증분 처리 추적 | ✗ |
| 데이터 카탈로그 | 스키마·메타데이터 관리 | ✗ |
| FindMatches 변환 | 중복 레코드 탐지 | 부분적 |
"ETL 데이터 정확성·일관성 구체적 검증 규칙"
→ Glue Data Quality 사용자 정의 규칙 세트
작업 북마크 = 증분 처리 (품질 검사 아님)
카탈로그 = 메타데이터 관리 (품질 검사 아님)Amazon CloudWatch Logs + CloudWatch Logs Insights는 AWS WAF 로그를 실시간에 가까운 속도로 수집하고 대화형 쿼리로 분석할 수 있습니다. WAF 로그는 CloudWatch Logs로 직접 전송 가능하며 추가 서비스 구성이 최소화됩니다.
은행 앱 콜센터에 계정 접근 불가 신고가 잇따릅니다. 보안 팀은 AWS WAF 웹 ACL이 일부 합법적인 요청을 차단하고 있음을 확인했습니다. 데이터 엔지니어가 WAF 로그에서 가양성(합법 요청 차단)을 식별할 가장 효율적인 솔루션은 무엇일까요?
- AFirehose로 WAF 로그를 전송하고, Amazon OpenSearch Service로 전달합니다. OpenSearch 대시보드로 가양성을 식별합니다.❌ Firehose + OpenSearch Service 클러스터 설정·유지보수까지 추가 오버헤드. OpenSearch 클러스터는 상시 운영 비용 발생. CloudWatch Logs보다 설정이 복잡.
- BFirehose로 WAF 로그를 전송하고, Amazon Redshift로 전달합니다. Redshift 쿼리 편집기로 가양성을 식별합니다.❌ Firehose + Redshift 클러스터 설정·로그 스키마 정의까지 추가 단계. WAF 로그 분석 목적에 과도한 인프라. 실시간 분석에도 부적합.
- CWAF 로그를 Amazon CloudWatch Logs로 전송하도록 구성합니다. Amazon CloudWatch Logs Insights 쿼리 편집기로 가양성을 식별합니다.✅ AWS WAF → CloudWatch Logs — WAF 로그를 CloudWatch Logs로 직접 전송. 추가 서비스 없이 즉시 수집 시작. CloudWatch Logs Insights — 대화형 쿼리 편집기로 로그를 실시간 분석. 단일 서비스 구성으로 가장 효율적.
- DWAF 로그를 S3로 전송하고, Glue 크롤러로 카탈로그를 만든 뒤 Athena 쿼리 편집기로 가양성을 식별합니다.❌ S3 + Glue 크롤러 + Athena 테이블 정의까지 여러 단계 구성. 로그 분석에 필요한 것보다 복잡. CloudWatch Logs Insights가 훨씬 직접적이고 빠름.
| 방법 | 설정 복잡도 | 실시간 분석? | 추가 비용 |
|---|---|---|---|
| CloudWatch Logs + Insights | 최소 | ✓ | Logs 저장 비용만 |
| Firehose + OpenSearch | 높음 | ✓ | 클러스터 상시 비용 |
| Firehose + Redshift | 높음 | 지연 | 클러스터 비용 |
| S3 + Glue + Athena | 중간 | 배치 | 쿼리 비용 |
"WAF/CloudWatch 로그 빠른 분석 + 최소 설정"
→ CloudWatch Logs + Logs Insights
Logs Insights = 대화형 쿼리 (SQL 아님, 전용 언어)
추가 서비스 없이 즉시 분석 가능Amazon MWAA(Managed Workflows for Apache Airflow)는 기존 온프레미스 Airflow DAG를 코드 변경 없이 그대로 마이그레이션할 수 있습니다. SQL 데이터 품질 검사 작업도 Airflow의 SQL 오퍼레이터로 그대로 유지 가능합니다.
온프레미스 Apache Airflow로 데이터 파이프라인을 오케스트레이션하고 있습니다. 파이프라인에는 SQL 데이터 품질 검사 작업이 포함됩니다. 이 파이프라인을 AWS 관리형 서비스로 마이그레이션하되 리팩터링을 최소화해야 합니다. 가장 적합한 솔루션은 무엇일까요?
- AAWS Outposts를 설정하고 EC2 인스턴스에 서버를 마이그레이션합니다. EC2에서 온프레미스 파이프라인과 상호 작용하도록 업데이트합니다.❌ AWS Outposts는 온프레미스에 AWS 인프라를 설치하는 하이브리드 솔루션. "AWS로 마이그레이션" 요건에 맞지 않음. EC2 직접 관리 오버헤드도 추가.
- BAirflow 코드가 포함된 커스텀 AMI를 생성하고 EC2 인스턴스에 배포합니다.❌ EC2에 Airflow를 직접 설치·운영하는 방식. EC2 관리·패치·확장을 직접 해야 함. MWAA처럼 Airflow 자체는 관리형이 아님. 오버헤드 높음.
- C기존 Airflow 오케스트레이션 구성을 Amazon MWAA로 마이그레이션합니다. 수집 중에 데이터 품질 검사를 생성하여 Airflow의 SQL 작업으로 데이터 품질을 검증합니다.✅ Amazon MWAA — 기존 Airflow DAG·오퍼레이터·플러그인을 코드 거의 변경 없이 그대로 사용 가능. SQL 데이터 품질 검사도 Airflow의 SQLOperator 등으로 유지. AWS가 Airflow 인프라 관리. 최소 리팩터링으로 AWS 마이그레이션 달성.
- D파이프라인을 AWS Step Functions로 변환하고, SQL 데이터 품질 검사를 Python 기반 Lambda 함수로 재작성합니다.❌ Airflow DAG를 Step Functions 상태 머신으로 변환 + SQL 검사를 Python Lambda로 재작성 = 전면 리팩터링. 최소 리팩터링 요건과 정반대.
| 방법 | 리팩터링? | Airflow 코드 재사용? | 관리형? |
|---|---|---|---|
| Amazon MWAA | 최소 | ✓ 그대로 | ✓ |
| EC2 + Airflow 직접 설치 | 최소 | ✓ | ✗ 직접 관리 |
| Step Functions + Lambda | 전면 리팩터링 | ✗ | ✓ |
"온프레미스 Airflow → AWS + 최소 리팩터링"
→ Amazon MWAA (관리형 Apache Airflow)
기존 DAG·오퍼레이터·플러그인 그대로 사용 가능
Step Functions = 전면 재작성 필요 (최소 리팩터링 아님)
