레디스 ?

Redis

일반적으로 레디스라 했을 때 떠오르는 이미지는,
DB에 접근하는 것이 느리기 때문에 DB 데이터의 일부를 저장하는 캐시 역할 의 Key-Value Store라고 알고있다.
대략적으로 이정도는 알지만, 정확히는 잘 몰랐기 때문에 이번에 정리를 한번 해보고자 한다

 

최근 이슈

---

Redis는 원래는 오픈소스였으나, 최근에 라이센스가 변경되어 더이상 오픈소스가 아니게 되었다

• 다행(?)인 점은 기존 개발자 중 몇명이 Fork를 떠서 가지고 나와서 ValKey라는 오픈 소스를 만들게 되었다
• ValKey는 현재 Linux의 재단에서 관리를 하고 있고, 이미 많은 사용자들이 ValKey를 사용하고 있다
• Fork를 떠온 것이기 때문에, 현재까지는 사용법에 큰 차이가 없다

 

Redis?

---

레디스란 무엇인가

• In-Memory Cache
• In-Memory NoSQL
  • Key-Value Store

공통적으로 들어간 단어가 In-Memory이다.
레디스는 In-Memory에서 동작을 한다

In-Memory를 사용하는 가장 큰 이유는 디스크에 접근하는 것보다 메모리에 접근하는 것이 훨씬 빠르기 때문
이때 메모리에 접근하는 주체는 CPU이기 때문에, 레디스의 성능은 CPU의 성능에 영향을 받는다
(좋은 CPU를 사용하면 레디스의 성능도 올라감!)

 

메모리 계층 구조

---

Memory Hierarchy

• 알다시피 메모리는 계층 구조를 이루고 있다
• 아래로 갈수록 느리지만 용량은 크고 값이 싼 저장장치
• Second와 Millisecond는 1,000배 차이
• Millisecond와 Microsecnd도 1,000배 차이
• Microsecond와 Nanosecond도 1,000배 차이
• 따라서 RAM에 접근하는 것과 디스크에 접근하는 것은 어마어마한 속도 차이가 발생 (대략 10만 배)
• L1, L2, L3 캐시는 CPU 근처에 붙어있는 작고 빠른 메모리
• 캐시(Cache)라는 개념은 느린 장치의 데이터의 일부를 빠른 장치에 올려두고 사용 하는 것
• DB는 초당 1,000 TPS(Transaction Per Second)의 성능
  • 초당 1,000번의 DB 접근이 가능하다는 뜻

 

Kafka?

---

번외이지만, Kafka는 메모리가 아닌데도 굉장히 빠르다던데?

• Sequential Access is faster than Random Access !
• 카프카는 Sequential Access를 사용 하기 때문에 메모리가 아닌데도 빠른 속도를 가질 수 있다
• 디스크의 경우에는 Random Access를 하게 되면, 매번 물리적인 헤드를 움직여야 하기 때문에 굉장히 느리다
  • 느린 저장 장치의 경우에는 연속적으로 데이터를 쭉 써두고 연속적으로 쭉 읽는 경우가 많다
• DB 인덱싱에 사용되는 자료 구조는 B-Tree, B+Tree
• B-Tree, B+Tree는 기본이 Random Access

Memory는 Random Access도 굉장히 빠르다!
=> 그렇기 떄문에 In-Memory를 사용하는 것이고, 메모리는 굳이 Sequential Access를 하지 않는다

 

In-Memory Cache Solution

---

In-Memory Solution은 엄청 많다

• Memcached
• Redis
• Hazelcast
• Infinispan
• Couchbase

이 중에서도 Redis가 압도적으로 많이 사용된다

Redis가 유명한 이유?
빠르면서도 다양한 자료구조를 제공 하기 때문
다양한 자료구조를 제공하게 되면, 개발이 훨씬 편해진다!

 

Redis 사용 분야

---

Redis는 어떤 식으로 사용될까?

• Cache
• Session Store
• Distributed Lock
• Rate Limiter
• LeaderBoard
• Queue

 

Cache

---

• Data Entity를 DB에서 가져가는 것이 아니라 더 빠른 저장 매체인 Redis에 1차적으로 저장 해두는 것
• Cache 목적으로 사용하는 것이 Redis 사용의 95% 정도
• 다양한 타입에 다양한 정보를 필요에 따라서 저장할 수 있다
• 전체 디스크에 저장된 데이터에 비해 캐시에 저장할 수 있는 용량은 매우 작은데, 어떻게 효과가 있을까?
  • 2대8의 법칙 (파레토의 법칙)
    • 트래픽의 80%는 DB의 20%이다
    • 이 20%를 빠른 메모리에 올려두고 사용하면 80%의 성능 개선이 일어난다는 뜻
  • 서비스를 할 때, 데이터의 습성을 알고 캐시를 적용하는 것이 필요하다
    • 만약 매번 다른 데이터에 접근을 한다면, 캐시가 사실 큰 힘을 발휘하지 못한다

 

Distributed Cache

---

• 데이터가 많다면, 하나의 Cache Server가 아니라 여러 캐시 서버를 구성 할 수 있다
  • Ex) Redis with Range, Redis with PreShard, Redis with Consistent Hashing
• 데이터 자체를 나눠서 저장하는 것

 

Quiz

위와 같이 캐시가 A,B로 나누어져 있고, 1~9까지의 데이터가 있다고 했을 때 데이터를 어떤 식으로 나눠서 저장할 수 있을까?

1. 홀짝으로 나눈다
2. 번호를 기준으로 반반으로 나눈다 => A에는 1~5까지, B에는 6~9까지
3. 무작위로 나눈다

1,2번과 같이 어떤 규칙이 적용되어 있다면, 데이터를 찾을 때 하나의 캐시 서버만 확인하면 데이터가 캐시에 있는지 없는지 바로 알 수 있다

그런데 A,B 캐시 외에 C라는 캐시가 하나 더 생성되었다면?

1. 홀짝(Modulo 방식)으로 나누게 되면, C라는 새로운 캐시가 생겼을 때 재배치가 필요하다
2. Range로 하게 되면, 특정 범위의 데이터가 모두 지워지게 되면, 해당 캐시는 놀게 된다
   => 결국은 재배치가 필요

결론: 어떻게 저장해도 재배치가 필요 하다

• 재배치를 최대한 줄일 수 있는 방향으로 캐시를 설계하려는 경우가 많다

 

Redis With Range

---

특정 Key의 Range로 구분

• ID가 50인 유저의 데이터를 찾아줘! 라고 했을 때 ID가 순차적으로 증가하는 방향으로 데이터가 분산되어 있다면, 어떤 DB에 요청을 보내야 할지 바로 알 수가 있다

 

Redis With Preshard

---

Hash slot을 16348과 같은 숫자로 미리 나눠두고 해당 서버에 저장

• Redis Cluster는 일종의 PreShard 구조 (crc16으로 hash)
• hash(key) % 16384

 

Redis With Consistent Hashing

---

Consistent Hashing을 통해서 Key를 분할

• 없어져도 다시 만들 수 있는 Cache 형태에 적합
• Consistent Hashing 의 단점
  • HashRing을 균등하게 구성하더라도 부하는 균등하게 몰리지 않는다
  • 필요한 개수보다 더 많은 노드가 필요한 경우가 종종 발생

 

Session Store

---

Session을 개별서버나, 클러스터링이 아니라 외부 스토리지(Redis)에 저장

• 로그인 기능을 구현할 때, 세션 방식을 많이 사용한다
• 이때 세션 정보(세션 스토어)를 서버의 메모리에 저장해도 되지만, 레디스를 많이 사용한다
• 서버마다 세선 스토리지를 가지고 있으면, 서로간에 Sync를 맞춰주기 위해서 성능이 저하된다
• 그래서 그냥 하나의 외부 스토리지로 빼버리는 것 이 좋을 수도 있다

 

Distributed Lock

---

분산 락으로 동작

• Optimistic Lock으로 동작
• key가 존재하면 대기하는 형태
  • 바로 실패로 구성할지, Spinlock 형태로 동작할지 (Redisson 구현체) 등 고민은 필요

 

Locking Algorithm

• setnx를 호출하면 단 하나의 프로세스만이 키를 가질 수 있다

 

Rate Limiter

---

• 인당 DB에 접근할 수 있는 횟수를 제한할 때 사용한다
  • 유료 회원은 50회, 무료 회원은 10회 이런 거 할 때
• 잦은 업데이트가 필요한 경우에 저장소로 사용되는 케이스
  • 일종의 Write Back 형태 or 전용 저장소로 동작
  • Rate Limiter를 위한 정보는 조금 날아가도 클라이언트에게 피해가는 게 없기 때문에 Write Back을 사용해도 큰 문제가 없다
• Rate Limiter 이외에 View Count 등을 저장할 때도 사용된다
• Rate Limiter 자체에 대한 알고리즘은 다음의 글을 참고
  • https://www.mimul.com/blog/about-rate-limit-algorithm/

 

Leaderboard

---

Sorted Set(zset)에 Score를 저장할 수 있으므로 이를 이용한다

• 랭킹을 보여줘야 하는 경우에 많이 사용
  • 물론 DB에서 가져와서 Sorting을 해서 보여줘도 되지만, 이걸 사용하는 게 더 편리하기 때문에 사용
• Sorted Set을 살 때 주의해야 하는 점은 Score가 Int가 아니라 Float
  • 실수형 데이터에 정수형 데이터를 넣으면, 완전히 다른 값으로 인식된다