AWS 중급 #4 RDS: 매니지드 DB, 백업, 파라미터 그룹

#3 S3가 객체 영역이었다면, 이제 관계형 DB 차례입니다. AWS의 관계형 DB 매니지드 서비스는 **RDS (Relational Database Service)**입니다. PostgreSQL / MySQL / MariaDB / Oracle / SQL Server / Aurora를 한 콘솔에서 띄우고 운영할 수 있습니다.

이 글에선 RDS의 매니지드 모델 → 자동 백업과 PITR → Multi-AZ와 Read Replica → 파라미터 / 옵션 그룹 → 업그레이드까지 차례로 정리하겠습니다.

EC2 위 DB vs RDS #

처음 클라우드를 만나면 다들 한 번씩 망설입니다. “EC2 한 대 띄워 PostgreSQL 직접 깔까, RDS로 갈까?”

운영 시스템은 99% RDS가 답입니다. EC2 위 DB는 익스텐션이 RDS에서 미지원이거나 OS 단 튜닝이 필요한 특수한 경우에만 씁니다.

엔진 선택 #

RDS가 지원하는 엔진:

PostgreSQL  ── 새 프로젝트의 첫 후보. JSONB / 익스텐션 풍부
MySQL       ── 가장 흔한 선택. 호환성 중시
MariaDB     ── MySQL 포크. 거의 MySQL과 동일
Oracle      ── 라이선스 비싼 엔터프라이즈
SQL Server  ── 마이크로소프트 생태계
Aurora      ── AWS 자체 엔진. PostgreSQL / MySQL 호환

Aurora의 특징 #

Aurora는 AWS가 만든 클라우드 네이티브 DB입니다. PostgreSQL / MySQL 와이어 호환이라 코드 변경 거의 없이 옮길 수 있습니다.

운영 규모 / 가용성이 중요하면 Aurora, 비용 / 단순성이 중요하면 RDS PostgreSQL.

Aurora Serverless v2는 사용량 기반 자동 스케일 RDS. 트래픽이 들쭉날쭉한 경우에 매력적입니다. 콜드 스타트가 거의 없음 (v1의 단점이 해결).

RDS 인스턴스 띄우기 #

aws rds create-db-instance \
  --db-instance-identifier my-postgres \
  --db-instance-class db.t3.micro \
  --engine postgres \
  --engine-version 16.4 \
  --master-username postgres \
  --master-user-password "very-strong-password" \
  --allocated-storage 20 \
  --storage-type gp3 \
  --vpc-security-group-ids sg-0abc... \
  --db-subnet-group-name my-db-subnet-group \
  --backup-retention-period 7 \
  --multi-az \
  --no-publicly-accessible

자주 만지는 옵션:

DB Subnet Group #

RDS는 Multi-AZ 구성에 둘 서브넷을 미리 지정해야 합니다. 그게 DB Subnet Group입니다. 보통 Private 서브넷 두 AZ 이상으로 둡니다.

aws rds create-db-subnet-group \
  --db-subnet-group-name my-db-subnet-group \
  --db-subnet-group-description "DB private subnets" \
  --subnet-ids subnet-0a1... subnet-0b2... subnet-0c3...

DB가 사는 곳은 Private 서브넷 (#1 VPC)입니다. 인터넷에 직접 노출하지 않고, 앱 서버 SG만 SG 단위로 들어오게 허용합니다.

자동 백업: 매니지드의 핵심 가치 #

RDS의 진짜 가치는 백업입니다.

Automated Backup #

backup-retention-period가 0보다 크면 자동 백업이 켜집니다.

• 매일 한 번 전체 백업 (백업 윈도우 시간에)
• 트랜잭션 로그 5분마다
• 보존 기간 (1~35일) 동안 보관
• DB 삭제 시 자동 백업도 같이 삭제 (SkipFinalSnapshot=false로 막을 수 있음)

Point-in-Time Recovery (PITR) #

자동 백업이 켜진 RDS는 보존 기간 안의 임의 시점으로 복원할 수 있습니다. 트랜잭션 로그 기반으로 5분 단위 정밀도로 지정 가능합니다.

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier my-postgres \
  --target-db-instance-identifier my-postgres-restored \
  --restore-time 2026-04-21T08:30:00Z

복원은 새 인스턴스를 만드는 형태로 이루어지며, 원본은 그대로 남습니다. “오늘 새벽 3시 27분 직전 상태가 필요합니다” 같은 요청도 가능합니다.

Manual Snapshot #

자동 백업과 별도로 사용자가 명시적으로 만드는 백업입니다. DB를 삭제해도 사라지지 않고, 보존 기한도 따로 없습니다.

aws rds create-db-snapshot \
  --db-instance-identifier my-postgres \
  --db-snapshot-identifier my-postgres-2026-04-21-prerelease

운영 용도:

• 메이저 업그레이드 직전 스냅샷
• 큰 마이그레이션 직전 스냅샷
• DB 삭제 시 final snapshot
• 다른 리전 / 계정으로 복사 (DR 구성)

Multi-AZ: 고가용성 #

--multi-az 옵션을 켜면 RDS가 Standby 인스턴스를 다른 AZ에 자동 복제.

   ┌──────────────────────────────────┐
   │           VPC                    │
   │                                  │
   │    AZ a              AZ b        │
   │    ┌──────┐          ┌──────┐    │
   │    │ Pri  │ ◀══════▶ │Stand │    │
   │    │mary  │  복제(동기) │ by   │    │
   │    └──────┘          └──────┘    │
   │       ▲                          │
   │       │ DNS endpoint             │
   │       │ (자동 페일오버)              │
   └───────┼──────────────────────────┘
           │
       앱 서버

• 동기 복제. Standby도 매 트랜잭션 commit까지 받아둠
• 장애 시 자동 페일오버. 30초~2분 안에 Standby가 Primary가 되고 DNS endpoint가 그쪽을 가리킴
• 읽기 분산 안 됨. Standby는 읽기에도 안 쓰임 (Aurora와 다른 점)

Multi-AZ의 비용 #

이중화의 대가는 인스턴스 / 스토리지 비용 2배. 학습 / 사이드 프로젝트는 단일 AZ, 운영은 Multi-AZ.

Multi-AZ Cluster (옵션) #

PostgreSQL / MySQL과 동일에 새로 나온 Multi-AZ DB Cluster는 standby가 읽기 가능 하고, 페일오버 시간도 35초 이하. 단, AZ 3개 사용 (인스턴스 3개 비용).

Read Replica: 읽기 분산 #

Read Replica는 비동기 복제로 만들어지는 읽기 전용 사본입니다. 읽기 트래픽이 많은 경우에 부하를 분산합니다.

aws rds create-db-instance-read-replica \
  --db-instance-identifier my-postgres-read-1 \
  --source-db-instance-identifier my-postgres \
  --availability-zone ap-northeast-2c

특징:

• 비동기 복제. 약간의 지연 (보통 ms~초)
• 다른 리전에도 가능. 글로벌 읽기 분산 / DR
• 최대 5개 (Aurora는 15개)
• Promote로 별도 인스턴스로 분리 가능

Read Replica의 용도 #

읽기 트래픽이 많지 않으면 Read Replica보다 Multi-AZ Cluster가 더 단순합니다.

파라미터 그룹과 옵션 그룹 #

DB 엔진의 설정 (max_connections, shared_buffers 같은)을 RDS에서는 파라미터 그룹으로 관리.

Parameter Group #

aws rds create-db-parameter-group \
  --db-parameter-group-name my-postgres-16-params \
  --db-parameter-group-family postgres16 \
  --description "Custom params for my workload"

aws rds modify-db-parameter-group \
  --db-parameter-group-name my-postgres-16-params \
  --parameters \
    "ParameterName=max_connections,ParameterValue=200,ApplyMethod=pending-reboot" \
    "ParameterName=log_statement,ParameterValue=ddl,ApplyMethod=immediate"

종류:

• Static. DB 재부팅 후 적용 (max_connections 등)
• Dynamic. 즉시 적용 (log_statement 등)

자주 만지는 파라미터:

Option Group #

엔진별 추가 기능 (예: SQL Server의 SSIS, Oracle의 OEM)을 켜는 그룹입니다. PostgreSQL / MySQL는 거의 안 만집니다.

업그레이드: 운영 작업 #

RDS는 엔진 버전을 두 종류로 나눕니다.

Minor Upgrade: 안전 #

16.3 → 16.4 같은 마이너 업그레이드. 보통 보안 패치 + 작은 개선. 자동 적용 옵션을 켜면 백업 윈도우에 자동.

aws rds modify-db-instance \
  --db-instance-identifier my-postgres \
  --auto-minor-version-upgrade \
  --apply-immediately

다운타임은 30초~5분입니다. Multi-AZ면 더 짧습니다 (Standby 먼저 → 페일오버 → 옛 Primary).

Major Upgrade: 신중 #

PostgreSQL 16 → 17 같은 메이저 업그레이드. 깨질 수 있습니다. 절차:

1. 수동 스냅샷 만들기 (롤백 대비)
2. 테스트 환경에서 같은 버전 마이그레이션 시도
3. Read Replica를 먼저 업그레이드 (가능하면)
4. 운영 시간 외 다운타임 윈도우 잡기
5. aws rds modify-db-instance --engine-version 17.0
6. 업그레이드 모니터링
7. 문제 시 스냅샷에서 새 인스턴스 복원

메이저 업그레이드 전 PostgreSQL의 deprecated SQL / MySQL의 strict mode 변경 같은 호환성 이슈를 먼저 점검.

Blue/Green Deployment #

RDS의 Blue/Green Deployment는 메이저 업그레이드 / 큰 변경의 다운타임을 줄이는 새 방식입니다. 복제본 (green)을 만들고 cutover 시점에만 짧게 멈춥니다.

aws rds create-blue-green-deployment \
  --blue-green-deployment-name my-postgres-bg \
  --source arn:aws:rds:ap-northeast-2:123456789012:db:my-postgres \
  --target-engine-version 17.0

Performance Insights: 성능 도구 #

RDS의 성능 모니터링 도구입니다. 어떤 SQL이 시간을 가장 많이 잡는지 그래프로 봅니다.

시간축 ──▶
DB Load ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮
        │ ── SELECT ... FROM users WHERE ...
        │ ── UPDATE products SET ...
        │ ── lock:relation

• 7일 무료, 그 이상은 추가 비용
• 슬로우 쿼리 / 락 / 대기 분석
• 장고 고급 #3 쿼리 최적화 편에서 만나는 N+1 같은 패턴이 그래프로 보입니다

RDS Proxy: 연결 풀 #

Lambda / 컨테이너에서 RDS로 연결할 때 매번 TCP / TLS 핸드셰이크가 비싼 작업입니다. RDS Proxy가 연결 풀을 매니지드로 만들어줍니다.

구성:

• Lambda + RDS. 매 invocation 새 연결 → Proxy로 풀
• 컨테이너 자동 스케일. 인스턴스 늘어나며 connection 폭증
• failover 자동 회복

비용은 vCPU 시간당. 작은 워크로드엔 오버킬일 수 있습니다.

자주 만나는 함정 #

1) 퍼블릭 RDS #

publicly-accessible=true로 만들고 SG가 0.0.0.0/0 → 며칠 안에 brute-force 공격이 옴. 운영은 항상 Private 서브넷 + 앱 SG만.

2) master-user-password를 git에 #

스크립트 / Terraform에 평문 비밀번호 → 노출. Secrets Manager (고급 #6)로 관리.

3) Multi-AZ 안 켰는데 운영 #

비용 절감으로 Multi-AZ를 끔 → AZ 장애 시 DB 1~2시간 다운. 운영은 켜기.

4) backup-retention 0 #

비용 절감으로 자동 백업 끔 → PITR도 동시에 꺼짐. 사고 시 복구 불가. 최소 7일 권장.

5) Final Snapshot 안 만들고 삭제 #

DB 삭제 시 --skip-final-snapshot으로 빨리 지움 → 데이터 영구 손실. terraform destroy 같은 자동화에서는 final snapshot 강제.

6) Storage Auto-Scaling 끔 #

디스크 80% 차오른 새벽 → 쓰기 실패. max-allocated-storage 옵션으로 자동 확장 켜기.

aws rds modify-db-instance \
  --db-instance-identifier my-postgres \
  --max-allocated-storage 200

7) Read Replica를 페일오버 용도로 #

Read Replica는 자동 페일오버 안 됨. 수동 promote 필요. 자동 페일오버는 Multi-AZ.

8) Connection 누수 #

앱이 연결을 안 닫아 max_connections를 채움 → 새 요청 거부. PgBouncer / RDS Proxy 또는 앱 풀 설정 점검.

정리 #

이번 글에서 잡은 것:

• RDS = AWS의 매니지드 관계형 DB. PostgreSQL / MySQL / Aurora가 일반
• Aurora = AWS 자체 엔진. 분산 스토리지, 빠른 페일오버, 더 많은 RR
• DB Subnet Group으로 Private 서브넷에. publicly-accessible=false가 운영 기본
• 자동 백업 + PITR = 5분 정밀도로 임의 시점 복원
• Manual Snapshot = 명시적, DB 삭제해도 살아남음
• Multi-AZ = 동기 복제 + 자동 페일오버, 그러나 standby는 읽기 안 됨
• Read Replica = 비동기 사본, 읽기 분산 / 분석용. 자동 페일오버 아님
• Parameter Group으로 엔진 설정 관리. Static / Dynamic 차이
• Minor 업그레이드 = 자동 적용 가능. Major 업그레이드 = Blue/Green 권장
• Performance Insights + RDS Proxy로 운영 보강
• 함정. 퍼블릭, 비밀번호, Multi-AZ 끔, 백업 0, final snapshot 누락, storage 자동확장, RR 페일오버 오해, connection 누수

다음: Route 53 #

DB 영역은 잡았습니다. 이제 사용자가 우리 시스템을 처음 만나는 관문, DNS로 이어집니다.

#5 Route 53: 도메인과 DNS에서는 도메인 등록 / Hosted Zone / 레코드 종류와 Alias / 라우팅 정책 (Failover / Latency / Geolocation) 까지 운영 도메인 운용을 정리하겠습니다.