Redis key 설계 시 고려해야할 점
1. Avoid long key
- key 크기는 1K(1024 bytes)가 넘지 않도록 한다.
- key의 길이가 크다면 메모리를 더 많이 차지하며, key 비교 연산에서도 비용이 많이 든다.
- key의 크기가 크다면, hashing을 통해 unique함을 보장하면서 줄이면 된다. ex) SHA1, SHA256 등
2. Avoid too short key
- key 사이즈가 크지도 않은데 일부러 축약어 등으로 과도하게 줄이는 것은 바람직하지 않다.
- 줄인 key의 의미를 파악할 수 없는 경우에는 개발 과정에서 버그를 야기할 수 있다.
- Redis 클러스터 이용 시 분산이 골고루 이어지지 않고 한 노드에 요청이 몰릴 수 있기 떄문에 key의 분산을 위해 다른 키도 이와같이 설계해야 한다.
- ex) user id 1000의 follower를 저장하는 자료구조 - user:1000:followers => u1000fw
Redis 사용과 운영
- Memory는 가격이 비싸고 한 Node 당 가질 수 있는 용량이 한계가 있으므로 용량 관리가 중요하다.
- Memory에 저장된 데이터는 컴퓨터가 종료되면 사라지므로 종료가 되더라도 데이터가 유지되도록 하는 방법을 고민하고, 비정상 종료가 되지 않도록 Node를 관리하는 것이 중요하다.
Key Eviction
- 메모리를 관리하는 기초적인 방법은 maxmemory를 넘지 않도록 하는 것이다.
- maxmemory에 다다르면 새로운 데이터 저장을 위해서 존재하는 key를 제거해야한다.
maxmemory 설정
- redis.conf 파일에 maxmemory 키로 설정한다.
- 추정치 이므로 해당 노드에 Redis가 가용한 총 memory보다 조금 적게 주어야 오차가 있더라도 관리가 가능하다.
Eviction 동작
1. client가 새로운 command를 요청하고 새로운 데이터가 추가된다면
2. memory usage를 확인하고 maxmemory limit을 넘는지 확인하고 넘는다면 eviction policy에 따라서 key를 eviction한다.
3. 새로운 command를 실행한다.
Eviction policy가 noeviction이었다면 error를 리턴한다.
Eviction Policies
redis.conf 파일에 maxmemory-policy 키로 설정한다.
* LRU (least recently used) : 최근에 사용한
* LFU (least frequently used) : 최근에 자주 사용한
* TTL (time-to-live) : 남은 시간
- noeviction
- allkeys-lru
- 사용해야할 때: 개발자들이 어떻게 사용할지 모르고 expire를 설정하는 것의 가이드가 잘 되어있지 않을 때
- allkeys-lfu
- volatile-lru
- volatile-lfu
- allkeys-random
- 사용해야할 때: 개발자들이 어떻게 사용할지 모르고 expire를 설정하는 것의 가이드가 잘 되어있지 않은데, key의 분배가 고르고 사용 패턴이 일정할 때
- volatile-random
- volatile-ttl
- 사용해야할 때: 개발자들이 어떻게 사용할지 모르지만, expire가 대부분 설정되어있을 때
Redis 세팅(운영자) 를 위한 Eviction 가이드
- Eviction policy는 runtime에 변경이 가능하다. (서버 중단할 필요가 없음)
- INFO의 결과 cache misses 수가 증가하는 것을 보고 수정 근거를 찾는 것이 바람직하다
- volatile-ttl이 Redis 사용자의 의도를 해치지 않는 가장 안정적인 선택이다.
개발자(사용자) 를 위한 가이드
- 모든 redis의 key에는 expire 설정을 꼭 해야한다. Redis (cluster)의 상태를 안좋게 만들 수 있다.
- 반드시 계속해서 유지해야하는 Cache 데이터인 경우에는 expire를 걸고 주기적으로 등록하는 방법이 귀찮지만 안전하다.
- List, HLL 자료구조에서 key 안의 member의 경우 expire 설정이 불가능 하다.
Use multiple keys
key를 시간대별로 구분할 수 있도록 설계한 뒤 key에 expire를 세팅한다. ex) HyperLogLog
Use single key
multiple keys 설계가 어려운 경우 key를 member의 값(score)에 timestamp를 알 수 있는 구분자를 넣어서 SCAN 또는 RANGE를 이용하여 주기적으로 지운다. ex) Sorted Sets
728x90
반응형
'DATA > Redis' 카테고리의 다른 글
Redis data types 자료구조 유형 (0) | 2022.12.29 |
---|---|
Redis 문제 해결 - WRONGTYPE Operation against a key holding the wrong kind of value (0) | 2022.12.29 |
Redis 운영모드 - Sentinel, Cluster (0) | 2022.12.29 |
Redis Persistence - RDB, AOF 장단점 (0) | 2022.12.28 |
Cache DB란? 관련 용어 및 종류 (Memcached, Redis) (0) | 2022.12.26 |
댓글