대표적인 캐싱 전략

ElastiCache를 이용해서 캐싱하는 전략에는 대표적으로 2가지가 있습니다.

  • Lazy loading
  • Write-through

Lazy loading은 말 그대로 지연 로딩으로, 데이터 요청이 있을 때만 캐싱됩니다. 즉, 최소 1번은 데이터를 조회해야만 캐싱이 되고, 최초 조회시 DB에 직접 요청하므로 느리다는 점이 단점입니다. 반면에, 데이터가 갱신되었을 때 기존에 캐싱된 데이터만 무효화 시키면 되는 점은 장점입니다.

Write-through 방식은 데이터 갱신시 캐시와 DB에 모두 업데이트하는 방식입니다. DB가 업데이트될 때마다 별도로 캐시도 업데이트 해줘야 하는 수고로움은 단점이지만, 이 작업이 끝나면 데이터 조회시 항상 캐시에서 조회하므로 속도가 빠릅니다.

Lazy loading
캐싱 전략 장점 단점
Lazy loading 요청한 데이터만 캐싱하므로 별도의 캐싱 작업이 필요없음 최초 요청시 데이터베이스에 직접 쿼리하므로 느림
Write-through 데이터 갱신이 끝나면, 모든 데이터가 캐싱되어 있으므로 조회시 항상 캐시를 읽어와 빠름 데이터 갱신시 DB, 캐시에 모두 업데이트하므로 느림
캐싱 전략별 장단점

실제 적용 예

현재 운영 중인 웹 서비스는 하루에 1번 데이터가 갱신됩니다. 사용자가 메뉴를 클릭시 요청한 대부분의 API는 3초 이내에 처리되지만, 사용자의 편의를 위해 처리 시간을 1초 내로 줄이고 싶습니다. 또 일부 메뉴는 연산할 데이터가 많아 실시간으로 처리하기엔 너무 오래 걸립니다. 이런 경우엔 어떻게 캐시를 적용해야 할까요?

Write-through 방식으로 모든 데이터를 매번 캐시에 업데이트하자니 부담스럽고, Lazy loading 방식처럼 매번 데이터를 처음 요청할 때마다 느린 것을 감수하자니 그것도 불편합니다. 그래서 두 개를 적절히 조합해서 이렇게 사용해보기로 합니다.

기본적으로 모든 API는 Lazy loading 방식으로 동작하게 합니다. 데이터가 갱신될 때, 캐시에 올라간 모든 데이터를 삭제합니다. 그리고 메뉴 클릭시 처음 조회하는 데이터에 한해서 캐싱합니다. 또한, 실시간으로 처리하기 어려운 메뉴의 데이터도 캐싱합니다.

위와 같은 방식으로 캐시를 사용하면, 데이터가 갱신될 때마다 모두 캐싱하지는 않지만, 일부 데이터를 캐싱함으로써 사용자에게 빠른 조회 속도를 보장할 수 있습니다.
또한, 실시간으로 처리하기 힘든 메뉴의 데이터도 1초이내에 제공할 수 있습니다.