1. 캐시와 CDN이란?

목차

 

책 '주니어 백엔드 개발자가 반드시 알아야 할 실무 지식' 2장을 읽고, 웹 서비스의 성능 최적화를 위해서 캐시와 CDN에 대해 공부했다. 이 글에서는 서버 캐시부터 브라우저 캐시, 그리고 CDN까지를 정리할 것이다.

1. 서버 캐시

DB 서버를 확장하지 않고 응답 시간과 처리량을 개선하고 싶다면 캐시(cache)를 사용할 수 있다.

• 캐시: (키, 값) 쌍을 저장하는 Map과 같은 형태의 데이터 저장소
• 캐시에 데이터를 저장해두면 동일한 데이터를 요청할 때 DB가 아닌 캐시에서 데이터를 읽어와 응답할 수 있다.
• 일반적으로 캐시에서 데이터를 읽는 속도가 DB보다 빠르기 때문에, 자주 조회되는 데이터를 캐시에 보관하면 응답 시간을 줄일 수 있다.
• DB뿐만 아니라 복잡한 계산 결과나 외부 API 연동 결과도 캐시에 보관하면 응답 시간을 줄일 수 있다.

적중률

캐시가 얼마나 효율적으로 사용되고 있는지는 적중률(hit rate)로 판단할 수 있다.

• 적중률 = 캐시에 존재한 건수/캐시에서 조회를 시도한 건수

적중률이 높을수록 캐시에서 데이터를 성공적으로 찾아내는 비율이 높다는 의미이며, 전체 시스템의 성능 향상(응답 시간 감소, 처리량 증가, DB 부하 감소 등)으로 이어진다.

삭제 규칙

캐시에 보관할 수 있는 데이터에 제한이 있으므로, 캐시 공간이 가득 찰 때 어떤 데이터를 삭제할지 선택하는 규칙은 다음과 같다.

• LRU(Least Recently Used): 가장 오래전에 사용된 데이터를 제거한다.
• LFU(Least Frequently Used): 가장 적게 사용된 데이터를 제거한다.
• FIFO(First In, First Out): 먼저 추가된 데이터를 먼저 삭제한다.

※ 캐시 유효 시간(TTL, Time To Live): 데이터의 최신 상태를 보장하기 위해 캐시에 유효 시간(TTL)을 설정하는 방식도 함께 사용된다. 예를 들어, "이 데이터는 10분 동안만 유효함"이라고 설정하면 10분이 지난 데이터는 자동으로 삭제된다.

캐싱 전략

캐시를 효과적으로 사용하려면 데이터의 읽기/쓰기 패턴에 맞는 적절한 전략을 선택해야 한다. 대표적인 캐싱 패턴들의 특징을 알아보자.

1) Cache-Aside (Lazy Loading) 패턴

• Cache-Aside 패턴은 가장 일반적으로 사용되는 캐싱 전략으로, 데이터가 필요할 때만 캐시에 저장하는 방식이다.
  • 읽기: 캐시 확인 → 없으면 DB 조회 → 캐시 저장 → 데이터 반환
  • 쓰기: DB 업데이트 → 기존 캐시 데이터 삭제
• 장점:
  • 필요한 데이터만 캐시에 저장되어 메모리를 효율적으로 사용함.
  • 캐시 서버에 장애가 발생해도 시스템이 정상 동작함.
  • 구현하기 쉽고 이해하기 직관적임.
• 단점:
  • 처음 요청할 때는 캐시에 데이터가 없어서 느림.
  • 애플리케이션 코드에 캐시 로직이 섞여서 복잡해짐.
• 대부분의 웹 애플리케이션에서 사용하며, 특히 읽기가 많고 모든 데이터를 캐시할 필요가 없는 경우 사용한다.

2) Write-Through 패턴

• Write-Through 패턴은 데이터 일관성을 가장 중요하게 생각하는 전략이다.
• 데이터를 쓸 때 캐시와 DB에 동시에 저장하고, 캐시와 DB가 항상 같은 데이터를 가지고 있음을 보장한다.
• 장점:
  • 캐시와 DB의 데이터가 항상 일치함.
  • 읽기 요청 시 항상 빠른 응답이 가능함.
  • 데이터 손실 위험이 거의 없음.
• 단점:
  • 쓰기 작업이 느림.
  • 캐시 서버 장애 시 쓰기 작업 자체가 실패할 수 있음.
• 정확한 데이터가 매우 중요한 금융 시스템, 결제 시스템 등에 사용한다.

3) Write-Behind (Write-Back) 패턴

• Write-Behind 패턴은 쓰기 성능을 최대한 빠르게 만드는 전략이다.
• 일단 캐시에만 데이터를 쓰고 즉시 응답하고, 나중에 백그라운드에서 DB에 저장한다.
• 장점:
  • 쓰기 성능이 매우 빠름.
  • 대량의 데이터 처리가 가능함.
  • 여러 번의 쓰기를 모아서 DB에 한 번에 처리 가능함.
• 단점:
  • 캐시 서버가 고장나면 아직 DB에 저장되지 않은 데이터가 사라질 수 있음.
  • 캐시와 DB의 데이터가 일시적으로 다를 수 있음.
  • 구현이 복잡하고 장애 상황 처리가 어려움.
• 로그 데이터, 게임 점수, 조회수 등 손실되어도 큰 문제가 없고 빠른 처리가 중요한 경우에 사용한다.

4) Write-Around 패턴

• Write-Around 패턴은 자주 바뀌는 데이터를 효율적으로 처리하는 전략이다.
• 쓰기는 DB에만 하고 캐시는 건드리지 않고, 읽기할 때만 캐시를 사용한다. (Cache-Aside 방식)
• 장점:
  • 쓰기 성능이 빠름. (캐시 업데이트 불필요)
  • 구현이 간단함.
  • 자주 업데이트되는 데이터에 효과적임.
• 단점:
  • 데이터를 업데이트한 후 첫 번째 읽기 요청은 느림. (캐시에 없어서)
  • 최신 데이터가 캐시에 반영되는 데 시간이 걸림.
• 로그 파일, 이벤트 데이터 등 한 번 쓰고 나서 당분간 읽지 않는 데이터에 사용한다.

5) Read-Through 패턴

• Read-Through 패턴은 캐시가 DB 역할을 대신하는 전략이다.
• 애플리케이션은 캐시하고만 대화하고, 캐시에 데이터가 없으면 캐시가 알아서 DB에서 가져온다.
• 장점:
  • 애플리케이션 코드가 단순해짐.
  • 캐시가 자동으로 데이터를 불러옴.
  • 여러 데이터를 한 번에 가져오는 것도 지원 가능함.
• 단점:
  • 캐시 시스템이 복잡해짐.
  • 캐시 서버에 문제가 생기면 전체 시스템에 영향을 미침.
• 하나의 DB만 사용하고 캐시 로직을 애플리케이션에서 분리하고 싶은 경우에 사용한다.

각 시스템의 특성과 요구사항을 잘 분석해서 적절한 캐싱 패턴을 선택하거나 여러 패턴을 섞어서 사용하는 것이 중요하다.

2. 로컬 캐시와 리모트 캐시

로컬 캐시

• 로컬(local) 캐시: 서버 프로세스와 동일한 메모리를 캐시 저장소로 사용한다.
• 구현 기술: Caffeine(자바), go-cache(Go), node-cache(Node.js) 등
• 장점:
  • 동일한 메모리 공간 사용으로 빠른 속도
  • 네트워크 오버헤드 없음
• 단점:
  • 서버 메모리 크기에 따른 데이터 크기 제한
  • 서버 재시작 시 캐시 데이터 소실로 인한 적중률 감소

리모트 캐시

• 리모트(remote) 캐시: 별도의 프로세스를 캐시 저장소로 사용한다.
• 구현 기술: Redis 등
• 장점:
  • 유연한 캐시 크기 확장
  • 서버 재시작 시에도 캐시 데이터 유지
• 단점:
  • 네트워크 통신으로 인한 속도 저하
  • 추가적인 인프라 관리 필요

로컬 캐시와 리모트 캐시 선택 여부는 데이터 규모, 변경 빈도, 응답 시간, 처리량 등을 판단 기준으로 결정한다.

• 캐시에 보관할 데이터 규모가 작고 변경 빈도가 낮다면 로컬 캐시를 사용한다.
• 데이터 규모가 크고 배포 빈도가 높은 서비스라면 리모트 캐시를 사용한다.

Q. Redis는 왜 인-메모리 데이터 저장소일까?

: 로컬 캐시는 인-메모리(in-memory) 캐시라고도 부르는데, 메모리에 캐시 데이터를 보관하기 때문이다. 리모트 캐시로 사용하는 Redis도 인-메모리 데이터 저장소라고 불린다. Redis가 별도의 프로세스로 동작하지만, 데이터를 메모리에 저장하기 때문이다. '인-메모리'는 데이터 저장 방식을 의미하며, 로컬/리모트는 캐시의 위치를 나타내는 구분이다.

3. 정적 자원과 브라우저 캐시

웹 서버가 응답하는 데이터는 2가지로 분류할 수 있다.

1. 동적 자원: 브라우저가 요청할 때마다 결과가 바뀌는 데이터 (API 응답, 사용자별 콘텐츠 등)
2. 정적 자원: 같은 URL에 대해서 같은 데이터를 응답하는 콘텐츠 (이미지, CSS, JS 등)

사용자가 상품 상세 페이지를 10번 방문한다고 가정했을 때, 브라우저 캐시가 없다면 동일한 이미지와 JS 파일을 10번 다운로드해야 한다. 하지만 다음과 같은 문제가 발생할 수 있다.

1. 불필요한 트래픽 발생
2. 트래픽 비용 증가
3. 사용자 경험 저하

브라우저 캐시를 활용하면 서버 입장에서 전송해야 할 트래픽이 줄어들어 네트워크 전송 비용을 크게 절약할 수 있다.

4. 정적 자원과 CDN

브라우저 캐시는 브라우저 단위로 동작하기 때문에 다음과 같은 한계가 있다.

• 동시에 많은 사용자가 접속하면 순간적으로 많은 양의 데이터를 전송해야 함
• 네트워크 포화 상태 발생
• 응답 시간 증가

CDN

• CDN(Content Delivery Network): 콘텐츠를 제공하기 위한 별도의 네트워크
• CDN 서비스: Amazon CloudFront, Akamai, Cloudflare 등
• CDN을 사용하면 클라이언트에 콘텐츠를 더 빠르고 효율적으로 전달할 수 있다.
• 장점:
  • 오리진 서버의 트래픽 감소
  • 콘텐츠의 빠른 제공 (지리적으로 가까운 서버에서 제공)
  • 트래픽 비용 절감
  • 글로벌 서비스 가능

CDN은 다음과 같이 동작한다.

1. 사용자가 CDN이 제공하는 URL을 통해 콘텐츠에 접근함
2. 가장 가까운 CDN 서버에서 콘텐츠를 제공함
3. 오리진 서버의 부하 감소

다음과 같은 상황에서는 CDN을 도입하는 것이 좋다.

• 글로벌 사용자를 대상으로 하는 서비스
• 이미지, 동영상 등 용량이 큰 정적 자원이 많은 서비스
• 트래픽이 급증하는 서비스

CDN 캐시

CDN도 내부적으로 캐시 시스템을 사용한다. CDN 서버들이 전 세계에 분산되어 있어서 각 서버마다 자주 요청되는 콘텐츠를 캐시로 저장해둔다.

• 동작 방식: 첫 번째 요청 시 오리진 서버에서 콘텐츠를 가져와 CDN 서버에 캐시 저장 → 이후 같은 요청은 CDN 캐시에서 바로 응답
• 장점:
  • 사용자에게 매우 빠른 응답 속도를 제공함.
  • 오리진 서버의 부하를 크게 줄여줌. (대부분의 요청을 CDN에서 처리)
  • 전 세계 어디서나 일관된 성능을 보장함.
  • 트래픽 비용을 절약함. (오리진 서버 대역폭 사용량 감소)
• 단점:
  • 콘텐츠 업데이트 시 즉시 반영되지 않을 수 있음. (캐시 TTL까지 기다려야 함)
  • CDN 서버별로 캐시 상태가 달라서 일시적인 불일치가 발생할 수 있음.
  • 캐시 무효화 비용이 발생함. (긴급하게 캐시를 삭제해야 할 때)
  • 디버깅이 복잡함. (어느 CDN 서버에서 문제가 생겼는지 파악이 어려움)

CDN 캐시는 웹 사이트 성능 향상에 매우 중요한 역할을 한다. 적절한 캐시 설정과 관리를 통해 사용자에게 빠른 서비스를 제공할 수 있고, 서버 비용도 절약할 수 있다.

참고 자료

1) 인파, "[REDIS] 📚 캐시(Cache) 설계 전략 지침 💯 총정리", 2022.11.10, https://inpa.tistory.com/entry/REDIS-📚-캐시Cache-설계-전략-지침-총정리#redis_-_캐시cache_전략

2) 데브오웬, "프론트엔드 개발자가 알아야 할 '캐싱' 개념 정리", 2023.11.29, https://yozm.wishket.com/magazine/detail/2341

3) CLOUDFLARE, "캐싱 소개", https://www.cloudflare.com/ko-kr/learning/cdn/what-is-caching

 

이 글은 『 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식』 책을 읽고 학습한 내용을 정리한 것입니다.