(24.07.04)[12주차] Redis 강의 학습

Spring 의 Mail Sender와 함께 인증번호를 전송하고 이를 인증 번호를 통해 회원가입시 본인인증을 진행하는 구축을 팀 프로젝트에서 사용한 적이 있었다.

 

당시에는 Redis에 대해서 제대로 알지를 못해서 사용을 했지만,

이번 학습 Session을 정리하면서 이론적으로 Redis에 대해 한번 정리를 했다.

---

Redis 강의 간단 정리

자료와 나만의 언어로 간단히 정리를 해보고 구체적인 내용은 Notion으로 옮겨서 학습을 진행

In-Memory Cache

• Redis, Memcached, Couchbase 등
  • In-Memory Cache는 사용한다는 의미, 분류로써는 NoSQL 이라고 할 수 있음

Query Cache

• DB 자체에서 사용하는 캐시
  • 동일 쿼리 실행 시 매번 조회하는 것이 아니라 캐시에 저장된 데이터를 반환

---

Cache 목적

• 복사는 복제와 달리 완벽하게 동일하게 복사하는 것으로 이를 사용하여 데이터를 미리 복사해서 저장해둬서 빠르게 접근할 수 있도록 하기 위해

---

Redis, Remote Dictionary Server

• 이름과 같이 데이터를 NoSQL 처럼 key-value pair를 저장하는 저장소
• 데이터를 메모리에 저장하여 빠르게 읽고 쓸 수 있는 성능을 제공
  • DB는 파일시스템을 사용, DB성능이 아무리 좋더라도 메모리단에서의 속도는 매우 빠름

제약

• 메모리 제약
  
  • 대규모 데이터를 저장하려면 많은 메모리가 필요 → 높은 성능과 용량의 물리적인 메모리가 필요하면서 리소스가 필요한 점
• 데이터 관리의 어려움
  • NoSQL이므로 복잡한 트랜잭션이나 RDBMS의 기능을 제공X
    • 데이터 간 관계가 없기 때문에
• 데이터 신뢰성
  • 메모리에 저장하기 때문에 서버가 종료시 곧 바로 데이터 손실

 

캐싱 적용을 해야하는 경우**

• 모든 DB 도 해당하는 내용
• 속도만 가지고 무조건 Redis를 사용하지 말아야한다는 점

데이터 접근 빈도가 많을 경우

• 자주 조회되는 데이터
  • 캐싱 메모리가 제한적이기 때문에 리소스 사용 및 유지 관리에 필요하기 때문

데이터 변경 빈도(= 일관성)가 적은 경우

• 변경이 잦거나 실시간 제공되어야 하는 데이터는 캐싱을 해서는 X
  • 캐시의 복사본에 의한 최신화가 필연적이기 때문에
  • 최신화를 위한 update에 대한 리소스 낭비가 발생

시스템 외부의 데이터일 경우

• 내부 시스템에 있는 데이터를 굳이 캐싱을 할 필요는 없음
  • 너무내부에서 가지고 와서 성능 리소스 효율을 낮추지 말아야

데이터 사용 패턴 = 쓰기 빈도가 낮은 데이터일 경우

• 데이트 일관성과 마찬가지로 계속 쓰기가 발생하지 않아야

 

Redis 유효기간

• DB와 다르게 TTL, Time to Live를 Expire로 데이터 유효기간을 지정 가능
• 만료된 데이터는 자동으로 데이터를 파기시킬 수 있음
  • DB 에서의 Access Token일 경우 만료가 되더라도 그 토큰을 찾아서 검증 후 삭제해야하지만, Redis는 알아서 지워줌

 

Redis 적용 전략

Cache through 방식

• Redis에서 miss 일경우 DB로 갔다오는 방식
• DB에서 받아왔으면 다시 Redis로도 update 해줘야함
• 가장 많이 쓰는 방식

Write through 방식

• Redis만 보는 방식
• Redis에서 데이터가 write 될 경우 DB에도 Redis가 바로 반영하는 방식

Read through 방식

• Redis에 데이터가 없으면, DB에서 가져와서 응답하는 방식

Write around 방식

• Cache through + Write through

 

 

---

Redis 에 관한 간단한 이론을 정리를 한 것이지,

실제로 코드를 작성하면서 해야하는 실습부분에서는 부족하기 때문에 오늘 정리한 이론을 바탕으로

실제 팀 프로젝트시 적용하면서 실습을 해야할 것