티스토리 뷰
웹 애플리케이션의 성능을 좌우하는 핵심은 바로 ‘응답 속도’입니다. 사용자가 요청한 데이터를 얼마나 빠르게 제공하느냐에 따라 사용자 경험이 달라지고, 서비스의 성공 여부가 갈립니다. AWS 환경에서는 다양한 수준에서 캐싱을 구현할 수 있으며, 이를 체계적으로 분리하고 구성하는 것을 '캐시 계층 설계'라고 합니다. 이 글에서는 AWS에서 적용할 수 있는 3가지 캐시 계층 (CloudFront, 애플리케이션 캐시, DB 캐시)에 대해 설명합니다.
첫 번째 계층: CDN 캐시 (CloudFront)
CloudFront는 AWS에서 제공하는 글로벌 CDN(Content Delivery Network) 서비스입니다. 웹사이트나 API의 정적 콘텐츠를 전 세계 사용자에게 지연 없이 제공하기 위해 가장 바깥쪽에 위치한 캐시 계층입니다.
주요 역할:
- 전 세계 엣지 로케이션을 통해 정적 파일을 사용자 가까이에서 제공
- 오리진 서버(예: S3, ALB, EC2)의 부하를 획기적으로 줄여줌
- 이미지, JS, CSS, HTML, 정적 JSON 등 캐싱 가능
- HTTPS 암호화, 압축(Gzip, Brotli), CORS 처리 등 부가 기능 제공
CloudFront 구성 팁:
- 오리진 선택: S3, ALB, EC2 등 다양하게 가능
- TTL 설정: 자산의 변경 주기에 따라 설정 (예: 이미지: 1일, JS: 1시간)
- 캐시 키 구성: 경로 + 쿼리 스트링 + 헤더 + 쿠키 등을 기준으로 캐싱 구분
- 오리진 보호: S3의 경우 OAI or OAC 설정을 통해 직접 접근 방지 가능
- 정적 자산 관리: 자산 변경 시 버저닝 적용 → main.v2.js 방식으로 캐시 무효화 최소화
실무 활용 예시:
- /static/logo.png → CloudFront에서 직접 제공
- /style/main.css → TTL 3600초, 버전마다 URL 분리
CloudFront 효과 요약:
- 웹사이트 응답 속도 최대 50~80% 향상
- 오리진 비용 및 리소스 절감
- 글로벌 사용자 대상 빠른 응답 보장
두 번째 계층: 애플리케이션 캐시 (ElastiCache for Redis/Memcached)
애플리케이션 캐시는 서버 내부 또는 가까운 외부 인메모리 스토리지를 사용하여, 반복 요청되는 데이터를 실시간으로 캐싱하는 계층입니다. AWS에서는 주로 ElastiCache for Redis 또는 Memcached를 사용합니다.
적합한 캐시 대상:
- 로그인 사용자 세션 정보
- 인기 상품 리스트
- 조회수가 많은 API 응답
- DB에서 자주 읽히는 읽기 전용 정보
- 계산 비용이 큰 처리 결과 (예: 통계, 환율 변환 결과)
Redis vs Memcached 비교:
| 항목 | Redis | Memcached |
| 데이터 구조 | 문자열, 리스트, 해시, 셋 등 다양한 타입 | 문자열(Key-Value)만 지원 |
| 지속성 | AOF, RDB 스냅샷 지원 | 없음 |
| 복제 및 장애복구 | 지원 | 지원 안 함 |
| 활용도 | 높은 수준의 제어 필요 시 적합 | 단순 캐싱에 적합 |
Redis 설정 팁:
- TTL 설정: 각 키마다 TTL 지정 가능 (예: product:123 → 300초)
- Eviction Policy: LRU 기반 설정 (volatile-lru, allkeys-lru)
- Cluster 모드: 수평 확장을 위한 샤딩 구조로 운영 가능
- 보안 설정: VPC, 보안 그룹, IAM 연동 필수
캐시 전략 예시:
- user:{id}:profile → 사용자 프로필 정보
- product:best10 → 인기상품 10개 리스트, TTL 1800초
- search:keyword:result → 검색 결과 캐시, TTL 300초
애플리케이션 캐시 도입 효과:
- DB 쿼리 감소 → 성능 향상
- 평균 응답 시간 획기적 단축 (ms 수준)
- 트래픽 피크 시 부하 분산
세 번째 계층: DB 캐시 또는 쿼리 최적화 계층 (RDS, Aurora)
AWS RDS(MySQL, PostgreSQL 등)나 Amazon Aurora는 내부적으로 일부 캐싱 기능을 제공하며, 읽기 성능을 보완하기 위해 Read Replica 또는 자체 쿼리 캐시 기능을 사용합니다.
DB 캐시 유형:
- RDS 쿼리 캐시
- MySQL의 query_cache 기능 (비활성화 권장되는 경우도 있음)
- Aurora에서는 자동 쿼리 결과 캐시 제공
- Read Replica
- 읽기 전용 요청을 복제 인스턴스로 분산
- 캐싱은 아니지만 캐시 효과 유사하게 구현 가능
- Materialized View 활용 (PostgreSQL)
- 주기적으로 갱신되는 뷰를 저장하여 반복 조회에 대응
활용 전략:
- 조회 트래픽이 많은 API는 Replica로 분산
- 실시간성이 필요 없는 데이터는 Materialized View 사용
- DB 캐시는 궁극적으로 애플리케이션 캐시를 보완하는 역할
실무 팁:
- Replica에는 쓰기 불가 → DB 설계 시 고려 필요
- 애플리케이션에서 Replica로 쿼리 분기하는 로직 포함
- 비용 측면에서 Redis + RDS Replica 병행 전략이 효율적
캐싱은 단순한 속도 개선 수단을 넘어서, 시스템 안정성 확보, 비용 최적화, 사용자 만족도 향상에 결정적인 역할을 합니다. AWS 환경에서는 CloudFront(정적), ElastiCache(애플리케이션), RDS 캐시(DB) 등 다단계 캐시 계층을 전략적으로 설계함으로써 최적의 퍼포먼스를 구현할 수 있습니다. 지금 사용하는 시스템이 느리거나, 트래픽에 따라 불안정하다면 캐시 계층을 재설계해서 적용하시길 추천드립니다.