Cache Strategy

캐싱은 API 설계에서 성능을 최적화하는 핵심 전략이다. 자주 요청되는 데이터를 임시 저장소에 저장함으로써 반복적인 계산, 데이터베이스 쿼리, 네트워크 요청을 줄이고 응답 시간을 대폭 향상시킬 수 있다.

API 캐싱은 현대 웹 애플리케이션과 분산 시스템의 성능, 확장성, 사용자 경험을 개선하는 필수적인 전략이다.

적절히 구현된 캐싱 전략은 다음과 같은 여러 이점을 제공한다:

그러나 API 캐싱은 단순히 기술적 구현 이상의 것이다. 효과적인 캐싱 전략은 데이터의 특성, 사용자 요구사항, 비즈니스 우선순위를 철저히 이해하고 이를 기반으로 설계되어야 한다. 데이터의 신선도, 캐시 적중률, 리소스 사용, 구현 복잡성 간의 균형을 맞추는 것이 중요하다.

또한, 캐싱은 정적인 것이 아니라 시스템과 함께 발전해야 하는 동적인 전략이다. 캐시 성능을 지속적으로 모니터링하고, 사용 패턴 변화에 따라 전략을 조정하며, 새로운 도구와 기술을 평가하는 것이 필요하다.

최종적으로, API 캐싱의 성공은 그것이 얼마나 보이지 않는지에 달려 있다. 사용자는 단지 빠르고 안정적으로 작동하는 API를 경험할 뿐, 그 뒤에서 작동하는 복잡한 캐싱 메커니즘에 대해서는 알 필요가 없다. 이것이 바로 잘 설계된 캐싱 전략의 특징이다. - 복잡성은 숨기고, 사용자에게는 원활한 경험만 제공하는 것이다.

API 캐싱의 중요성과 이점

API 캐싱을 구현하면 다음과 같은 여러 이점을 얻을 수 있다:

  1. 성능 향상
    캐싱은 응답 시간을 크게 단축시킨다. 데이터베이스 접근, 복잡한 계산, 외부 서비스 호출 등 시간이 많이 소요되는 작업의 결과를 캐시에 저장하여 재사용함으로써, 사용자에게 훨씬 빠른 응답을 제공할 수 있다.

  2. 서버 부하 감소
    자주 요청되는 데이터를 캐싱하면 서버가 처리해야 할 요청 수가 줄어든다. 이는 CPU, 메모리, 데이터베이스 연결과 같은 서버 리소스의 사용을 최적화하여 더 많은 요청을 처리할 수 있게 한다.

  3. 확장성 개선
    효과적인 캐싱 전략은 시스템의 확장성을 크게 향상시킨다. 동일한 하드웨어로 더 많은 요청을 처리할 수 있게 되므로, 인프라 비용을 절감하면서도 성장하는 트래픽을 수용할 수 있다.

  4. 안정성 향상
    외부 서비스나 데이터베이스에 일시적인 장애가 발생하더라도, 캐시된 데이터를 통해 서비스를 계속 제공할 수 있다. 이는 시스템의 전반적인 안정성과 회복력을 높이는 데 기여한다.

  5. 대역폭 절약
    네트워크 대역폭 사용을 줄임으로써, 특히 모바일 환경이나 제한된 네트워크 환경에서 사용자 경험을 개선할 수 있다.

API 캐싱의 기본 원칙

효과적인 API 캐싱을 구현하기 위해서는 몇 가지 핵심 원칙을 이해하는 것이 중요하다:

  1. 캐시 위치(Cache Location)
    캐시는 시스템의 여러 계층에 위치할 수 있으며, 각 위치는 고유한 장단점을 갖는다:

    • 클라이언트 측 캐싱: 브라우저나 모바일 앱 등의 클라이언트에서 데이터를 캐싱
    • 네트워크 캐싱: CDN, 프록시 서버, API 게이트웨이에서의 캐싱
    • 서버 측 캐싱: API 서버 내부 또는 분산 캐시 시스템에서의 캐싱
    • 데이터베이스 캐싱: 데이터베이스 쿼리 결과나 계산된 데이터의 캐싱

  2. 캐시 무효화(Cache Invalidation)
    캐시된 데이터가 원본 데이터와 일치하도록 관리하는 과정은 캐싱에서 가장 어려운 부분 중 하나이다:

    • TTL(Time-To-Live) 기반: 일정 시간이 지나면 자동으로 캐시 항목 만료
    • 이벤트 기반: 데이터 변경 이벤트 발생 시 관련 캐시 항목 무효화
    • 버전 기반: 데이터 변경 시 새 버전 식별자를 사용하여 캐시 항목 관리

  3. 캐시 정책(Caching Policy)
    어떤 데이터를 얼마나 오래 캐싱할지 결정하는 정책은 애플리케이션의 특성과 요구사항에 맞게 설계되어야 한다:

    • 자주 접근되고 변경이 적은 데이터: 더 오랜 기간 캐싱
    • 자주 변경되는 데이터: 짧은 캐싱 기간 또는 특정 조건에서만 캐싱
    • 개인화된 데이터: 사용자별 캐싱 또는 캐싱 제외 고려

API 캐싱 전략 유형

API 캐싱은 다양한 수준과 위치에서 구현될 수 있으며, 각 전략은 특정 사용 사례와 요구사항에 적합하다.

다음은 주요 API 캐싱 전략들이다:

HTTP 캐싱

HTTP 프로토콜은 웹에서의 효율적인 캐싱을 위한 내장 메커니즘을 제공한다. 이 방법은 구현이 간단하며 브라우저, CDN, 프록시 서버 등 HTTP 스택의 모든 계층에서 작동한다.

주요 HTTP 캐싱 헤더

Cache-Control: 가장 중요한 캐싱 헤더로, 캐싱 동작을 세밀하게 제어한다.

1

Cache-Control: max-age=3600, public

주요 지시어:

ETag: 리소스의 특정 버전을 식별하는 고유 문자열이다. 변경 감지에 사용된다.

1

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Last-Modified: 리소스가 마지막으로 변경된 날짜와 시간을 나타낸다.

1

Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT

If-None-Match 및 If-Modified-Since: 클라이언트가 이전에 받은 ETag 또는 Last-Modified 정보를 사용하여 조건부 요청을 보낼 때 사용된다.

HTTP 캐싱 작동 방식
  1. 클라이언트가 리소스를 요청한다.
  2. 서버는 캐싱 헤더를 포함한 응답을 보낸다.
  3. 클라이언트(또는 중간 캐시)는 이 응답을 저장한다.
  4. 동일한 리소스에 대한 후속 요청 시, 캐시 정책에 따라:
    • 유효한 캐시가 있으면: 캐시된 응답을 직접 사용(304 Not Modified)
    • 캐시가 오래되었으면: 조건부 요청으로 서버에 재검증
구현 예제(Spring Boot)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

@RestController
public class ProductController {

    @GetMapping("/products/{id}")
    public ResponseEntity<Product> getProduct(@PathVariable Long id) {
        Product product = productService.findById(id);
        
        // ETag 생성 (제품 데이터의 해시 값)
        String etag = DigestUtils.md5DigestAsHex(product.toString().getBytes());
        
        return ResponseEntity.ok()
            .cacheControl(CacheControl.maxAge(1, TimeUnit.HOURS).cachePublic())
            .eTag(etag)
            .body(product);
    }
}
HTTP 캐싱의 장점
HTTP 캐싱의 단점

애플리케이션 레벨 캐싱

애플리케이션 레벨 캐싱은 API 서버 내부에서 메모리, 로컬 디스크 또는 전용 캐싱 시스템을 사용하여 구현된다. 이 방법은 세밀한 제어가 가능하고 특정 애플리케이션 요구사항에 맞게 최적화할 수 있다.

인메모리 캐싱

가장 단순하고 빠른 형태의 캐싱으로, 애플리케이션 메모리에 데이터를 직접 저장한다.

Node.js 구현 예제(node-cache):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

const NodeCache = require('node-cache');
const cache = new NodeCache({ stdTTL: 600 }); // 10분 TTL

async function getProductById(id) {
  // 캐시에서 먼저 확인
  const cacheKey = `product_${id}`;
  const cachedProduct = cache.get(cacheKey);
  
  if (cachedProduct) {
    console.log('Cache hit!');
    return cachedProduct;
  }
  
  // 캐시에 없으면 데이터베이스에서 조회
  console.log('Cache miss, fetching from database…');
  const product = await db.products.findById(id);
  
  // 결과를 캐시에 저장
  cache.set(cacheKey, product);
  
  return product;
}

Spring Boot 구현 예제(Caffeine):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

@Configuration
@EnableCaching
public class CacheConfig {

    @Bean
    public CacheManager cacheManager() {
        CaffeineCacheManager cacheManager = new CaffeineCacheManager("products");
        cacheManager.setCaffeine(Caffeine.newBuilder()
            .expireAfterWrite(10, TimeUnit.MINUTES)
            .maximumSize(1000));
        return cacheManager;
    }
}

@Service
public class ProductService {

    @Autowired
    private ProductRepository productRepository;
    
    @Cacheable(value = "products", key = "#id")
    public Product findById(Long id) {
        // 캐시 미스 시에만 실행됨
        return productRepository.findById(id)
            .orElseThrow(() -> new ProductNotFoundException(id));
    }
    
    @CacheEvict(value = "products", key = "#product.id")
    public Product update(Product product) {
        return productRepository.save(product);
    }
}
분산 캐싱

여러 서버 또는 인스턴스 간에 캐시를 공유하기 위해 Redis, Memcached와 같은 분산 캐시 시스템을 사용한다.

Node.js 구현 예제(Redis):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

const redis = require('redis');
const { promisify } = require('util');
const client = redis.createClient();

// 프로미스 기반으로 Redis 메서드 변환
const getAsync = promisify(client.get).bind(client);
const setAsync = promisify(client.set).bind(client);

async function getProductById(id) {
  const cacheKey = `product:${id}`;
  
  try {
    // 캐시에서 먼저 확인
    const cachedProduct = await getAsync(cacheKey);
    
    if (cachedProduct) {
      return JSON.parse(cachedProduct);
    }
    
    // 캐시에 없으면 데이터베이스에서 조회
    const product = await db.products.findById(id);
    
    // 결과를 캐시에 저장 (10분 TTL)
    await setAsync(cacheKey, JSON.stringify(product), 'EX', 600);
    
    return product;
  } catch (error) {
    console.error('Cache error:', error);
    // 캐시 오류 시 데이터베이스에서 직접 조회
    return await db.products.findById(id);
  }
}

Spring Boot 구현 예제(Redis):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

@Configuration
@EnableCaching
public class RedisCacheConfig {

    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory();
    }
    
    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory redisConnectionFactory) {
        RedisCacheConfiguration cacheConfig = RedisCacheConfiguration.defaultCacheConfig()
            .entryTtl(Duration.ofMinutes(10))
            .serializeValuesWith(
                RedisSerializationContext.SerializationPair.fromSerializer(
                    new GenericJackson2JsonRedisSerializer()));
        
        return RedisCacheManager.builder(redisConnectionFactory)
            .cacheDefaults(cacheConfig)
            .build();
    }
}

@Service
public class ProductService {

    @Cacheable(value = "products", key = "#id", unless = "#result == null")
    public Product findById(Long id) {
        return productRepository.findById(id).orElse(null);
    }
    
    @CacheEvict(value = "products", key = "#product.id")
    public Product update(Product product) {
        return productRepository.save(product);
    }
}
애플리케이션 레벨 캐싱의 장점
애플리케이션 레벨 캐싱의 단점

데이터베이스 캐싱

데이터베이스 자체에 내장된 캐싱 메커니즘을 활용하거나, 데이터베이스 쿼리 결과를 캐싱하는 전략.

데이터베이스 내장 캐싱

대부분의 데이터베이스 시스템은 내부적으로 다양한 캐싱 메커니즘을 제공한다:

MySQL 쿼리 캐싱 설정 예제:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

-- 쿼리 캐시 상태 확인
SHOW VARIABLES LIKE 'query_cache%';

-- 쿼리 캐시 활성화 (my.cnf 또는 my.ini 파일)
-- query_cache_type = 1
-- query_cache_size = 64M

-- 특정 쿼리에 대해 캐싱 활성화/비활성화
SELECT SQL_CACHE * FROM products WHERE category_id = 5;
SELECT SQL_NO_CACHE * FROM products WHERE category_id = 5;
ORM 수준의 캐싱

ORM(Object-Relational Mapping) 프레임워크는 일반적으로 여러 수준의 캐싱을 제공한다:

Hibernate 2차 캐시 구성 예제:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

@Configuration
@EnableCaching
public class HibernateCacheConfig {

    @Bean
    public LocalContainerEntityManagerFactoryBean entityManagerFactory() {
        LocalContainerEntityManagerFactoryBean em = new LocalContainerEntityManagerFactoryBean();
        // … 기본 설정 …
        
        Properties hibernateProps = new Properties();
        hibernateProps.setProperty("hibernate.cache.use_second_level_cache", "true");
        hibernateProps.setProperty("hibernate.cache.region.factory_class", 
            "org.hibernate.cache.jcache.JCacheRegionFactory");
        hibernateProps.setProperty("hibernate.javax.cache.provider", 
            "org.ehcache.jsr107.EhcacheCachingProvider");
        
        em.setJpaProperties(hibernateProps);
        return em;
    }
}

@Entity
@Table(name = "products")
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class Product {
    // 엔티티 정의
}
데이터베이스 캐싱의 장점
데이터베이스 캐싱의 단점

CDN 캐싱(Content Delivery Network)

CDN은 전 세계 여러 위치에 분산된 서버 네트워크를 통해 콘텐츠를 캐싱하고 제공한다. API 응답을 CDN을 통해 캐싱하면 지리적으로 분산된 사용자에게 더 빠른 응답을 제공할 수 있다.

CDN 캐싱 구성
  1. API 응답에 적절한 캐싱 헤더 설정(Cache-Control, Expires 등)
  2. CDN 서비스(Cloudflare, Akamai, AWS CloudFront 등) 구성
  3. API 엔드포인트를 CDN 배포에 연결

AWS CloudFront 설정 예제:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

{
  "DistributionConfig": {
    "DefaultCacheBehavior": {
      "TargetOriginId": "api-origin",
      "ViewerProtocolPolicy": "redirect-to-https",
      "AllowedMethods": {
        "Quantity": 7,
        "Items": ["GET", "HEAD", "OPTIONS", "PUT", "POST", "PATCH", "DELETE"]
      },
      "CachedMethods": {
        "Quantity": 3,
        "Items": ["GET", "HEAD", "OPTIONS"]
      },
      "ForwardedValues": {
        "QueryString": true,
        "Cookies": {
          "Forward": "whitelist",
          "WhitelistedNames": {
            "Quantity": 1,
            "Items": ["session-id"]
          }
        },
        "Headers": {
          "Quantity": 3,
          "Items": ["Authorization", "Accept", "Content-Type"]
        }
      },
      "MinTTL": 0,
      "DefaultTTL": 3600,
      "MaxTTL": 86400
    }
  }
}
CDN 캐싱을 위한 API 설계 고려사항
CDN 캐싱의 장점
CDN 캐싱의 단점

API 게이트웨이 캐싱

API 게이트웨이는 API 요청을 라우팅하고 관리하는 중간 계층으로, 자체적인 캐싱 기능을 제공한다. 이는 백엔드 서비스의 부하를 줄이고 응답 시간을 개선하는 데 도움이 된다.

주요 API 게이트웨이 캐싱 기능

AWS API Gateway 캐싱 구성 예제:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

{
  "stageName": "prod",
  "cacheClusterEnabled": true,
  "cacheClusterSize": "0.5",
  "methodSettings": {
    "*/*": {
      "cachingEnabled": true,
      "cacheTtlInSeconds": 300
    },
    "GET/products": {
      "cachingEnabled": true,
      "cacheTtlInSeconds": 3600
    },
    "GET/products/{id}": {
      "cachingEnabled": true,
      "cacheTtlInSeconds": 1800,
      "cacheKeyParameters": ["method.request.path.id"]
    },
    "POST/orders": {
      "cachingEnabled": false
    }
  }
}

Kong API Gateway 캐싱 플러그인 구성 예제:

1
2
3
4
5
6
7
8

plugins:
  - name: proxy-cache
    config:
      strategy: memory
      content_type:
        - application/json
      cache_ttl: 300
      cache_control: false
API 게이트웨이 캐싱의 장점
API 게이트웨이 캐싱의 단점

고급 API 캐싱 전략 및 패턴

기본적인 캐싱 전략을 넘어, 더 복잡한 요구사항에 대응하기 위한 고급 캐싱 패턴과 전략:

계층형 캐싱(Layered Caching)

다양한 수준에서 여러 캐시 계층을 조합하여 성능과 확장성을 최적화하는 전략이다.

구현 예:

장점:

프리디클티브 캐싱(Predictive Caching)

사용 패턴과 동향을 분석하여 실제로 요청되기 전에 데이터를 미리 캐싱하는 선제적 접근 방식.

구현 방법:

예시:

스태일-와일-리밸리데이트(Stale-While-Revalidate)

만료된 캐시 콘텐츠를 제공하면서 동시에 백그라운드에서 새로운 데이터로 캐시를 새로고침하는 전략.

HTTP 구현 예제:

1

Cache-Control: max-age=600, stale-while-revalidate=3600

애플리케이션 로직 구현:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

async function getData(key) {
  const cachedData = cache.get(key);
  const isStale = cachedData && cachedData.timestamp + maxAge < Date.now();
  
  if (cachedData) {
    // 캐시된 데이터가 오래되었다면, 백그라운드에서 새로고침
    if (isStale && !refreshingKeys.has(key)) {
      refreshingKeys.add(key);
      
      // 비동기적으로 데이터 새로고침
      setTimeout(async () => {
        try {
          const freshData = await fetchFromSource(key);
          cache.set(key, {
            data: freshData,
            timestamp: Date.now()
          });
        } finally {
          refreshingKeys.delete(key);
        }
      }, 0);
    }
    
    // 오래된 데이터라도 즉시 반환
    return cachedData.data;
  }
  
  // 캐시에 없으면 소스에서 가져옴
  const freshData = await fetchFromSource(key);
  cache.set(key, {
    data: freshData,
    timestamp: Date.now()
  });
  
  return freshData;
}

장점:

단점:

캐시 스탬핑 헤드(Cache Stampede/Thundering Herd) 방지

동시에 많은 요청이 캐시 미스를 경험할 때 백엔드 시스템에 갑작스러운 부하가 발생하는 현상을 방지하는 전략.

구현 방법:

  1. 잠금 메커니즘: 첫 번째 요청만 실제 데이터를 가져오고 나머지는 대기

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

    const locks = new Map();

async function getDataWithLock(key) {
  const cachedData = cache.get(key);

  if (cachedData) {
    return cachedData;
  }

  // 이미 진행 중인 요청이 있는지 확인
  if (locks.has(key)) {
    // 다른 요청이 데이터를 가져오는 동안 대기
    return new Promise(resolve => {
      const checkInterval = setInterval(() => {
        const data = cache.get(key);
        if (data) {
          clearInterval(checkInterval);
          resolve(data);
        }
      }, 50);
    });
  }

  // 잠금 설정
  locks.set(key, true);

  try {
    // 소스에서 데이터 가져오기
    const data = await fetchFromSource(key);
    cache.set(key, data);
    return data;
  } finally {
    // 잠금 해제
    locks.delete(key);
  }
}

  2. 프로배빌리스틱 조기 만료(Probabilistic Early Expiration): 캐시 항목의 실제 만료 전에 일부 요청만 새로고침 허용

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

    function shouldRefreshCache(ttl, maxAge) {
  const elapsed = maxAge - ttl;
  const probability = elapsed / maxAge;

  return Math.random() <= probability;
}

async function getData(key) {
  const cachedItem = cache.get(key);

  if (cachedItem) {
    const ttl = cachedItem.expiry - Date.now();

    // 아직 만료되지 않았지만 확률적으로 새로고침 결정
    if (ttl > 0 && !shouldRefreshCache(ttl, MAX_AGE)) {
      return cachedItem.data;
    }
  }

  // 캐시 미스 또는 새로고침 필요
  const data = await fetchFromSource(key);

  cache.set(key, {
    data,
    expiry: Date.now() + MAX_AGE
  });

  return data;
}

  3. 배경 새로고침(Background Refresh): 만료 시간에 가까워지면 백그라운드에서 주기적으로 캐시 미리 새로고침

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

    // 캐시 새로고침 작업을 스케줄링하는 시스템
const refreshScheduler = {
  tasks: new Map(),

  schedule(key, ttl) {
    // 이미 예약된 작업이 있다면 취소
    if (this.tasks.has(key)) {
      clearTimeout(this.tasks.get(key));
    }

    // 만료 10초 전에 새로고침 작업 예약
    const refreshTime = Math.max(ttl - 10000, 0);
    const taskId = setTimeout(async () => {
      try {
        const freshData = await fetchFromSource(key);
        cache.set(key, {
          data: freshData,
          expiry: Date.now() + MAX_AGE
        });
        // 새 만료 시간으로 다시 스케줄링
        this.schedule(key, MAX_AGE);
      } catch (error) {
        console.error(`Background refresh failed for ${key}:`, error);
      }
    }, refreshTime);

    this.tasks.set(key, taskId);
  }
};

장점:

컨텍스트 인식 캐싱(Context-Aware Caching)

사용자 컨텍스트(위치, 기기, 사용자 세그먼트 등)에 따라 캐싱 전략을 동적으로 조정하는 고급 접근법.

구현 고려사항:

  1. 캐시 키 전략: 컨텍스트 정보를 캐시 키에 통합

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

    function generateCacheKey(baseKey, context) {
  // 필요한 컨텍스트 요소만 선택
  const relevantContext = {
    country: context.country,
    userType: context.userType,
    device: context.deviceCategory
  };

  // 컨텍스트를 정렬된 문자열로 변환하여 일관성 유지
  const contextString = JSON.stringify(relevantContext, Object.keys(relevantContext).sort());

  return `${baseKey}:${hash(contextString)}`;
}

  2. 변형 관리(Variant Management): 동일한 리소스의 다양한 컨텍스트별 변형 관리

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

    async function getProductDetails(productId, userContext) {
  // 베이스 키와 컨텍스트 기반 키 생성
  const baseKey = `product:${productId}`;
  const contextKey = generateCacheKey(baseKey, userContext);

  // 먼저 컨텍스트별 캐시 확인
  let data = cache.get(contextKey);
  if (data) return data;

  // 컨텍스트별 캐시 미스 시 기본 캐시 확인
  data = cache.get(baseKey);
  if (data) {
    // 기본 데이터를 컨텍스트에 맞게 변환
    const contextualizedData = contextualizeData(data, userContext);

    // 컨텍스트별 캐시에 저장
    cache.set(contextKey, contextualizedData, CONTEXT_TTL);

    return contextualizedData;
  }

  // 모든 캐시 미스 시 원본에서 가져오기
  data = await fetchProductFromSource(productId);

  // 기본 캐시 저장
  cache.set(baseKey, data, BASE_TTL);

  // 컨텍스트화 및 컨텍스트별 캐시 저장
  const contextualizedData = contextualizeData(data, userContext);
  cache.set(contextKey, contextualizedData, CONTEXT_TTL);

  return contextualizedData;
}

  3. 적응형 TTL: 컨텍스트, 데이터 유형, 사용 패턴에 따라 캐시 만료 시간 동적 조정

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

    function determineTTL(resourceType, context, usagePattern) {
  let baseTTL = DEFAULT_TTL;

  // 리소스 유형별 기본 TTL 조정
  switch (resourceType) {
    case 'product': baseTTL = 3600; break; // 1시간
    case 'category': baseTTL = 7200; break; // 2시간
    case 'userProfile': baseTTL = 300; break; // 5분
  }

  // 지역별 조정
  if (context.country === 'US') {
    baseTTL *= 0.8; // 미국은 데이터 변화가 빠르므로 TTL 감소
  }

  // 사용 패턴별 조정
  if (usagePattern === 'highFrequency') {
    baseTTL *= 1.5; // 자주 접근되는 데이터는 더 오래 캐싱
  }

  return Math.floor(baseTTL);
}

장점:

단점:

에지 컴퓨팅 기반 캐싱(Edge Computing-Based Caching)

콘텐츠를 사용자에게 가까운 에지 위치에서 캐싱 및 처리하여 지연 시간을 최소화하는 전략.

주요 에지 캐싱 패턴:

  1. 정적 에지 캐싱: 변경이 적은 데이터를 에지에 장기간 캐싱

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

    // Cloudflare Workers 예제
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const cacheKey = new URL(request.url);

  // 캐시 확인
  const cache = caches.default;
  let response = await cache.match(request);

  if (!response) {
    // 원본 서버에서 가져오기
    response = await fetch(request);

    // 성공적인 GET 요청만 캐싱
    if (request.method === 'GET' && response.status === 200) {
      // 에지에 1시간 동안 캐싱
      const newResponse = new Response(response.body, response);
      newResponse.headers.set('Cache-Control', 'public, max-age=3600');

      event.waitUntil(cache.put(request, newResponse.clone()));
      return newResponse;
    }
  }

  return response;
}

  2. 동적 에지 생성(Dynamic Edge Generation): 에지에서 부분적 콘텐츠 생성 및 변환

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

    // Cloudflare Workers 예제 - 데이터 변환
async function handleRequest(request) {
  // 원본 API에서 데이터 가져오기
  const apiResponse = await fetch('https://api.example.com/data');
  const data = await apiResponse.json();

  // 에지에서 데이터 필터링 및 변환
  const transformedData = transformAtEdge(data, getRegionFromRequest(request));

  // 변환된 결과 반환
  return new Response(JSON.stringify(transformedData), {
    headers: {
      'Content-Type': 'application/json',
      'Cache-Control': 'public, max-age=60'
    }
  });
}

function transformAtEdge(data, region) {
  // 지역에 따라 데이터 필터링 및 정렬
  return data
    .filter(item => item.availableRegions.includes(region))
    .sort((a, b) => b.relevanceScore - a.relevanceScore)
    .slice(0, 20); // 상위 20개 항목만 유지
}

  3. 근접성 기반 라우팅(Proximity-Based Routing): 사용자와 가장 가까운 에지 또는 원본 서버로 요청 라우팅

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

    async function handleRequest(request) {
  const userLocation = request.cf.country || 'US';

  // 사용자 위치에 기반한 최적의 데이터 소스 결정
  const dataSource = determineOptimalDataSource(userLocation);

  // 데이터 소스에서 데이터 가져오기
  return fetch(`https://${dataSource}/api/data`, {
    headers: request.headers
  });
}

function determineOptimalDataSource(location) {
  const regionMap = {
    'US': 'us-east.api.example.com',
    'CA': 'us-east.api.example.com',
    'GB': 'eu-west.api.example.com',
    'DE': 'eu-central.api.example.com',
    'JP': 'ap-northeast.api.example.com',
    'AU': 'ap-southeast.api.example.com'
  };

  return regionMap[location] || 'global.api.example.com';
}

장점:

단점:

API 캐싱을 위한 모범 사례

효과적인 API 캐싱을 위한 핵심 모범 사례와 권장 사항은 다음과 같다:

  1. 캐싱 정책 설계

    • 리소스별 캐싱 전략: 각 API 엔드포인트의 특성(변경 빈도, 중요도, 접근 패턴)에 맞는 캐싱 정책 설계
    • 캐시 계층화: 여러 캐싱 레이어(클라이언트, CDN, API 게이트웨이, 애플리케이션)의 특성을 활용한 전략 구성
    • TTL 최적화: 데이터 특성에 따라 적절한 캐시 수명 설정
    • 일관된 캐싱 헤더: 모든 응답에 명확하고 일관된 캐싱 헤더 제공

  2. 캐시 키 설계

    • 효과적인 캐시 키 선택: URL 경로, 쿼리 매개변수, 헤더 등을 고려한 캐시 키 설계
    • 정규화: 동일한 리소스에 대한 다양한 URL 형식을 정규화하여 캐시 효율성 향상
    • 버전 관리: 캐시 키에 리소스 버전 포함하여 갱신 관리
    • 컨텍스트 고려: 필요에 따라 사용자 세그먼트, 디바이스 유형, 위치 등 컨텍스트 정보 포함
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

    function generateCacheKey(request) {
  // 기본 URL 및 경로 정규화
  const url = new URL(request.url);
  const path = url.pathname.toLowerCase().replace(/\/+$/, '');

  // 필수 쿼리 매개변수만 포함 (정렬하여 일관성 유지)
  const relevantParams = ['category', 'sort', 'limit'];
  const queryParams = {};

  relevantParams.forEach(param => {
    if (url.searchParams.has(param)) {
      queryParams[param] = url.searchParams.get(param);
    }
  });

  const queryString = new URLSearchParams(queryParams).toString();

  // 관련 헤더 포함 (예: 언어, 국가)
  const language = request.headers.get('Accept-Language') || 'en';
  const country = request.headers.get('CF-IPCountry') || 'US';

  // API 버전 고려
  const apiVersion = request.headers.get('API-Version') || 'v1';

  return `${apiVersion}:${path}:${queryString}:${language}:${country}`;
}

  3. 캐시 무효화 전략

    • 시간 기반 만료: 적절한 TTL 설정으로 자동 만료
    • 명시적 무효화: 데이터 변경 시 관련 캐시 항목 명시적 삭제
    • 버전 기반 무효화: 리소스 버전을 변경하여 캐시 우회
    • 일괄 무효화: 관련 캐시 항목 그룹을 한 번에 무효화
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

    // Redis 캐시 무효화 예제
async function invalidateCache(patterns) {
  const redisClient = getRedisClient();

  for (const pattern of patterns) {
    // 패턴과 일치하는 모든 키 찾기
    const keys = await redisClient.keys(pattern);

    if (keys.length > 0) {
      // 일치하는 모든 키 삭제
      await redisClient.del(keys);
      console.log(`Invalidated ${keys.length} cache entries matching pattern: ${pattern}`);
    }
  }
}

// 제품 업데이트 시 관련 캐시 무효화
async function updateProduct(productId, productData) {
  // 제품 업데이트
  await database.products.update(productId, productData);

  // 관련 캐시 항목 무효화
  await invalidateCache([
    `product:${productId}*`,           // 제품 세부 정보
    `category:${productData.categoryId}*`,  // 카테고리 목록
    `search:*`                         // 검색 결과
  ]);
}

  4. 모니터링 및 최적화

    • 캐시 적중률 추적: 캐시 성능을 측정하기 위한 지표 모니터링
    • 핫스팟 식별: 자주 접근되지만 캐시되지 않는 리소스 식별
    • 캐시 크기 최적화: 메모리 사용량과 캐시 적중률 간의 균형 조정
    • TTL 미세 조정: 사용 패턴에 따른 TTL 주기적 조정
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

    // 캐시 메트릭 수집 미들웨어
function cacheMetricsMiddleware(req, res, next) {
  const startTime = Date.now();
  const originalSend = res.send;

  // 캐시 상태 확인을 위한 플래그 추가
  req.cacheStatus = 'MISS'; // 기본값

  // 응답 메서드 오버라이드
  res.send = function(body) {
    const responseTime = Date.now() - startTime;

    // 메트릭 수집
    const metrics = {
      path: req.path,
      method: req.method,
      status: res.statusCode,
      responseTime,
      cacheStatus: req.cacheStatus,
      contentLength: Buffer.isBuffer(body) ? body.length : Buffer.byteLength(body)
    };

    // 메트릭 저장 또는 전송
    recordMetrics(metrics);

    // 원래 메서드 호출
    return originalSend.call(this, body);
  };

  next();
}

// Redis 캐시 래퍼 예제 (메트릭 수집 포함)
async function getCachedData(req, key, fetchFunction) {
  const redisClient = getRedisClient();

  try {
    // 캐시 확인
    const cachedData = await redisClient.get(key);

    if (cachedData) {
      // 캐시 적중
      req.cacheStatus = 'HIT';
      return JSON.parse(cachedData);
    }

    // 캐시 미스
    req.cacheStatus = 'MISS';

    // 원본 데이터 가져오기
    const data = await fetchFunction();

    // 결과 캐싱
    await redisClient.set(key, JSON.stringify(data), 'EX', 3600);

    return data;
  } catch (error) {
    // 오류 발생 시
    req.cacheStatus = 'ERROR';
    throw error;
  }
}

  5. 보안 고려사항

    • 민감한 데이터 캐싱 제한: 개인 식별 정보(PII)나 민감한 데이터는 캐싱 제외
    • 인증된 콘텐츠 처리: 인증이 필요한 데이터의 적절한 캐싱 전략 구현
    • 캐시 포이즌(Cache Poisoning) 방지: 사용자 입력 검증 및 캐시 키 설계 주의
    • HTTPS 사용: 전송 중 데이터 보호
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

    function shouldCacheResponse(request, response) {
  // 민감한 엔드포인트는 캐싱하지 않음
  if (request.path.includes('/user/') || 
      request.path.includes('/payment/') ||
      request.path.includes('/admin/')) {
    return false;
  }

  // 인증된 요청은 특별히 처리
  if (request.headers.has('Authorization')) {
    // 개인화된 데이터는 캐싱하지 않음
    return false;

    // 또는 사용자별 캐시 키 사용 (주의 필요)
    // request.cacheKey = `${request.cacheKey}:user:${getUserIdFromToken(request)}`;
    // return true;
  }

  // 오류 응답은 캐싱하지 않음
  if (response.status >= 400) {
    return false;
  }

  // 나머지는 캐싱
  return true;
}

API 캐싱 구현 사례 연구

실제 API 캐싱 구현의 예시를 통해 다양한 전략과 그 효과를 살펴보자:

사례 1: 전자상거래 API 캐싱

시나리오: 대규모 전자상거래 플랫폼의 제품 및 카테고리 API

도전 과제:

구현된 캐싱 전략:

  1. 다중 계층 캐싱:
    • CDN: 제품 이미지, 설명 등 정적 콘텐츠 (TTL: 24시간)
    • API 게이트웨이: 카테고리 목록, 제품 검색 결과 (TTL: 15분)
    • 애플리케이션 캐시(Redis): 제품 상세 정보 (TTL: 5분)
    • 데이터베이스 쿼리 캐시: 복잡한 집계 쿼리 (TTL: 1시간)
  2. 컨텍스트 인식 캐싱:
    • 국가/지역별 가격 및 재고 캐싱
    • 사용자 세그먼트별 추천 제품 캐싱
  3. 재고 관리를 위한 특수 전략:
    • 재고 숫자 > 20: 일반 캐싱 (TTL: 5분)
    • 재고 숫자 <= 20: 짧은 캐싱 (TTL: 1분)
    • 재고 숫자 <= 5: 캐싱하지 않음 (실시간 확인)

결과:

사례 2: 소셜 미디어 API 캐싱

시나리오: 대규모 소셜 네트워크 플랫폼의 타임라인 및 사용자 프로필 API

도전 과제:

구현된 캐싱 전략:

  1. 프래그먼트 캐싱(Fragment Caching):
    • 타임라인의 개별 게시물 단위로 캐싱
    • 사용자 프로필의 각 섹션(기본 정보, 활동, 연결 등) 별도 캐싱
  2. 사용자별 캐싱:
    • 사용자 ID 기반 캐시 키
    • 활성 사용자와 비활성 사용자에 대한 차별화된 TTL
  3. 타임라인 최적화:
    • ‘인기’ 타임라인: 광범위하게 캐싱 (TTL: 5분)
    • ‘팔로우’ 타임라인: 사용자별 캐싱 + 실시간 업데이트 병합
    • 댓글 및 반응: 읽기 전용 캐싱 + 쓰기 시 무효화
  4. 푸시 기반 무효화:
    • 콘텐츠 업데이트 시 이벤트 기반 캐시 무효화
    • 팬아웃(fan-out) 기법으로 관련 사용자의 캐시 선택적 무효화

결과:

사례 3: 금융 서비스 API 캐싱

시나리오: 주식 시세, 계좌 정보, 거래 이력을 제공하는 금융 API

도전 과제:

구현된 캐싱 전략:

  1. 데이터 유형별 차별화된 전략:
    • 시장 데이터(공개): 적극적인 캐싱 + 짧은 TTL (10-30초)
    • 계좌 요약 정보: 제한적 캐싱 + 인증 컨텍스트 포함 (TTL: 5분)
    • 거래 이력: 읽기 전용 캐싱 (TTL: 15분)
    • 개인 금융 정보: 캐싱하지 않음
  2. 타임스탬프 기반 캐싱:
    • 시장 시간 외 데이터: 장기 캐싱 (TTL: 몇 시간)
    • 거래 시간 중 데이터: 매우 짧은 캐싱 (TTL: 10초)
    • 장 마감 후 데이터: 중간 길이 캐싱 (TTL: 10분)
  3. 안전한 사용자별 캐싱:
    • 암호화된 사용자 식별자 기반 캐시 키
    • 메모리 전용 캐싱 (디스크에 저장하지 않음)
    • 세션 종료 시 자동 캐시 무효화
  4. 이벤트 기반 실시간 업데이트:
    • WebSocket을 통한 시장 데이터 실시간 푸시
    • 거래 완료 후 관련 캐시 즉시 무효화

결과:

용어 정리

용어설명

참고 및 출처