서비스 초기엔 인스턴스에 직접 PostgreSQL을 깔아 썼습니다. 그런데 어느 날 그 인스턴스의 디스크가 고장 나 데이터가 통째로 날아갔고, 백업은 없었습니다. 복구에 사흘, 신뢰는 영영. 그 뒤로 팀은 DB를 관리형으로 옮겼습니다 — 패치·백업·이중화를 사람이 잊지 않도록. DB는 '죽으면 가장 아픈' 자원이라, 운영을 위임할 가치가 가장 큽니다.
- 1관리형 DB가 대신 해주는 것과, 여전히 내 책임인 것을 구분할 수 있다
- 2멀티AZ가 '가용성'을 위한 것임을 설명할 수 있다
- 3읽기 복제본이 '읽기 확장'을 위한 것임을 구분할 수 있다
- 4자동 백업·시점 복구로 사고에 대비하는 법을 안다
- 5DB를 프라이빗 서브넷에 두는 보안 원칙을 적용할 수 있다
운영을 위임하되, 설계는 내 몫
관리형 DB가 맡는 것 / 안 맡는 것
관리형 DB(RDS 등)는 운영을 대신합니다: OS·엔진 패치, 자동 백업, 장애 복구, 멀티AZ 이중화, 기본 모니터링. DBA가 없어도 안정 운영이 가능합니다.
하지만 설계는 그대로 내 책임입니다: 데이터 모델링, 인덱스, 느린 쿼리 튜닝, 커넥션 관리. 관리형이라고 나쁜 스키마·쿼리가 빨라지지 않습니다. [[database]] 트랙의 지식이 클라우드에서도 그대로 필요합니다.
멀티AZ vs 읽기 복제본 — 자주 헷갈리는 둘
이름이 비슷해 헷갈리지만 목적이 정반대입니다.
- 멀티AZ: 다른 AZ에 동기 복제된 대기(standby). 주가 죽으면 자동 전환(failover). 목적은 가용성(살아남기). 대기는 평소 트래픽을 안 받음.
- 읽기 복제본(read replica): 비동기 복제된 읽기 전용 사본(여러 개 가능, 다른 리전도). 읽기 트래픽 분산. 목적은 읽기 확장. 복제 지연으로 stale read 가능.
"고가용성"이 필요하면 멀티AZ, "읽기가 많아 버겁다"면 읽기 복제본입니다.
백업과 복구 — 복제본은 백업이 아니다
관리형 DB는 자동 스냅샷+트랜잭션 로그로 시점 복구(PITR) 를 제공합니다. 실수로 데이터를 지워도 그 직전으로 새 인스턴스를 복원할 수 있습니다.
주의: 읽기 복제본은 백업이 아닙니다. 주에서 잘못된 DELETE가 일어나면 복제본에도 그대로 복제됩니다. 백업(되돌릴 수 있는 시점 사본)과 복제(실시간 사본)는 다른 안전장치입니다. 둘 다 필요합니다.
멀티AZ·백업 보존·공개 접근 여부를 한 번에 점검합니다.
aws rds describe-db-instances \
--query "DBInstances[].{Id:DBInstanceIdentifier,MultiAZ:MultiAZ,Backup:BackupRetentionPeriod,Public:PubliclyAccessible}" --output table
+-------------+---------+--------+--------+
| prod-db | True | 7 | False |
| legacy-db | False | 0 | True | ← 위험: 단일AZ·백업없음·공개
+-------------+---------+--------+--------+
aws rds describe-db-instances시점 복구가 어디까지 가능한지(보존 범위) 확인합니다.
aws rds describe-db-instances --db-instance-identifier prod-db \
--query "DBInstances[0].{Earliest:LatestRestorableTime,Retention:BackupRetentionPeriod}"
{ "Earliest": "2026-06-15T13:20:00Z", "Retention": 7 }
aws rds describe-db-instances- PubliclyAccessible=True인 DB — DB는 프라이빗 서브넷·비공개가 원칙([[cloud-vpc-network]]). 공개면 즉시 차단 검토
- BackupRetentionPeriod=0 — 자동 백업 꺼짐. 사고 시 복구 불가. 최소 7일 이상 권장
- 운영 핵심인데 MultiAZ=False — 단일 AZ 장애로 다운. 가용성 요구에 따라 멀티AZ 활성화
- 읽기 복제본의 복제 지연(ReplicaLag) — 지연이 크면 stale read 심화. 쓰고 바로 읽는 요청은 주로 라우팅
상황: 쓰기 직후 읽기 복제본에서 조회하면 데이터가 없거나 옛 값.
원인: 읽기 복제본은 비동기 복제라 주→복제본 반영에 지연(ReplicaLag)이 있음. '쓰고 즉시 읽는' 요청이 복제본으로 가면 아직 복제 전이라 안 보임(stale read).
진단: 복제본의 ReplicaLag 지표 확인 → 해당 요청이 어느 엔드포인트로 가는지 확인(쓰기/읽기 분리 라우팅).
해결: '쓰고 바로 보여줘야 하는' 흐름(주문 직후 확인 등)은 주 인스턴스에서 읽기. 분석·목록처럼 약간의 지연이 허용되는 읽기만 복제본으로. 복제 지연을 모니터링하고 임계 초과 시 알림([[cloud-observability-governance]]).
면접 단골: "DB 가용성을 어떻게 확보하나요?" → "운영 DB는 멀티AZ로 자동 failover, 읽기 부하는 읽기 복제본으로 분산, 자동 백업+PITR로 사고 대비, DB는 프라이빗 서브넷에 둬 외부 노출 차단"이면 탄탄합니다.
실무 함정: 관리형 DB로 옮겼다고 안심하다가 복구를 한 번도 연습 안 해 정작 사고 때 우왕좌왕하는 경우가 많습니다. 백업이 '있는 것'과 '복구되는 것'은 다릅니다 — 정기적으로 스냅샷에서 복원해 보는 DR 훈련이 진짜 안전장치입니다. 커넥션 풀·느린 쿼리 같은 성능 이슈는 클라우드여도 [[database]] 트랙의 튜닝이 그대로 필요합니다.
다음 모듈에서는 서버를 아예 띄우지 않고 코드만 실행하는 서버리스(Lambda) — 이벤트 기반 실행과 콜드스타트, 과금 모델을 다룹니다.