10분 테코톡 저문, 라온의 Cache & Redis 영상을 보고 정리하였습니다.
캐시 사용이유.
- 시간적 지역성: 이전에 접근했던 데이터에 또 다시 접근할 확률이 높음
- 공간적 지역성: 인접된 곳의 데이터를 계속 접근할 확률이 높음
캐시 전략 패턴
읽기 전략
Look Aside Pattern 캐시에 데이터가 없을 때, DB에서 데이터를 가져오는 전략. 장점: 캐시에 문제가 생기는 경우 DB로 요청을 위임 단점: 캐시 DB데이터 정합성 유지 어려움. 첫 조회시 DB과부하 발생
Read Through Pattern 항상 Cache로 부터 데이터를 읽는 전략. 장점: 캐시, DB간의 데이터 정합성 보장 단점: 캐시가 죽으면 어플리케이션에 문제 발생
쓰기 전략
Write Around 쓰기우회. 캐시에 직접쓰지 않고 DB에 쓴다. 만약 읽기전략과 혼합해서 사용할 때는 캐시 miss가 발생할 경우 캐시 스토어에 쓰기도 한다. 장정: 성능이 좋음. 불필요한 데이터를 캐시에 올리지 않고 바로 쓰기 때문에 리소스를 아낄 수 있다. 단점: 캐시 DB간의 연결점이 없기 때문에 정합성 유지가 어려움
Write Back 캐시에 쓰기작업을 먼저 쓰고, 나중에 DB에 반영한다. 한꺼번에 많은양의 쓰기작업을 scheduling을 한다. 장점: 쓰기횟수 비용을 줄일 수 있음 단점: 캐시의 데이터 유실 가능성
Write Trough 모든 데이터 쓰기를 Cache를 거쳐서 진행한다. 장점: 데이터 정합성이 보장됨. 단점: 필수적으로 두번의 쓰기가 항상 진행되기 때문에 성능이 고려되어야 함.
캐시사용시 주의 사항
- 자주 사용되면서 변경되지 않는 데이터
- 유실되어도 크게 문제가 없는 데이터
- 데이터베이스와 함께 사용할 때 데이터 정합성 문제 고려되어야
Redis (Remote Dictionary)
Key-value구조. Hashmap과 비슷함. memory기반의 key-value store. 캐시 구현방법 Memcached, Redis, Local memory기반의 임시 작업 큐, 실시간 채팅, 메시지 브로커로도 활용됨.
특징
- Get/Set의 경우 10만 TPS 가능.
- 다양한 자료구조 제공(Collection)
- Key: string
- Value: Hash, List Set, Sorted Set
- Single Thread
- 한번에 하나의 명령만을 처리
- Race condition이 (거의) 발생하지 않음
- Persistence: 메모리에 저장된 데이터를 디스크에 영속화할 수 있다.
- RDB(Redis Database Backup): 압축하여 저장하기 때문에 크기가 작음. 스냅샷 남김
- AOF(Append Only File): insert, update, delete가 일어날 때마다 Log파일에 기록. 크기가 크고 복원 소요시간 김.
Redis 우아하게 사용하기
-
데이터 타입에 따른 적절한 자료구조 사용 sorted set의 정렬기능 활용하면, SQL의 ORDERBY(정렬), DISTINCT(중복제거) 를 한번에 해결 가능하다.
-
O(N) 명령어 주의 KEYS/FLUSHALL , FLUSHDB, DELETE Collections , Get All Collections 같은 O(N)명령어를 실행하면, single thread인 Redis가 다른 명령어를 처리하지 못할 수 있다.
-
메모리 관리 메모리 단편화 (내부단편화, 외부 단편화) 발생. 사용가능한 공간이 충분함에도 새로운 메모리 공간 할당이 불가함. -> RSS(Resident Set Size) 모니터링 필요
-
목적성 캐시용인지 저장소용인지 명확히 구분하여 Persistent 기능을 끌 수 있으면 끄자.