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 테이블에서 특정 데이터를 읽어야 합니다. 해당 회사는 필요한 레코드의 파티션 키 값을 알고 있습니다. 기존 AWS Glue PySpark 작업의 처리 로직은 데이터가 DynamicFrame 형식이어야 합니다. 회사는 작업이 지정된 데이터만 읽도록 보장하는 솔루션이 필요합니다. 어떤 솔루션이 최소한의 읽기 용량 단위(RCU)로 이 요구 사항을 충족할까요?
-
AAWS Glue DynamoDB ETL 커넥터를 사용하여 DynamoDB 테이블을 읽습니다. 필요한 파티션 키를 읽으려면 필터 옵션을 사용하십시오.❌ Glue DynamoDB 커넥터의 필터 옵션은 내부적으로 전체 테이블 스캔 후 필터링. 원하는 데이터만 읽는 게 아니라 전체를 읽고 버리는 방식 → RCU 낭비.
-
BAWS Glue 작업에서 DynamoDB 테이블을 스캔합니다. 데이터를 DynamicFrame에 저장합니다. 파티션 키를 기준으로 DynamicFrame을 필터링합니다.❌ 스캔(Scan) — 도서관 전체 책을 다 꺼내서 읽은 후 필요한 책만 고르는 것. 테이블 전체를 읽으므로 RCU가 가장 많이 소비됨. 최소 RCU와 반대.
-
CAWS Glue 작업에서 DynamoDB 테이블에 대한 쿼리를 수행합니다. 키 조건식에 파티션 키를 사용합니다. 데이터를 DynamicFrame에 저장합니다.✅ 쿼리(Query) — 도서관 색인에서 책 번호 확인 후 그 책만 꺼내는 것. 파티션 키를 키 조건식에 사용하면 해당 파티션의 데이터만 정확히 읽음 → RCU 최소화. 결과를 DynamicFrame으로 변환해 기존 처리 로직과 호환.
-
D키 조건식에서 정렬 키만 사용하여 AWS Glue 작업의 DynamoDB 테이블에서 쿼리를 수행합니다. 데이터를 DynamicFrame에 로드합니다.❌ DynamoDB 쿼리는 반드시 파티션 키가 있어야 실행 가능. 정렬 키(Sort Key)만으로는 쿼리 자체가 불가. 파티션 키 없이 정렬 키만 사용하면 에러 발생.
| 방식 | 비유 | 읽는 범위 | RCU 소비 |
|---|---|---|---|
| GetItem | 📖 책 번호로 한 권 바로 꺼냄 | 단일 항목 | 최소 |
| Query (파티션 키) | 📚 색인으로 해당 선반만 | 파티션 내 항목들 | ✓ 적음 |
| Scan + 필터 | 🏛️ 전체 도서관 다 꺼내고 골라냄 | 테이블 전체 | 최대 |
"최소 RCU로 특정 항목 읽기" → Query + 파티션 키
Scan = 전체 읽기 → RCU 최대 (오답 패턴)
정렬 키만 = Query 불가 → 파티션 키 필수!
Amazon DynamoDB + DAX(DynamoDB Accelerator)는 서버리스 NoSQL에 인메모리 캐시를 추가해 마이크로초 단위 응답을 제공합니다. 반정형 데이터·서버리스·밀리초 응답 조합에서 DEA-C01의 단골 정답 패턴입니다.
한 회사가 애플리케이션에 필요한 반정형 트랜잭션 데이터를 데이터베이스에 저장해야 합니다. 이 데이터베이스는 서버리스 방식이어야 합니다. 애플리케이션은 데이터를 자주 쓰지는 않지만 자주 읽습니다. 또한, 애플리케이션은 데이터를 밀리초 단위로 빠르게 검색해야 합니다. 어떤 솔루션이 운영 부담을 최소화하면서 이러한 요구 사항을 충족할까요?
-
A데이터를 Amazon S3 Apache Iceberg 테이블에 저장합니다. S3 전송 가속을 활성화합니다.❌ S3 Iceberg — 데이터 레이크 테이블 포맷. 밀리초 단위 개별 레코드 조회 불가. S3 전송 가속(Transfer Acceleration)은 업로드 속도 향상 기능으로 쿼리 응답속도와 무관.
-
B데이터를 Amazon S3 Standard 버킷에 저장합니다. S3 전송 가속을 활성화합니다.❌ S3는 객체 스토리지로 DB가 아님. 개별 레코드 검색에 밀리초 응답 불가. S3 전송 가속도 이 요건과 무관.
-
C데이터를 Amazon RDS for MySQL 클러스터에 저장합니다. 클러스터에 대해 RDS 최적화 읽기를 구성합니다.❌ Amazon RDS — 관계형 DB 관리 서비스. 서버(EC2 인스턴스)를 프로비저닝해야 해서 서버리스 아님. MySQL은 정형 데이터에 적합하고 반정형(JSON 등) 처리에 DynamoDB보다 불편.
-
D데이터를 Amazon DynamoDB 테이블에 저장합니다. 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 Redshift에 저장하는 데이터세트 중 하나에 공급업체의 데이터가 포함되어 있습니다. 최근 공급업체는 회사에 매주 한 번씩 공급업체의 데이터를 공급업체의 Amazon S3 버킷으로 전송해 달라고 요청했습니다. 어떤 솔루션이 이 요구 사항을 충족시킬까요?
-
AAmazon Redshift 데이터 공유 기능을 사용하세요. 공급업체의 S3 버킷을 대상으로 설정하고, 필요한 데이터를 선택하는 사용자 지정 SQL 쿼리로 소스를 구성하세요.❌ Redshift 데이터 공유(Data Sharing) — 다른 AWS 계정의 Redshift 클러스터끼리 데이터를 실시간 공유하는 기능. S3 버킷을 대상으로 설정하는 기능이 없음. 용도 자체가 다름.
-
BRedshift 데이터 웨어하우스에 연결하는 AWS Lambda 함수를 생성합니다. Redshift COPY 명령을 사용하여 필요한 데이터를 공급업체의 S3 버킷에 일정에 따라 복사하도록 Lambda 함수를 구성합니다.❌ COPY 명령 — S3 → Redshift 방향(데이터 가져오기). 문제는 Redshift → S3 방향(내보내기)을 원함. 방향이 반대.
-
C공급업체의 S3 버킷을 대상으로 사용하도록 Amazon Redshift Spectrum을 구성하세요. 양방향 데이터 쿼리를 활성화하세요.❌ Redshift Spectrum — S3의 데이터를 Redshift에서 외부 테이블로 읽어오는 기능. S3에 쓰는 기능이 아님. "양방향 데이터 쿼리"라는 옵션도 존재하지 않음.
-
DRedshift 데이터 웨어하우스에 연결하는 AWS Glue 작업을 생성합니다. Redshift UNLOAD 명령을 사용하여 필요한 데이터를 공급업체의 S3 버킷에 일정에 따라 로드하도록 AWS Glue 작업을 구성합니다.✅ UNLOAD 명령 — Redshift → S3 방향으로 데이터를 내보내는 명령. 창고에서 짐을 트럭에 싣는 것. Glue 작업에서 UNLOAD를 실행하고 EventBridge나 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 데이터 웨어하우스를 사용하고 있습니다. 팀에서는 장기 실행 쿼리로 인해 발생할 수 있는 성능 문제를 방지하려고 합니다. 데이터 엔지니어는 쿼리 최적화 프로그램이 성능 문제를 나타낼 수 있는 조건을 식별할 때 이상 현상을 기록하기 위해 Amazon Redshift에서 시스템 테이블을 선택해야 합니다. 이 요구 사항을 충족하려면 데이터 엔지니어가 어떤 테이블 보기를 사용해야 합니까?
-
ASTL 사용 제어❌ STL_UTILITYTEXT — COPY·UNLOAD·CREATE 등 유틸리티 SQL 명령의 실행 텍스트를 기록. 쿼리 최적화 이상 현상과 무관.
-
BSTL 계획 정보❌ STL_PLAN_INFO — 쿼리 실행 계획(Execution Plan)의 세부 정보를 기록. 계획 자체를 보는 것이지, 성능 이상 현상을 자동 감지해 기록하는 것이 아님.
-
CSTL 경고 이벤트 로그✅ STL_ALERT_EVENT_LOG — 쿼리 최적화 프로그램이 성능 경고를 감지할 때 자동 기록. 경비원이 이상한 상황을 발견하면 자동으로 경보 일지를 쓰는 것. 기록 내용: 해시 루프·중첩 루프 조인·대용량 분산·파티션 누락 등 성능 이슈 패턴.
-
DSTL 쿼리 측정항목❌ 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 파이프라인을 사용하여 데이터를 처리합니다. 또한 Amazon S3 버킷에 저장된 데이터를 분석하기 위해 Amazon Athena를 사용합니다. 배송 일정을 더 잘 파악하기 위해 회사는 주문 데이터 외에도 배송일과 도착일을 수집 및 저장하기로 결정했습니다. 또한 배송일이 주문일보다 늦고 도착일이 배송일보다 늦는지 확인하는 데이터 품질 검사를 추가했습니다. 품질 검사를 통과하지 못한 주문은 별도의 아마존 S3 버킷에 저장해야 합니다. 어떤 솔루션이 이러한 요구 사항을 가장 비용 효율적인 방식으로 충족할까요?
-
AAmazon Athena를 사용하여 세 개의 날짜 열을 쿼리하고 값을 비교합니다. 실패한 레코드는 두 번째 S3 버킷으로 내보냅니다.❌ Athena는 분석용 쿼리 도구. ETL 파이프라인에 통합되어 있지 않아 별도 쿼리를 매번 실행해야 함. 실패 레코드 내보내기도 수동 과정이라 운영 부담이 있고 기존 Glue ETL과 분리된 솔루션.
-
BAWS Glue 크롤러를 사용하여 AWS 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(Glue 데이터 품질)보다 비용 효율 낮음.
| 도구 | 특징 | ETL 통합? | 비용 효율 |
|---|---|---|---|
| Glue 데이터 품질 | DQDL 규칙, 실패 레코드 라우팅 | ✓ 내장 | ✓ 최적 |
| Glue DataBrew | 노코드 GUI 정제 도구 | ✗ 별도 | 추가 비용 |
| Athena 쿼리 | 분석 쿼리 도구 | ✗ 별도 | 수동 운영 |
| Glue 크롤러 | 스키마 자동 탐지 | 카탈로그 전용 | ✗ 용도 다름 |
"ETL 파이프라인 내 데이터 품질 검사 + 실패 레코드 라우팅"
→ Glue 데이터 품질(Data Quality)
DataBrew = 노코드 GUI 정제 (별도 서비스, 추가 비용)
Glue DQ = ETL 파이프라인 내장 (비용 효율적)
