Today I Learned
(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
- 데이터 간 관계가 없기 때문에
- 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 에 관한 간단한 이론을 정리를 한 것이지,
실제로 코드를 작성하면서 해야하는 실습부분에서는 부족하기 때문에 오늘 정리한 이론을 바탕으로
실제 팀 프로젝트시 적용하면서 실습을 해야할 것
'Today I Learned' 카테고리의 다른 글
(24.07.15)[14주차] 프로젝트 중 동시성 제어를 위한 Redisson 활용 (1) | 2024.07.15 |
---|---|
(24.07.09)[13주차] @DataJpaTest 슬라이스 테스트에서의 빈 등록 (0) | 2024.07.09 |
(24.07.03)[12주차] QueryDSL사용을 위한 Repository 분리 (0) | 2024.07.03 |
(24.07.02)[12주차] QueryDSL의 Wildcard 와 Count (0) | 2024.07.02 |
(24.06.28)[11주차] QueryDSL과 SQL의 비교와 정리 (0) | 2024.06.28 |