AWS DEA-C01 문제로 공부하기 — Day 10
Athena 부실 파티션 제거, MWAA 하이브리드 오케스트레이션, EMR 암호화 보안 구성, CloudTrail Lake 멀티계정 감사, Redshift ALL 분산 스타일 — 5문제 핵심 정리.
Athena에서 S3 파티션을 수동 삭제하면 Glue 데이터 카탈로그에 파티션 메타데이터가 남아 "Partitions missing from file system" 오류가 발생합니다. ALTER TABLE DROP PARTITION으로 부실 메타데이터를 제거해야 합니다.
데이터 팀이 Amazon Athena 외부 테이블의 S3 파티션 경로 하나를 콘솔에서 직접 삭제했습니다. 이후 Athena 테이블을 새로 고치려 했지만 "Partitions missing from file system" 오류가 발생합니다. 운영 효율적으로 오류를 해결하고 테이블을 정상화하는 방법은 무엇일까요?
- A오류가 사라질 때까지 MSCK REPAIR TABLE 명령을 반복 실행합니다.❌ MSCK REPAIR TABLE — S3에 있는 파티션을 카탈로그에 추가하는 명령. 이미 S3에서 삭제된 파티션 메타데이터를 제거하지 않음. 반복 실행해도 오류 해결 불가.
- B누락된 파티션 경로를 S3에 다시 만드는 Python 스크립트를 작성합니다.❌ 문제는 S3에 파일이 없는데 카탈로그에 메타데이터가 남아있는 것. 해결책은 S3에 파일을 복원하는 것이 아니라 카탈로그의 부실 메타데이터를 제거하는 것. 방향이 반대.
- CALTER TABLE DROP PARTITION 명령으로 카탈로그에 남아있는 부실 파티션 메타데이터를 제거합니다.✅ ALTER TABLE DROP PARTITION — Glue 데이터 카탈로그에서 특정 파티션 메타데이터를 제거하는 Athena DDL 명령. S3에서 이미 삭제된 파티션의 카탈로그 항목만 정확히 삭제. 한 번 실행으로 해결 가능.
- DVACUUM 명령을 실행하여 부실 파티션을 정리합니다.❌ VACUUM — Iceberg/Delta 테이블에서 오래된 데이터 파일을 압축·정리하는 명령. Athena 파티션 메타데이터 관리와 무관. Athena에서 파티션 제거에 사용하지 않음.
| 명령 | 동작 | S3 파일 삭제 후 오류 해결? |
|---|---|---|
| ALTER TABLE DROP PARTITION | 카탈로그 파티션 메타데이터 삭제 | ✓ 정확 |
| MSCK REPAIR TABLE | S3 경로 스캔 후 메타데이터 추가 | ✗ 추가만 가능 |
| ALTER TABLE ADD PARTITION | 수동으로 파티션 메타데이터 추가 | ✗ 방향 반대 |
| VACUUM | 데이터 파일 정리·압축 | ✗ 무관 |
"S3 파티션 삭제 후 카탈로그 오류"
→ ALTER TABLE DROP PARTITION (부실 메타데이터 제거)
MSCK REPAIR = 추가만 가능 (제거 불가) → 이 경우 오답
VACUUM = 파티션 관리 아님Amazon MWAA(Managed Workflows for Apache Airflow)는 오픈소스 Apache Airflow를 완전 관리형으로 제공합니다. 온프레미스와 클라우드 리소스를 모두 오케스트레이션할 수 있으며, 오픈소스 생태계와의 호환성이 핵심 강점입니다.
데이터 팀이 온프레미스 리소스와 AWS 클라우드 리소스를 함께 사용하는 하이브리드 데이터 오케스트레이션 워크플로를 구축하려 합니다. 이동성과 오픈소스 생태계 활용을 우선시합니다. 두 환경 모두를 지원하는 단일 서비스는 무엇일까요?
- AAWS Data Exchange❌ AWS Data Exchange — 타사 데이터셋 구독·공유 서비스. 데이터 오케스트레이션 기능 없음. 클라우드 전용 서비스로 온프레미스 연동 불가.
- BAmazon Simple Workflow Service(SWF)❌ Amazon SWF — 분산 애플리케이션 조정 서비스. 오케스트레이션 기능은 있지만 오픈소스가 아니며 온프레미스·클라우드 하이브리드에 특화되지 않음. 추가 서비스나 드라이버가 별도로 필요.
- CAmazon Managed Workflows for Apache Airflow(Amazon MWAA)✅ Amazon MWAA — 오픈소스 Apache Airflow의 완전 관리형 서비스. 플러그인으로 온프레미스·클라우드 데이터 소스 모두 연결 가능. 오픈소스 오퍼레이터 생태계(1,000+)를 그대로 사용. 이동성(Portability) 완벽 지원.
- DAWS Glue❌ AWS Glue 워크플로 — AWS 클라우드 전용 ETL 오케스트레이션. 온프레미스에서 Glue 워크플로를 직접 실행할 수 없음. 오픈소스가 아닌 AWS 고유 서비스.
| 서비스 | 오픈소스? | 온프레미스 지원? | 하이브리드 적합? |
|---|---|---|---|
| Amazon MWAA (Airflow) | ✓ Apache | ✓ | ✓ 최적 |
| AWS Step Functions | ✗ AWS 전용 | 제한적 | 클라우드 중심 |
| AWS Glue 워크플로 | ✗ AWS 전용 | ✗ | 클라우드만 |
| Amazon SWF | ✗ | 제한적 | 추가 서비스 필요 |
"하이브리드 오케스트레이션 + 오픈소스 + 이동성"
→ Amazon MWAA (관리형 Apache Airflow)
Glue 워크플로 = 클라우드 전용 (온프레미스 불가)
Airflow = 오픈소스 → 어디서나 실행 가능Amazon EMR 보안 구성(Security Configuration)은 클러스터의 저장 데이터 암호화(at rest)와 전송 데이터 암호화(in transit)를 한 번에 설정하는 기능입니다. IAM 정책이나 외부 소프트웨어 설치 없이 내장 기능으로 구성합니다.
분석팀이 Amazon EMR 클러스터에서 대용량 데이터를 처리합니다. 보안 정책상 클러스터에 저장된 데이터와 노드 간 전송 중인 데이터 모두 암호화해야 합니다. 운영 오버헤드를 최소화하는 방법은 무엇일까요?
- AEMR 클러스터를 시작하기 전에 부트스트랩 작업을 사용하여 각 노드에 암호화 설정 스크립트를 배포합니다.❌ 부트스트랩 스크립트로 암호화 설정하는 것은 기술적으로 가능하지만 직접 코드 작성·유지보수 부담이 큼. EMR에 내장된 보안 구성 기능을 쓰면 코딩 없이 해결 가능.
- BAmazon EMR의 보안 구성(Security Configuration) 기능을 사용하여 저장 데이터 및 전송 데이터 암호화를 설정합니다.✅ EMR 보안 구성(Security Configuration) — EMR 전용 보안 설정 템플릿. 저장 데이터 암호화(S3, HDFS, EBS), 전송 중 암호화(노드 간 TLS), Kerberos 인증을 GUI/JSON으로 한번에 설정. 클러스터 생성 시 보안 구성을 선택하면 자동 적용.
- CEMR 클러스터에서 암호화를 허용하는 IAM 정책을 생성합니다.❌ IAM 정책 — AWS 리소스 접근 권한 관리. 암호화 설정은 IAM 정책이 아닌 EMR 보안 구성에서 수행. IAM으로 "암호화를 허용"해도 실제 암호화가 활성화되지 않음.
- D각 EMR 클러스터 노드에 서드파티 암호화 소프트웨어를 직접 설치하고 구성합니다.❌ 외부 소프트웨어 설치·유지보수·라이선스 관리까지 추가되어 운영 오버헤드가 가장 큼. EMR 내장 보안 구성으로 불필요한 작업.
| 암호화 대상 | 지원 방식 |
|---|---|
| S3 저장 데이터 | SSE-S3, SSE-KMS, CSE-KMS |
| HDFS 저장 데이터 | HDFS 투명 암호화 |
| EBS 볼륨 | AWS KMS 암호화 |
| 노드 간 전송 데이터 | TLS(전송 계층 보안) |
"EMR 저장·전송 데이터 암호화" → EMR 보안 구성(Security Configuration)
IAM 정책 = 접근 제어 (암호화 설정 아님)
EMR 보안 구성 = 암호화 전용 설정 템플릿 (내장, 코딩 불필요)AWS CloudTrail Lake는 여러 AWS 계정의 CloudTrail 이벤트를 이벤트 데이터 스토어로 집계하고 SQL로 직접 쿼리할 수 있는 완전관리형 서비스입니다. S3 + Glue + Athena 파이프라인보다 훨씬 적은 설정으로 구현 가능합니다.
다수의 AWS 계정을 운영하는 기업이 모든 계정의 활동을 중앙에서 감사하려 합니다. 감사팀이 SQL 쿼리로 이벤트 로그를 분석할 수 있어야 합니다. 최소한의 개발·관리 작업으로 구현하는 방법은 무엇일까요?
- A중앙 S3 버킷으로 CloudTrail 로그를 수집하고, Glue ETL로 JSON을 변환한 뒤 Athena로 쿼리합니다.❌ S3 프로비저닝 + Glue ETL 작업 구성 + Athena 테이블 스키마 정의 + SQL 스크립트 작성까지 여러 단계를 직접 구성해야 함. 개발·관리 부담이 큼.
- BAWS CloudTrail Lake를 사용하여 이벤트 데이터 스토어를 생성하고 SQL 쿼리로 분석합니다.✅ AWS CloudTrail Lake — 여러 계정 이벤트를 이벤트 데이터 스토어로 자동 집계 + SQL 쿼리 기능 내장. 별도 S3·Glue·Athena 설정 없이 CloudTrail Lake 하나로 완결. 최소 설정으로 멀티계정 감사 + SQL 분석 구현.
- C중앙 S3 버킷으로 CloudTrail 로그를 수집하고 Redshift에 로드하여 쿼리합니다.❌ S3 + Redshift 클러스터 배포 + COPY 명령 구성까지 추가 인프라와 설정이 필요. 관리 부담이 높음.
- D계정별 S3 버킷에 CloudTrail 로그를 수집하고 중앙 Glue 카탈로그 + Athena로 쿼리합니다.❌ 계정별 S3 버킷 관리 + Glue 크롤러 + ETL 작업 + Athena 설정까지 가장 많은 구성이 필요. 개발·관리 오버헤드 최대.
| 방법 | SQL 쿼리 | 설정 복잡도 | 관리 부담 |
|---|---|---|---|
| CloudTrail Lake | ✓ 내장 | 최소 | 완전관리형 |
| S3 + Athena | ✓ (설정 필요) | 중간 | 중간 |
| S3 + Glue + Athena | ✓ (많은 설정) | 높음 | 높음 |
| S3 + Redshift | ✓ (클러스터 필요) | 높음 | 높음 |
"멀티 AWS 계정 감사 + SQL 쿼리 + 최소 설정"
→ AWS CloudTrail Lake
이벤트 데이터 스토어 생성 → SQL 쿼리 바로 실행
S3+Glue+Athena = 여러 단계 직접 구성 필요Redshift ALL 분산 스타일은 테이블 전체 복사본을 모든 노드에 배치합니다. 자주 변경되지 않는 소규모 차원 테이블에 적합하며, 조인 시 브로드캐스트(네트워크 전송)를 제거해 쿼리 성능을 크게 향상시킵니다.
Redshift 클러스터에서 트랜잭션, 매장위치, 고객 테이블 세 개가 EVEN 분산으로 설정되어 있습니다. 매장위치 테이블은 수년에 한두 번만 업데이트됩니다. 대부분의 쿼리 실행 시 매장위치 테이블 전체가 4개 노드 모두로 브로드캐스트되어 성능이 저하됩니다. 가장 비용 효율적으로 브로드캐스트를 최소화하는 방법은 무엇일까요?
- A매장위치 테이블의 분산 스타일을 EVEN에서 ALL로 변경합니다.✅ ALL 분산 — 테이블 전체를 모든 노드에 미리 복사해 두는 방식. 쿼리 실행 시 브로드캐스트(실시간 전송) 불필요 → 네트워크 오버헤드 제거. 수년에 한두 번만 업데이트되는 느리게 변하는 차원 테이블에 최적.
- B매장위치 테이블을 카디널리티가 높은 컬럼 기준 KEY 분산으로 변경합니다.❌ KEY 분산 — 특정 키 값으로 행을 각 노드에 분산. 같은 키 값끼리 같은 노드에 모임. 브로드캐스트를 줄이지 않음. 팩트-차원 테이블 조인 최적화에는 조인 키로 KEY 분산이 유리하지만 이 케이스엔 부적합.
- C모든 테이블 정렬 키에 매장 ID 조인 컬럼을 추가합니다.❌ 정렬 키(Sort Key) — 노드 내 데이터 정렬로 범위 스캔 최적화. 노드 간 브로드캐스트를 줄이는 기능은 없음. 서로 다른 문제를 해결하는 설정.
- DRedshift 예약 노드를 더 큰 인스턴스 크기로 업그레이드합니다.❌ 인스턴스 크기 업그레이드는 각 노드의 컴퓨팅·메모리 증가. 노드 간 브로드캐스트 자체는 줄어들지 않음. 추가 비용만 발생.
| 분산 스타일 | 데이터 배치 | 적합한 테이블 | 브로드캐스트? |
|---|---|---|---|
| EVEN | 라운드 로빈 균등 분산 | 일반 팩트 테이블 | 조인 시 발생 |
| ALL | 모든 노드에 전체 복사 | 소규모·느린 변경 차원 테이블 | ✗ 제거됨 |
| KEY | 키 값 기준 분산 | 팩트-차원 조인 키 일치 | 키 일치 시 제거 |
| AUTO | Redshift 자동 선택 | 일반 케이스 | 상황에 따라 |
"브로드캐스트 반복 발생 + 자주 안 바뀌는 소규모 테이블"
→ ALL 분산 (모든 노드에 미리 복사, 브로드캐스트 제거)
EVEN = 균등 분산 (브로드캐스트 여전히 발생)
ALL = 차원 테이블 전용 (느린 업데이트 테이블에 최적)
