카테고리 없음

Chapter 9강 (Caching, Stale Data) 심화 스터디

Chansman 2025. 4. 9. 10:38

🔍 캐싱 무효화가 번거로운 이유

캐싱 무효화(Invalidation)는 CloudFront의 각 엣지 로케이션에서 캐싱된 데이터를 강제로 삭제하는 작업인데, 다음과 같은 단점이 있습니다.

  • 무효화 요청마다 시간이 걸림(약 5~15분 정도 소요됨)
  • 무효화 요청 횟수 제한(한 달에 무료 제공되는 요청 수 초과 시 추가 요금 발생)
  • 관리상 불편함(수동 작업이 많아질수록 운영 효율성 저하)

따라서 캐싱 무효화를 최소화하거나 자동화하는 방법을 사용하는 것이 현실적입니다.

✅ 무효화를 최소화하는 방법들

① 파일명에 해시(Hash) 또는 버전 붙이기 (권장)

파일명이 변경되면 자동으로 새로운 파일로 간주하여 캐싱이 새로 이루어지므로 무효화 자체가 필요 없습니다.

  • 예를 들어, 기존:
 
app.js
  • 해시 값을 붙인 후:
 
app.12a3b4.js

장점:

  • 파일이 변경될 때마다 새로운 URL이 되어 캐싱 문제 해결
  • 무효화 요청 필요 없음
  • 브라우저 및 CDN이 항상 최신 버전을 제공함

단점:

  • 매번 빌드할 때 자동으로 해시값을 붙이도록 개발 환경 구성이 필요함

② Cache-Control 헤더 사용하기 (HTTP 헤더)

웹 서버에서 HTTP 응답 헤더를 설정하여 캐시의 유효 기간을 지정할 수 있습니다.

Cache-Control: max-age=300  // 5분간만 캐싱 허용

장점:

  • 간단한 설정만으로 캐싱 기간 설정 가능
  • 설정된 시간이 지나면 자동으로 캐시 갱신

단점:

  • 너무 짧은 캐시 기간은 CDN의 효율성을 떨어뜨릴 수 있음
  • 여전히 무효화가 즉시 되지는 않음 (짧은 주기로 최신화)

③ Lambda@Edge 활용 (고급)

CloudFront에 Lambda@Edge를 연결하여 특정 조건에서만 실시간으로 원본 데이터를 가져오도록 설정할 수 있습니다.

예를 들어, 중요한 데이터만 캐싱을 무시하고 항상 최신 데이터를 가져오게 설정 가능합니다.

장점:

  • 세부적인 캐시 제어 가능
  • 동적 콘텐츠와 정적 콘텐츠를 효과적으로 혼합하여 제공 가능

단점:

  • 추가 비용이 발생할 수 있음 (Lambda@Edge 실행 비용)
  • 설정과 관리가 복잡할 수 있음

④ CloudFront Functions 활용 (경량)

Lambda@Edge보다 더 가볍고 빠르게 작동하는 CloudFront Functions를 활용하여 간단한 캐시 관리 로직을 추가할 수 있습니다.

예를 들어, 특정 조건 하에 캐싱 무효화가 아닌 우회나 무시를 통해 매번 새로운 콘텐츠를 제공할 수 있습니다.

장점:

  • Lambda@Edge보다 비용 효율적
  • 빠르고 간단한 설정 가능

단점:

  • 복잡한 로직 구현이 어려움 (단순한 로직만 가능)

🗂 상황별 추천 솔루션 요약 표

상황추천 방법설명복잡성비용
일반적인 웹 애플리케이션 파일명 해시값 붙이기 가장 권장되는 방식으로 개발 환경 구성 시 간단히 해결 가능 ⭐️⭐️ 무료
뉴스 사이트나 실시간으로 변경되는 콘텐츠 Cache-Control 헤더 짧은 캐시 기간 설정으로 최신성 유지 가능 ⭐️ 무료
복잡한 비즈니스 로직 필요 Lambda@Edge 실시간으로 세부적인 캐싱 제어 ⭐️⭐️⭐️⭐️ 추가 비용 발생
간단한 캐싱 우회 및 제어 CloudFront Functions 빠르고 간단한 로직으로 캐시 제어 ⭐️⭐️⭐️ 매우 저렴

🎯 가장 현실적이고 권장되는 방법: 파일명에 버전(해시)을 붙이는 방법

프론트엔드 애플리케이션 빌드 과정에서 webpack, Parcel, Vite 등의 빌드 툴을 활용하면 자동으로 파일 이름에 해시 값을 붙여주는 기능이 제공됩니다. 이를 통해 무효화 작업 없이 CDN 캐싱 문제를 효율적으로 해결할 수 있습니다.

webpack 예시

output: {
  filename: '[name].[contenthash].js'
}

🚩 결론

캐싱 무효화(Invalidation)는 필수적이지만 번거롭고 비용이 들 수 있습니다. 이를 최소화하기 위해 위와 같은 다양한 방법을 활용할 수 있으며, 파일명 해시(버전) 추가 방식이 가장 간편하고 효과적인 방법입니다.

 

📌 Stale Data가 발생하는 이유

사용자가 웹사이트에 접속하면, 빠른 응답을 위해 CDN과 같은 서비스가 콘텐츠를 미리 저장(캐싱)해두고 제공합니다. 그러나 원본 데이터가 변경된 후에도 캐시된 데이터가 그대로 유지될 경우, 사용자는 최신 데이터가 아닌 오래된 데이터를 보게 됩니다.

이렇게 최신 버전으로 업데이트되지 않고 캐시에 남아 있는 데이터를 "스테일 데이터(Stale Data)" 라고 합니다.

🧩 간단한 예시

예를 들어, 쇼핑몰의 가격 정보가 변경되었을 때를 생각해봅시다.

  • 최초 가격: 10,000원
  • 가격 변경: 8,000원으로 할인 적용

하지만 CDN이 10,000원의 데이터를 캐싱해두었다면, 사용자는 여전히 10,000원(스테일 데이터)을 보게 됩니다. 실제 가격은 8,000원이지만, 캐시 때문에 과거의 데이터를 보고 있는 상황입니다.

상태원본 데이터 (오리진)CDN 캐시 데이터 (엣지 로케이션)
최초 데이터 10,000원 ✅ 10,000원 ✅
가격 변경 후 8,000원 ✅ 10,000원 (Stale Data ⚠️)

⚠️ Stale Data의 문제점

  • 사용자에게 정확하지 않은 정보를 제공할 수 있음.
  • 가격, 재고, 뉴스 등 최신성이 중요한 데이터에 문제 발생 가능성.
  • 서비스의 신뢰성 하락 가능성.

🚧 해결 방법

Stale Data 문제는 다음과 같은 방법으로 해결할 수 있습니다.

  1. 캐시 무효화(Invalidation)
    • CDN에 저장된 기존 데이터를 삭제하여 다음 요청 시 최신 데이터를 가져오도록 합니다.
    • 단점: 매번 수행하기 번거롭고 비용 발생 가능성 존재.
  2. 짧은 캐시 유효기간 설정(Cache-Control 헤더)
    • 자주 변경되는 콘텐츠의 경우 짧은 유효기간을 설정하여 최신성을 유지합니다.
  3. 파일 이름 버저닝(Versioning)
    • 콘텐츠가 변경될 때마다 URL을 변경해 자동으로 새로운 데이터를 받아오도록 합니다.
      (예: product-info.json → product-info.20240409.json)

이 중 가장 권장되는 방법은 파일 이름에 버전이나 해시를 붙이는 방법으로, CDN 캐시 문제를 효과적으로 해결할 수 있습니다.

🔑 결론

Stale Data는 최신 데이터를 반영하지 못하는 오래된 데이터이며, CDN 사용 시 자주 발생하는 문제입니다. 무효화(Invalidation), 캐시 제어, 파일 버저닝 등의 방법으로 관리하는 것이 좋습니다.