RDS의 시험 핵심은 Multi-AZ와 Read Replica의 차이다. 이 두 기능은 완전히 다른 목적으로 만들어졌는데도 자주 혼동된다. Multi-AZ는 동기 복제로 Standby를 유지하며, 장애 시 자동으로 Standby를 Primary로 승격하는 HA(고가용성) 도구다. Read Replica는 비동기 복제로 읽기 전용 복사본을 만들어 읽기 트래픽을 분산하는 도구다.
두 기능이 다른 목적이라는 증거: Standby는 평상시 트래픽을 처리하지 않는다. Primary 장애 시 자동 페일오버(60-120초)를 위해서만 존재한다. Read Replica는 별도 엔드포인트로 읽기 트래픽을 받는다. 페일오버는 수동 Promote가 필요하고 수 분~수십 분이 걸린다.
RDS Proxy는 두 문제를 각각 다른 방식으로 해결한다. Lambda처럼 단발적이고 대량의 연결을 만드는 클라이언트에는 연결 풀링을 제공하고, Multi-AZ 페일오버 시 클라이언트의 연결 전환 시간을 단축한다.
기능
목적
복제 방식
페일오버
읽기
비용
Multi-AZ
HA (고가용성)
동기 (Synchronous)
자동 (60-120초)
Standby 읽기 불가
2배
Read Replica
읽기 확장
비동기 (Async)
수동 Promote
가능 (별도 엔드포인트)
Replica당 추가
RDS Proxy
연결 풀링
N/A
페일오버 가속
N/A
인스턴스 비용의 일부
RDS Multi-AZ 동기 복제가 1-2ms 지연에도 동작하는 이유 — RDS Multi-AZ의 동기 복제가 AZ 간 1-2ms 지연에도 불구하고 잘 동작하는 이유는 데이터베이스 트랜잭션의 commit 패턴에 있다. OLTP 시스템에서 대부분의 트랜잭션은 ms 단위로 완료된다. 1-2ms의 AZ 간 RTT가 추가되더라도 전체 트랜잭션 완료 시간은 수 ms 수준이므로 사용자 체감 지연이 크지 않다. 반면 리전 간 RTT(예: 서울~도쿄 약 35ms)는 OLTP 트랜잭션에 심각한 영향을 준다. 이것이 "리전 간 동기 복제는 불가능하다"는 설계 결정의 근거이고, Aurora Global Database가 스토리지 레이어에서 비동기 복제를 선택한 이유다.
DynamoDB에서 가장 중요한 단일 개념은 파티션 키 설계다. Hot Partition이 발생하면 Adaptive Capacity로 완화할 수 있지만 근본적으로는 파티션 키를 재설계해야 한다.
개념
핵심 사실
파티션 키
균등 분포 + High Cardinality 필수
WCU
1KB 쓰기 1회 = 1 WCU (트랜잭션은 ×2)
RCU
4KB 강한 일관성 읽기 1회 = 1 RCU, 결과적 일관성은 ×0.5
LSI
같은 PK, 다른 SK. 생성 시만 추가. 강한 일관성 가능
GSI
다른 PK. 언제든 추가. 결과적 일관성만
DAX
DynamoDB 전용 캐시. SDK 변경만으로 적용. 마이크로초
Global Tables
멀티 리전 Active-Active. LWW 충돌 해결. ~1초 복제
Streams
24시간 변경 로그. Lambda 이벤트 소스 매핑으로 후속 처리
On-Demand
트래픽 예측 불가 시. 요청당 과금
Provisioned+AS
안정적 트래픽 시. 비용 최적화
PITR
35일 이내 초 단위 복구. 새 테이블로만 복구
CAP 정리로 보는 5주차 서비스 선택 — 데이터베이스 선택은 CAP 정리(Brewer, 2000)의 실제 적용이다. RDS Multi-AZ는 같은 리전 내에서 CP(Consistency + Partition Tolerance)를 선택한다. DynamoDB 결과적 일관성은 AP(Availability + Partition Tolerance)를 선택한다. Aurora Global Database의 Primary 리전은 CP, Secondary 리전은 eventual consistency로 AP에 가깝다. MemoryDB for Redis는 내구성 보장(Multi-AZ WAL)으로 C를 강하게 보장한다. 비즈니스 요구에 따라 어떤 트레이드오프를 선택할지가 아키텍처 결정의 핵심이다. "항상 CA"를 만족하는 분산 시스템은 CAP 정리에 의해 불가능하다.
5주차에서 다룬 데이터베이스 서비스들은 각각 다른 문제를 풀기 위해 만들어졌다. RDS는 전통적 관계형 DB를 관리 부담 없이, Aurora는 관계형 DB의 한계를 스토리지 재설계로, DynamoDB는 스키마 없이 수억 개의 항목을 밀리초로, ElastiCache는 메모리 속도로 반복 읽기를. 이 서비스들이 시험에서 어떻게 출제되는지 확실히 정리하는 날이다.
시험 문제는 대부분 "이 시나리오에서 무엇을 선택하겠는가"의 형태로 나온다. 여러 선택지 중 하나가 기술적으로 가능해 보이지만 나머지보다 더 나은 이유를 찾는 것이 핵심이다. 그 "더 나은 이유"를 찾으려면 각 서비스의 설계 목적과 제약을 내부에서 이해해야 한다. 기술을 외우는 것이 아니라 왜 그렇게 설계됐는지를 이해해야 하는 이유가 여기에 있다.
"15개 Replica", "30초 페일오버", "리전 간 <1초 복제", "변동 트래픽 자동 스케일" → Aurora
"Oracle/SQL Server/MariaDB 엔진 필요", "비용 절감 최우선", "안정적 워크로드" → 일반 RDS
GSI vs LSI:
테이블 생성 후 추가 가능하고 완전히 다른 PK → GSI (결과적 일관성만)
같은 PK 유지하고 강한 일관성이 필요하고 테이블 생성 시 추가 → LSI
DAX vs ElastiCache:
DynamoDB 전용이고 SDK 변경만 필요 → DAX
다양한 소스(RDS, Aurora, API 결과)를 캐싱하거나 세션/Pub/Sub → ElastiCache Redis
MemoryDB vs ElastiCache Redis:
장애 시 데이터 손실이 절대 허용 안 됨 → MemoryDB
손실 허용 가능하고 캐시로 사용 → ElastiCache Redis
Aurora Global Database vs RDS Cross-Region Read Replica:
< 1초 복제 지연, 스토리지 레이어 복제, 수 분 수준의 managed failover → Aurora Global DB
범용 엔진(MySQL, PG, Oracle 등), 수 초 지연 허용 → RDS Cross-Region RR
DynamoDB Global Tables vs Aurora Global DB:
모든 리전에서 쓰기 필요(액티브-액티브), NoSQL → DynamoDB Global Tables
관계형 + 쓰기는 Primary 리전만, 읽기 분산 → Aurora Global DB
Capital One 보안 사고와 DB 아키텍처 교훈 — 2019년 Capital One 데이터 유출 사건(1억 600만 명 개인정보 노출)은 데이터베이스 설계보다 IAM과 EC2 메타데이터 서비스 보안 문제였다. 그러나 이 사건은 RDS 암호화, KMS 키 관리, VPC 내 프라이빗 서브넷 배치, 최소 권한 원칙이 얼마나 중요한지를 상기시켰다. RDS를 퍼블릭 서브넷에 두거나, 과도한 IAM 권한을 부여하거나, 암호화를 비활성화하는 것은 실제 사고의 원인이 됐다. SAA-C03 시험에서도 "DB는 프라이빗 서브넷에, 암호화 활성화, 최소 권한 IAM"이 항상 올바른 보안 답안이다.
DynamoDB Streams → Lambda → OpenSearch: 주문 삽입 시 검색 인덱스 자동 업데이트
Aurora: 사용자 계정, 상품 카탈로그, 관계형 데이터
OpenSearch: 상품 검색, 로그 분석, Dashboards 시각화
Redshift: 야간 배치 OLAP 분석, BI 대시보드
🔍 데이터 액세스 패턴 분석이 먼저다 — 아키텍처를 설계하기 전에 반드시 답해야 할 질문들: (1) 읽기와 쓰기의 비율은? (2) 트래픽 패턴이 예측 가능한가? (3) 응답 지연 요구사항은? (4) 데이터 모델이 관계형인가 Key-Value인가? (5) 글로벌 사용자가 있는가? (6) 데이터 손실 허용 수준(RPO)은? (7) 다운타임 허용 수준(RTO)은? 이 7가지 질문에 답하면 서비스 선택이 거의 자동으로 결정된다. SAA-C03 시험 문제도 이 7가지 차원 중 하나 이상을 강조해서 정답을 유도한다.
SAA-C03는 비용 최적화 Pillar(20%)도 다룬다. 데이터베이스 선택에서 비용 관점:
RDS vs Aurora: Aurora가 약 20% 비싸다. "같은 MySQL/PostgreSQL 워크로드에서 Aurora가 정당화되는 시나리오"는 페일오버 요구사항이 30초 이내, 다수의 Reader 필요(Aurora는 클러스터당 최대 15개), 글로벌 복제 필요, 변동 트래픽일 때다.
On-Demand vs Provisioned: DynamoDB On-Demand는 안정적 트래픽에서 Provisioned보다 최대 4배 비싸다. 트래픽 예측이 가능한 워크로드는 Provisioned + Auto Scaling이 비용 효율적이다.
ElastiCache 캐시: 캐시 히트율이 90% 이상이면 캐시로 인해 DB 인스턴스 크기를 줄일 수 있어서 전체 비용이 내려간다. TTL을 너무 짧게 설정하면 히트율이 떨어진다.
Aurora I/O-Optimized: I/O 비용이 전체의 25% 이상이면 I/O-Optimized 요금제가 유리하다. 정액 I/O 비용으로 전환된다.
ElastiCache Reserved Nodes: 1년 또는 3년 예약으로 온디맨드 대비 최대 55% 절감. 안정적 캐시 워크로드라면 Reserved가 유리하다.
⚠️ 인스턴스 업사이징이 마지막 수단인 이유 — "더 큰 인스턴스로 업그레이드"가 항상 옳지 않다. 읽기 부하는 Read Replica가, 연결 수 문제는 RDS Proxy가, 반복 읽기는 ElastiCache가, DynamoDB 읽기는 DAX가 더 비용 효율적으로 해결한다. 인스턴스 업사이징은 마지막 수단이다. 시험에서 "인스턴스 크기를 늘린다"는 선택지가 나오면, 그보다 더 정확한 솔루션(Proxy, Read Replica, Cache)이 있는지 먼저 확인한다.