AWS RDS 완전 정복: 데이터베이스 관리라는 '야간 당직'에서 해방되는 법

들어가며: 새벽 3시의 전화

데이터베이스 관리자(DBA)에게는 공포의 시나리오가 있다.

새벽 3시, 전화가 울린다. "DB 서버가 응답하지 않습니다." 잠이 덜 깬 채로 VPN에 접속하고, SSH로 서버에 들어가고, MySQL 프로세스 목록을 확인한다. 디스크가 꽉 찼다. 로그 파일이 디스크를 다 먹었다. 급하게 로그를 삭제하고, 서비스를 재시작하고, 데이터가 무사한지 확인하고 — 새벽 5시가 되어서야 다시 잠든다.

이것은 과장이 아니라, EC2에 직접 데이터베이스를 설치·운영하는 기업에서 실제로 반복되던 일상이었다.

데이터베이스는 모든 서비스의 심장이다. 웹 서버가 죽어도 재시작하면 되지만, 데이터베이스가 죽으면 데이터가 사라질 수 있다. 그래서 DB 운영은 모든 인프라 운영 중 가장 까다롭고, 가장 스트레스가 높은 영역이다.

"DB 설치·패치·백업·복구·스케일링을 AWS가 대신 해주면 안 되나?"

이 질문에 대한 답이 RDS(Relational Database Service)다.

1. 데이터베이스를 직접 운영한다는 것

EC2에 DB를 올리면 생기는 일

EC2 인스턴스에 MySQL을 직접 설치해서 운영하면, 이런 것들을 전부 직접 해야 한다:

핵심 문제: DBA의 시간 대부분이 **"데이터를 안전하게 지키는 것"**에 쓰이고, 정작 **"데이터를 활용하는 것"**에 쓸 시간이 부족하다.

데이터베이스 장애의 공포

2017년 1월, GitLab에서 벌어진 유명한 사고를 보자. 한 엔지니어가 DB 복제 문제를 해결하려다 프로덕션 데이터베이스를 실수로 삭제했다. 6시간 분량의 데이터가 사라졌다. 5가지 백업 방법 중 제대로 작동하는 것이 하나도 없었다. GitLab은 이 사고를 투명하게 공개하며 라이브 스트리밍으로 복구 과정을 보여줬는데, 전 세계 개발자 커뮤니티에 "백업은 복원 테스트를 해야 의미가 있다"는 교훈을 남겼다.

2. RDS의 탄생: "관리형"이라는 혁명

2009년: AWS RDS 출시

2009년 10월, AWS는 RDS(Relational Database Service)를 출시했다. 처음에는 MySQL만 지원했다. 핵심 약속:

"데이터베이스 엔진의 설치, 패치, 백업, 복구, 스케일링을 AWS가 대신 한다. 당신은 데이터와 쿼리에만 집중하라."

RDS가 자동으로 하는 것

지원 엔진: 6가지 DB 엔진

3. RDS의 핵심 기능

Multi-AZ: 자동 장애 복구

RDS의 가장 중요한 기능. Multi-AZ를 활성화하면 RDS는 다른 가용 영역(AZ)에 동기식 대기(Standby) 복제본을 자동으로 유지한다.

Primary 인스턴스에 장애가 발생하면:

1. RDS가 자동으로 장애를 감지 (수 초)
2. DNS 레코드를 Standby로 변경
3. Standby가 새로운 Primary로 승격
4. 총 페일오버 시간: 60초 이내
5. 애플리케이션은 같은 엔드포인트를 사용하므로 코드 변경 불필요

EC2에서 이것을 구현하면? Keepalived, HAProxy, Pacemaker 같은 도구를 설치하고 설정하고 테스트하는 데 며칠~수 주가 걸린다. RDS에서는 체크박스 하나.

읽기 복제본 (Read Replicas)

트래픽이 증가하면 DB가 병목이 된다. 특히 읽기 쿼리가 대부분인 서비스에서.

RDS Read Replica는 Primary의 데이터를 비동기적으로 복제하는 읽기 전용 인스턴스다:

• 최대 15개의 Read Replica 생성 가능 (Aurora)
• 읽기 쿼리를 Replica로 분산하여 Primary 부하 감소
• 다른 리전에 Cross-Region Replica 생성 가능 (글로벌 서비스)

# 애플리케이션에서의 읽기/쓰기 분리 패턴
import sqlalchemy

# 쓰기는 Primary로
write_engine = sqlalchemy.create_engine("mysql://primary-endpoint:3306/mydb")

# 읽기는 Replica로
read_engine = sqlalchemy.create_engine("mysql://replica-endpoint:3306/mydb")

자동 백업과 시점 복구

RDS는 매일 자동으로 DB 스냅샷을 생성하고, 트랜잭션 로그를 5분 간격으로 S3에 저장한다.

시점 복구(Point-in-Time Recovery, PITR): 지난 35일 이내의 아무 시점으로 DB를 복원할 수 있다. "오늘 오후 2시 35분 22초의 DB 상태로 돌려줘"가 가능하다.

Performance Insights

2018년 도입된 RDS의 성능 분석 도구. DB의 병목이 어디인지 시각적으로 보여준다:

• 어떤 쿼리가 가장 많은 자원을 소비하는가
• 어떤 대기 이벤트가 성능을 저하시키는가
• 시간대별 부하 패턴은 어떠한가

별도의 모니터링 도구(Datadog, New Relic)를 설치하지 않아도 상당한 수준의 성능 분석이 가능하다.

4. Aurora: 관계형 데이터베이스의 "재발명"

"클라우드를 위해 설계된" 데이터베이스

2014년 AWS re:Invent에서 발표된 Amazon Aurora는 RDS의 가장 혁신적인 엔진이다. AWS VP Anurag Gupta가 발표하며 사용한 표현: "클라우드를 위해 관계형 데이터베이스를 재발명했다(reinvented)."

기존 MySQL/PostgreSQL을 그대로 클라우드에 올린 것이 아니라, 스토리지 레이어를 완전히 새로 설계했다.

Aurora의 핵심 혁신: 스토리지와 컴퓨팅의 분리

전통적 DB에서는 데이터가 DB 서버의 로컬 디스크에 저장된다. Aurora는 이것을 뒤집었다:

Aurora의 스토리지는:

• 3개 AZ에 걸쳐 6개 복제본 자동 유지
• 6개 중 4개만 쓰기 가능하면 쓰기 성공 (쿼럼 기반)
• 6개 중 3개만 읽기 가능하면 읽기 성공
• 최대 128TB까지 자동 확장 (용량 계획 불필요)
• 10GB 단위로 자동 증가, 축소는 없지만 비용은 사용량 기준

Aurora의 성능

AWS가 발표한 벤치마크:

Aurora Serverless: DB도 서버리스로

2018년 출시된 Aurora Serverless는 서버리스 개념을 DB에 적용한 것이다:

• 트래픽이 없으면 자동으로 일시 중지 (비용 0원)
• 트래픽이 오면 자동으로 깨어남 (수 초)
• 부하에 따라 컴퓨팅 용량 자동 조절 (ACU 단위)

개발/테스트 환경, 트래픽이 불규칙한 서비스에 이상적이다.

5. DB 보안: 글로벌 사고에서 배우기

데이터베이스는 공격자의 최종 목표

해커가 웹 서버를 장악하는 것은 수단이다. 진짜 목표는 데이터베이스에 있는 데이터다 — 사용자 정보, 결제 데이터, 비즈니스 기밀.

주요 DB 보안 사고

RDS 보안 모범 사례

1. 네트워크 격리: RDS 인스턴스를 프라이빗 서브넷에 배치. 인터넷에서 직접 접근 불가. 애플리케이션만 접근 가능.

2. 암호화:

• 전송 중 암호화: SSL/TLS 강제. require_secure_transport=ON
• 저장 시 암호화: AES-256 암호화. RDS 생성 시 활성화하면 스냅샷, 로그, 복제본 모두 자동 암호화

3. IAM 인증: 전통적 사용자/비밀번호 대신 IAM 토큰으로 DB 인증. 비밀번호 관리와 회전이 불필요해진다.

4. Secrets Manager 연동: DB 비밀번호를 코드에 하드코딩하지 말고, Secrets Manager에 저장하고 자동 회전 설정.

6. RDS 비용 구조와 최적화

비용 구성 요소

비용 최적화 전략

1. Reserved Instances: 1~3년 약정으로 최대 60% 할인. 프로덕션 DB처럼 장기 운영하는 인스턴스에 필수.

2. 적정 사이즈: CloudWatch와 Performance Insights로 실제 CPU/메모리 사용률을 확인. 과도한 인스턴스는 한 단계 낮추기.

3. 개발/테스트 환경: Aurora Serverless 사용 → 업무 시간 외에 자동 일시 중지. 또는 스케줄로 인스턴스를 중지/시작.

4. Graviton 인스턴스: ARM 기반 db.r7g, db.m7g 클래스는 x86 대비 20% 저렴하면서 동등 이상의 성능.

7. RDS vs Aurora vs 자체 운영: 선택 가이드

8. 실제 사례

Airbnb: PostgreSQL → Aurora 마이그레이션

Airbnb는 자체 관리 PostgreSQL에서 Aurora PostgreSQL로 마이그레이션했다. 결과:

• DB 관리 운영 부담 대폭 감소
• 읽기 성능 3배 향상 (Aurora Read Replica 활용)
• 페일오버 시간 수 분 → 30초

Samsung: 글로벌 IoT 플랫폼

Samsung SmartThings는 전 세계 수억 대의 IoT 기기 데이터를 Aurora에 저장한다. 글로벌 Aurora로 여러 리전에서 저지연 읽기를 제공한다.

Duolingo: Aurora Serverless로 비용 최적화

언어 학습 앱 Duolingo는 부하가 시간대별로 크게 변동한다. Aurora Serverless v2를 사용하여 새벽에는 최소 용량, 피크 타임에는 자동 확장하여 비용을 40% 절감했다.

한국 기업 사례

• 쿠팡: 대규모 트랜잭션 처리에 Aurora MySQL 사용. Read Replica로 상품 조회 분산
• 토스: 금융 데이터의 높은 가용성 요구에 Aurora PostgreSQL + Multi-AZ
• 당근마켓: RDS PostgreSQL로 시작, 트래픽 증가에 따라 Aurora로 마이그레이션

9. RDS의 미래: AI 시대의 데이터베이스

Aurora DSQL: 분산 SQL의 등장 (2024 프리뷰)

2024년 re:Invent에서 발표된 Aurora DSQL은 여러 리전에 걸쳐 강력한 일관성을 가진 분산 SQL 데이터베이스다. Google Spanner에 대한 AWS의 대답으로, 글로벌 서비스에 단일 DB 엔드포인트를 제공한다.

AI와 DB의 융합

• Aurora ML: SQL 쿼리 안에서 SageMaker ML 모델을 호출. SELECT predict_sentiment(review_text) FROM reviews
• pgvector: PostgreSQL 확장으로 벡터 검색 지원. AI 임베딩 저장과 유사도 검색에 사용
• RDS 성능 자동 튜닝: AI가 쿼리 패턴을 분석하고 인덱스·파라미터를 자동 추천

마치며: 데이터베이스는 "관리"가 아니라 "활용"의 대상이다

RDS의 핵심 가치는 이렇다:

DBA의 시간을 "DB를 살아있게 유지하는 것"에서 "데이터를 활용하는 것"으로 전환시킨 것.

패치를 적용하고, 백업을 확인하고, 디스크를 확장하고, 장애에 대응하는 — 이런 "유지보수"는 가치를 만들지 않는다. 하지만 데이터 모델을 설계하고, 쿼리를 최적화하고, 데이터에서 인사이트를 추출하는 것은 비즈니스 가치를 직접 만든다.

RDS(그리고 Aurora)가 전자를 대신 해줌으로써, DB 전문가는 후자에 집중할 수 있게 됐다. 이것이 "관리형"의 진짜 의미다 — 관리를 없앤 것이 아니라, 관리의 주체를 바꾼 것이다.

코어닷투데이의 AI 서비스에서도 데이터베이스는 핵심이다. AI 모델의 메타데이터, 사용자 데이터, 추론 결과 — 이 모든 것이 Aurora PostgreSQL에 안전하게 저장되고, pgvector로 벡터 검색이 수행되며, Multi-AZ로 데이터가 보호된다. 새벽 3시에 전화가 울리는 대신, DB가 조용히 자기 할 일을 한다.