RDS로 관리형 데이터베이스 운영하기

요약: 관리형 관계형 DB(RDS)를 프라이빗 서브넷·백업·멀티 AZ로 안전하게 올리는 기준을 정리한다.

---

1. 언제 RDS인가

RDS는 Relational Database Service, AWS가 패치·백업·페일오버를 대신하는 관계형 DB다. EC2에 Postgres를 직접 깔 수도 있다. 그때는 OS 패치·디스크·복제가 전부 내 일이다. 그 운영을 맡기고 싶을 때 RDS가 맞다.

엔진	흔한 선택
PostgreSQL	일반 웹/API, JSON·제약
MySQL / MariaDB	레거시, 워드프레스
Aurora	읽기 확장·고가용 요구가 클 때
SQL Server 등	기존 라이선스·호환이 필요할 때

Aurora는 RDS 계열의 클라우드 최적화 엔진이다. 비용·호환을 보고 고른다. “일단 Aurora”가 항상 답은 아니다.

EC2 자체 설치가 나은 경우도 있다. 특수한 확장, 세밀한 커널 튜닝, RDS가 지원하지 않는 버전. 그 대가는 백업과 장애 훈련이다.

---

2. 핵심 개념

DB 서브넷 그룹. RDS ENI가 들어갈 프라이빗 서브넷 묶음이다. 두 AZ 이상을 넣는다. 퍼블릭 서브넷에 두면 실수로 공인 접근이 열리기 쉽다.

퍼블릭 액세스. 기본은 끈다. 로컬에서 붙을 때는 배스천, SSM 포트 포워딩, VPN을 쓴다. 0.0.0.0/0으로 3306/5432를 열지 않는다.

보안 그룹. DB SG 인바운드는 앱 SG만. 내 노트북 CIDR을 상시 열어 두지 않는다.

파라미터 그룹. max_connections, 로그 설정 등 엔진 파라미터. 기본 그룹을 직접 수정하지 말고 복사본을 문서화한다.

멀티 AZ. 동기 대기 인스턴스가 다른 AZ에 있다. 장애 시 DNS가 넘어간다. 프로덕션 권장이다. 개발은 비용 때문에 단일 AZ가 흔하다.

자동 백업과 스냅샷. 보존 기간을 합의한다. 백업 윈도우에 부하가 있다. 스냅샷을 수동으로만 믿고 자동 백업을 끄지 않는다.

스토리지. gp3 + 자동 확장을 검토한다. 디스크가 가득 차면 쓰기가 멈춘다. FreeStorageSpace 알람은 필수에 가깝다.

마스터 비밀번호는 콘솔에 한 번 넣고, 앱은 Secrets Manager에서 읽는다. 글에는 YOUR_DB_PASSWORD만 쓴다.

---

3. 최소 구성 예

웹 API용 PostgreSQL을 가정한다.

1. 프라이빗 서브넷 두 개로 서브넷 그룹 생성
2. DB SG: 앱 SG → 5432
3. 엔진 PostgreSQL, 작은 클래스(개발 t4g.micro 등). 프로덕션은 부하 측정 후
4. 퍼블릭 액세스 끄기, 암호화 켜기
5. 자동 백업 7일(합의), 멀티 AZ는 프로덕션만
6. 삭제 보호는 프로덕션에서 켜기

연결은 앱만. 호스트는 RDS 엔드포인트다.

postgresql://APP_USER:YOUR_DB_PASSWORD@app-db.REGION.rds.amazonaws.com:5432/app

앱 사용자는 마스터가 아니다. APP_USER에 해당 DB만 GRANT한다.

확인:

aws rds describe-db-instances \
  --query "DBInstances[].{id:DBInstanceIdentifier,az:AvailabilityZone,multi:MultiAZ,pub:PubliclyAccessible}"

PubliclyAccessible가 true이면 이유가 있어야 한다. 보통은 false다.

마이그레이션은 앱 파이프라인에서 돌린다. RDS가 스키마를 대신 짜 주지 않는다. Flyway·Prisma 등은 연결만 RDS를 가리킨다.

---

4. 운영 시 주의

연결. 앱 풀 × 인스턴스 수가 max_connections를 넘기면 장애다. RDS 프록시나 PgBouncer는 서버리스·다수 태스크일 때 검토한다. 유휴 연결을 너무 길게 두지 않는다.

백업. 자동 백업 + 스냅샷 보존을 비용과 함께 본다. 스냅샷이 쌓이면 스토리지 요금이 난다. 복원을 스테이징에서 한 번 한다. 암호화된 스냅샷 복원은 키 권한도 필요하다.

비용. 인스턴스 클래스보다 먼저 슬로우 쿼리와 인덱스를 본다. 개발은 야간 중지(가능한 엔진·구성)를 쓴다. Aurora I/O·스토리지는 모델이 다르다. 견적을 읽고 켠다. 멀티 AZ는 거의 두 대 요금이다. 가치와 같이 설명한다.

보안. 마스터 계정을 앱에 넣지 않는다. 마이너 버전 자동 업데이트를 윈도우와 함께 켠다. 메이저 업은 호환 테스트를 한다.

성능. CPU만 보지 않는다. IOPS, 커넥션, 레플리카 지연을 CloudWatch에 둔다. 읽기 레플리카는 비동기라 “방금 쓴 행”이 없을 수 있다.

삭제. 종료 시 최종 스냅샷 옵션을 확인한다. 실수로 지운 DB는 백업 보존 안에만 살릴 수 있다.

메이저 업그레이드. RDS가 블루/그린 배포를 지원하는 엔진이 있다. 그래도 앱 SQL 호환을 스테이징에서 먼저 본다. 파라미터 그룹 값이 메이저 버전과 안 맞으면 인스턴스가 안 뜬다.

로컬 접속. 개발자가 집에서 직접 붙이려면 SSM 포트 포워딩이 안전하다. 보안 그룹에 집 IP를 매주 갈아 끼우는 운영은 구멍이 남는다. 배스천을 둘 거면 배스천도 패치 대상이다.

흔한 실수. 퍼블릭 액세스 + 약한 마스터 암호, 스토리지 알람 없음, 개발 RDS를 멀티 AZ로 켜 두고 비용 놀람. 세 가지는 첫 달에 자주 난다.

---

5. 정리

RDS는 “DB 설치”가 아니다. 프라이빗 배치 · SG · 백업 · 멀티 AZ를 세트로 계약하는 일이다. 쿼리와 연결 수는 여전히 앱 책임이다.

체크리스트

• 퍼블릭 액세스를 끈다. 인터넷에 열린 5432/3306은 스캔 대상이다.
• DB SG 소스는 앱 SG뿐이다. 노트북 CIDR 상시 개방은 구멍이 된다.
• 자동 백업을 켜고 복원을 한 번 연습한다. 찍기만 한 백업은 백업이 아니다.
• 스토리지 부족 알람을 단다. 디스크 풀은 즉시 장애다.
• 앱은 마스터가 아닌 최소 권한 사용자로 붙는다.

연습

1. describe-db-instances로 PubliclyAccessible와 MultiAZ를 확인한다.
2. 보안 그룹 인바운드가 앱 SG만인지 콘솔에서 대조한다.
3. 스냅샷을 스테이징으로 복원해 앱이 읽기만 되는지 시험한다.

읽기 레플리카는 조회를 나누려 할 때 추가한다. 쓰기는 여전히 프라이머리만. 복제 지연 메트릭을 알람에 넣는다. 레플리카를 하나 더 켜는 비용이 인덱스 하나보다 비쌀 때가 많다. 슬로우 쿼리를 먼저 고친다.

개발 DB 식별자에 dev를 넣고, 프로덕션 스냅샷을 개발에 복원할 때 데이터를 마스킹할지 정한다. 원본 고객 이메일이 개발 계정에 그대로 있으면 그 계정의 IAM이 곧 개인정보 범위다.

RDS Proxy는 연결 폭주(Lambda, 많은 ECS 태스크)에 검토한다. 프록시 자체 요금이 있다. 커넥션 10개짜리 앱 하나면 필요 없다. too many connections가 반복되면 그때 견적을 본다.

엔진 업그레이드 알림 메일을 무시하지 않는다. 강제 마이너 패치 윈도우에 재시작이 있을 수 있다. 멀티 AZ면 페일오버로 짧아질 수 있다. 그래도 배포 캘린더에 적는다.

스토리지 자동 확장은 한도를 둔다. 무한 확장은 무한 청구다. 테이블이 비대해지면 확장이 아니라 아카이브·파티션을 본다. FreeableMemory가 항상 바닥이면 클래스만 키우지 말고 슬로우 쿼리를 먼저 본다.

---

---