Cache
- 같은 요청에 대해서 같은 결과를 제공할 때, 시간이 오래 걸리거나 많은 리소스를 사용하는 작업에 대한 결과를 계산해서 In-Memory에 저장해두었다가 재요청이 오면 재계산 없이 바로 결과를 돌려주는 것.
- 계산, DB 접근 등 사용할 리소스와 거리를 줄여준다.
- 80%의 활동을 20% 유저가 하기 때문에 20%의 데이터를 캐시하면, 서비스의 대부분 데이터를 커버할 수 있다. (파레토 법칙)
- 유용한 케이스
- 적은 데이터가 비번하게 접근될 때 유용하다.
- 여러 데이터가 조금씩 다 접근하면 캐시의 효용성은 떨어진다.
리소스 별 속도 비교
리소스 | 속도 | 비교속도(ns) | 비교 |
HDD I/O | 1~10ms | 1000000~10000000ns | NVME SSD보다 100배 이상 느리다. |
NVME SSD I/O | 7~150us | 7000~150000ns | RAM에 비해서 100배 이상 느리다. |
RAM Access | 70~100ns | 70~150ns |
In-Memory의 장단점
장점
- 접근 속도가 빠르므로, 다른 스토리지(SSD, HDD)를 쓰는 것보다 속도가 빠르다.
단점
- 다른 스토리지에 비해 크기가 작으면서 비싸다.
- 메모리는 SDD보다 20배 가량 비싸다.
* In-Memory는 성능이 중요할 때 보통 사용한다.
Cache 사용
- 사용자의 요청이 들어오게 되면 Cache를 확인한다.
- Hit일 경우, 해당 데이터를 바로 응답한다.
- miss일 경우, DB에 데이터를 요청한다.
- 전달 받은 데이터를 계산하고 사용자에게 응답한다.
DB 호출이 초당 100만 건일 경우
- DB Server의 성능을 Scale-up한다.
- 그러나, 어떤 장비든 한계가 존재하기 때문에 결국 Cache가 필요하게 된다.
캐시 대상 고려
- 자주 변하는 데이터인지 확인
- Key 정의 고려
- 유일성
- 유일성
- Value 정의 고려
- 응답 결과를 그대로 저장할 것인가?
- 필요한 데이터만 저장할 것인가?
* 캐시에 존재하는 데이터를 update 했을 시, 캐시에 존재하는 데이터를 지워서 잘못된 데이터를 응답하지 않도록 한다.
'Redis' 카테고리의 다른 글
Redis + Spring 설정 및 간단한 실습 (0) | 2022.11.24 |
---|---|
[Redis] Reids 내용 정리 (0) | 2022.11.08 |
[DB] Redis란? (0) | 2022.11.07 |