RDS와 EKS 아키텍처
TL;DR
- 항목 RDS (일반) Aurora Read Replica 최대 5개 최대 15개 Replica Auto Scaling ❌ ✅ Serverless 옵션 ❌ ✅ (v2) 스토리지 자동 확장 제한적 자동 (최대 128TB) 복제 지연 수 초 수 ms 비용 저렴 20% 정도 비쌈 Failover 속도 60-120초 30초 이내 방식 자동?
- Replica Auto Scaling ❌ ✅
- 원문 전체는 아래 상세 내용에 그대로 포함했다.
1. 개념
항목 RDS (일반) Aurora Read Replica 최대 5개 최대 15개 Replica Auto Scaling ❌ ✅ Serverless 옵션 ❌ ✅ (v2) 스토리지 자동 확장 제한적 자동 (최대 128TB) 복제 지연 수 초 수 ms 비용 저렴 20% 정도 비쌈 Failover 속도 60-120초 30초 이내 방식 자동?
2. 배경
Read Replica 최대 5개 최대 15개
3. 이유
Replica Auto Scaling ❌ ✅
4. 특징
Serverless 옵션 ❌ ✅ (v2)
5. 상세 내용
RDS와 EKS 아키텍처
1. EKS와 RDS의 관계
핵심 개념
┌─────────────────────────────────────────────────────────────┐
│ │
│ 중요한 사실: │
│ │
│ ❌ "EKS에서 제공하는 RDS" │
│ ✅ "AWS에서 제공하는 별개의 서비스" │
│ │
│ EKS = Elastic Kubernetes Service (컨테이너 오케스트레이션)│
│ RDS = Relational Database Service (관리형 데이터베이스) │
│ │
│ → 둘은 완전히 독립적인 AWS 서비스 │
│ → EKS의 Pod이 RDS에 "접속"하는 클라이언트-서버 구조 │
│ → RDS는 Pod이 아님, EC2 기반의 별도 관리형 인스턴스 │
│ │
└─────────────────────────────────────────────────────────────┘
아키텍처 다이어그램
┌─────────────────────────────────────────────────────────────┐
│ │
│ VPC │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ EKS Cluster (Public/Private Subnet) │ │
│ │ ┌─────┐ ┌─────┐ ┌─────┐ ... ┌─────┐ │ │
│ │ │Pod 1│ │Pod 2│ │Pod 3│ │Pod N│ │ │
│ │ │ App │ │ App │ │ App │ │ App │ │ │
│ │ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ │ │
│ │ │ │ │ │ │ │
│ │ └───────┴───────┴─────┬─────┘ │ │
│ │ │ │ │
│ └───────────────────────────┼────────────────────────┘ │
│ │ TCP 연결 (3306/5432) │
│ ┌───────────────────────────┼────────────────────────┐ │
│ │ RDS (Private Subnet) ▼ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ RDS Instance (관리형) │ │ │
│ │ │ PostgreSQL / MySQL / etc. │ │ │
│ │ │ │ │ │
│ │ │ → Pod이 아님! │ │ │
│ │ │ → EC2 기반 관리형 인스턴스 │ │ │
│ │ │ → AWS가 OS, 패치, 백업 관리 │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ └────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
2. Pod 스케일링과 RDS
자동 스케일링이 아님
┌─────────────────────────────────────────────────────────────┐
│ │
│ 시나리오: Pod 10개 → 1000개 스케일링 │
│ │
│ Pod 1 ──┐ │
│ Pod 2 ──┤ │
│ Pod 3 ──┤ TCP Connection │
│ ... ├────────────────────────→ RDS (단일 인스턴스) │
│ Pod 999 ─┤ │ │
│ Pod 1000─┘ │ │
│ │ │
│ 질문: AWS가 자동으로 RDS 스케일링? │ │
│ 답변: ❌ 아니요! │ │
│ │ │
│ RDS는: ▼ │
│ ├── 지정한 인스턴스 타입 그대로 유지 (db.t3.medium 등) │
│ ├── Pod 개수와 무관하게 고정 │
│ ├── 수동으로 스케일업 필요 (더 큰 인스턴스로 변경) │
│ └── 또는 Aurora Auto Scaling 사용 (읽기 전용) │
│ │
│ EKS HPA: Pod 자동 스케일링 ✅ │
│ RDS 일반: 수동 스케일링만 가능 │
│ Aurora: Read Replica 자동 스케일링 가능 │
│ │
└─────────────────────────────────────────────────────────────┘
3. 동기화 문제는 없음
오해와 사실
┌─────────────────────────────────────────────────────────────┐
│ │
│ 오해: RDS도 여러 Pod처럼 분산 → 동기화 필요? │
│ │
│ 사실: │
│ ├── RDS는 Pod이 아님 │
│ ├── RDS는 단일 인스턴스 (또는 Primary-Replica 구조) │
│ ├── 모든 Pod이 "같은" RDS 엔드포인트에 접속 │
│ └── 데이터는 RDS 내부에서 단일 진실 (Single Source) │
│ │
│ Pod 1 ──write──→ ┌──────────┐ │
│ Pod 2 ──write──→ │ RDS │ ← 하나의 데이터베이스 │
│ Pod 3 ──read───→ │ (단일) │ │
│ Pod 4 ──read───→ └──────────┘ │
│ │
│ → Pod 간 데이터 동기화 문제 없음 (같은 DB에 접속) │
│ → 동시성 제어는 DB 트랜잭션/락이 처리 │
│ → ACID 보장은 RDS(PostgreSQL/MySQL)의 책임 │
│ │
└─────────────────────────────────────────────────────────────┘
Read Replica 사용 시
┌─────────────────────────────────────────────────────────────┐
│ │
│ Primary-Replica 구조: │
│ │
│ Pod ──write──→ ┌─────────┐ │
│ Pod ──write──→ │ Primary │──비동기 복제──→ ┌─────────┐ │
│ └─────────┘ │ Replica │ │
│ └─────────┘ │
│ Pod ──read───────────────────────────────────→ ↑ │
│ Pod ──read───────────────────────────────────────┘ │
│ │
│ 동기화: │
│ ├── AWS가 자동으로 Primary → Replica 복제 │
│ ├── 비동기 복제 (약간의 지연 있음, 보통 ms 단위) │
│ ├── 애플리케이션은 복제 신경 안 써도 됨 │
│ └── 단, 읽기 직후 쓴 데이터가 안 보일 수 있음 (최종 일관성)│
│ │
└─────────────────────────────────────────────────────────────┘
4. RDS 스케일링 옵션
4.1 수직 스케일링 (Scale Up)
┌─────────────────────────────────────────────────────────────┐
│ │
│ 인스턴스 타입 변경: │
│ │
│ db.t3.medium (2 vCPU, 4GB) │
│ │ │
│ ▼ 수동 변경 (AWS Console / CLI) │
│ db.r5.xlarge (4 vCPU, 32GB) │
│ │ │
│ ▼ │
│ db.r5.4xlarge (16 vCPU, 128GB) │
│ │
│ 특징: │
│ ├── 수동으로 변경해야 함 (자동 아님) │
│ ├── Multi-AZ면 다운타임 최소화 (Failover) │
│ ├── Single-AZ면 다운타임 발생 (수 분) │
│ └── 비용 증가 │
│ │
└─────────────────────────────────────────────────────────────┘
4.2 읽기 복제본 (Read Replica)
┌─────────────────────────────────────────────────────────────┐
│ │
│ 수평 스케일링 (읽기 전용): │
│ │
│ ┌─────────────┐ │
│ │ Primary │ ← 쓰기 전용 │
│ │ (Write) │ │
│ └──────┬──────┘ │
│ │ 비동기 복제 │
│ ┌──────┴──────┬──────────────┐ │
│ ▼ ▼ ▼ │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │Replica1│ │Replica2│ │Replica3│ ← 읽기 전용 │
│ └────────┘ └────────┘ └────────┘ │
│ │
│ 특징: │
│ ├── RDS: 최대 5개 복제본 │
│ ├── Aurora: 최대 15개 복제본 │
│ ├── 읽기 부하 분산 │
│ ├── 수동 생성 (AWS Console / CLI) │
│ └── Aurora는 Auto Scaling 지원 │
│ │
└─────────────────────────────────────────────────────────────┘
4.3 Aurora Auto Scaling
┌─────────────────────────────────────────────────────────────┐
│ │
│ Aurora 한정 기능: │
│ │
│ 읽기 복제본 자동 증감: │
│ ├── CPU 사용률 기반 │
│ ├── 연결 수 기반 │
│ └── 최소 1개 ~ 최대 15개 설정 │
│ │
│ 예시 정책: │
│ ├── CPU > 70% → Replica 추가 │
│ ├── CPU < 30% → Replica 제거 │
│ └── 최소 2개, 최대 10개 유지 │
│ │
│ 제한: │
│ ├── ✅ Read Replica 자동 스케일링 │
│ ├── ❌ Primary(쓰기) 자동 스케일링 없음 │
│ └── ❌ 일반 RDS에서는 사용 불가 │
│ │
└─────────────────────────────────────────────────────────────┘
4.4 Aurora Serverless v2
┌─────────────────────────────────────────────────────────────┐
│ │
│ Aurora Serverless v2: │
│ │
│ ACU (Aurora Capacity Unit) 기반 자동 스케일링: │
│ ├── 0.5 ACU ~ 128 ACU 범위에서 자동 조절 │
│ ├── 1 ACU ≈ 2GB RAM │
│ ├── 읽기/쓰기 모두 자동 스케일링 │
│ └── 초 단위로 용량 조절 │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ ┌──┐ │ │
│ │ ACU ┌─┘ └─┐ │ │
│ │ ↑ ┌───┘ └───┐ │ │
│ │ │ ┌───┘ └───┐ │ │
│ │ │ ────┘ └──── │ │
│ │ └────────────────────────────────→ 시간│ │
│ │ 부하에 따라 자동으로 용량 조절 │ │
│ └──────────────────────────────────────────┘ │
│ │
│ 장점: │
│ ├── 완전 자동 스케일링 (읽기+쓰기) │
│ ├── 유휴 시 비용 최소화 │
│ └── 급격한 트래픽 변화 대응 │
│ │
│ 단점: │
│ ├── 비용 예측 어려움 │
│ ├── 콜드 스타트 지연 가능 │
│ └── Aurora만 지원 (일반 RDS 불가) │
│ │
└─────────────────────────────────────────────────────────────┘
5. 대규모 트래픽 시 실제 문제들
5.1 Connection 고갈
┌─────────────────────────────────────────────────────────────┐
│ │
│ 문제: │
│ Pod 1000개 × 각 10 connections = 10,000 connections 필요 │
│ │
│ RDS max_connections (인스턴스 크기별): │
│ ├── db.t3.medium ≈ 80 │
│ ├── db.r5.large ≈ 700 │
│ ├── db.r5.4xlarge ≈ 5,000 │
│ └── 아무리 커도 수만 개는 힘듦 │
│ │
│ 증상: │
│ ├── "too many connections" 에러 │
│ ├── 연결 실패 │
│ └── 애플리케이션 장애 │
│ │
└─────────────────────────────────────────────────────────────┘
5.2 해결책: Connection Pooling
┌─────────────────────────────────────────────────────────────┐
│ │
│ RDS Proxy (AWS 관리형): │
│ │
│ Pod 1 ──┐ ┌────────┐ │
│ Pod 2 ──┤ │ │ │
│ Pod 3 ──┼── 10,000 connections ──→│ RDS │── 200 ──→ RDS│
│ ... │ │ Proxy │ connections │
│ Pod 1000─┘ │ │ │
│ └────────┘ │
│ │
│ 특징: │
│ ├── 연결 재사용 (Connection Pooling) │
│ ├── 수천 개 앱 연결 → 수백 개 DB 연결로 변환 │
│ ├── IAM 인증 지원 │
│ ├── Failover 자동 처리 │
│ └── 추가 비용 발생 ($0.015/vCPU/시간) │
│ │
│ 대안: │
│ ├── PgBouncer (PostgreSQL) │
│ ├── ProxySQL (MySQL) │
│ └── 애플리케이션 레벨 풀링 (HikariCP 등) │
│ │
└─────────────────────────────────────────────────────────────┘
6. 권장 아키텍처
대규모 트래픽용
┌─────────────────────────────────────────────────────────────┐
│ │
│ EKS Pods (1000개) │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ RDS Proxy │ ← Connection Pooling │
│ └──────┬──────┘ │
│ │ │
│ ┌────┴────┐ │
│ ▼ ▼ │
│ ┌─────┐ ┌─────────────────────────┐ │
│ │Write│ │ Read Replicas │ │
│ │ DB │ │ ┌────┐ ┌────┐ ┌────┐ │ │
│ │ │──→ │ R1 │ │ R2 │ │ R3 │ │ ← Aurora Auto Scale │
│ └─────┘ │ └────┘ └────┘ └────┘ │ │
│ Primary └─────────────────────────┘ │
│ │
│ Write: Primary (단일, 수동 스케일업) │
│ Read: Replica들 (Aurora Auto Scaling) │
│ Connection: RDS Proxy로 관리 │
│ │
└─────────────────────────────────────────────────────────────┘
애플리케이션 코드 예시
// DataSource 설정
@Configuration
public class DataSourceConfig {
// Write용 DataSource (Primary)
@Bean
@Primary
public DataSource writeDataSource() {
return DataSourceBuilder.create()
.url("jdbc:postgresql://my-db-proxy.proxy-xxx.rds.amazonaws.com:5432/mydb")
.build();
}
// Read용 DataSource (Replica)
@Bean
public DataSource readDataSource() {
return DataSourceBuilder.create()
.url("jdbc:postgresql://my-db-cluster-ro.cluster-xxx.rds.amazonaws.com:5432/mydb")
.build(); // Aurora Reader Endpoint
}
}
7. 비교 정리
RDS vs Aurora
| 항목 | RDS (일반) | Aurora |
|---|---|---|
| Read Replica | 최대 5개 | 최대 15개 |
| Replica Auto Scaling | ❌ | ✅ |
| Serverless 옵션 | ❌ | ✅ (v2) |
| 스토리지 자동 확장 | 제한적 | 자동 (최대 128TB) |
| 복제 지연 | 수 초 | 수 ms |
| 비용 | 저렴 | 20% 정도 비쌈 |
| Failover 속도 | 60-120초 | 30초 이내 |
스케일링 방식 요약
| 방식 | 자동? | 쓰기 스케일링 | 읽기 스케일링 |
|---|---|---|---|
| 수직 스케일링 | 수동 | ✅ | ✅ |
| Read Replica | 수동 | ❌ | ✅ |
| Aurora Auto Scaling | 자동 | ❌ | ✅ |
| Aurora Serverless v2 | 자동 | ✅ | ✅ |
관련 키워드
RDS, EKS, Aurora, Read Replica, Primary, RDS Proxy, Connection Pooling, PgBouncer, ProxySQL, Aurora Auto Scaling, Aurora Serverless, ACU, max_connections, Multi-AZ, Failover