Day 5 - Week 7 종합: 데이터 계층 의사결정의 모든 것

이번 주는 AWS의 데이터 계층 3대 축 — RDS, ElastiCache, Aurora — 를 통과했다. 각각이 다른 문제를 풀고, 다른 trade-off를 가진다는 걸 봤다. RDS는 관계형 DB의 운영 부담을 AWS에 위임하는 1세대 관리형 DB, Aurora는 그 한 단계 위에서 스토리지·복제 레이어를 클라우드 네이티브로 재설계한 2세대, ElastiCache는 그 둘 위에서 인메모리 캐시 계층을 제공하는 보완재다.

DVA-C02 시험의 데이터 영역 문제는 정해진 틀이 있다. "이런 요구사항(가용성, latency, 비용, 확장성, 일관성)이 주어졌을 때 어느 서비스를 어떻게 구성하나"를 시나리오로 묻는다. 오늘은 이번 주 내용을 시나리오 중심으로 다시 묶고, 12문항의 실전 시나리오로 종합 점검한다.

의사결정 프레임워크: 데이터 계층 선택 5단계

production에서 데이터 계층을 결정할 때 거치는 사고 흐름은 다음 5단계다. 시험 시나리오 분석에도 그대로 적용된다.

1단계: 데이터 모델
  └─ 관계형(JOIN, 트랜잭션 필요)        → RDS / Aurora
  └─ 키-값 (단일 entity 조회 위주)      → DynamoDB / ElastiCache
  └─ 문서·시계열·그래프 등             → DocumentDB / Timestream / Neptune

2단계: 일관성 요구
  └─ Strong consistency (ACID 필요)    → RDS / Aurora / MemoryDB
  └─ Eventual consistency 허용         → DynamoDB / ElastiCache Replica

3단계: latency 요구
  └─ μs (마이크로초)                   → ElastiCache / MemoryDB / DAX
  └─ ms (밀리초 한 자리)                → Aurora primary / DynamoDB
  └─ 수 ms ~ 수십 ms                   → RDS / Aurora Replica / S3

4단계: 가용성·DR 요구
  └─ Single AZ OK                      → 기본 RDS Single-AZ
  └─ AZ 장애 자동 복구 (RTO 분 단위)    → RDS Multi-AZ
  └─ Cross-region DR (RTO 분 단위)      → Aurora Global / DynamoDB Global Tables

5단계: 비용 모델
  └─ 안정 트래픽                       → Reserved Instance (~50-70% 절감)
  └─ 변동 트래픽                       → Aurora Serverless v2 / DynamoDB On-Demand
  └─ 개발/스테이징                     → Single-AZ + Reserved (or Serverless auto-pause)

RDS·ElastiCache·Aurora 비교: 같은 질문 다른 답

"고가용성"에 대한 세 서비스의 답

"읽기 확장"에 대한 세 서비스의 답

"비밀번호/키 관리"에 대한 답

시험 함정 15가지 정리

헷갈리기 쉬운 함정을 모았다.

1. Multi-AZ Standby는 읽기 불가 — 단 Multi-AZ Cluster Deployment(2022~)는 readable standby 2개 제공
2. 암호화 전환 = 스냅샷 → KMS copy → restore — direct modify 불가
3. 자동 백업 0일 설정 시 PITR/Read Replica 생성 모두 차단
4. IAM DB Auth 토큰 = 15분 SigV4, SSL 필수
5. DB 삭제 시 자동 백업은 함께 삭제 (Final Snapshot 옵션 필수), 수동 스냅샷은 유지
6. Read Replica 쓰기 직후 조회 = stale data (Read-Your-Writes 위반 가능)
7. Aurora Replica 자동 페일오버 < 30초, RDS Multi-AZ는 60-120초
8. Aurora 스토리지 = 3 AZ × 2 사본 = 6, W=4 R=3
9. Aurora Serverless v1은 분 단위 + 콜드 스타트, v2는 세밀한 단위 + 스케일링 중 작업 중단 없음(auto-pause 재개 시 약 15초)
10. Redis Cluster Mode Disabled는 단일 샤드 — 한 노드 메모리가 한도
11. Memcached는 영속성·백업·Multi-AZ·복제 모두 없음
12. Redis Sorted Set = 리더보드 정답 (ZADD/ZREVRANK O(log N))
13. DAX는 DynamoDB 전용, ElastiCache는 범용 (서로 못 바꿈)
14. RDS Proxy = Lambda + RDS connection storm 해결책 1순위
15. Aurora Backtrack = MySQL only, 72시간 in-place (PITR과 다른 메커니즘)

⚠️ 함정 예시 1 — 자동 백업 보존 기간 0일: 자동 백업을 "끄고 싶다"는 의도로 보존 기간을 0일로 설정하면 그 순간 PITR이 불가능해지고 Read Replica 생성도 막힌다. 시험 문제: "Read Replica 생성 시도가 실패하는 원인은?" → 자동 백업 비활성화. 해결책: 보존 기간 1일 이상으로 설정.

⚠️ 함정 예시 2 — Aurora vs RDS Read Replica 최대 개수: Aurora 클러스터는 Aurora Replica 최대 15개이고, RDS도 MySQL/PostgreSQL/MariaDB/SQL Server는 소스당 최대 15개다. Oracle은 엔진별 문서를 따른다. 시험에서 "RDS Read Replica 최대 개수"라는 단순 문제가 나오면 엔진을 보고 답해야 한다.

실전 패턴: 시나리오 매핑

알아두면 좋은 cross-service 패턴

패턴 1: "고성능 OLTP + 분석 격리 + DR"

Production 서울:
  Aurora MySQL Multi-AZ
    ├── Writer endpoint → OLTP 트래픽
    ├── Reader endpoint → 일반 read
    └── Custom endpoint (큰 인스턴스 2개) → 분석 워크로드 격리

DR 도쿄:
  Aurora Global Database secondary
    └── Read-only, region 내 latency 최소화
    └── Primary region 다운 시 promote (RTO 수 분)

캐시 계층:
  ElastiCache Redis Cluster Mode Enabled (서울)
    ├── 세션 데이터
    ├── 인기 상품 정보 (Lazy Loading + TTL 5분)
    └── 리더보드 (Sorted Set)

비밀 관리:
  Secrets Manager + RDS Proxy (Lambda function 측)
  KMS CMK로 스토리지/스냅샷/Secrets 모두 암호화

이 한 구성에 이번 주 개념 대부분이 들어간다.

패턴 2: "스타트업 MVP에서 production까지 진화"

Phase 1 (MVP):
  RDS MySQL Single-AZ db.t3.micro + 로컬 in-memory 캐시 (라이브러리)

Phase 2 (트래픽 증가):
  RDS MySQL Multi-AZ db.t3.medium + ElastiCache Redis (세션, 인기 데이터)

Phase 3 (확장):
  Aurora MySQL Multi-AZ + Aurora Replica 3개 + ElastiCache Redis Cluster
  RDS Proxy 도입 (Lambda 함수가 늘어남에 따라)

Phase 4 (글로벌):
  Aurora Global Database (서울 + 도쿄)
  CloudFront + S3 static asset CDN
  ElastiCache Replica를 각 region에

패턴 3: "Compliance 강화 환경"

- RDS at-rest 암호화 (KMS CMK, 회사 소유 키)
- TLS 강제 (rds.force_ssl=1)
- IAM DB Auth + Secrets Manager (인간 사용자는 IAM, 애플리케이션은 Secrets Manager + RDS Proxy)
- Audit log → CloudWatch Logs (KMS 암호화) → 1년 보존 → S3 archive
- AWS Backup Vault Lock으로 백업 WORM 보호
- VPC private subnet only, NAT Gateway 없음 (egress 차단)
- CloudTrail 데이터 이벤트 활성화

HIPAA, PCI-DSS, ISO 27001 같은 인증을 받는 환경에서 쓰는 구성 예시다.

비용 관점: Reserved Instance와 Serverless의 손익분기

"비용 최적화" 시나리오에서는 트래픽 패턴이 안정적이면 Reserved Instance, 변동적이면 Serverless가 답이다. 변동의 기준은 "사용량이 시간대별로 5배 이상 차이" 정도로 보며, 그 미만이면 RI가 유리하다.

CLI/SDK 빠른 참조

# RDS 생성 (Multi-AZ + 암호화 + IAM 인증)
aws rds create-db-instance \
  --db-instance-identifier prod-mysql \
  --db-instance-class db.r6g.large \
  --engine mysql --master-username admin \
  --master-user-password "$(aws secretsmanager get-random-password --output text --query RandomPassword)" \
  --allocated-storage 100 --storage-type gp3 \
  --multi-az --storage-encrypted \
  --enable-iam-database-authentication \
  --backup-retention-period 14 \
  --enable-cloudwatch-logs-exports '["audit","error","general","slowquery"]'
 
# Aurora Cluster 생성 (Global Database 준비)
aws rds create-global-cluster --global-cluster-identifier my-global \
  --engine aurora-mysql
aws rds create-db-cluster --db-cluster-identifier my-primary \
  --engine aurora-mysql --global-cluster-identifier my-global \
  --master-username admin --master-user-password ... 
aws rds create-db-instance --db-instance-identifier my-primary-instance \
  --db-cluster-identifier my-primary --db-instance-class db.r6g.large \
  --engine aurora-mysql
 
# Secondary region에 추가
aws rds create-db-cluster --region us-east-1 \
  --db-cluster-identifier my-secondary \
  --engine aurora-mysql --global-cluster-identifier my-global
 
# ElastiCache Redis Cluster Mode Enabled
aws elasticache create-replication-group \
  --replication-group-id prod-cache \
  --replication-group-description "production cache" \
  --engine redis --cache-node-type cache.r7g.large \
  --num-node-groups 3 --replicas-per-node-group 2 \
  --automatic-failover-enabled --multi-az-enabled \
  --at-rest-encryption-enabled --transit-encryption-enabled \
  --auth-token "$(aws secretsmanager get-random-password ...)"
 
# RDS Proxy 생성
aws rds create-db-proxy \
  --db-proxy-name my-proxy \
  --engine-family MYSQL \
  --auth '[{"AuthScheme":"SECRETS","SecretArn":"arn:aws:secretsmanager:..."}]' \
  --role-arn arn:aws:iam::123456789012:role/rdsproxyrole \
  --vpc-subnet-ids subnet-aaa subnet-bbb \
  --require-tls

정리

이번 주 내용은 두 가지로 압축된다.

• "관계형 vs 키-값", "강일관성 vs 최종일관성", "동기 복제 vs 비동기 복제" 같은 분산 시스템의 근본 trade-off가 AWS 데이터 서비스 선택에 그대로 투영된다.
• 같은 문제(가용성, 확장성, latency)에 RDS/Aurora/ElastiCache가 각자 다른 답을 가지며, 시험은 그 답들 중 "주어진 제약에서 가장 적절한 하나"를 묻는다.

다음 주는 NoSQL — DynamoDB — 로 넘어간다. DynamoDB는 RDS와 거의 정반대 철학(샤딩 자동, 강일관성 옵션, 무제한 확장, 관계형 모델 포기)을 가진 서비스다. 이번 주 RDS/Aurora를 이해하면 DynamoDB의 "왜 그렇게 다르게 설계됐나"가 훨씬 잘 보인다.

📝 Week 7 종합 실전 시나리오 12문항