Cache

캐시 도입 이유

페이지마다 필요한 데이터를 서버에서 불러와 상태로 저장하게 되는데 가계부 내역 처럼 여러곳에서 사용되는 경우 같은 데이터를 중복으로 요청하게 된다. 서버로 가는 요청을 한번이라도 줄일 수 있다면 많은 사용자가 모였을때 성능적으로 큰 이득을 볼 수 있을것으로 판단하여 캐시를 도입하게 되었다.

캐시 전략

• API를 요청하기 전 캐시에서 데이터가 존재하는지 확인하고 캐시가 있다면 캐시 데이터를 응답한다. 캐시 데이터가 없으면 서버로 API 요청을 전송하고 응답된 데이터를 캐시에 저장한다.

• 가계부 내역처럼 월 별로 저장되는 캐싱 데이터는 최대 12개월의 데이터를 보관하고 추가로 캐싱이 요청되면 요청된 데이터의 날짜에서 가장 먼 날짜의 캐시 데이터를 삭제하여 공간을 확보한다.

  • 현재 서비스 구현 방식이 월별로 한칸씩 이동하기 때문에 가까운 월 데이터로의 참조 가능성이 가장 높고 먼 날짜의 월 데이터로의 참조 가능성은 가장 낮기 때문

• 데이터가 새로 등록되거나 수정/삭제 되면 해당하는 캐싱 데이터를 삭제하고 새로 캐싱 될 수 있도록 한다.

캐싱 적용 모습

한계점

• 월 별로 캐싱 된 데이터가 다시 사용되는 빈도가 낮다면 캐싱의 의미가 떨어지고 메모리의 낭비가 된다
• 데이터 등록,수정,삭제에 대한 캐시의 처리
  • 해당하는 캐시 데이터를 삭제하고 다음 요청에서 다시 캐싱 되도록 처리
  • 입력/수정 작업이 빈번하다면 사실상 캐싱의 의미가 떨어짐