캐시전략 종류 살펴보기

일을 하다보면, 도메인과 아키텍처에 따라 캐시를 사용하는 방법이 달랐다. 캐시 전략의 종류와 사례를 정리해보자. 

Look-aside

애플리케이션에서 먼저 캐시를 확인하고, 캐시가 미스되면 DB 혹은 API를 호출하여 캐시를 해두는 방법을 말한다. 

사용 사례:

• 카디널리티가 높아서 모든 데이터를 캐싱해둘 수 없는 경우가 있다. 그러나 롱테일 분포에 의하여, 조회가 많이 되는 데이터는 한정적인 경우가 있다. 이럴 때에는 요청이 올 때 캐싱해두는게 현실적인 경우가 있다.
  • 예를 들어, 상품을 캐싱해둔다고 생각해보자. 수많은 상품 정보를 미리 캐싱해두는게 어려울 수 있다. 이 때, 자주 접근하는 상품 정보만 캐싱함으로써 효율적으로 캐싱을 할 수 있다.
• 다른 MSA 서버에서 제공하는 데이터라 캐싱 갱신 시점을 모르는 경우에도 유용하다. 
  • 만약 같은 애플리케이션에서 DB와 캐시 접근을 같이 한다면, DB가 갱신될 때 캐시도 갱신할 수 있다.
  • 그러나 타 서버에서 관리하는 데이터라 갱신 시점을 알 수 없는 경우가 있다.
    • 만약 변경 시점에 카프카 이벤트 발행 혹은 API를 호출해준다면, 알 수도 있다. 그런데 이를 제공받지 못하는 경우도 있다. 

참고 아티클: 

• 캐시를 적용하기 까지의 험난한 길 (TPS 1만 안정적으로 서비스하기)

Read-aside 

애플리케이션은 캐시만 조회하는 방법을 말한다. 만약 캐시가 미스되면, 캐시가 알아서 DB에서 조회하고 캐시를 채운다. 

사용 사례:

• Spring JPA 2차 캐시가 대표적인 Read-aside 사례이다. 개발자는 캐시 미스 시, 캐시를 다시 써주는 방법을 고민하지 않는다.

기타:

• Look-aside와 Read-aside는 얼핏 비슷해보인다.
• 그러나 Look-aside은 애플리케이션에서 캐시를 다시 써주는 작업을 해야하지만, Read-aside는 캐시 (or 라이브러리)가 이를 담당하는걸 말한다. 

 

Write-through 

데이터가 DB에 기록될 때, 동시에 캐시에도 기록하는 것을 말한다. 

사용 사례:

• 데이터의 주인인 애플리케이션에서 DB와 캐시를 동시에 쓰는 경우 유용하다.
• 예를 들어, 재고 관리 애플리케이션에서는 Write-through가 유용하다. 
  • 재고 증감/차감 시, 총 재고량을 관리하는 캐시를 써두는 방식으로 사용할 수 있다. 

Write-behind/Write-back

데이터를 먼저 캐시에 쓰고, 나중에 비동기적으로 DB에 기록하는 방법을 말한다. 

쓰기 작업 성능을 높이고, 갑작스런 트래픽 증가로 인한 부하를 방지하는 데에 도움이 되는 방법이다. 

사용 사례: 

• 배너 조회수를 캐시에 담아두고, 배치에서 이를 통계 DB에 퍼올리는 방법이 있다. 
  • 배너를 조회할 때마다 DB에 update문을 실행하면 DB 부하가 클 것이다. 이를 방지하기 위해 캐시를 사용할 때 활용하는 방법이다. 

Refresh-ahead

자주 접근하는 데이터를 만료되기 전에 미리 갱신하는 방법을 말한다. 

사용 사례:

• 사용기간이 제한된 데이터 목록을 통채로 캐싱해야하는 경우가 있다. 
• 예를 들어, 전시 기간이 지정된 배너 목록을 캐싱해두는 상황을 가정해보자. 배치에서 미리 갱신하지 않으면, 전시 기간이 지난 배너가 계속 조회되는 문제가 발생할 수 있다. 이 경우, 분단위 배치에서 최신 데이터를 갱신하면 문제를 해결할 수 있다.