Hook

데이터베이스는 애플리케이션의 심장이고, 캐시는 그 심장에 가해지는 부하를 줄여주는 완충재입니다. AWS는 이 두 영역 모두에서 관리형 서비스를 제공하여, 인프라 운영이 아닌 데이터 모델링과 쿼리 최적화에 집중할 수 있게 합니다.

이 글에서는 Part 1에서 RDS/Aurora의 고가용성 아키텍처, 보안, 백업, 모니터링, RDS Proxy, 비용 최적화를 다루고, Part 2에서 ElastiCache의 Memcached vs Redis 비교와 캐싱 전략(Lazy Loading, Write-Through, TTL)을 정리합니다.

TL;DR

• RDS Multi-AZ는 DR용, Read Replica는 성능용 — 동기 복제와 비동기 복제의 목적이 다릅니다
• Aurora는 스토리지-컴퓨팅 분리 — 6개 복사본(3AZ) 분산 스토리지로 MySQL 대비 최대 5배 처리량
• RDS Proxy로 Lambda 커넥션 병목 해소 — 수천 개의 동시 연결을 풀링합니다
• Redis가 Memcached보다 기능이 압도적 — 복제, 장애조치, 영속성, 다양한 데이터 구조
• Lazy Loading + TTL 조합이 실전의 정석 — 메모리 효율과 데이터 신선도를 동시에 확보합니다

Part 1. RDS & Aurora — 관리형 관계형 데이터베이스

RDS 개요

Amazon RDS(Relational Database Service)는 AWS가 OS 패치, 자동 백업, 소프트웨어 업그레이드, 장애 감지 및 복구를 대신 처리하는 관리형 관계형 데이터베이스 서비스입니다. 지원 엔진은 MySQL, PostgreSQL, MariaDB, Oracle, SQL Server입니다.

관리형 서비스의 핵심 이점은 데이터베이스 관리 부담을 줄이고 애플리케이션 개발에 집중할 수 있다는 점입니다. 프로비저닝부터 백업, 패치, 스케일링까지 자동화됩니다.

RDS 아키텍처: Multi-AZ vs Read Replica

RDS의 가용성과 성능은 두 가지 복제 방식으로 확보합니다. 두 방식은 목적이 완전히 다릅니다.

Multi-AZ 배포 (동기 복제)

프라이머리 DB 인스턴스가 다른 가용 영역(AZ)에 대기(Standby) 복제본을 동기식으로 유지합니다.

• 프라이머리 장애 시 자동으로 대기 인스턴스로 장애 조치 (60~120초)
• 데이터 손실 없음 (동기 복제)
• 대기 인스턴스는 비활성 — 읽기 트래픽 분산에는 사용되지 않음

읽기 복제본 (Read Replica, 비동기 복제)

프라이머리 DB의 데이터를 비동기식으로 복제하여 읽기 전용 복제본을 생성합니다.

• 읽기 트래픽 분산으로 성능 향상
• 최대 15개 생성 가능 (MySQL, PostgreSQL, MariaDB)
• Cross-Region Read Replica로 다른 리전에 배치 가능
• 보고/분석 쿼리를 복제본으로 분리

단일 AZ vs Multi-AZ

핵심: Multi-AZ는 재해 복구(DR)용이고, Read Replica는 읽기 성능 확장용입니다. 두 개를 함께 쓰는 것이 프로덕션의 표준입니다.

Amazon Aurora

Aurora는 AWS가 개발한 클라우드 네이티브 관계형 데이터베이스로, MySQL 및 PostgreSQL과 호환됩니다. 기존 애플리케이션 코드 수정 없이 마이그레이션이 가능합니다.

Aurora의 핵심은 스토리지와 컴퓨팅의 분리입니다. 분산 스토리지(6개 복사본, 3개 AZ) 위에 Writer 인스턴스와 최대 15개의 Reader 인스턴스가 올라가는 구조로, MySQL 대비 최대 5배, PostgreSQL 대비 3배의 처리량을 제공합니다.

Aurora 주요 기능 (2026 업데이트)

RDS 보안

RDS 보안은 네트워크, 암호화, 인증 세 축으로 구성합니다.

• VPC 내 배치 & 보안 그룹 — DB 서브넷 그룹으로 Multi-AZ 서브넷 지정, 퍼블릭 접근 비활성화
• 저장 데이터 암호화 (KMS) — 데이터, 로그, 백업, 스냅샷 암호화. 인스턴스 생성 시에만 활성화 가능
• 전송 중 암호화 (SSL/TLS) — 연결 시 SSL 파라미터 필수 설정 권장
• IAM 데이터베이스 인증 — 비밀번호 대신 인증 토큰 사용. Lambda, EC2 통합에 적합

RDS 백업

RDS 모니터링

4단계 모니터링 도구를 단계적으로 적용합니다.

1. CloudWatch 지표 — CPU, 메모리, 디스크 I/O, 연결 수, 읽기/쓰기 지연. 기본 1분 해상도
2. Enhanced Monitoring — OS 수준 상세 지표. 최대 1초 해상도, 에이전트 기반
3. Performance Insights — 대기 이벤트(AAS) 기반 분석. 느린 쿼리 식별, 성능 병목 진단
4. RDS 이벤트 알림 — SNS를 통한 이메일/SMS 알림. 이벤트 구독 필터링

RDS Proxy

RDS Proxy는 데이터베이스 연결을 풀(Pool)로 관리하여 재사용하는 서비스입니다. 수천 개의 동시 연결을 효율적으로 처리하고 연결 생성/해제 오버헤드를 감소시킵니다.

서버리스 환경에서 특히 효과적입니다. Lambda 함수의 갑작스러운 연결 증가와 콜드 스타트로 인한 DB 연결 병목을 해소합니다. Lambda 함수가 RDS Proxy 엔드포인트로 연결하고, 프록시가 DB 연결을 유지하여 실행 시간을 단축합니다. IAM 인증 지원으로 자격 증명 관리도 간소화됩니다.

RDS 비용 최적화

Part 2. ElastiCache — 관리형 In-Memory 캐시

캐시 개요

캐시(Cache)는 자주 사용되는 데이터를 빠르게 접근할 수 있는 임시 저장소에 보관하는 기법입니다. 원본 데이터 소스에 매번 접근하는 것보다 캐시에서 직접 가져오는 것이 훨씬 빠릅니다.

캐시의 핵심 원칙은 세 가지입니다.

• 지역성(Locality) — 최근 접근한 데이터에 다시 접근할 확률이 높음 (시간 지역성)
• 빈도(Frequency) — 자주 사용되는 데이터를 우선 캐싱
• 비용-효율 — 비싼 연산/IO의 결과를 저장하여 재사용

디스크 vs 메모리 성능 차이

메모리 기반 캐시는 디스크 기반 데이터베이스보다 수십~수백 배 빠릅니다. 이 차이가 ElastiCache가 존재하는 이유입니다.

ElastiCache 개요

Amazon ElastiCache는 Redis와 Memcached 두 가지 엔진을 지원하는 관리형 In-Memory 캐시 서비스입니다. 두 가지 주요 용도로 사용합니다.

① 데이터베이스 캐시 — RDS 앞단에 캐시 계층을 두어 읽기 성능을 극대화합니다. 읽기 요청의 80~90%를 캐시에서 처리하면 RDS 부하가 감소하고 응답 시간이 10ms에서 0.1ms로 단축됩니다.

② 세션 스토어 — 웹 애플리케이션의 사용자 세션 데이터를 ElastiCache에 저장합니다. 다중 서버 환경에서 세션 공유가 가능해집니다.

관리형 서비스의 이점으로 OS 패치 자동화, 장애 감지 및 자동 복구, 백업/복원(Redis), CloudWatch 모니터링 통합 등을 제공합니다.

Memcached vs Redis

선택 기준: 영속성, 복제, 장애조치, 다양한 데이터 구조가 필요하면 Redis. 단순한 Key-Value 캐시만 필요하고 데이터 유실이 허용되면 Memcached. 실무에서는 Redis가 사실상 표준입니다.

캐시 전략

캐시를 어떻게 채우고 갱신하느냐에 따라 성능과 일관성이 결정됩니다. 세 가지 전략을 상황에 맞게 선택하거나 조합합니다.

Lazy Loading (Cache-Aside)

애플리케이션이 캐시를 먼저 확인하고, 없으면 데이터베이스에서 조회 후 캐시에 저장합니다.

① GET cache_key
② Cache HIT → 데이터 반환 (끝)
③ Cache MISS → DB 조회
④ DB 결과를 Cache에 SET (TTL 설정)
⑤ 데이터 반환

• 장점: 실제로 사용되는 데이터만 캐시에 저장하여 메모리 효율적
• 단점: 최초 요청은 항상 DB 조회 (Cold Start), 캐시 미스 시 지연 발생

Write-Through

데이터베이스에 쓸 때마다 캐시에도 동시에 씁니다.

① 데이터 업데이트 요청
② Cache에 WRITE
③ DB에 WRITE
④ 반환

• 장점: 캐시와 DB 항상 동기화, 캐시 미스 없음
• 단점: 쓰기 지연 증가 (이중 쓰기), 자주 변경되지 않는 데이터에 비효율

Write-Behind (Write-Back)

캐시에 먼저 쓰고, 일정 시간 후 비동기로 DB에 반영합니다.

• 장점: 매우 빠른 쓰기 성능, 쓰기 집약적 워크로드에 적합
• 단점: 캐시 장애 시 데이터 유실 가능, 일관성 보장 어려움

TTL 관리

모든 캐시 항목에는 TTL(Time to Live)을 설정하여 만료 시간을 관리합니다. Lazy Loading에 TTL을 결합하면 데이터 신선도를 보장하면서도 메모리를 효율적으로 사용합니다.

실전 조합: Lazy Loading + TTL이 가장 널리 쓰이는 패턴입니다. Write-Through에는 TTL을 안전망으로 추가하여 동기화 실패 시 자연스럽게 만료되도록 설계합니다.

ElastiCache 사용 사례

• 데이터베이스 쿼리 캐시 — 읽기 요청의 80~90%를 캐시에서 처리. RDS 부하 감소, 응답 시간 10ms → 0.1ms
• 세션 스토어 — 다중 웹 서버 간 세션 공유. 어떤 서버에 연결되든 동일한 세션 데이터 접근
• 리더보드/순위 — Redis Sorted Set으로 실시간 순위표 구현 (ZADD, ZREVRANGE)
• Pub/Sub 메시징 — 채팅, 알림, 로그 등 발행/구독 패턴 구현

2026 업데이트: Serverless Cache

ElastiCache Serverless는 용량 계획, 스케일링, 클러스터 관리가 완전히 자동화된 서버리스 캐시입니다. 트래픽에 따라 초 단위로 자동 확장/축소하며, 사용한 데이터 용량(ECPUs)만큼만 과금합니다. 99.9% SLA와 자동 장애조치, Multi-AZ가 내장되어 있으며 기존 Redis 클라이언트로 그대로 사용 가능합니다.

Takeaway

1. Multi-AZ는 DR, Read Replica는 성능 — 두 복제 방식의 목적을 구분해서 설계해야 합니다. 프로덕션에서는 Multi-AZ + Read Replica 조합이 표준이며, Aurora는 분산 스토리지로 이를 하나로 통합합니다
2. Redis가 Memcached보다 사실상 표준 — 복제, 장애조치, 영속성, 다양한 데이터 구조를 모두 갖춘 Redis가 대부분의 캐싱 시나리오에 적합합니다. Memcached는 단순 일시적 캐시에만 고려합니다
3. Lazy Loading + TTL이 캐싱의 정석 — 실제 사용되는 데이터만 캐싱하여 메모리를 효율적으로 쓰고, TTL로 데이터 신선도를 보장하는 조합이 가장 검증된 패턴입니다

AWS 시리즈 7/16

← 엣지 서비스 — CloudFront, Route 53, Global Accelerator
	분석 & 파일 스토리지 — Redshift, Athena, EFS, FSx →