0610 AWS 운영 실무 기초 (3/N): RDS와 데이터베이스 운영 관리
✅ 1. RDS란 무엇인가?
- RDS(Relational Database Service)는 AWS에서 제공하는 관리형 관계형 데이터베이스 서비스입니다.
- MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 같은 관계형 DB를 직접 서버에 설치하지 않고 AWS에서 관리형으로 사용할 수 있습니다.
- 쉽게 말하면, EC2에 직접 DB를 설치해서 운영하는 대신 AWS가 DB 서버 운영의 많은 부분을 대신 관리해주는 서비스입니다.
➕ 1-1. RDS를 사용하는 이유
-
DB 운영 부담 감소
- DB 설치, 패치, 백업, 모니터링, 스냅샷 같은 작업을 AWS 기능으로 관리할 수 있습니다.
-
자동 백업
- 설정한 보존 기간 동안 자동 백업을 남길 수 있습니다.
- 장애나 실수 발생 시 특정 시점으로 복구할 수 있습니다.
-
서버와 DB 분리
- EC2 서버와 DB를 분리하면 웹 서버 장애가 DB에 직접 영향을 주는 상황을 줄일 수 있습니다.
-
보안 관리
- 보안 그룹, VPC, 서브넷, 암호화 설정을 통해 DB 접근을 제한할 수 있습니다.
-
확장성
- 트래픽이나 데이터가 늘어나면 인스턴스 타입, 스토리지, 읽기 복제본 등을 조정할 수 있습니다.
✅ 2. EC2 내부 DB와 RDS의 차이
- 작은 프로젝트에서는 EC2 안에 Docker로 PostgreSQL이나 MySQL을 띄워서 사용할 수도 있습니다.
- 하지만 운영 서비스에서는 DB를 EC2 내부에 같이 두는 것보다 RDS로 분리하는 것이 더 안정적인 경우가 많습니다.
| 구분 | EC2 내부 DB | RDS |
|---|---|---|
| 설치/관리 | 직접 설치 및 관리 | AWS 관리형 |
| 백업 | 직접 구성 필요 | 자동 백업 지원 |
| 장애 대응 | 직접 처리 | 관리 기능 제공 |
| 서버 장애 영향 | EC2 장애 시 DB도 영향 | EC2와 분리 가능 |
| 비용 | 초기에는 저렴할 수 있음 | 별도 비용 발생 |
| 운영 안정성 | 관리 역량에 의존 | 상대적으로 안정적 |
➕ 2-1. EC2 내부 DB가 적합한 경우
- 로컬 개발 환경
- 테스트 서버
- 아주 작은 사이드 프로젝트
- 비용을 최대한 줄여야 하는 초기 MVP
- 데이터 중요도가 낮은 임시 서비스
➕ 2-2. RDS가 적합한 경우
- 실제 고객 데이터가 저장되는 서비스
- 상담 신청, 주문, 결제, 회원 정보가 있는 서비스
- 백업과 복구가 중요한 서비스
- 서버와 DB를 분리해 운영 안정성을 높이고 싶은 경우
- 장기적으로 서비스 확장을 고려하는 경우
✅ 3. RDS에서 선택해야 할 주요 항목
➕ 3-1. DB 엔진
- RDS를 만들 때는 어떤 데이터베이스를 사용할지 선택해야 합니다.
| DB 엔진 | 특징 |
|---|---|
| PostgreSQL | 기능이 강력하고 타입/쿼리 기능이 풍부함 |
| MySQL | 사용자가 많고 자료가 많음 |
| MariaDB | MySQL 계열 오픈소스 DB |
| Oracle | 대기업/레거시 환경에서 사용 |
| SQL Server | Microsoft 생태계에서 사용 |
- React + NestJS + Prisma 조합에서는 PostgreSQL 또는 MySQL을 많이 사용합니다.
- Prisma와 타입 안정성, JSON 필드, 관계형 설계를 고려하면 PostgreSQL도 좋은 선택입니다.
➕ 3-2. 인스턴스 클래스
- RDS 인스턴스 클래스는 DB 서버의 CPU와 메모리 성능을 결정합니다.
| 타입 | 용도 |
|---|---|
db.t3.micro | 테스트/소규모 |
db.t3.small | 작은 운영 서비스 |
db.t3.medium | 트래픽이 있는 운영 서비스 |
db.m 계열 | 안정적인 운영 워크로드 |
db.r 계열 | 메모리 사용량이 큰 DB |
- 처음부터 큰 타입을 고르기보다는 작은 타입으로 시작하고, CPU, 메모리, 연결 수를 보면서 조정하는 것이 좋습니다.
- 단, 운영 DB가 너무 작은 인스턴스에서 계속 CPU 80~90% 이상을 유지하면 API 전체가 느려질 수 있습니다.
➕ 3-3. 스토리지
- RDS 스토리지는 DB 데이터가 저장되는 공간입니다.
- 데이터, 인덱스, 로그, 임시 작업 공간이 모두 스토리지를 사용합니다.
초기 소규모 서비스:
20GB ~ 50GB
데이터가 계속 쌓이는 서비스:
100GB 이상 검토- 상담 신청, 주문, 로그성 데이터가 계속 쌓이면 생각보다 빠르게 용량이 증가할 수 있습니다.
- 스토리지 자동 확장 옵션을 켜두면 용량 부족으로 DB가 멈추는 위험을 줄일 수 있습니다.
✅ 4. RDS 네트워크 구조
- RDS 운영에서 가장 중요한 것 중 하나는 네트워크 접근 제어입니다.
- DB는 웹처럼 누구나 접근해야 하는 서비스가 아닙니다.
- 가능하면 외부 인터넷에 직접 공개하지 않고, EC2 백엔드 서버에서만 접근하게 해야 합니다.
➕ 4-1. 기본 구조
사용자
↓
CloudFront / Nginx
↓
EC2 백엔드 서버
↓
RDS 데이터베이스- 사용자는 RDS에 직접 접근하지 않습니다.
- 사용자는 API 서버에 요청하고, API 서버가 필요한 경우 RDS에 접근합니다.
➕ 4-2. Public Access 설정
- RDS 생성 시 Public Access 옵션이 있습니다.
- 운영 DB는 가능하면 Public Access를
No로 설정하는 것이 좋습니다.
권장:
Public Access = No
주의 필요:
Public Access = Yes- Public Access가 Yes이고 보안 그룹까지 넓게 열려 있으면 외부에서 DB 접속 시도가 가능해집니다.
- 특히
5432,3306포트를0.0.0.0/0으로 여는 것은 매우 위험합니다.
✅ 5. RDS 보안 그룹
- RDS 보안 그룹은 DB에 접근할 수 있는 IP나 리소스를 제한합니다.
- EC2에서만 RDS에 접근하게 하려면 RDS 인바운드 규칙에 EC2 보안 그룹을 허용하는 방식이 좋습니다.
➕ 5-1. PostgreSQL 보안 그룹 예시
RDS Security Group Inbound
Type: PostgreSQL
Port: 5432
Source: EC2 Security Group➕ 5-2. MySQL 보안 그룹 예시
RDS Security Group Inbound
Type: MySQL/Aurora
Port: 3306
Source: EC2 Security Group- 이렇게 하면 EC2에 연결된 서버만 RDS에 접근할 수 있습니다.
- 내 PC에서 직접 DB에 접속해야 한다면 임시로 내 IP만 허용하고, 작업 후 제거하는 것이 좋습니다.
임시 허용:
내 IP/32
금지:
0.0.0.0/0✅ 6. DATABASE_URL 구성
- 백엔드 서버는 환경변수
DATABASE_URL을 통해 RDS에 접속합니다. - Prisma를 사용하는 경우
schema.prisma에서DATABASE_URL을 참조합니다.
➕ 6-1. PostgreSQL DATABASE_URL 예시
DATABASE_URL="postgresql://USER:PASSWORD@RDS_ENDPOINT:5432/DB_NAME?schema=public"➕ 6-2. MySQL DATABASE_URL 예시
DATABASE_URL="mysql://USER:PASSWORD@RDS_ENDPOINT:3306/DB_NAME"➕ 6-3. DATABASE_URL에서 확인할 항목
| 항목 | 설명 |
|---|---|
USER | DB 사용자명 |
PASSWORD | DB 비밀번호 |
RDS_ENDPOINT | RDS 엔드포인트 주소 |
PORT | PostgreSQL 5432, MySQL 3306 |
DB_NAME | 데이터베이스 이름 |
| 옵션 | PostgreSQL schema 등 |
- 운영 서버의
.env에 들어가는DATABASE_URL은 절대 GitHub에 올리면 안 됩니다. - 비밀번호에 특수문자가 포함되어 있으면 URL 인코딩 문제가 생길 수 있습니다.
✅ 7. EC2에서 RDS 연결 테스트
- RDS를 생성한 뒤에는 EC2 백엔드 서버에서 RDS에 연결 가능한지 확인해야 합니다.
➕ 7-1. PostgreSQL 클라이언트 설치
sudo apt update
sudo apt install -y postgresql-client➕ 7-2. PostgreSQL 접속 테스트
psql -h RDS_ENDPOINT -p 5432 -U USER -d DB_NAME- 접속이 안 된다면 다음을 확인해야 합니다.
1. RDS가 실행 중인가?
2. RDS 보안 그룹이 EC2 보안 그룹을 허용하는가?
3. EC2와 RDS가 같은 VPC 안에 있는가?
4. Public Access 설정이 현재 접근 방식과 맞는가?
5. DB 사용자명과 비밀번호가 맞는가?
6. 포트가 맞는가?✅ 8. Prisma와 RDS
- Prisma를 사용하는 NestJS 프로젝트에서는 RDS 연결 후 마이그레이션을 적용해야 할 수 있습니다.
➕ 8-1. Prisma 연결 확인
npx prisma db pull- 기존 DB 구조를 Prisma schema로 가져올 때 사용할 수 있습니다.
npx prisma generate- Prisma Client를 생성합니다.
➕ 8-2. 운영 마이그레이션 적용
npx prisma migrate deploy- 운영 환경에서는
migrate dev가 아니라migrate deploy를 사용해야 합니다. migrate dev는 개발 환경에서 마이그레이션을 만들고 적용하는 용도입니다.
➕ 8-3. 절대 조심해야 할 명령어
npx prisma migrate reset- 이 명령어는 DB를 초기화할 수 있으므로 운영 DB에서 사용하면 매우 위험합니다.
- 운영 DB에서
reset,drop,force계열 명령어는 반드시 피해야 합니다.
✅ 9. RDS 자동 백업
- RDS의 가장 큰 장점 중 하나는 자동 백업입니다.
- 자동 백업을 활성화하면 설정한 보존 기간 동안 특정 시점으로 복구할 수 있습니다.
➕ 9-1. 자동 백업에서 확인할 것
- 자동 백업이 활성화되어 있는가?
- 백업 보존 기간은 몇 일인가?
- 백업 시간대가 서비스 피크 시간과 겹치지 않는가?
- 복구 테스트를 해본 적이 있는가?
- 중요한 배포 전 수동 스냅샷을 남겼는가?
➕ 9-2. 백업 보존 기간 예시
테스트 DB:
1일 ~ 3일
소규모 운영 DB:
7일
중요 운영 DB:
14일 ~ 35일- 백업 보존 기간이 길수록 복구 가능성은 좋아지지만 비용도 증가할 수 있습니다.
- 중요한 것은 백업이 있다는 사실보다, 실제로 복구가 가능한지 검증해보는 것입니다.
✅ 10. RDS 스냅샷
- 스냅샷(Snapshot)은 특정 시점의 DB 상태를 저장하는 백업입니다.
- 대규모 배포, 마이그레이션, 데이터 일괄 수정 전에 수동 스냅샷을 남기면 안전합니다.
➕ 10-1. 스냅샷이 필요한 상황
- 운영 DB 마이그레이션 전
- 대량 UPDATE/DELETE 전
- 테이블 구조 변경 전
- 중요한 이벤트 오픈 전
- 외부 API 연동 구조 변경 전
- 데이터 정리 배치 실행 전
➕ 10-2. 스냅샷 운영 기준
1. 작업 전 수동 스냅샷 생성
2. 스냅샷 생성 완료 확인
3. 작업 실행
4. 작업 결과 확인
5. 문제 발생 시 스냅샷 기반 복구 검토- 스냅샷 생성은 시간이 걸릴 수 있습니다.
- 스냅샷이 “생성 중”인지 “완료”인지 확인한 뒤 위험 작업을 진행해야 합니다.
✅ 11. RDS 복구 전략
- DB 장애나 실수 삭제가 발생했을 때는 복구 전략이 중요합니다.
- 백업이 있어도 복구 절차를 모르면 실제 장애 상황에서 시간이 오래 걸립니다.
➕ 11-1. 복구 방식
-
Point-in-Time Recovery
- 자동 백업을 이용해 특정 시점으로 복구합니다.
-
Snapshot Restore
- 스냅샷을 기준으로 새 RDS 인스턴스를 생성합니다.
-
Dump 파일 복구
pg_dump,mysqldump로 만든 SQL 백업 파일을 복구합니다.
➕ 11-2. 복구 시 주의점
- 기존 DB를 바로 덮어쓰는 방식보다 새 RDS로 복구 후 검증하는 것이 안전합니다.
- 복구된 DB의 엔드포인트가 달라질 수 있으므로
DATABASE_URL변경이 필요할 수 있습니다. - 복구 시점 이후에 들어온 데이터는 사라질 수 있습니다.
- 복구 전에 RTO와 RPO를 판단해야 합니다.
RTO:
서비스를 몇 시간 안에 복구해야 하는가?
RPO:
최대 몇 시간 전 데이터까지 손실을 허용할 수 있는가?✅ 12. RDS 모니터링
- RDS는 한 번 만들고 끝나는 것이 아니라 지속적으로 상태를 확인해야 합니다.
- DB가 느려지면 API 전체가 느려지고, 사용자 화면도 느려집니다.
➕ 12-1. 확인해야 할 주요 지표
| 지표 | 의미 |
|---|---|
| CPU 사용률 | DB 서버 연산 부하 |
| Freeable Memory | 사용 가능한 메모리 |
| Database Connections | DB 연결 수 |
| Free Storage Space | 남은 스토리지 |
| Read/Write IOPS | 디스크 읽기/쓰기 작업 |
| Read/Write Latency | 디스크 응답 지연 |
| Deadlocks | 트랜잭션 충돌 |
| Slow Queries | 느린 쿼리 |
➕ 12-2. 위험 신호
CPU가 계속 80% 이상
Free Storage Space가 계속 감소
Connection 수가 급증
특정 API 호출 후 DB 부하 급증
관리자 목록 조회가 점점 느려짐
백업 시간대에 서비스가 느려짐- 이런 신호가 보이면 쿼리, 인덱스, 페이지네이션, 서버 커넥션 풀 설정을 확인해야 합니다.
✅ 13. DB 커넥션 관리
- 백엔드 서버는 DB에 연결해서 쿼리를 실행합니다.
- 요청마다 무제한으로 DB 연결을 만들면 RDS가 버티지 못할 수 있습니다.
➕ 13-1. 커넥션이 문제가 되는 상황
- 트래픽이 갑자기 증가
- 서버 프로세스를 여러 개 실행
- PM2 cluster mode 사용
- Prisma Client를 요청마다 새로 생성
- API마다 DB 쿼리를 과도하게 실행
- DB connection limit 초과
➕ 13-2. Prisma 사용 시 주의점
- Prisma Client는 보통 애플리케이션 전체에서 하나의 인스턴스로 재사용해야 합니다.
- 요청마다
new PrismaClient()를 만들면 커넥션이 과도하게 늘어날 수 있습니다.
// 피해야 할 방식
app.get('/users', async () => {
const prisma = new PrismaClient();
return prisma.user.findMany();
});// 권장 방식
@Injectable()
export class PrismaService extends PrismaClient {
constructor() {
super();
}
}✅ 14. 느린 쿼리와 인덱스
- RDS 성능 문제의 상당수는 쿼리와 인덱스 문제에서 시작됩니다.
- 데이터가 적을 때는 문제가 없어 보이다가, 데이터가 쌓이면 갑자기 느려질 수 있습니다.
➕ 14-1. 느린 쿼리가 생기는 원인
- WHERE 조건 컬럼에 인덱스 없음
- ORDER BY 컬럼에 인덱스 없음
- JOIN 대상 컬럼에 인덱스 없음
- 페이지네이션 없이 전체 조회
%keyword%같은 검색 남발- 불필요하게 많은 컬럼 조회
- N+1 쿼리 발생
➕ 14-2. 실무 예시
SELECT * FROM consults
WHERE phone = '01012345678';- 전화번호 검색을 자주 한다면
phone컬럼 인덱스를 고려할 수 있습니다.
CREATE INDEX idx_consults_phone ON consults(phone);SELECT * FROM consults
ORDER BY createdAt DESC
LIMIT 20;- 최신순 목록 조회가 많다면
createdAt인덱스도 검토할 수 있습니다.
✅ 15. RDS 비용 관리
- RDS는 EC2보다 비용이 더 크게 느껴질 수 있습니다.
- 인스턴스가 실행 중이면 계속 비용이 발생하고, 스토리지와 백업도 비용에 영향을 줍니다.
➕ 15-1. RDS 비용 요소
- DB 인스턴스 실행 시간
- 인스턴스 클래스
- 스토리지 용량
- 스토리지 타입
- 백업 스토리지
- 스냅샷 보관량
- Multi-AZ 사용 여부
- 데이터 전송량
- 읽기 복제본 사용 여부
➕ 15-2. 비용 절약 기준
- 테스트 RDS는 사용하지 않을 때 중지합니다.
- 운영 DB는 무작정 큰 타입으로 시작하지 않습니다.
- 오래된 수동 스냅샷을 정리합니다.
- 백업 보존 기간을 서비스 중요도에 맞게 설정합니다.
- CloudWatch 로그와 Enhanced Monitoring 비용도 확인합니다.
- Multi-AZ는 안정성은 좋아지지만 비용이 증가하므로 서비스 단계에 맞게 판단합니다.
✅ 16. 운영 DB에서 절대 조심해야 할 작업
➕ 16-1. 위험한 SQL
DELETE FROM users;
UPDATE orders SET status = 'DONE';
DROP TABLE consults;
TRUNCATE TABLE logs;- WHERE 없는 UPDATE/DELETE는 운영 사고로 이어질 수 있습니다.
- 테이블 삭제, 초기화, 대량 변경은 반드시 백업과 검토 후 실행해야 합니다.
➕ 16-2. 안전한 작업 습관
- SELECT로 먼저 대상 데이터 확인
- WHERE 조건 명확히 작성
- 영향받는 row 수 예상
- 트랜잭션 사용 가능 여부 확인
- 작업 전 스냅샷 생성
- 작업 쿼리 기록
- 작업 후 결과 검증
-- 1. 먼저 확인
SELECT * FROM consults
WHERE status = 'TEST';
-- 2. 그 다음 삭제
DELETE FROM consults
WHERE status = 'TEST';✅ 17. 실무 체크리스트
➕ 17-1. RDS 생성 체크리스트
- DB 엔진을 프로젝트에 맞게 선택했는가?
- 인스턴스 클래스가 현재 트래픽에 맞는가?
- 스토리지 자동 확장을 고려했는가?
- Public Access를 비활성화했는가?
- 보안 그룹에서 EC2만 접근하도록 제한했는가?
- 자동 백업을 활성화했는가?
- 백업 보존 기간을 설정했는가?
- 운영 DB 비밀번호를 안전하게 저장했는가?
➕ 17-2. 배포 전 DB 체크리스트
- 마이그레이션 파일을 검토했는가?
- 운영 DB 백업 또는 스냅샷을 확인했는가?
npx prisma migrate deploy를 사용할 준비가 되었는가?migrate reset같은 위험 명령어를 사용하지 않는가?- 대량 데이터 변경이 포함되어 있는가?
- 롤백이 가능한 변경인가?
- DB 변경 후 API가 정상 동작하는지 테스트할 계획이 있는가?
➕ 17-3. 운영 중 DB 체크리스트
- CPU와 메모리 사용률을 확인하는가?
- DB 연결 수가 급증하지 않는가?
- 남은 스토리지 용량이 충분한가?
- 느린 쿼리가 반복되지 않는가?
- 백업이 정상적으로 생성되고 있는가?
- 오래된 스냅샷이 비용을 만들고 있지 않은가?
- 운영 DB에 직접 접속할 수 있는 사람이 제한되어 있는가?
- 민감정보가 포함된 덤프 파일을 안전하게 관리하는가?
✅ 18. AI를 활용해 RDS 문제를 해결할 때 질문법
- RDS 문제는 네트워크, 보안 그룹, 환경변수, DB 계정, Prisma, 마이그레이션이 함께 연결됩니다.
- AI에게 질문할 때는 실제 비밀번호는 가리고, 구조와 오류 메시지를 정확히 알려줘야 합니다.
➕ 18-1. 좋은 질문 예시
NestJS + Prisma + AWS RDS PostgreSQL 환경에서 DB 연결 오류가 발생해.
환경:
1. 백엔드는 EC2 Ubuntu에서 PM2로 실행 중
2. DB는 AWS RDS PostgreSQL
3. RDS Public Access는 No
4. EC2와 RDS는 같은 VPC
5. RDS 보안 그룹은 EC2 보안 그룹을 허용하도록 설정했다고 생각함
6. DATABASE_URL은 .env에 설정함
7. PM2 logs에는 Can't reach database server at RDS_ENDPOINT:5432 라고 나옴
실제 비밀번호와 엔드포인트는 가렸어.
확인해야 할 순서와 가능한 원인을 알려줘.
운영 서버에서 실행할 명령어도 같이 설명해줘.➕ 18-2. AI 답변 검증 기준
- 실제 DB 비밀번호를 요구하지 않는가?
- EC2와 RDS의 VPC/보안 그룹을 확인하는가?
- Public Access와 접근 방식의 관계를 설명하는가?
DATABASE_URL형식을 점검하는가?- EC2에서
psql접속 테스트를 안내하는가? - Prisma 마이그레이션 명령어를 운영/개발로 구분하는가?
- 위험한 reset/drop 명령어를 권하지 않는가?
📌 요약
- RDS는 AWS에서 제공하는 관리형 관계형 데이터베이스 서비스입니다.
- EC2 내부 DB보다 비용은 들 수 있지만, 자동 백업, 스냅샷, 모니터링, 운영 안정성 측면에서 장점이 큽니다.
- 운영 DB는 가능하면 Public Access를 비활성화하고, RDS 보안 그룹에서 EC2 보안 그룹만 허용하는 구조가 안전합니다.
- 백엔드 서버는
DATABASE_URL환경변수를 통해 RDS에 연결하며, 이 값은 절대 GitHub에 올리면 안 됩니다. - Prisma를 사용할 때 운영에서는
npx prisma migrate deploy를 사용하고,migrate reset은 운영 DB에서 절대 사용하면 안 됩니다. - RDS 자동 백업과 수동 스냅샷은 운영 DB 보호의 핵심이며, 실제 복구 테스트까지 해봐야 의미가 있습니다.
- DB 성능 문제는 CPU, 메모리, 연결 수, 스토리지, 느린 쿼리, 인덱스 문제를 함께 확인해야 합니다.
- 운영 DB에서 UPDATE, DELETE, DROP 같은 작업은 반드시 SELECT 확인, 백업, 조건 검토 후 진행해야 합니다.
