반응형
캐시(Cache)는 자주 사용하는 데이터를 빠르게 접근할 수 있도록 저장하는 임시 저장소이다.
웹 애플리케이션에서는 데이터베이스, 서버, 브라우저 등 다양한 계층에서 캐시를 활용하여 성능을 향상시킨다.
1) 캐시의 필요성
- 속도 향상: 데이터를 매번 새로 요청하는 대신 캐시에서 가져와서 빠르게 처리
- 서버 부하 감소: DB 또는 원격 서버의 요청을 줄여 시스템 부하를 낮춤
- 네트워크 트래픽 절감: 동일한 요청을 반복적으로 서버에 보내지 않도록 함
2) 캐시(Cache)의 종류
- 클라이언트 측(Cache)
- 브라우저 캐시(Browser Cache)
- 웹 브라우저가 웹 페이지 리소스(HTML, CSS, JavaScript, 이미지)를 저장하여 다음 방문 시 빠르게 로드
- Cache-Control, ETag 등을 이용하여 캐시를 관리
- DNS 캐시(DNS Cache)
- DNS 서버에 요청을 보내지 않고, 이전에 조회한 도메인의 IP 주소를 저장하여 속도 향상
- 애플리케이션 캐시(Application Cache)
- 모바일 앱 또는 웹 애플리케이션 내부에서 자주 사용하는 데이터를 저장하여 성능 최적화
- 브라우저 캐시(Browser Cache)
- 서버 측(Cache)
- 데이터베이스 캐시(DB Cache)
- DB에서 자주 조회되는 쿼리 결과를 캐시하여 DB 부하를 줄임
- MySQL의 Query Cache, Redis, Memcached 사용
- 웹 서버 캐시(Web Server Cache)
- 웹 서버(Nginx, Apache 등)에서 캐시를 활용하여 정적 리소스를 빠르게 제공
- 객체 캐시(Object Cache)
- 세션 데이터, API 응답 등을 빠르게 제공하기 위해 Redis, Memcached와 같은 캐시 시스템을 사용
- 데이터베이스 캐시(DB Cache)
- 네트워크 및 프록시 캐시(Proxy Cache)
- CDN 캐시(Content Delivery Network Cache)
- CDN 서버가 웹 콘텐츠(이미지, 동영상, CSS, JavaScript 등)를 캐싱하여 전 세계 사용자에게 빠르게 제공
- 역방향 프록시 캐시(Reverse Proxy Cache)
- 웹 서버 앞단에서 요청을 캐싱하여 서버 부하를 줄이고 성능을 향상
- 대표적인 예: Nginx, Varnish, Cloudflare
- 순방향 프록시 캐시(Forward Proxy Cache)
- 클라이언트 요청을 대신 처리하면서 캐싱하여 동일한 요청을 줄임
- 대표적인 예: Squid Proxy, 웹 브라우저의 캐시 서버
- CDN 캐시(Content Delivery Network Cache)
3) 캐시 동작 방식
- 첫 번째 요청:
- 사용자가 서버에 요청을 보냄
- 서버는 요청을 처리하고 데이터를 반환하며, 해당 데이터를 캐시에 저장
- 두 번째 요청(캐시 HIT):
- 동일한 요청이 발생하면, 캐시에서 데이터를 가져와 제공 (서버에 재요청하지 않음)
- 캐시 만료(Cache Expiration, MISS 발생)
- 캐시 데이터가 만료되면, 다시 서버에서 최신 데이터를 가져와 캐시를 갱신
4) 캐시 제어(Cache Control) - HTTP 캐시 제어
캐시는 웹 성능을 최적화하는 핵심 요소이며, HTTP 헤더를 통해 캐시 동작을 제어할 수 있다.
- Cache-Control 헤더
- Cache-Control: no-cache → 매번 서버에서 최신 데이터 요청
- Cache-Control: no-store → 캐시에 절대 저장하지 않음
- Cache-Control: max-age=3600 → 1시간(3600초) 동안 캐시 유지
- Cache-Control: public → 모든 클라이언트가 캐시 사용 가능
- Cache-Control: private → 특정 사용자(브라우저)만 캐시 사용 가능
- ETag(Entity Tag)
- 캐시된 리소스가 변경되었는지 확인하는 방식
- ETag 값이 변경되지 않았다면, 서버에서 데이터를 다시 전송하지 않음
- Last-Modified
- 마지막으로 변경된 시간을 기반으로 캐시 여부를 판단
- If-Modified-Since 요청을 보내서 변경되지 않았다면 304(Not Modified) 응답
5) 캐시 무효화(Cache Invalidation)
캐시는 성능을 향상시키지만, 데이터가 변경될 경우 최신 데이터를 반영해야 하는 문제가 발생할 수 있다. 이를 해결하는 방법은 아래와 같다.
- 시간 기반 만료(Time-based Expiration)
- max-age, expires 값을 설정하여 일정 시간이 지나면 자동으로 캐시를 삭제
- ETag 및 Last-Modified 기반 검증(Validation)
- 서버에서 최신 데이터를 확인하여 캐시를 유지할지 갱신할지 결정
- 수동 캐시 삭제(Manual Purging)
- Redis, CDN 캐시를 API 또는 명령어를 통해 강제로 삭제
- 버전 변경(Cache Busting)
- 파일명에 버전 정보를 추가하여 변경이 있을 때마다 새로운 리소스를 요청
- 예: style.css → style_v2.css
6) 캐시 시스템 예시
- Redis
- 인메모리 데이터베이스로 빠른 속도로 데이터 캐싱
- TTL(시간 제한) 설정 가능
- 세션 저장, 실시간 데이터 처리 등에 활용
- Memcached
- Key-Value 기반의 분산 캐시 시스템
- 메모리에서 데이터를 빠르게 조회하는 데 최적화됨
- Varnish
- 웹 서버 앞단에서 HTTP 캐싱을 수행하는 고성능 Reverse Proxy
- Cloudflare / Akamai (CDN)
- 글로벌 네트워크를 활용한 콘텐츠 캐싱 제공
7) 프록시 캐시(Proxy Cache)란?
프록시 캐시는 클라이언트와 서버 사이에서 요청을 가로채고 캐시를 저장하는 방식이다.
프록시 캐시는 두 가지 방식으로 나뉜다.
- 순방향 프록시 캐시(Forward Proxy Cache)
- 클라이언트(사용자) 측에서 캐싱을 수행
- 동일한 요청이 반복될 경우, 캐시에서 데이터를 제공하여 성능을 최적화
- 예시: Squid Proxy, 브라우저 프록시 캐시
- 역방향 프록시 캐시(Reverse Proxy Cache)
- 서버 앞단에서 캐싱을 수행하여 부하를 줄임
- 웹 서버(Nginx, Apache) 앞단에 위치하여 요청을 캐싱하고 응답 속도를 향상
- 예시: Varnish, Cloudflare, Nginx Cache
8) 캐시 활용 시 고려할 점
- 데이터 일관성 유지
- 캐시된 데이터가 최신 데이터와 다를 수 있으므로, 적절한 무효화 전략 필요
- 캐시 크기 관리
- 메모리 기반 캐시는 저장 공간이 제한적이므로, 적절한 크기 설정 필요
- TTL(만료 시간) 설정
- 너무 길면 오래된 데이터가 남아있고, 너무 짧으면 캐시 히트율이 낮아짐
- 보안 이슈
- 민감한 정보(사용자 로그인 데이터)는 캐싱하지 않도록 설정해야 함
9) 결론
캐시는 성능 최적화에 중요한 역할을 하며, 브라우저, 웹 서버, 데이터베이스 등 다양한 계층에서 사용된다.
하지만 캐시의 데이터 일관성을 유지하는 것이 중요하며, 적절한 캐시 전략(Cache-Control, ETag, Reverse Proxy Cache 등)을 설정하는 것이 필요하다.
반응형
