AWS DEA-C01 문제로 공부하기 — Day 04
DynamoDB 최소 RCU 쿼리, DynamoDB DAX 서버리스, Redshift UNLOAD, Redshift 경고 시스템 테이블, Glue 데이터 품질까지 — 5문제 핵심 정리.
DynamoDB Query는 파티션 키를 조건으로 해당 파티션만 읽어 RCU(읽기 용량 단위)를 최소화합니다. Scan은 전체 테이블을 읽어 RCU 낭비가 크며, DEA-C01에서 "최소 RCU" 키워드가 나오면 Query + 파티션 키 조합이 정답입니다.
AWS Glue PySpark 작업이 Amazon DynamoDB 테이블에서 특정 레코드를 읽어야 합니다. 처리해야 할 레코드의 파티션 키 값은 이미 알고 있으며, 이후 처리 로직은 데이터가 DynamicFrame 형식이어야 합니다. 불필요한 데이터를 최대한 적게 읽으면서 이 요건을 충족하는 방법은 무엇일까요?
- AGlue DynamoDB ETL 커넥터로 테이블 전체를 읽고, 커넥터의 필터 옵션으로 필요한 파티션 키 레코드만 걸러냅니다.❌ Glue DynamoDB 커넥터의 필터 옵션은 내부적으로 전체 테이블 스캔 후 필터링. 원하는 데이터만 읽는 게 아니라 전체를 읽고 버리는 방식 → RCU 낭비.
- BGlue 작업에서 DynamoDB 테이블 전체를 스캔하여 DynamicFrame에 적재한 뒤, 파티션 키로 DynamicFrame을 필터링합니다.❌ 스캔(Scan) — 도서관 전체 책을 다 꺼내서 읽은 후 필요한 책만 고르는 것. 테이블 전체를 읽으므로 RCU가 가장 많이 소비됨. 최소 RCU와 반대.
- CGlue 작업에서 파티션 키를 키 조건식으로 사용해 DynamoDB 쿼리를 실행하고, 결과를 DynamicFrame에 저장합니다.✅ 쿼리(Query) — 도서관 색인에서 책 번호 확인 후 그 책만 꺼내는 것. 파티션 키를 키 조건식에 사용하면 해당 파티션의 데이터만 정확히 읽음 → RCU 최소화. 결과를 DynamicFrame으로 변환해 기존 처리 로직과 호환.
- D정렬 키만 키 조건식으로 사용해 DynamoDB 쿼리를 실행하고, 결과를 DynamicFrame에 로드합니다.❌ DynamoDB 쿼리는 반드시 파티션 키가 있어야 실행 가능. 정렬 키(Sort Key)만으로는 쿼리 자체가 불가. 파티션 키 없이 정렬 키만 사용하면 에러 발생.
| 방식 | 비유 | 읽는 범위 | RCU 소비 |
|---|---|---|---|
| GetItem | 📖 책 번호로 한 권 바로 꺼냄 | 단일 항목 | 최소 |
| Query (파티션 키) | 📚 색인으로 해당 선반만 | 파티션 내 항목들 | ✓ 적음 |
| Scan + 필터 | 🏛️ 전체 도서관 다 꺼내고 골라냄 | 테이블 전체 | 최대 |
"최소 RCU로 특정 항목 읽기" → Query + 파티션 키
Scan = 전체 읽기 → RCU 최대 (오답 패턴)
정렬 키만 = Query 불가 → 파티션 키 필수!Amazon DynamoDB + DAX(DynamoDB Accelerator)는 서버리스 NoSQL에 인메모리 캐시를 더해 마이크로초 단위 응답을 제공합니다. 반정형 데이터·서버리스·밀리초 응답 조합은 DEA-C01의 단골 정답 패턴입니다.
애플리케이션이 JSON 구조의 트랜잭션 데이터를 저장해야 합니다. 인프라 관리 부담이 없는 서버리스 데이터베이스여야 하며, 쓰기는 드물게 발생하지만 읽기 요청은 매우 빈번합니다. 데이터는 밀리초 이내에 반환되어야 합니다. 운영 부담을 최소화하는 솔루션은 무엇일까요?
- AAmazon S3에 Apache Iceberg 테이블 형태로 데이터를 저장하고, S3 Transfer Acceleration을 활성화합니다.❌ S3 Iceberg — 데이터 레이크 테이블 포맷. 밀리초 단위 개별 레코드 조회 불가. S3 Transfer Acceleration은 업로드 속도 향상 기능으로 쿼리 응답속도와 무관.
- BAmazon S3 Standard 버킷에 데이터를 저장하고 S3 Transfer Acceleration을 활성화합니다.❌ S3는 객체 스토리지로 DB가 아님. 개별 레코드 검색에 밀리초 응답 불가. S3 Transfer Acceleration도 이 요건과 무관.
- CAmazon RDS for MySQL에 데이터를 저장하고 RDS Optimized Reads를 구성합니다.❌ Amazon RDS — 관계형 DB 관리 서비스. 서버(EC2 인스턴스)를 프로비저닝해야 해서 서버리스 아님. MySQL은 정형 데이터에 적합하고 반정형(JSON) 처리에 DynamoDB보다 불편.
- DAmazon DynamoDB에 데이터를 저장하고, DAX(DynamoDB Accelerator) 캐시를 앞단에 구성합니다.✅ Amazon DynamoDB — 완전 서버리스 NoSQL, 반정형(JSON) 데이터 저장 가능. DAX(DynamoDB Accelerator) — DynamoDB 앞단의 인메모리 캐시. 자주 읽는 데이터를 캐시에 올려 마이크로초 단위 응답. 쓰기는 적고 읽기가 많은 패턴에 최적.
| 서비스 | 서버리스? | 데이터 형태 | 응답 속도 | 읽기 최적화 |
|---|---|---|---|---|
| DynamoDB + DAX | ✓ | 반정형(JSON) | 마이크로초 | ✓ DAX 캐시 |
| Aurora Serverless | ✓ | 정형(SQL) | 밀리초 | 읽기 전용 복제본 |
| RDS MySQL | ✗ | 정형(SQL) | 밀리초 | 최적화 읽기 |
| S3 | ✓ | 파일 기반 | 초 단위 | 해당 없음 |
"서버리스 + 반정형 + 밀리초 + 읽기 多" → DynamoDB + DAX
DAX = DynamoDB 앞단 인메모리 캐시 (마이크로초 응답)
읽기 多 · 쓰기 少 패턴에 특히 효과적Redshift UNLOAD는 분석 연구실(Redshift)의 결과물을 초대형 창고(S3)로 내보내는 명령어입니다. 반대로 COPY는 창고(S3)에서 연구실(Redshift)로 가져오는 것입니다. 이 방향 구분이 DEA-C01에서 자주 출제되는 함정입니다.
기업의 Amazon Redshift 데이터 웨어하우스에 협력사 관련 데이터가 포함되어 있습니다. 협력사 측에서 매주 한 번 해당 데이터를 자사의 Amazon S3 버킷으로 받고 싶다고 요청했습니다. 이 요건을 충족하는 방법은 무엇일까요?
- ARedshift 데이터 공유(Data Sharing) 기능을 설정하고, 협력사 S3 버킷을 공유 대상으로 지정합니다.❌ Redshift 데이터 공유(Data Sharing) — 다른 AWS 계정의 Redshift 클러스터끼리 데이터를 실시간 공유하는 기능. S3 버킷을 대상으로 설정하는 기능이 없음. 용도 자체가 다름.
- BRedshift에 연결하는 Lambda 함수를 만들고, COPY 명령으로 데이터를 협력사 S3 버킷에 주기적으로 복사합니다.❌ COPY 명령 — 창고(S3) → 연구실(Redshift) 방향(데이터 가져오기). 문제는 연구실(Redshift) → 창고(S3) 방향(내보내기)을 원함. 방향이 반대.
- CRedshift Spectrum의 대상 위치를 협력사 S3 버킷으로 설정하고 양방향 쿼리를 활성화합니다.❌ Redshift Spectrum — 창고(S3)의 데이터를 연구실(Redshift)에서 외부 테이블로 읽어오는 기능. S3에 쓰는 기능이 아님. "양방향 쿼리 활성화"라는 옵션도 존재하지 않음.
- DRedshift에 연결하는 Glue 작업을 만들고, UNLOAD 명령으로 필요한 데이터를 협력사 S3 버킷에 주간 스케줄로 내보냅니다.✅ UNLOAD 명령 — 연구실(Redshift) 결과물을 창고(S3)에 보관하는 것. Glue 작업에서 UNLOAD를 실행하고 Glue Trigger로 주간 스케줄링 → 요건 완벽 충족.
| 명령 | 방향 | 비유 |
|---|---|---|
| UNLOAD | Redshift → S3 | 📦 연구실(Redshift) 결과물을 창고(S3)에 보관 |
| COPY | S3 → Redshift | 🏭 창고(S3)에서 연구실(Redshift)로 재료 가져오기 |
| Spectrum | S3 → Redshift (읽기전용) | 🔭 창고 짐을 연구실로 안 옮기고 제자리에서 분석 |
| Data Sharing | Redshift → Redshift | 🤝 연구실 간 데이터 직접 공유 |
Redshift → S3 → UNLOAD (연구실 결과물 → 창고 보관)
S3 → Redshift → COPY (창고 재료 → 연구실로 가져오기)
COPY와 UNLOAD 방향 헷갈리면 오답!STL_ALERT_EVENT_LOG는 Redshift 쿼리 최적화 엔진이 성능 이상 패턴을 감지할 때 자동으로 기록하는 시스템 테이블입니다. DEA-C01 Redshift 운영 도메인에서 자주 출제됩니다.
운영 리포팅 팀이 Amazon Redshift를 사용하고 있으며, 장기 실행 쿼리로 인한 성능 저하를 사전에 방지하고자 합니다. Redshift의 쿼리 최적화 엔진이 성능 문제로 이어질 수 있는 조건을 감지했을 때 자동으로 이를 기록하는 시스템 테이블은 무엇인가요?
- ASTL_UTILITYTEXT❌ STL_UTILITYTEXT — COPY·UNLOAD·CREATE 등 유틸리티 SQL 명령의 실행 텍스트를 기록. 쿼리 최적화 이상 현상과 무관.
- BSTL_PLAN_INFO❌ STL_PLAN_INFO — 쿼리 실행 계획(Execution Plan)의 세부 정보를 기록. 계획 자체를 보는 것이지, 성능 이상 현상을 자동 감지해 기록하는 것이 아님.
- CSTL_ALERT_EVENT_LOG✅ STL_ALERT_EVENT_LOG — 쿼리 최적화 엔진이 성능 경고를 감지할 때 자동 기록. 경비원이 이상한 상황을 발견하면 자동으로 경보 일지를 쓰는 것. 해시 루프·중첩 루프 조인·대용량 분산·파티션 누락 등 성능 이슈 패턴을 기록.
- DSTL_QUERY_METRICS❌ STL_QUERY_METRICS — CPU·메모리·디스크 I/O 같은 쿼리 실행 중 리소스 소비 지표를 기록. 성능 지표를 측정하는 것이지 최적화 이상 현상을 자동 감지하는 것이 아님.
| 테이블 | 기록 내용 | 자동 이상 감지? |
|---|---|---|
| STL_ALERT_EVENT_LOG | 쿼리 최적화 경고 이벤트 | ✓ 자동 감지 |
| STL_QUERY_METRICS | CPU·메모리·I/O 리소스 지표 | ✗ 수동 분석 |
| STL_PLAN_INFO | 쿼리 실행 계획 세부 정보 | ✗ 계획 정보만 |
| STL_UTILITYTEXT | 유틸리티 SQL 텍스트 | ✗ 무관 |
"쿼리 최적화 이상 현상 자동 기록" → STL_ALERT_EVENT_LOG
ALERT = 경보 → 최적화가 문제 감지 시 자동 기록
METRICS = 지표 → 수동으로 분석해야 함AWS Glue 데이터 품질(Data Quality)은 ETL 파이프라인 내에서 사용자 정의 규칙으로 데이터를 검증하고, 실패한 레코드를 별도 경로로 자동 라우팅하는 기능입니다. 추가 도구 없이 파이프라인에 통합되어 비용 효율적입니다.
물류 회사가 AWS Glue ETL 파이프라인으로 주문 데이터를 처리하고 Athena로 분석합니다. 이제 배송일과 도착일 컬럼이 추가되었으며, "배송일 > 주문일", "도착일 > 배송일" 조건을 만족하지 않는 주문은 별도의 S3 버킷에 격리해야 합니다. 가장 비용 효율적인 방법은 무엇일까요?
- AAmazon Athena로 세 날짜 컬럼을 쿼리하여 비교하고, 조건을 만족하지 않는 레코드를 두 번째 S3 버킷으로 내보냅니다.❌ Athena는 분석용 쿼리 도구. ETL 파이프라인에 통합되어 있지 않아 별도 쿼리를 매번 실행해야 함. 기존 Glue ETL과 분리된 솔루션으로 운영 부담이 있음.
- BGlue 크롤러로 Glue 데이터 카탈로그를 업데이트하고, 세 날짜 컬럼에 대한 필터를 생성합니다.❌ Glue 크롤러(Crawler) — 스키마를 자동 탐지해 카탈로그에 등록하는 도구. 데이터 품질 검사나 레코드 라우팅 기능이 없음.
- CAWS Glue 데이터 품질 기능으로 날짜 순서를 검증하는 사용자 정의 규칙을 만들고, 규칙 미통과 레코드를 두 번째 S3 버킷으로 자동 라우팅합니다.✅ AWS Glue 데이터 품질(Data Quality) — Glue ETL 파이프라인 내에서 DQDL(Data Quality Definition Language)로 규칙을 정의하고 실패 레코드를 자동 분리하는 기능. 기존 Glue 파이프라인에 통합 → 추가 서비스 없이 비용 효율적으로 날짜 순서 검증 + 별도 버킷 라우팅 구현.
- DAWS Glue DataBrew에서 DATEDIFF 함수로 날짜 차이 컬럼을 추가하고 유효성을 검사한 뒤, 실패 레코드를 두 번째 S3 버킷에 저장합니다.❌ AWS Glue DataBrew — 노코드 GUI 데이터 정제 도구. 기존 Glue ETL 파이프라인과 별도로 동작해 추가 DataBrew 작업 비용이 발생. ETL 파이프라인 내 통합인 C보다 비용 효율 낮음.
| 도구 | 특징 | ETL 통합? | 비용 효율 |
|---|---|---|---|
| Glue 데이터 품질 | DQDL 규칙, 실패 레코드 라우팅 | ✓ 내장 | ✓ 최적 |
| Glue DataBrew | 노코드 GUI 정제 도구 | ✗ 별도 | 추가 비용 |
| Athena 쿼리 | 분석 쿼리 도구 | ✗ 별도 | 수동 운영 |
"ETL 파이프라인 내 데이터 품질 검사 + 실패 레코드 라우팅"
→ Glue 데이터 품질(Data Quality)
DataBrew = 노코드 GUI 정제 (별도 서비스, 추가 비용)
Glue DQ = ETL 파이프라인 내장 (비용 효율적)
