캐싱을 도입했다가 철회한 경우들. (첫번째 경우)

   프로젝트를 진행하면서 캐싱을 도입했다가 캐싱을 효과적으로 사용하지 못한다고 느껴서 철회한 경우가 있어서 정리를 하며 캐싱을 도입하는 이유에 대해 고찰을 해보자고 합니다. 

 

A. 첫번째 경우:   Redis  -> DB

 

캐시를 임시 DB처럼 사용하다가 DB를 이용하도록 변경 결정

   

1. 캐시 사용의 이유 

•  프로젝트에서 필요한 가게 관련 데이터를 Kakao API의 DB에 의존하는 특성상 데이터를 관리할 수 없습니다.
• 그래서 관련 데이터를 DB에 저장하여  관리하기보다는, 가게 검색시 카카오 API 요청으로 받는 가게 정보를 일시적으로 캐싱해 재검색시 API 요청을 줄여 성능 향상및 API 요청에 대한 비용을 줄이려고 했습니다.

2. 프로젝트 변경

• 그렇지만, 이후 가게 사장님이 직접 가게 정보를 추가할 수도 있게 서비스가 변경되면서 프로젝트의 DB에 저장된 정보와 캐싱된 카카오 API의 정보가 조회시 합쳐서 제공하게 되었습니다.
• 이를 구분하기 위해 API:1, DB:1 이런 식으로 의미가 있는 식별자를 사용하게 되었습니다.
• 변화된 상황에 현재 캐시에 API정보와 DB 정보가 공존하는 설계가 오히려 복잡성을 증가 시키고, 의미있는 식별자를 사용하게 되는 문제점도 있어 두가지 데이터를 합친 테이블을 DB에서 관리하는 방식으로 변경하였습니다. 

3. 캐시를 DB처럼 사용할 때의 문제점

서비스에 변화가 생기면서 이전의 레디스를 DB처럼 사용하는 아키텍처의 취약점에 관련한 인사이트를 얻게 되었습니다.

• 캐시는 일반적으로 HDD나 SDD같은 파일시스템에 저장되지 않고 RAM에 저장됩니다. 이를 통해, 빠른 조회 성능을 가질 수 있지만, 메모리가 제한적이여서 요청이 많아질 경우 메모리가 부족해 질 수 있습니다.
• 또한,  현재 캐싱되는 정보는 자주 조회되는 쿼리나 결과는 아니여서 임시 DB의 역할을 하고 있을 뿐, 캐싱을 사용함으로서 얻는 이점을 누리지 못하고 있었습니다. (캐시 적중률 낮음.)
• 그렇다면 캐시 적중률이 낮은 상황에서 임시 DB로 휘발성이 있는 캐시를 사용하기 보다는 DB를 사용하는 것이 더욱 안정적으로 데이터를 제공하면서 현재 식별자 문제도 해결할 수 있다고 생각하였습니다. 
• 캐시를 사용한다면 자주 조회 될 가능성이 높아 캐시 적중률(캐시 히트)를 높일 수 있는 경우에 사용하려고 합니다.

Article1: 응답속도 향상을 위한 캐싱 적용기 (+ 언제 캐싱을 쓰는게 좋을까?)

이어보기: 캐싱을 도입했다가 철회한 경우들. (두번째 경우)