2023.03.21 (72일)

Day 72

---

- 실전 프로젝트

오늘은 크롤링한 데이터의 카테고리를 맞추고 조정하는 작업과 로그인 시 세션을 이용해서 로그인 상태를 유지하는 방법을 공부했다. 세션 아이디를 저장하고 인증해서 처리하는 것은 쉬웠으나 프론트에서 세션 아이디를 받아오는 과정에서 문제가 있었다. document.cookies()로 데이터를 받아오려 했으나 계속해서 -1이 반환되었다. 검색해보니 httpOnly 라는 설정때문이라는데 이 설정이 체크되어 있으면 자바스크립트에서 호출하는 것이 불가능하다고 한다. 그래서 다른 방법을 이용했는데 현재 타임리프를 이용하고 있어서 타임리프를 활용했다. model 값을 이용하는 것 처럼 session.{key값} 으로 저장된 value를 찾아올 수 있었다. 만약 저장되지 않았다면 null이 반환된다. 이 조건으로 로그인 로그아웃 버튼이 상황에 맞게 나오도록 변경하였다.

그 이외에 추가적인 공부로 레디스의 캐시를 공부했다. 오늘 공부한 내용을 정리하고 마무리하겠다.

캐싱

성능 향상을 위해 값을 복사해놓은 임시 기억 장치
→ 복사본을 저장해놓아서 속도가 느린 장치로의 접근 횟수를 줄여서 성능을 향상

캐시 데이터는 원본이 아니며 언제든 사라질 수 있음

관련 용어

• 캐시 적중 (Cache Hit) : 캐시에 접근해 데이터를 발견함
• 캐시 미스 (Cache Miss) : 캐시에 접근했지만 데이터를 발견하지 못함
• 캐시 삭제 정책 (Eviction Policy) : 캐시의 데이터 공간 확보를 위해 저장된 데이터 삭제
• 캐시 전략 (Eviction Policy) : 캐시의 운영 방식

캐시 전략

Cache-Aside (Lazy Loading)

일반적인 캐싱
항상 캐시를 먼저 체크하고 없으면 원본에서 읽어온 후 캐시에 저장

• 장점
  • 필요한 데이터만 저장
  • Cache Miss가 발생해도 치명적이지 않음
• 단점
  • 최초의 접근이 느림
  • 업데이트 주기가 일정하지 않아 정합성 문제 있음

Write-Through

데이터를 쓸 때 항상 캐시를 업데이트하여 최신 상태를 유지

• 장점
  • 캐시가 항상 동기화되어있음
• 단점
  • 자주 사용하지 않는 데이터도 캐시됨
  • 쓰기 지연 시간이 증가

Write-Back

데이터를 캐시에만 쓰고, 캐시의 데이터를 일정 주기로 DB에 업데이트

• 장점
  • 쓰기가 많은 경우 DB의 부하를 줄일 수 있음
• 단점
  • 캐시가 DB쓰기 전에 장애가 생기면 데이터 유실 가능

데이터 제거 방식

언제 어떤 데이터를 지울것인가?

• Expiration
  • 각 데이터에 TTL(Time-To-Live)을 설정해 시간 기반으로 삭제
• Eviction Algorithm : 공간을 확보해야 할 경우 어떤 데이터를 삭제할지 결정하는 방식
  • LRU (Least Recently Used) : 가장 오랫동안 사용되지 않은 데이터를 삭제
  • LFU (Least Frequently Used) : 가장 적게 사용된 데이터를 삭제
  • FIFO (First In First Out) : 먼저 들어온 데이터를 삭제

Spring에서의 Cache-Aside

CacheManager를 통해서 일반적인 캐시 인터페이스 구현
메서드 위에 @Cacheable 어노테이션으로 적용가능

Annotation	설명
@Cacheable	메소드에 캐시를 적용한다. (Cache-Aside 패턴 수행)
@CachePut	메소드의 리턴값을 캐시에 설정한다.
@CacheEvict	메소드의 키값을 기반으로 캐시를 삭제한다.