Cache

[su3inni]

Cache : Caching

Caching 하는 경우

• 데이터 변경 가능성이 적을때 : 일관성 요구사항
• 자주 접근하는 데이터인 경우
• 동시 접속이 많은 경우
  • & 변경이 적은 경우 > 캐싱
  • & 변경이 많은 경우 > 리소스 확장으로 부하 분산 , 데이터베이스 성능 최적화, 요청 제한

Caching 관리

공유 : 여러 인스턴스에서 공유하는 경우 데이터 정합성 확인 필수적

• 데이터 정합성 확인을 위해
  • 수정 여부 확인 > 업데이트 드물고 충돌이 드물 경우 적합
  • Lock 사용 > Lock 을 사용하는 경우 대기열이 발생하기 때문에 데이터 크기가 작고 빠르게 수정가능하거나 빈번한 수정인 경우 적합

제거 : 캐시 데이터는 영구 저장소와 반드시 동기화 필요

• 만료정책으로 TTL 사용
  • TTL이 짧은 경우 > 성능 저하 대규모 트래픽인 경우 cache tempede 현상 발생
    • cache tempede 현상은 여러 환경에서 key 를 조회할 때, 한 번에 조회(duplicated read) 한 번에 작성 (duplicated write)으로 인해 성능저하가 발생하는 것을 의미한다. 요청 병목 현상으로 서비스 장애로 이어질 수 있다.
  • TTL이 긴 경우 > 데이터 정합성 확인 / 메모리 부족

Caching 전략

READ

• Lazy Loading : 요청받은 데이터에 대해 cahce에 저장
  • 요청받은 데이터에 대해서만 진행하기 때문에 효율적이며, 캐시 miss가 많이 발생할 수록 지연된다.
  • 초기 데이터는 항상 cache miss로 cache warming이 필요하다.
  • 캐시 조회 > DB 조회 > 캐시 저장
  • DB 조회는 앱서버가 진행한다.
• Read Through : 기본적인 부분은 Lazy Loading과 동일하지만 DB조회를 Cache 에서 한다는 차이점이 있다.

WRITE ( 데이터 생성/수정 )

• Write Through : 모든 데이터를 DB와 Cache에 저장

  • 모든 데이터를 DB 와 Cache에 동일하게 저장하기 때문에 최신 데이터를 유지한다.
  • 데이터가 유실되면 안되는 경우에 적합하다.
  • 리소스를 효율적으로 사용할 수 없다.

• Write Around : DB 에만 저장하고 필요한 경우 Cache에 저장

  • Lazy Loading과 함께 잘 쓰이는 전략이다.
  • 데이터가 잘 읽히지 않는 작업에 대해 적합하다. ex. 실시간 로그, 실시간 채팅
  • Write Through 전략보다 속도가 빠르다.

• Write Back : Cache에만 저장하다가 한 번에 DB에 저장

  • Insert 작업이 많고 쓰기 작업이 빈번할 때 적합하다.

Reference

• https://velog.io/@newdana01/DB-Redis-%ED%8A%B9%EC%A7%95%ED%99%9C%EC%9A%A9%EB%B2%95%EC%BA%90%EC%8B%B1%EC%A0%84%EB%9E%B5
• https://aws.amazon.com/ko/caching/