데이터베이스 선택 기준

데이터 모델과 접근 패턴에 따라 알맞은 AWS 데이터베이스 서비스를 고르는 흐름

데이터베이스 선택은 데이터 모델과 접근 패턴에서 시작한다. 트랜잭션과 SQL이 필요한지, 키로 빠르게 조회하는지, 데이터 분석 쿼리가 중심인지에 따라 후보가 달라진다. 서비스 이름을 먼저 고르기보다 쓰기·읽기 패턴, 지연 목표, 운영 부담을 차례로 확인한다.

1. AWS 데이터베이스 서비스 전체 지도

관계형(SQL)
  ├── RDS          — 기존 엔진 리프트&시프트 (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB)
  └── Aurora       — AWS 재설계 고성능 관계형 DB

NoSQL / 특수 목적
  ├── DynamoDB     — 서버리스 key-value / document, 밀리초 지연
  ├── ElastiCache  — 인메모리 캐시 (Redis / Memcached)
  ├── MemoryDB     — Redis 호환 + 내구성 (영속 저장 가능)
  └── DocumentDB   — MongoDB 호환 document DB

분석 / 데이터 웨어하우스
  ├── Redshift     — 페타바이트급 OLAP, columnar
  ├── Athena       — S3 위 SQL (서버리스)
  └── OpenSearch   — 검색 / 로그 분석

그래프 / 시계열 / 원장
  ├── Neptune      — 그래프 DB
  ├── Timestream   — 시계열 DB
  └── QLDB         — 불변 원장 DB

2. RDS (Relational Database Service)

핵심 개념

RDS는 EC2 위에서 실행되는 관리형 관계형 DB다. OS 패치, 백업, 복제를 AWS가 대신 처리한다.

항목 내용
지원 엔진 MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2
배포 옵션 Single-AZ / Multi-AZ / Multi-AZ DB Cluster
스토리지 gp2, gp3, io1, io2 (EBS 기반)
최대 스토리지 64TB (io1/io2), 16TB (gp)
읽기 확장 Read Replica 최대 5개 (MySQL/PostgreSQL은 최대 15개)

Multi-AZ vs Read Replica

구분 Multi-AZ Read Replica
목적 고가용성 (HA) 읽기 성능 향상
동기 방식 동기 복제 비동기 복제
엔드포인트 단일 DNS (자동 페일오버) 별도 엔드포인트
다른 리전 가능 불가 가능 (Cross-Region)
쓰기 가능 스탠바이 불가 불가 (읽기 전용)
승격 자동 페일오버 수동 승격 가능

SAP 핵심: HA = Multi-AZ, 성능 = Read Replica. 둘을 함께 써도 된다.

RDS Proxy

Lambda나 짧은 수명의 클라이언트가 DB에 직접 연결하면 커넥션 풀이 폭발한다. RDS Proxy는 커넥션 풀링을 대신 처리해 DB 부하를 줄인다.

  • Lambda → RDS 패턴에서 필수 고려
  • IAM 인증 지원
  • 페일오버 시간 66% 단축

RDS 백업

  • 자동 백업: 매일 스냅샷 + 트랜잭션 로그 → 최대 35일 보존, 특정 시점 복구(PITR) 가능
  • 수동 스냅샷: 보존 기간 무제한, 계정 간 공유 가능

3. Aurora

Aurora가 RDS와 다른 이유

Aurora는 AWS가 클라우드 환경에 맞게 새로 설계한 관계형 DB다. MySQL·PostgreSQL과 호환되지만 내부 아키텍처가 완전히 다르다.

                ┌─────────────┐
   Write        │  Primary DB │
   (AZ-a)       │  Instance   │
                └──────┬──────┘
                       │ 공유 스토리지 볼륨
          ┌────────────┼────────────┐
     AZ-a │       AZ-b │       AZ-c │
    Copy1,2│      Copy3,4│      Copy5,6│

스토리지가 3 AZ에 걸쳐 6개 사본 으로 자동 복제된다. 인스턴스가 스토리지를 소유하지 않기 때문에 Read Replica를 추가해도 스토리지 복사가 일어나지 않는다.

Aurora vs RDS 비교

항목 RDS Aurora
스토리지 복제 EBS 단일 볼륨 3 AZ × 2 = 6사본
Read Replica 최대 5~15개 최대 15개
페일오버 시간 약 60~120초 약 30초 미만
스토리지 자동 증가 수동 설정 10GB 단위 자동 (최대 128TB)
비용 표준 RDS 대비 약 20% 높음
쓰기 처리량 표준 MySQL 대비 최대 5배

Aurora 주요 기능

Aurora Serverless v2

  • 트래픽에 따라 0.5 ACU 단위로 자동 스케일 업/다운
  • 예측 불가능한 부하, 개발/테스트 환경에 적합
  • v1은 콜드 스타트 있음, v2는 즉시 스케일

Aurora Global Database

  • 최대 5개 보조 리전
  • 보조 리전 복제 지연 < 1초
  • 재해 복구 시 보조 리전을 Primary로 승격 (RPO < 1초, RTO < 1분)

Aurora Multi-Master

  • 모든 인스턴스가 쓰기 가능
  • 단, 충돌 해결은 애플리케이션 책임

SAP 핵심: 글로벌 DR = Aurora Global Database, 서버리스 = Aurora Serverless v2

4. DynamoDB

핵심 특성

DynamoDB는 완전 관리형 서버리스 NoSQL DB다. 스키마가 없고, 수평 확장이 무한에 가깝다.

항목 내용
데이터 모델 Key-Value + Document (JSON)
지연 시간 한 자릿수 밀리초
스케일 페타바이트, 초당 수백만 요청
내구성 3 AZ 자동 복제
서버 관리 불필요

기본 구조

테이블
  └── 아이템 (행)
        └── 속성 (열, 동적 스키마)

기본키 구성:
  - Partition Key (PK) 단독
  - Partition Key + Sort Key (복합키)

용량 모드

구분 On-Demand Provisioned
설정 불필요 RCU/WCU 직접 설정
비용 요청당 과금 프로비저닝량 기반
적합 예측 불가한 트래픽 일정한 트래픽
Auto Scaling 해당 없음 지원

RCU = 1 강한 일관성 읽기 또는 2 최종 일관성 읽기 (4KB 단위) WCU = 1 쓰기 (1KB 단위)

DynamoDB 주요 기능

DynamoDB Accelerator (DAX)

  • DynamoDB 전용 인메모리 캐시
  • 읽기 지연을 밀리초 → 마이크로초로 단축
  • 애플리케이션 코드 변경 최소화 (SDK 호환)

DynamoDB Streams

  • 테이블 변경 이벤트를 스트림으로 발행
  • Lambda와 조합해 이벤트 기반 아키텍처 구현
  • 변경 후 24시간 보존

Global Tables

  • 다중 리전 복제 (Active-Active)
  • 어느 리전에서든 읽기/쓰기 가능
  • 리전 간 지연 < 1초 목표

TTL (Time To Live)

  • 아이템에 만료 시각 속성 설정
  • 만료된 아이템 자동 삭제 (비용 무료)
  • 세션 데이터, 임시 토큰에 유용

DynamoDB 일관성 모델

구분 최종 일관성 강한 일관성
기본값 O X
비용 표준 RCU 2배 소비
사용 대부분의 읽기 금융, 재고 등

5. ElastiCache

Redis vs Memcached

항목 Redis Memcached
데이터 구조 String, List, Set, Hash, ZSet 등 String만
영속성 AOF/RDB 지원 없음
복제 지원 (Multi-AZ) 없음
클러스터 지원 지원
Pub/Sub 지원 없음
순위판 ZSet으로 구현 불가

SAP 핵심: 기능이 필요하다면 Redis, 단순 캐시만 필요하다면 Memcached

ElastiCache 패턴

Lazy Loading (Cache-Aside)

1. 앱 → 캐시 조회
2. 캐시 미스 → DB 조회
3. DB 결과를 캐시에 저장
4. 앱에 반환
  • 캐시에 실제 사용된 데이터만 저장
  • 캐시 미스 시 3번의 왕복 발생

Write-Through

1. 앱 → DB 쓰기
2. 동시에 캐시에도 쓰기
  • 캐시가 항상 최신 상태
  • 쓰기 레이턴시 증가

MemoryDB for Redis

  • Redis 호환 + 내구성 있는 데이터 저장
  • 트랜잭션 로그를 Multi-AZ에 기록
  • ElastiCache Redis가 캐시 계층이라면, MemoryDB는 주 데이터베이스로 사용 가능
  • 마이크로초 읽기, 한 자릿수 밀리초 쓰기

6. Redshift

OLTP vs OLAP

구분 OLTP OLAP
대표 서비스 RDS, Aurora, DynamoDB Redshift
쿼리 특성 짧고 빈번한 트랜잭션 복잡한 집계, 분석
데이터 크기 GB ~ TB TB ~ PB
스토리지 방식 Row-based Columnar

Redshift는 컬럼형 스토리지를 사용해 집계 쿼리를 매우 빠르게 처리한다.

주요 특성

항목 내용
노드 타입 RA3 (스토리지 분리), DC2 (로컬 SSD)
최대 규모 페타바이트급
인터페이스 PostgreSQL 호환 SQL
병렬 처리 MPP (Massively Parallel Processing)

Redshift 주요 기능

Redshift Spectrum

  • Redshift 클러스터에서 S3 데이터를 직접 쿼리
  • S3에 데이터를 두고 필요할 때만 조회 (비용 절감)

Redshift Serverless

  • 클러스터 관리 불필요
  • 자동 스케일, 사용량 기반 과금

AQUA (Advanced Query Accelerator)

  • 하드웨어 기반 쿼리 가속
  • RA3 노드에서 자동 활성화

7. SAP 시나리오별 DB 선택 가이드

시나리오 패턴 정리

패턴 1: 기존 관계형 DB 마이그레이션

Oracle/SQL Server → RDS (같은 엔진) 또는 Aurora (MySQL/PostgreSQL 호환으로 전환)

패턴 2: 글로벌 서비스, 낮은 지연 필요

단일 리전 → Aurora Global Database Active-Active 필요 → DynamoDB Global Tables

패턴 3: 예측 불가한 트래픽, 서버리스 아키텍처

관계형 필요 → Aurora Serverless v2 NoSQL 가능 → DynamoDB On-Demand

패턴 4: 세션 저장소, 리더보드, 실시간 캐시

ElastiCache Redis 순위판(Leaderboard) → Redis Sorted Set

패턴 5: Lambda + DB 연결 시 커넥션 폭발

RDS Proxy 필수

패턴 6: 수백만 req/s, 밀리초 미만 응답

DynamoDB + DAX

패턴 7: 데이터 분석, BI 대시보드, 로그 집계

Redshift (페타바이트 분석) Athena (S3 위 서버리스 SQL, 간단한 분석)

패턴 8: IoT 시계열 데이터

Timestream

패턴 9: SNS/MongoDB처럼 유연한 문서 저장

DocumentDB (MongoDB 호환)

패턴 10: 소셜 그래프, 추천 엔진

Neptune (그래프 DB)

빠른 판단 체크리스트

SQL이 필요한가?
  Y → 기존 엔진 유지해야 하나?
        Y → RDS
        N → Aurora (성능/HA 더 좋음)
  N → 얼마나 빠른 응답이 필요한가?
        마이크로초 → DynamoDB + DAX
        밀리초      → DynamoDB
        분석/집계   → Redshift or Athena
        캐시        → ElastiCache Redis

글로벌 복제가 필요한가?
  관계형 → Aurora Global Database
  NoSQL  → DynamoDB Global Tables

서버리스여야 하나?
  관계형 → Aurora Serverless v2
  NoSQL  → DynamoDB On-Demand
  분석   → Athena / Redshift Serverless

8. 데이터베이스 마이그레이션

AWS DMS (Database Migration Service)

  • 이기종 DB 마이그레이션 도구
  • CDC(Change Data Capture) 로 무중단 마이그레이션 가능
  • 소스 → DMS 복제 인스턴스 → 타겟
온프레미스 Oracle
  → DMS (Full Load + CDC)
    → Aurora PostgreSQL

SCT (Schema Conversion Tool)

  • 스키마, 저장 프로시저, 함수를 타겟 DB에 맞게 자동 변환
  • DMS 전에 SCT로 스키마 먼저 변환

9. 핵심 암기 포인트

키워드 선택
고가용성 (HA) Multi-AZ
읽기 성능 향상 Read Replica
글로벌 DR < 1초 Aurora Global Database
Active-Active 글로벌 DynamoDB Global Tables
Lambda + DB 커넥션 RDS Proxy
밀리초 미만 캐시 DAX (DynamoDB), ElastiCache
페타바이트 분석 Redshift
서버리스 SQL Aurora Serverless v2
이벤트 기반 DB 변경 DynamoDB Streams + Lambda
TTL 자동 삭제 DynamoDB TTL
세션/리더보드/Pub-Sub ElastiCache Redis
MongoDB 호환 DocumentDB
그래프 Neptune
시계열 Timestream

마무리

이번 포스트에서 다룬 내용을 한 줄로 요약하면:

  • 관계형 + HA → Aurora (또는 RDS Multi-AZ)
  • 글로벌 + 낮은 지연 → Aurora Global / DynamoDB Global Tables
  • 서버리스 + 예측 불가 트래픽 → Aurora Serverless v2 / DynamoDB On-Demand
  • 캐시 → ElastiCache Redis
  • 분석 → Redshift
  • NoSQL 밀리초 → DynamoDB

이어 읽기: 07. S3·EBS·EFS·FSx 스토리지 선택