[E-commerce] 캐시를 통한 애플리케이션 성능 개선

 

Redis 캐시 읽기 전략

Look Aside (Cache Aside)

• 데이터를 조회할 때, 캐시에 저장된 데이터가 읽는지 확인하고 없으면 DB에서 조회하는 전략
• 캐시에 장애가 생겨도 DB에서 조회하면 되기 때문에 캐시 장애가 애플리케이션에 영향을 미치지 않는다.
• 동일 조회 쿼리가 반복적으로 발생하는 상황에서 적합한 전략

Read Through

• Look Aside 전략과 다르게 데이터를 캐시에서만 조회하는 전략
• 조회하려는 데이터가 캐시에 없으면 캐시에서 DB에 접근하여 조회 후 캐시에 저장
• DB에 접근하는 횟수를 줄여 성능을 높일 수 있지만 캐시에 장애가 발생할 경우 애플리케이션에 영향을 미친다.

Redis 캐시 쓰기 전략

Write Back

• 비동기로 캐시와 DB를 동기화 한다.
• DB에 저장할 데이터를 캐시에 저장해두었다가, 한번에 일정 주기마다 DB에 업데이트
• 한번에 DB에 쓰기 작업을 하기 때문에 쓰기 부하가 적다.
• 캐시에 저장된 데이터를 DB에 업데이트 전 캐시에 장애가 발생하면 데이터가 유실될 수 있는 문제가 있음
• 캐시와 DB간 데이터 정합성이 일치하지 않는 시점이 존재할 수 있다.

Write Through

• 동기적으로 데이터를 캐시와 DB에 같이 저장하는 전략 (데이터 저장 후 바로 캐시에 저장)
• DB와 캐시가 항상 동기화 되어 있어 캐시의 데이터를 최신 상태로 유지 가능
• DB와 캐시에 두번 저장 하기 때문에 쓰기, 수정 작업을 많이 하는 서비스에서는 리소스 낭비가 있을 수 있다.

Write Around

• 데이터를 캐시에 저장하지 않고 모두 DB에 저장하는 전략 (캐시 갱신 x)
• 데이터 조회 시 캐시에 없을 경우 캐시에 데이터를 저장
• 캐시와 DB간 데이터가 불일치 하는 경우가 있다. (데이터가 수정, 삭제될 때 마다 캐시도 삭제 또는 수정 해줘야 한다.)

어떤 캐시 읽기, 쓰기 전략을 선택해야 할까?

• 읽기 전략은 Read Through 보단 Look Aside(Cache Aside) 전략을 선택
  -> Read Through는 외부 캐시 저장소(redis)에 의존하고 있다 보니 레디스에 장애가 발생할 경우 애플리케이션에도 영향을 미치는 점이 큰 단점이라고 생각하여 속도 보단 서비스의 안정성이 더 높은 Look Aside 전략 선택
• 쓰기 전략은 Write Through 전략 선택
  데이터 일관성을 높이기 위해 쓰기 작업 과 동시에 동기적으로 캐시에도 저장하고 DB에도 저장하는 전략을 선택 (캐시 미스 발생 가능성 저하)

그래서 상품을 읽는 작업이 많은 이커머스 서비스에서 읽기 작업의 성능을 높이고, 데이터의 일관성을 유지하기 위해 Look Aside(Cache Aside) + Write Through를 선택

 

캐시를 적용하기 적합한 비즈니스 로직

• 빈번한 접근으로 재사용이 높은 데이터
• 자주 사용되는 데이터에 캐시를 적용하면 DB에 접근하는 횟수를 줄여 성능향상을 기대할 수 있다.
• 업데이트가 적은 데이터
  업데이트가 많은 데이터를 캐싱하면 캐싱된 데이터와 DB에 저장된 데이터와 불일치 하는 경우가 생기기 때문에 정합성이 중요한 데이터(계좌 잔액)는 캐시를 적용하지 않는다.
• 데이터를 가져오기 위한 연산 비용이 높은 데이터
• 비용이 큰 복잡한 쿼리를 캐시해두면 복잡한 쿼리를 실행하는 횟수를 줄여 성능을 향상시킬 수 있다.

 

현재 서비스에서 캐시를 적용하기 적합한 로직

• 인기 상품 조회
  인기 상품 조회는 쿼리의 연산 비용이 높고 자주 요청되는 데이터라고 판단되어 캐시를 적용하는 것이 효율적으로 판단
   -> 하지만 인기 판매 순위가 변동이 될 수 있기 때문에 데이터 정합성을 위해 적절한 Eviction 전략이 필요
• 상품 리스트 및 상품 상세 정보 조회
  이커머스 서비스 특성 상 상품 리스트와 상세 정보 조회는 필연적으로 이루어질 수 밖에 없기 때문에 캐시를 적용하면 효율을 높일 수 있을것으로 생각이 됨.
  -> 하지만 상품 재고를 수정하기 때문에 상품의 캐시 데이터를 업데이트 해줘야 한다.