07/10 — 데이터베이스 모델·용량·캐시
이 구간은 데이터 모델과 접근 패턴 → 실제 병목 → 확장·캐시 수단 순서로 선택을 연결한다.
1. 단순 정의
- 관계형 데이터베이스: 관계, 조인, 제약 조건, SQL 트랜잭션을 중심으로 데이터를 다룬다. RDS와 Aurora가 대표적이다.
- DynamoDB: 키-값·문서 모델의 서버리스 NoSQL DB다. 미리 정한 키 접근 경로의 대규모 처리에 맞는다.
- 접근 패턴: 어떤 키로 어떤 항목을 한 건·범위·정렬 순서로 읽을지에 대한 실제 조회 경로다. DynamoDB에서는 데이터 모양보다 먼저 정한다.
- 읽기 복제본: RDS Read Replica는 원본 변경을 비동기로 반영하는 읽기 인스턴스다. Aurora reader endpoint는 공유 클러스터 스토리지를 읽는 Aurora Replica에 새 연결을 분산한다.
- RDS Proxy: 많은 애플리케이션 연결을 더 적은 DB 연결로 풀링·다중화한다. 쿼리 결과 캐시는 아니다.
- 캐시: 반복 조회 결과를 메모리에서 재사용한다. DAX는 DynamoDB 전용, ElastiCache는 범용이며 최신성·갱신 규칙을 함께 정한다.
2. 결정 축과 관계
첫 번째 축은 데이터 관계와 조회 방식이다. 조인, 참조 무결성, 다중 행 트랜잭션, 유연한 SQL이 중심이면 RDS/Aurora를 고른다. 관계형 모델을 유지하면서 수요가 변하면 Aurora Serverless v2의 ACU 범위 안에서 조정한다. 알려진 키로 독립 항목을 대규모·저지연 처리하면 DynamoDB가 맞다. AWS 데이터베이스 선택
DynamoDB는 주 접근 경로를 기본 키에 새긴다. partition key는 활동을 분산시키고, sort key는 같은 partition의 항목을 정렬·범위 조회한다. 다른 조회 키는 GSI로 만들되 비동기 갱신, eventual read, 투영 속성과 쓰기 용량을 고려한다. TTL은 항목별 수명을 선언해 비동기로 정리한다. 정확한 시각의 업무 동작은 별도 스케줄·이벤트로 처리한다. DynamoDB 키 설계, GSI, TTL
두 번째 축은 용량 변동의 예측 가능성이다. 신규·불규칙 워크로드는 DynamoDB on-demand로 요청당 지불한다. 안정적·주기적이면 provisioned capacity와 Auto Scaling을 쓴다. Auto Scaling은 관측 사용률을 따라 조정하므로 순간 급증은 on-demand나 사전 여유 용량으로 받는다. DynamoDB 용량 모드
세 번째 축은 관계형 DB의 병목 종류다. 읽기 SQL을 더 실행해야 하면 RDS read replica나 Aurora reader를 쓴다. reader endpoint는 쿼리가 아니라 새 연결을 분산한다. Lambda의 짧은 연결이 급증하면 RDS Proxy, 동일 결과의 반복 계산을 줄이면 ElastiCache다. 읽기 실행 용량, 연결 수, 반복 결과는 서로 다른 병목이다. RDS 읽기 복제본, RDS Proxy
마지막 축은 캐시 대상과 최신성 계약이다. 반복되는 DynamoDB eventual read는 API 호환 DAX로 가속한다. strong·transactional read는 캐시되지 않는다. 관계형 결과·세션·범용 객체는 ElastiCache에 두고 애플리케이션이 cache-aside·write-through, TTL, 무효화를 정한다. DAX 적합성, ElastiCache 엔진
3. 아키텍처 적용
사례 A — 연결 급증과 읽기가 많은 관계형 API
쓰기는 Lambda/ECS → RDS Proxy 기본 endpoint → Aurora writer, 읽기는 RDS Proxy read-only endpoint → Aurora Replica로 보낸다. Proxy는 연결 폭주, replica는 읽기 SQL을 담당한다.
사례 B — 키 중심의 대규모 상태 저장
API Gateway/Lambda → DynamoDB에서 사용자·테넌트처럼 분산되는 partition key와 시간·항목 종류의 sort key로 주 조회를 만든다. 상태·카테고리 조회는 GSI, 세션·임시 레코드는 TTL, 예측하기 어려운 초기 트래픽은 on-demand로 연결한다. 인기 항목의 반복 eventual read가 병목일 때만 DAX를 추가한다.
사례 C — 관계형 조회 결과의 cache-aside
애플리케이션이 ElastiCache를 먼저 확인하고 miss일 때 Aurora/RDS를 조회해 TTL과 함께 채운다. 쓰기는 DB 성공 후 관련 키를 무효화하거나 갱신한다. DB를 기준 원본으로 두고 허용 최신성과 cache miss 부하를 정한다.
4. 정답 구조
- 관계·조인·트랜잭션·SQL → RDS/Aurora → 관계형 모델
- 확정된 키 접근·대규모 처리 → DynamoDB → partition key 분산
- 같은 partition의 정렬·범위 조회 → sort key → 관련 항목을 함께 배치
- 다른 DynamoDB 조회 축 → GSI → 대체 partition/sort key의 비동기 인덱스
- 항목별 보존 기간 → DynamoDB TTL → 만료 항목의 비동기 정리
- 예측하기 어려운 요청량 → on-demand → 요청당 과금
- 예측 가능한 처리량 → provisioned + Auto Scaling → 목표 사용률에 맞춘 RCU/WCU 조정
- 관계형 읽기 실행 분산 → read replica/reader endpoint → 읽기 쿼리 처리
- 서버리스 연결 급증 → RDS Proxy → 연결 풀링·다중화
- 반복 DynamoDB eventual read → DAX → DynamoDB API 호환 인메모리 캐시
- 관계형 결과·세션·범용 객체 → ElastiCache → 애플리케이션이 관리하는 범용 캐시
5. 긍정형 암기표
| 요구사항의 중심 | 올바른 연결 |
|---|---|
| 조인·제약·다중 행 트랜잭션 | RDS/Aurora |
| 알려진 키로 대규모 저지연 접근 | DynamoDB |
| 기본 키와 다른 조회 경로 | GSI |
| 임시 항목의 수명 주기 정리 | DynamoDB TTL |
| 불규칙·예측 곤란한 요청량 | DynamoDB on-demand |
| 안정적·예측 가능한 처리량 | provisioned + Auto Scaling |
| 관계형 읽기 SQL 분산 | read replica/Aurora reader |
| Lambda의 짧고 많은 DB 연결 | RDS Proxy |
| 반복되는 DynamoDB eventual read | DAX |
| 관계형 결과·세션·범용 캐시 | ElastiCache |
다음: 08/10 — 실행 모델·확장 신호·과금 단위. 작업 시간, 패키징, 상태, 확장 신호와 실제 과금 단위를 연결한다.