---
type: knowledge
domain: aws
status: active
last-reviewed: 2026-07-12
tags:
  - aws
  - database
  - cache
---

# 데이터베이스와 캐시

> 한 줄 정의
> 익숙한 엔진이 아니라 데이터 모델, 접근 패턴, 일관성, 지연, 확장, 복구 요구로 목적별 데이터베이스를 선택한다.

## 서비스 선택

| 모델 | 서비스 | 맞는 경우 |
|---|---|---|
| 관계형 | RDS | PostgreSQL·MySQL·MariaDB·Oracle·SQL Server·Db2 관리형 |
| 클라우드 관계형 | Aurora | MySQL/PostgreSQL 호환, 분리형 스토리지·고가용성 |
| 분산 SQL | Aurora DSQL | 지원 범위와 일관성 특성이 요구에 맞는 신규 분산 앱 |
| Key-value/document | DynamoDB | 알려진 접근 패턴, 대규모 저지연, 서버리스 |
| Document | DocumentDB | MongoDB 호환 요구. 기능 호환성 사전 검증 |
| Graph | Neptune | 관계 탐색, 지식 그래프, 사기 탐지 |
| Wide-column | Keyspaces | Cassandra 호환 |
| Time series | Timestream for InfluxDB | 신규 시계열 워크로드 후보. InfluxDB 호환성과 운영 모델 검증 |
| Time series (기존 고객) | Timestream for LiveAnalytics | 2025-06-20부터 신규 고객 접근 종료. 기존 워크로드만 유지·이전 계획 검토 |
| Cache | ElastiCache | 캐시·세션·rate limit |
| Durable in-memory | MemoryDB | Valkey 호환, 내구성 있는 인메모리 DB |
| Search | OpenSearch Service | 전문 검색·로그 분석·벡터 검색 |
| Warehouse | Redshift | 대규모 OLAP·BI |

## RDS·Aurora 운영

| 구성 | 고가용성 | 읽기 처리 | 핵심 용도 |
|---|---|---|---|
| RDS Multi-AZ DB instance | 1개 비가독 standby로 자동 failover | standby 읽기 불가 | 전통적인 RDS HA |
| RDS Multi-AZ DB cluster | 2개 readable standby로 자동 failover | reader endpoint로 읽기 분산 | HA + 읽기 처리 |
| RDS read replica | 승격 가능하지만 자동 HA standby와 목적이 다름 | 읽기 확장 | 읽기 부하·일부 DR |
| Aurora Replica | writer 장애 시 failover target | reader endpoint로 읽기 확장 | Aurora HA + 읽기 처리 |

- “Multi-AZ=HA, read replica=읽기”라는 단순 암기 대신 배포 형태별 endpoint, 복제 방식, failover, replica lag를 확인한다.
- 자동 백업 보존, PITR, 수동 스냅샷, 교차 계정/리전 복사 정책을 정한다.
- 애플리케이션 연결 풀을 제한하고 Lambda 대량 연결에는 RDS Proxy를 검토한다.
- 파라미터 그룹, 유지보수 창, minor version 정책, Performance Insights/Database Insights를 관리한다.
- 스키마 변경은 [[배포 전략 실전]]의 expand-contract로 수행한다.
- DB subnet group과 SG로 사설 접근만 허용하고 공개 접근은 예외 승인한다.

## DynamoDB 데이터 모델

1. 화면과 API의 **접근 패턴**을 먼저 목록화한다.
2. partition key는 트래픽을 고르게 분산하고, sort key는 범위·정렬·계층을 표현한다.
3. GSI는 새 접근 패턴을 위한 별도 인덱스이며 쓰기·저장 비용을 만든다.
4. hot partition, 큰 item, scan, 저선택도 인덱스를 피한다.
5. 조건부 쓰기, transaction, idempotency, TTL, Streams를 목적에 맞게 쓴다.
6. On-demand와 provisioned capacity는 트래픽 예측성과 비용으로 선택한다.
7. PITR, backup, global tables의 일관성과 충돌 모델을 확인한다.

## 캐시 원칙

- 캐시는 진실의 원천이 아니며 삭제되어도 정합성이 복구돼야 한다.
- cache-aside가 기본: miss → DB 조회 → TTL과 함께 저장.
- TTL jitter로 동시 만료를 분산하고 cache stampede를 lock·single-flight로 막는다.
- eviction, failover, replication lag, hot key를 관측한다.
- 민감 데이터의 캐시 암호화와 인증을 설정한다.

> [!WARNING] 목적별 DB의 대가
> 데이터베이스 종류가 늘면 복제·트랜잭션·백업·관측·인력 비용도 늘어난다. 한 저장소로 요구를 충분히 충족하면 분리하지 않는다.

## 공식 문서

- [Choosing an AWS database service](https://docs.aws.amazon.com/databases-on-aws-how-to-choose/)
- [Amazon RDS](https://docs.aws.amazon.com/rds/)
- [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html)
- [RDS Multi-AZ deployments](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
- [Amazon DynamoDB](https://docs.aws.amazon.com/dynamodb/)
- [Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/)
- [Timestream for LiveAnalytics availability change](https://docs.aws.amazon.com/timestream/latest/developerguide/AmazonTimestreamForLiveAnalytics-availability-change.html)

## 관련 문서

- [[06_스토리지]] · [[08_메시징과 애플리케이션 통합]] · [[12_신뢰성과 재해 복구]]