AWS Certified Solutions Architect - Associate (SAA-C03) #10 Domain 3-2 고성능 아키텍처: 캐싱
#9 컴퓨팅 선택에 이어, 고성능 도메인의 두 번째 수단인 캐싱을 다룹니다. 캐싱은 “같은 데이터를 반복해서 비싸게 가져오지 말고, 가까운 곳에 저장해 두고 빠르게 꺼내자"는 원리입니다. SAA에서는 어디에 캐싱하는가(애플리케이션 옆 인메모리 vs 사용자 가까운 엣지)로 서비스가 갈립니다.
ElastiCache: 인메모리 데이터 캐시 #
ElastiCache는 관리형 인메모리 캐시입니다. 데이터베이스 앞에 두어 반복 조회의 부하를 흡수하고 응답을 마이크로초~밀리초로 끌어올립니다. 두 엔진이 있고, 차이가 시험에 자주 나옵니다.
| 항목 | Redis | Memcached |
|---|---|---|
| 영속성(persistence) | 지원 | 없음 |
| 복제,Multi-AZ | 지원(고가용성) | 없음 |
| 자료 구조 | 다양(list, set, sorted set, pub/sub) | 단순 key-value |
| 멀티스레드 | 아니오 | 예 |
| 백업/스냅샷 | 지원 | 없음 |
- Redis. 영속성,복제,Multi-AZ,백업,풍부한 자료 구조가 필요하면 Redis입니다. 세션 저장, 리더보드, pub/sub 등 고급 기능에 적합합니다.
- Memcached. 단순한 key-value 캐시이고, 멀티스레드로 수평 확장(샤딩)하며, 영속성,복제가 필요 없을 때 적합합니다.
“고가용성/영속성/복제가 필요한 캐시"는 Redis, “단순,멀티스레드 캐시"는 Memcached로 답합니다.
캐시 전략 #
- Lazy Loading(지연 로딩). 캐시에 없으면(miss) DB에서 읽어 캐시에 채웁니다. 실제 요청된 데이터만 캐싱되지만, 첫 요청은 느리고 오래된 데이터가 남을 수 있습니다.
- Write-Through. 데이터를 쓸 때 캐시도 함께 갱신합니다. 캐시가 항상 최신이지만, 쓰이지 않을 데이터까지 캐싱될 수 있습니다.
- TTL. 캐시 항목에 만료 시간을 두어 오래된 데이터를 자동 제거합니다.
DAX: DynamoDB 전용 가속 #
**DynamoDB Accelerator(DAX)**는 DynamoDB 앞에 두는 인메모리 캐시로, 읽기 응답을 밀리초에서 마이크로초로 낮춥니다. 중요한 점은 DAX가 DynamoDB 전용이라는 것입니다. RDS나 다른 DB의 캐시로는 쓸 수 없습니다. “DynamoDB 읽기를 마이크로초로"라는 단서면 DAX입니다.
CloudFront: 엣지 콘텐츠 캐시(CDN) #
CloudFront는 전 세계 엣지 로케이션에 콘텐츠를 캐싱해, 사용자와 물리적으로 가까운 곳에서 응답하게 하는 CDN입니다. ElastiCache가 애플리케이션 옆 캐시라면, CloudFront는 사용자 가까운 캐시입니다.
- 오리진(Origin). S3, ALB, 또는 외부 서버를 원본으로 둡니다.
- 효과. 지연 시간 감소 + 오리진 부하 경감. 정적 콘텐츠뿐 아니라 동적 콘텐츠도 가속합니다.
- OAC(Origin Access Control). S3 오리진을 CloudFront로만 접근하게 잠가, 버킷 직접 노출을 막습니다.
- 서명 URL/쿠키. 특정 사용자에게만 콘텐츠 접근을 허용합니다.
- 엣지 로직. CloudFront Functions / Lambda@Edge로 엣지에서 요청을 변형합니다.
“전 세계 사용자에게 지연 시간을 줄여 콘텐츠를 전달”, “오리진 부하를 줄여라”, “S3를 직접 노출하지 않고 배포"라는 요구사항이면 CloudFront입니다.
CloudFront vs Global Accelerator #
둘 다 사용자 경험을 빠르게 하지만 방식이 다릅니다.
| 서비스 | 방식 | 적합 |
|---|---|---|
| CloudFront | 콘텐츠를 엣지에 캐싱 | 정적/동적 웹 콘텐츠 배포 |
| Global Accelerator | 캐싱 없이 AWS 백본으로 라우팅 | 비 HTTP(TCP/UDP), 고정 IP, 빠른 장애 전환 |
캐싱이 핵심이면 CloudFront, “캐싱은 아니지만 글로벌 네트워크 경로 최적화,고정 anycast IP"가 필요하면 Global Accelerator입니다.
stateless를 위한 세션 외부 저장 #
#6 Auto Scaling에서 인스턴스가 수시로 늘고 줄었습니다. 세션을 인스턴스 메모리에 두면 그 인스턴스가 사라질 때 세션도 사라집니다. 그래서 세션을 ElastiCache(Redis) 같은 외부 저장소로 빼 애플리케이션 계층을 stateless로 만듭니다. 이렇게 하면 어떤 인스턴스가 요청을 받아도 같은 세션을 읽습니다.
시험 출제 패턴 #
- “전 세계 사용자에게 콘텐츠를 가깝게, 지연 감소.” → CloudFront
- “DB 읽기 부하 감소, 인메모리 캐시.” → ElastiCache
- “영속성/복제/Multi-AZ 캐시.” → Redis
- “단순,멀티스레드 캐시, 영속성 불필요.” → Memcached
- “DynamoDB 읽기를 마이크로초로.” → DAX
- “세션 상태를 외부 저장해 stateless.” → ElastiCache(Redis)
- “S3를 직접 노출 않고 CDN 배포.” → CloudFront + OAC
자주 만나는 함정 #
1) Memcached에 영속성,복제가 있다고 생각 #
영속성,복제,Multi-AZ,백업은 Redis입니다. Memcached는 단순 캐시입니다.
2) CloudFront와 ElastiCache를 혼동 #
CloudFront는 사용자 가까운 엣지 CDN, ElastiCache는 애플리케이션 옆 인메모리 캐시입니다. 푸는 문제가 다릅니다.
3) DAX를 RDS 캐시로 쓴다 #
DAX는 DynamoDB 전용입니다. 관계형 DB 캐시는 ElastiCache입니다.
4) CloudFront로 비 HTTP 트래픽을 가속하려 한다 #
CloudFront는 웹 콘텐츠 캐싱입니다. TCP/UDP 일반 트래픽의 경로 최적화는 Global Accelerator입니다.
정리 #
이번 글에서 잡은 것:
- ElastiCache. 인메모리 캐시. Redis(영속성,복제,Multi-AZ) vs Memcached(단순,멀티스레드)
- DAX. DynamoDB 전용 마이크로초 캐시
- CloudFront. 엣지 CDN. 지연 감소 + 오리진 부하 경감. OAC로 S3 보호
- CloudFront vs Global Accelerator. 캐싱 vs 네트워크 경로 최적화
- 세션을 ElastiCache로 외부 저장해 애플리케이션을 stateless하게
다음: Domain 3-3 스토리지 선택 #
캐싱을 잡았으니, 다음은 데이터를 어디에 어떤 스토리지로 둘 것인가입니다.
#11 Domain 3-3 스토리지 선택에서는 블록(EBS),파일(EFS,FSx),객체(S3)의 구분, EBS 볼륨 타입, EFS와 FSx(Windows,Lustre)의 용도, 그리고 S3 스토리지 클래스(Standard,Intelligent-Tiering,IA,Glacier)와 수명 주기 정책을 정리하겠습니다.