Redis를 어디서 들어봤지만 대충 DB관련된 툴이라고 들어본 정도가 다인 경우가 많다. 오늘은 Redis와 관련해서 알아야 하는 Cache에 대해서 정리해보았다.
Redis
Remote dictionary Server의 약자로, 기존의 데이터를 빠르고 쉽게 데이터를 접근할 수 있는 시스템이다.
Redis의 특징은 아래와 같다.
- Remote dictionary Server : 직역하면 외부 자료구조 서버? 느낌으로 와닿을 수 있다.
- Database, Cache, Message broker
- In-memory Database(Cache)
- 빠른 성능
- 평균 작업속도 < 1ms
- 초당 수백만 건 작업 가능
- 다양한 자료구조 제공
이렇게 Redis는 가장 유명한 software caching 솔루션인데, 여기서 Caching은 뭘까?
Caching
Caching은 데이터의 원래 소스보다 더 빠르고 효율적으로 엑세스할 수 있는 임시 데이터 저장소이다.
- 같은 데이터를 반복적으로 엑세스할때 효율적이다.
- 변하지 않는 데이터를 사용할때 효율적이다.
캐싱 전략
어떻게 캐싱을 관리해야 효율적일까?
캐싱 전략은 읽기 전략과 쓰기 전략이 있다.
읽기 전략 중 대표적인 Look-Aside(Lazy Loading)을 보자.
읽기 전략 : Look-Aside(Lazy Loading)
Redis를 캐시로 사용할때 가장 일반적으로 사용하는 방법이다. 과정은 아래와 같다.
- 어플리케이션은 데이터를 찾을때 캐시에 먼저 확인
- 캐시에 있을경우, 데이터 가져오는 작업 반복
- 찾는 데이터가 없을 때 DB에 직접 가져와서 다시 Redis에 저장
따라서, 캐시는 찾는 데이터가 없을 때만 입력되므로 Lazy Loading이라고 부른다.
이 구조의 특징은 아래와 같다.
- Redis가 다운되더라도 바로 장애로 이어지지 않고 DB에서 데이터 가져올 수 있음
- Cache로 붙어있던 커넥션이 많은 경우 -> 커넥션이 모두 DB로 붙음 -> DB에 부하가 몰릴 수 있음
Cache Warming - 데이터를 미리 캐싱
캐시를 새로 투입하거나 DB에만 새로운 데이터를 저장했다면 초기에 Cache Miss 많이 발생 -> 성능 저하
이때 DB에서 캐시로 데이터를 밀어 넣어주는 작업을 할 수 있다. -> Cache Warming
쓰기 전략 : Write-Around
DB에만 데이터를 저장하는 방식이다.
Cache Miss가 발생한 경우 Cache에 데이터를 끌어옴
단점 : Cache내의 데이터와 DB의 데이터가 다를 수 있음
쓰기 전략 : Write-Through
DB에 데이터 저장 시 Cache에도 저장하는 방법, 즉 데이터를 읽을 때 캐시로만 데이터를 읽어온다.
장점 : Cache 최신 정보 저장 가능
단점 : 저장 시 2단계의 step을 거쳐야 하므로 상대적으로 느림, 저장하는 데이터가 재사용되지 않을경우 리소스 낭비
따라서 데이터 저장시 얼마동안 보관하겠다는 의미인 Expire time 설정하는 것이 좋음
이미지 출처 : https://www.youtube.com/watch?v=92NizoBL4uA