🗄️ AWS RDS & Aurora (관계형 데이터베이스)#

🔑 RDS (Relational Database Service)란?#

• SQL 기반 관계형 데이터베이스를 위한 AWS 관리형 서비스 (Managed DB Service)
• 사용자가 DB 엔진만 선택하면 나머지는 AWS가 운영

지원 DB 엔진#

자동 확장 조건 (모두 충족 시)#

1
1️⃣ 여유 스토리지 < 할당 스토리지의 10%
2
        AND
3
2️⃣ 저용량 상태가 5분 이상 지속
4
        AND
5
3️⃣ 마지막 수정으로부터 6시간 이상 경과

💡 Use Case: 예측 불가한 워크로드(Unpredictable Workloads)가 있는 애플리케이션. 모든 RDS 엔진 지원.

📖 개념#

• 읽기 요청(SELECT)을 메인 DB에서 분산하여 읽기 성능 향상
• 비동기 복제 (ASYNC Replication) → 최종 일관성 (Eventually Consistent)
  • 복제 전에 읽으면 약간 오래된(Stale) 데이터가 조회될 수 있음

1
[Primary DB] ──ASYNC 복제──→ [Read Replica 1]
2
             ──ASYNC 복제──→ [Read Replica 2]  ← 읽기 전용 쿼리
3
             ──ASYNC 복제──→ [Read Replica N]

📋 주요 특성#

WARNING

⚠️ 애플리케이션 수정 필요: Read Replica를 사용하려면 연결 문자열(Connection String)을 복제본 엔드포인트로 업데이트해야 함.

💰 Read Replica 네트워크 비용#

💡 Read Replica 활용 시나리오#

1
[상황]
2
운영 DB: 정상 트래픽 처리 중
3
팀 요청: 분석용 리포팅 애플리케이션 추가
4

5
[잘못된 방법]  운영 DB에서 직접 분석 쿼리 실행 → 성능 저하
6
[올바른 방법]  Read Replica 생성 → 분석 쿼리는 복제본에서 실행
7
              → 운영 DB 영향 없음

🔄 개념#

• 동기 복제 (SYNC Replication) — 메인 DB의 모든 변경사항을 즉시 Standby에 동기화
• 단일 DNS 이름 — 장애 시 애플리케이션 수정 없이 자동 페일오버 (Automatic Failover)

1
[Primary DB] ──SYNC 복제──→ [Standby DB]
2
     │                           │
3
     └────── 단일 DNS ───────────┘
4
             (자동 전환)

📋 주요 특성#

TIP

📌 Read Replica는 Multi-AZ로 설정 가능 → Standby 복제본을 이중 보호

🔧 Single-AZ → Multi-AZ 전환#

• Zero Downtime — DB 중지 없이 전환 가능
• AWS 콘솔에서 “Modify(수정)” 클릭만으로 완료

1
내부 동작:
2
1. 현재 DB 스냅샷 생성
3
2. 새 AZ에 스냅샷에서 Standby DB 복원
4
3. 두 DB 간 동기화 확립 완료

📊 Read Replica vs Multi-AZ 비교#

✨ 개요#

• AWS가 독자 개발한 독점 기술 (Proprietary Technology) (오픈소스 아님)
• PostgreSQL, MySQL과 호환 (드라이버 교체만으로 마이그레이션 가능)
• AWS 클라우드에 최적화: MySQL 대비 5배, PostgreSQL 대비 3배 성능 향상 주장
• 스토리지 자동 증가: 10GB 단위, 최대 128TB (이전 256TB에서 업데이트)
• 최대 15개 복제본, 복제 지연 10ms 미만 (Sub 10ms replica lag)
• 즉각적인 페일오버 (Instantaneous Failover) — HA Native
• RDS 대비 약 20% 비용 증가 (하지만 효율성으로 상쇄)

🏗️ Aurora 고가용성 & 스토리지 아키텍처#

1
[Aurora Writer (Master)]  →  [Read Replica] × 최대 15개
2
         │
3
         ▼
4
[분산 스토리지 클러스터]
5
├── AZ 1: 복사본 2개
6
├── AZ 2: 복사본 2개
7
└── AZ 3: 복사본 2개
8
     → 총 6개 복사본 (3 AZ × 2)

🔗 Aurora 엔드포인트#

1
[Writer Endpoint] ──→ [Master (쓰기)]          ← 항상 마스터를 가리킴
2
[Reader Endpoint] ──→ [Read Replicas (읽기)]   ← 복제본 간 로드 밸런싱
3
[Custom Endpoint] ──→ [특정 복제본 서브셋]      ← 분석 쿼리 등 특수 목적

⚙️ Aurora DB 클러스터 주요 기능#

🌐 Aurora Serverless#

• 실제 사용량 기반 자동 DB 인스턴스화 및 오토스케일링
• 비정기적(Infrequent), 간헐적(Intermittent), 예측 불가한(Unpredictable) 워크로드에 적합
• 용량 계획 불필요
• 초 단위 과금 (Pay per second) — 경우에 따라 비용 효율적

🌍 Global Aurora#

Aurora Global DB 특성:

• 1개 Primary Region (읽기/쓰기)
• 최대 5개 Secondary(보조) 리전 (읽기 전용)
• 보조 리전당 최대 16개 Read Replica
• 리전 간 복제 지연 1초 미만 (< 1 second)
• 보조 리전 승격 시 RTO(Recovery Time Objective) < 1분
• 지역별 지연 시간 감소에 효과적

🤖 Aurora Machine Learning#

• Aurora에서 SQL 쿼리로 ML 기반 예측 수행
• Aurora ↔ AWS ML 서비스 간 최적화된 보안 통합

Use Case: 사기 탐지(Fraud Detection), 광고 타겟팅, 감성 분석, 상품 추천

🔄 Babelfish for Aurora PostgreSQL#

• Aurora PostgreSQL이 Microsoft SQL Server의 T-SQL 명령을 이해하도록 지원
• MS SQL Server 기반 애플리케이션을 코드 수정 거의 없이 Aurora PostgreSQL로 마이그레이션 가능

🔄 자동 백업 (Automated Backups)#

📸 수동 스냅샷 (Manual DB Snapshots)#

• 사용자가 직접 트리거
• 보존 기간 무제한 (자동 백업은 최대 35일)
• 오래 DB를 중지할 경우: 스냅샷 저장 후 삭제 → 나중에 복원 (스토리지 비용 절감)

🔃 복원 옵션 (Restore Options)#

🔁 Aurora Database Cloning (클로닝)#

• 기존 Aurora DB 클러스터에서 새 클러스터 빠르게 생성
• 스냅샷 & 복원보다 빠름
• Copy-on-Write 프로토콜 사용:

1
초기 상태: 원본과 클론이 동일한 스토리지 볼륨 공유 (복사 없음 → 빠름)
2
         │
3
         ▼
4
클론에 데이터 변경 발생 시: 변경된 데이터만 별도 스토리지에 분리 저장

Use Case: 프로덕션 DB에 영향 없이 스테이징 DB 즉시 생성 (Useful to create a staging database from a production database without impacting the production database)

🔐 보안 레이어#

🔑 암호화 관련 핵심 규칙#

1
마스터 암호화 ← Read Replica 암호화 여부 결정
2
  │
3
  ├── 마스터 암호화 → 복제본도 암호화 가능
4
  └── 마스터 미암호화 → 복제본 암호화 불가 ❌
5

6
미암호화 DB → 암호화 변환 방법:
7
  1. DB 스냅샷 생성
8
  2. 스냅샷 복사 시 암호화 활성화
9
  3. 암호화된 스냅샷으로 새 DB 복원

RDS vs Aurora#

📌 시험 자주 출제 포인트#