기준: DEA-C01 시험 가이드오류 제보

DEA-C01· AssociateWeek 7 · Day 4읽기 약 15분

핵심 정리

RDS/Aurora 는 행 기반 OLTP 스토어다. 정규화된 스키마, 트랜잭션, 소량 행의 읽기·쓰기에 맞고 대량 컬럼 집계에는 맞지 않는다.
Aurora 는 컴퓨팅과 스토리지를 분리하고 데이터를 3개 AZ 의 6개 스토리지 노드에 복제한다. 리더(Aurora 복제본)는 최대 15개다.
운영 DB 의 분석 부하는 단계적으로 떼어 낸다: Read Replica(같은 엔진, 1차 완화) → 웨어하우스로 복제(제로 ETL·DMS) → 필요하면 레이크로 내보내기.
제로 ETL 은 AWS 가 관리하는 복제로 원천을 Redshift 에 거의 실시간으로 옮긴다. 변환은 하지 않고, 대상 데이터베이스는 읽기 전용이다. 이종 DB 마이그레이션과 폭넓은 소스·타깃 조합은 DMS 다.
스토어는 접근 패턴으로 고른다: 트랜잭션·조인 = RDS/Aurora, 키 조회 = DynamoDB, 대량 집계 = Redshift, S3 애드혹 = Athena, 검색 = OpenSearch.

Day 4 - RDS/Aurora & 스토어 선택: OLTP, 제로 ETL, 워크로드→스토어 결정

RDS 와 Aurora 개요

Amazon RDS: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2 를 관리형으로 호스팅한다. 엔진은 그대로이고 패치·백업·복구·장애 조치를 서비스가 맡는다. 스토리지는 인스턴스에 붙은 EBS 볼륨이다.
Amazon Aurora: MySQL·PostgreSQL 호환의 클라우드 네이티브 엔진이다. 인스턴스(컴퓨팅)와 클러스터 볼륨(스토리지)이 분리되어 있다.

Aurora 클러스터
  ├─ 라이터 인스턴스 1개 ─┐
  ├─ 리더 인스턴스(최대 15)┼──► 클러스터 볼륨: 3개 AZ · 6개 스토리지 노드에 복제, 자동 확장
  └─ ...                 ─┘     (인스턴스를 늘려도 데이터를 새로 복사하지 않는다)

축	RDS	Aurora
스토리지	인스턴스별 EBS, 용량을 지정(자동 확장 옵션)	공유 클러스터 볼륨, 쓴 만큼 자동 증감
복제본	엔진의 복제 기능으로 비동기 복제	같은 볼륨을 공유해 읽음
Read Replica 수	원본당 15개(쿼터)	15개
장애 조치	Multi-AZ 대기 인스턴스로 전환	리더 중 하나를 라이터로 승격
최대 스토리지	엔진·스토리지 유형에 따름	클러스터 볼륨 128TiB, 최신 엔진 버전은 256TiB
엔진	6종	MySQL·PostgreSQL 호환만

Aurora 클러스터 볼륨의 상한은 오래 128TiB 로 알려져 있었고, 현행 문서는 최신 엔진 버전(Aurora PostgreSQL 15.13·16.9·17.5 이상, Aurora MySQL 3.10 이상)에서 256TiB 로 적는다. 시험 자료에는 옛 값으로 나올 수 있다.
Aurora 스토리지는 쓴 만큼 과금되고, 데이터를 지우면 할당량도 줄어든다. 스토리지 구성은 Aurora Standard(I/O 요청 건수를 따로 과금)와 Aurora I/O-Optimized(I/O 요금 없음) 중에 고른다. I/O 지출이 전체 Aurora 비용의 25% 이상이면 I/O-Optimized 가 유리하다.
리더가 있으면 라이터 장애 시 리더가 승격되어 보통 60초 안에 복구된다. 리더가 하나도 없으면 인스턴스를 새로 만들어야 해서 훨씬 오래 걸린다.

💡 관련 이론: RDS/Aurora 는 행 기반 저장이다. 한 행의 모든 컬럼이 디스크에 붙어 있어 "주문 한 건을 읽고 고친다"에는 최적이지만, "1억 행에서 금액 컬럼만 합산"하려면 필요 없는 컬럼까지 전부 읽어야 한다. 컬럼형인 Redshift·Parquet 은 정반대다. 스토어 선택의 첫 질문이 "행을 다루는가, 컬럼을 집계하는가"인 이유다.

OLTP vs OLAP

구분	OLTP (RDS/Aurora/DynamoDB)	OLAP (Redshift/Athena)
목적	트랜잭션 처리, 운영	분석, 집계, 리포팅
저장	행 기반	컬럼 기반
쿼리	소량 행 읽기·쓰기, 짧은 응답	대량 스캔·집계
스키마	정규화	비정규화·스타 스키마
동시성	짧은 요청이 아주 많이	무거운 쿼리가 비교적 적게
데이터 범위	현재 상태	이력 전체
인덱스	B-트리 인덱스로 행을 찾음	정렬 키·파티션·통계로 블록을 건너뜀

분석을 위해 OLTP 데이터를 OLAP 스토어로 옮기는 것이 ETL 이다. 문제는 이 파이프라인을 만들고 지키는 일이다. 스케줄, 재시도, 스키마 변경 대응, 지연이 모두 운영 부담이 된다.

분석 부하를 떼어 내는 단계

운영 DB 에 무거운 리포트 쿼리를 그대로 던지면 락과 I/O 경합으로 트랜잭션이 느려진다. 떼어 내는 방법은 부담이 작은 것부터 순서가 있다.

단계	방법	얻는 것	한계
1	Read Replica / Aurora 리더로 쿼리 분리	라이터 보호, 변경 없이 바로 적용	여전히 행 기반. 대규모 집계는 느리다. 복제 지연이 있을 수 있다
2	제로 ETL 로 Redshift 에 복제	컬럼형 엔진에서 거의 실시간 분석, 파이프라인 관리 없음	지원되는 소스·타깃 조합에 한정, 변환 없음
2'	DMS 로 Redshift·S3 에 복제	폭넓은 소스·타깃, 세밀한 매핑·변환 규칙	복제 인스턴스(또는 서버리스 용량)와 태스크를 운영
3	스냅샷·쿼리 결과를 S3 로 내보내 Athena 로	가장 저렴한 장기 이력 분석	실시간이 아님

RDS Read Replica는 비동기 복제이고 읽기 전용이다. Multi-AZ 의 대기 인스턴스는 동기 복제이지만 읽기 트래픽을 받지 못한다. "가용성"이면 Multi-AZ, "읽기 분산·리포팅 분리"면 Read Replica가다.
RDS 는 Read Replica를 자동으로 늘리거나 줄여 주지 않는다. 복제본도 일반 DB 인스턴스와 같은 요금으로 과금되므로, 리포트가 도는 시간에만 필요하면 그 비용을 따져 본다.
Redshift 나 Athena 에서 운영 DB 를 직접 조회하는 페더레이션 쿼리도 있다. 데이터를 옮기지 않는 대신 쿼리마다 운영 DB 에 부하가 가므로, 가끔 하는 조회나 최신 값 확인에 맞는다.

제로 ETL 통합

제로 ETL 통합은 원천의 데이터를 파이프라인을 만들지 않고 Redshift 로 복제한다. 초기 적재와 이후의 변경 복제, 상태 감시와 복구를 AWS 가 맡는다.

Aurora MySQL / Aurora PostgreSQL / RDS / DynamoDB ...
   │  (제로 ETL 통합 — 초기 적재 후 변경분을 계속 복제)
   ▼
Amazon Redshift (Serverless 또는 RA3 계열 프로비저닝)
   └─ 통합에서 만든 "대상 데이터베이스" — 읽기 전용
        └─ 다른 데이터베이스의 머티리얼라이즈드 뷰·교차 DB 쿼리로 가공

항목	내용
소스	Aurora MySQL, Aurora PostgreSQL, RDS for MySQL·PostgreSQL·Oracle, DynamoDB, 그 밖에 SaaS 애플리케이션과 자체 관리 DB
타깃	Redshift Serverless 또는 RA3 계열 프로비저닝 클러스터(프로비저닝은 암호화 필요), 대소문자 구분 활성화 필수
그 밖의 타깃	Aurora 는 SageMaker 레이크하우스, DynamoDB 는 OpenSearch Service 로도 통합
지연	Aurora·RDS 는 거의 실시간. DynamoDB 는 증분 export 방식이라 최소 15분
변환	없다. 원천 그대로 복제한다. 가공은 Redshift 안에서 한다
대상 데이터베이스	읽기 전용. 그 안에 테이블·뷰를 만들 수 없다
범위 지정	데이터 필터링으로 복제할 테이블을 포함·제외

알아 둘 제약은 다음과 같다.

원천 테이블에 기본 키가 있어야 한다. 없는 테이블은 복제되지 않는다.
원천 클러스터와 타깃은 같은 리전이어야 한다.
원천에서 ALTER TABLE 같은 DDL 을 실행하면 그 테이블이 재동기화되며, 그동안 Redshift 에서 조회하지 못할 수 있다.
처음 통합을 만들 때와 재동기화 때 초기 적재에 20~25분 이상이 걸릴 수 있다.
Aurora MySQL 통합은 바이너리 로그(binlog)에 의존한다. Aurora PostgreSQL 은 데이터 필터를 최소 하나(데이터베이스 단위) 지정해야 한다.

⚠️ 함정: "제로 ETL"은 T(변환)가 없다는 뜻에 가깝다. 정규화된 운영 스키마가 그대로 Redshift 에 온다. 스타 스키마로 바꾸거나 집계 테이블을 만들려면 Redshift 안에서 머티리얼라이즈드 뷰나 SQL 로 가공해야 한다. 지문이 "복제 도중 컬럼을 마스킹·변환"을 요구하면 제로 ETL 이 아니라 DMS 의 변환 규칙이나 Glue 다.

DMS 와의 비교

AWS DMS(Database Migration Service) 는 소스 엔드포인트에서 읽어 타깃 엔드포인트에 쓰는 태스크를 복제 인스턴스(또는 서버리스)에서 돌린다.

태스크 유형	동작
전체 적재(full load)	현재 데이터를 한 번 옮긴다
CDC	변경분만 계속 복제한다
전체 적재 + CDC	옮기는 동안의 변경을 모아 두었다가 이어서 계속 복제한다. 무중단 마이그레이션의 기본

이종 엔진(예: Oracle → Aurora PostgreSQL)이면 스키마와 코드 객체를 먼저 바꿔야 한다. DMS Schema Conversion 또는 AWS SCT 가 이 일을 하고, DMS 는 데이터를 옮긴다. 같은 엔진이면 변환이 필요 없다.
마이그레이션 동안 원천은 계속 운영된다.
타깃이 Redshift 이면 DMS 는 데이터를 S3 에 CSV 로 올린 뒤 COPY 로 적재한다. 이때 Redshift 클러스터는 복제 인스턴스와 같은 계정·같은 리전이어야 한다.
타깃을 S3 로 두면 변경 이력을 레이크에 쌓는 CDC 파이프라인이 된다.

판단 기준	제로 ETL	DMS	Glue ETL
본질	관리형 복제	마이그레이션·지속 복제 도구	범용 변환 엔진
소스·타깃	정해진 조합	매우 폭넓음(온프레미스 포함)	JDBC·S3·스트림 등
변환	없음	테이블 매핑·간단한 변환 규칙	임의의 코드
운영 부담	거의 없음	복제 인스턴스·태스크 관리	잡·스케줄 관리
지연	거의 실시간	거의 실시간(CDC)	배치(또는 스트리밍 잡)
대표 단서	"파이프라인 없이 Aurora 를 Redshift 에서 분석"	"Oracle 을 Aurora 로 이전하며 변경도 계속 복제"	"복잡한 정제·조인 후 Parquet 으로 적재"

RDS/Aurora 에서 레이크로 내보내는 방법

방법	내용	맞는 경우
스냅샷을 S3 로 내보내기	DB 스냅샷을 Parquet 으로 S3 에 내보낸다. 운영 인스턴스에 부하가 없다	정기 전체 스냅샷 분석
쿼리 결과를 S3 로 쓰기	Aurora 가 SELECT 결과를 S3 파일로 직접 쓴다	일부 테이블·조건만 추출
DMS → S3	전체 적재 + CDC 를 S3 에 지속 적재	변경 이력을 레이크에 유지
Glue JDBC 잡(북마크)	북마크 컬럼 기준으로 증분 추출	추가만 되는 테이블의 배치 적재
Lake Formation 블루프린트	위의 Glue 잡·크롤러·트리거를 자동 생성	표준 패턴을 빨리 구성

워크로드 → 스토어 결정 프레임

접근 패턴을 먼저 정하고 스토어를 맞춘다.

① 한 건을 읽고 쓰는가, 많은 행을 집계하는가?
   ├─ 한 건(트랜잭션) ──► ②로
   └─ 집계(분석) ───────► ③으로
 
② 관계와 조인, 여러 행에 걸친 트랜잭션이 필요한가?
   ├─ 필요 ─────────────► RDS / Aurora
   └─ 키로만 찾는다, 규모·동시성이 크다 ──► DynamoDB
 
③ 얼마나 자주, 얼마나 무겁게 분석하는가?
   ├─ 상시·반복, 복잡한 조인, 빠른 응답 ──► Redshift
   ├─ 가끔, S3 에 있는 데이터를 바로 ─────► Athena
   └─ 웨어하우스 + S3 이력을 함께 ────────► Redshift Spectrum
 
④ 형태가 특수한가?
   ├─ 전문 검색, 로그 탐색 ───► OpenSearch Service
   ├─ 마이크로초 캐시·세션 ───► ElastiCache / MemoryDB
   ├─ 관계 탐색(그래프) ──────► Neptune
   ├─ 시계열 지표 ────────────► Timestream
   └─ JSON 문서(MongoDB 호환) ─► DocumentDB

요구 사항	1순위	이유	고르면 안 되는 것
주문·결제 트랜잭션, 정규화 스키마	Aurora / RDS	ACID, 조인, 제약 조건	DynamoDB(조인 없음), Redshift(OLTP 아님)
사용자 ID 로 밀리초 조회, 예측 불가 트래픽	DynamoDB	키 조회, 서버리스 확장	Aurora(확장 한계), Athena(지연)
수억 행 대시보드, 다중 조인	Redshift	컬럼형 MPP, 분산·정렬 키	Aurora(행 기반)
S3 로그를 가끔 SQL 로	Athena	인프라 없음, 스캔량 과금	Redshift(상시 비용)
상품 이름 부분 일치·오타 허용 검색	OpenSearch	역색인	RDS 의 LIKE 검색
DB 앞단 캐시	ElastiCache	인메모리	-
기존 Oracle·SQL Server 를 그대로 클라우드로	RDS	같은 엔진 유지	Aurora(호환 엔진 아님)

선택 기준을 한 줄씩 정리하면 이렇다.

접근 패턴: 키 조회 / 트랜잭션·조인 / 집계 / 검색 / 관계 탐색.
데이터 형태: 정형 / 반정형 / 비정형.
지연과 동시성: 밀리초의 많은 요청 / 초~분의 무거운 쿼리.
운영 모델: 서버리스(Athena, DynamoDB 온디맨드, Redshift Serverless, Aurora Serverless) / 프로비저닝.
과금 단위: 인스턴스 시간(RDS·Aurora) / 요청·용량 단위(DynamoDB) / 노드 시간·RPU(Redshift) / 스캔량(Athena).

증상 → 원인 → 조치

증상	원인	조치
리포트가 도는 시간에 주문 처리가 느려진다	라이터에서 분석 쿼리 실행	Read Replica·리더로 분리
복제본으로 옮겼는데 집계가 여전히 느리다	행 기반 엔진의 한계	Redshift 로 복제(제로 ETL·DMS)
제로 ETL 에서 일부 테이블이 오지 않는다	기본 키 없음, 데이터 필터에서 제외	기본 키 추가, 필터 확인
제로 ETL 통합 생성이 실패한다	타깃의 대소문자 구분 비활성, 미지원 노드 타입, 리전 불일치	타깃 설정 수정
원천에서 컬럼을 바꾼 뒤 Redshift 테이블 조회 불가	DDL 로 인한 재동기화	완료 대기, 변경 시간대 조정
DMS CDC 지연이 계속 커진다	타깃 테이블에 기본 키 없음, 복제 인스턴스 부족	기본 키 추가, 인스턴스 확장
Read Replica가 오래된 값을 돌려준다	비동기 복제 지연	지연 지표 감시, 최신 값이 필요한 읽기는 라이터로

지문 단서 → 정답 판별표

지문 단서	정답
"정규화된 트랜잭션, ACID, 조인"	RDS / Aurora
"운영 DB 의 리포팅 부하를 가장 간단히 분리"	Read Replica(Aurora 리더)
"Aurora 데이터를 Redshift 에서 거의 실시간, 파이프라인 관리 없이"	제로 ETL 통합
"Oracle → Aurora PostgreSQL 마이그레이션 + 지속 복제"	DMS(스키마는 DMS Schema Conversion/SCT)
"온프레미스 DB 의 변경을 S3 에 계속 적재"	DMS(타깃 S3)
"복제하면서 복잡한 변환·조인"	Glue ETL
"스냅샷 데이터를 운영 부하 없이 Athena 로 분석"	스냅샷을 S3 로 내보내기
"가끔 Redshift 에서 운영 DB 의 최신 행을 함께 조회"	페더레이션 쿼리
"키 기반 밀리초, 대규모 동시성, 서버리스"	DynamoDB
"S3 데이터를 간헐적으로 SQL 분석"	Athena
"장애 시 자동 전환(가용성)"	Multi-AZ(Read Replica가 아님)

내일은 이번 주의 스토어들을 한 장에 놓고 워크로드별 선택과 스토어 사이의 데이터 이동 경로를 복습한다.

📖 용어

OLTP / OLAP : 소량 행의 트랜잭션 처리와, 대량 데이터의 분석·집계 처리.
클러스터 볼륨 : Aurora 의 공유 스토리지. 여러 AZ 에 복제되고 모든 인스턴스가 함께 쓴다.
Read Replica : 원본을 비동기로 따라가는 읽기 전용 사본. 읽기 부하를 나눈다.
Multi-AZ : 다른 AZ 에 대기 인스턴스를 두어 장애 시 자동 전환하는 가용성 구성.
CDC : Change Data Capture. 원천의 변경(삽입·수정·삭제)만 잡아 전달하는 방식.
제로 ETL 통합 : 파이프라인을 만들지 않고 AWS 가 원천을 분석 스토어로 계속 복제해 주는 관리형 기능.
DMS : 데이터베이스를 옮기고 변경을 계속 복제하는 서비스. 복제 인스턴스·엔드포인트·태스크로 구성된다.
스키마 변환 : 엔진이 다른 DB 로 옮길 때 테이블 정의와 코드 객체를 대상 엔진 문법으로 바꾸는 작업.
페더레이션 쿼리 : 데이터를 옮기지 않고 다른 스토어를 직접 조회하는 쿼리.
스타 스키마 : 가운데 팩트 테이블과 둘레의 차원 테이블로 이루어진 분석용 모델.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

다음 중 행 기반 OLTP에 최적화되어 정규화된 트랜잭션·ACID 워크로드에 가장 적합한 스토어는?

문제 2

Aurora의 데이터를 별도 ETL 파이프라인(DMS/Glue) 구축 없이 Redshift로 거의 실시간 복제해 분석하려면 무엇을 사용하는가?

문제 3

운영 Aurora 인스턴스에 무거운 BI 리포팅 쿼리가 트랜잭션 성능을 저하시킨다. 가장 먼저 고려할 1차 완화책은?

문제 4

Oracle DB를 Aurora PostgreSQL로 마이그레이션하면서 마이그레이션 중 지속적 변경 복제(CDC)가 필요하다. 가장 적절한 서비스는?

문제 5

"사용자 ID 기반 한 자릿수 ms 조회, 예측 불가한 대규모 동시성, 서버리스 운영"이 핵심 요구일 때 가장 적합한 스토어는?

참고 공식 자료