#1. [우아한 테크 세미나 191121] 우아한레디스 보고 정리-1부

[목차]

- Redis 소개

- 왜 Collection이 중요한가?

- Redis Collections

- Redis 운영

- Redis 데이터 분산

- Redis Failover

 

[Redis 소개]

- In-Memory 데이터구조 저장소

- 오픈소스 (BSD 3License)

- 여러 자료구조를 지원

- 오직 1명의 커미터(Redis 개발자)

 

[Cache]

- Cache는 나중에 요청한 결과를 미리 저장했다가 빠르게 서비스를 해주는 것.

(Cache Memory의 기능과 유사, Dynamic 프로그래밍도 이와 비슷

ex) 아주 큰 수의 factorial을 계산 할 때 이전에 계산해놓은 팩토리얼을 어딘가에 저장해놓으면

계산하기가 아주 쉬워진다.)

 

[CPU Cache 그림]

위로갈수록 속도가 빨라지고 밑으로 갈수록 용량이 증가한다.

 

 

[Cache 구조]

- Look aside Cache

1. Client가 WebServer에 데이터 로드 요청

2. Web Server는 데이터가 있는지 Cache에서 확인

3-1. Cache에 데이터가 있으면 Cache에서 데이터를 가져옴.

3-2. 만약 Cache에 데이터가 없으면 DB에서 확인

4. DB에 데이터가 있으면 Cache에 저장 후 WebServer가 Client에 넘겨줌.

(이렇게 Memory Cache를 이용하면 훨씬 더 빠른 속도로 서비스가 가능함)

 

- Write Back

1. Client가 WebServer에 데이터 저장 요청

2. Web Server는 모든 데이터를 Cache에만 저장

3-1. Cache에 특정 시간동안의 데이터가 저장

3-2. Cache에 있는 데이터를 DB에 저장

4. DB에 저장된 데이터를 삭제

(이렇게 Memory Cache를 이용하게 되면 훨씬 더 빠른 속도로 서비스가 가능함)

 

DB에 Insert Query를 500번 날리는 것과

DB에 500개의 Insert 쿼리를 한번에 날리는 것 중 어떤게 더 빠를까요? 

후자가 훨씬 빠르다. 이걸 배치(?)작업 이라고 한다.

 

이런 Write Back의 주의할 점! 

데이터를 저장할 때 항상 먼저 Cache에 저장되는데 이때 어떠한 장애로 Reboot가 되면 저장된 데이터가

모두 날라가기 때문에 이 부분을 조심해야 한다.

 

Log를 DB에 저장할 때, 보통 많은 Log를 Cache에 저장하고, 

Cache에 저장된 데이터를 한번에 DB에 저장하는데, 이렇게 Write back이 유용하게 쓰인다.

 

[왜 Collection이 중요한가?]

- 개발의 편의성

- 개발의 난이도

 

만약 랭킹 서버를 직접 구현한다면?

- 가장 편한 방법 score를DB에 저장하고, 이를 Order by를 통해 정렬해서 읽어오는 것.

그런데 문제는 사용자가 엄청나가 많아지면 속도에 문제가 발생할 수 있음.

(data를 가져오기 위해 디스크 접근이 필요하고 기게 지연을 발생 시킴).

 

그래서 In-Memory 기준으로 랭킹 서버의 구현이 필요함.

능력자면 빠르게 만들겠지....

Redis의 Sorted Set(Collection)을 이용하면, 랭킹을 구현 할 수 있음.

- Replication 도 사용 가능

- 다만 가져다 쓰면 거기에 한계에 종속적이 됨.

만약 랭킹에 저장해야 할 id가 1개당 100byte라고 하면,

10000000명이면 1G이다..!! 

 

 

친구 리스트를 관리한다면?

- 친구 리스트를 Key-Value형태로 저장해야 한다면?

* 현재 유저 A의 친구 Key는 friend:123, 친구 A가 있는 중이다.

 

Transaction1) 친구 B를 추가

- 친구 리스트 friend:123을 읽는다.

- friend:123의 끝에 친구 B를 추가한다.

- 해당 값을 friend:123에 저장한다.(쓰기)

 

Transaction2) 친구 C를 추가

- 친구 리스트 friend:123을 읽는다.

- friend:123의 끝에 친구 C를 추가한다.

- 해당 값을 friend:123에 저장한다.(쓰기)

 

그런데 이게 문제가 있다.

가장 이상적인 형태가 A - B - C 형태의 리스트로 DB에 저장한 것이 된다.

하지만 타이밍에 따라 A - B, A - C, A - B - C가 들어갈 수도 있다.

 

즉, Critical Section문제가 있네?

 

- Redis의 경우는 자료구조가 Atomic 하기 때문에, 해당 Race Condition을 피할 수 있다.

- 그래도 잘못짜면 발생함.

 

따라서 Collection은 여러가지 개발 시간을 단축시키고, 문제를 줄여줄 수 있기 때문에 중요하다.

 

[Redis 사용처]

- Remote Data Store

  * A서버, B서버, C서버에서 데이터를 공유하고 싶을 때

- 한대에서만 필요하다면, 전역변수를 써도 되지 않을까??

  * Redis 자체가 Atomic을 보장해준다.(Single Thread임)

- 주로 많이 쓰는 곳들

  * 인증 토큰 등을 저장(Strings 또는 hash)

  * Ranking 보드로 사용(Sorted Set)

  * 유저 API Limit

  *  잡큐(list)

 

[Redis Collections]

- Strings : Key-Value로 저장하는 구조 

- List : 말그대로 List

- Set : 집합(중복 제외를 위해)

- Sorted Set : 정렬 집합

 기본적으로 다루는 값이 실수임. 따라서 IEEE754에 따라 부동소수점의 경우

표현이 되지 않는 정수가 존재함. 이런 이슈가 있기 때문에

랭킹 시스템에서 특정 점수를 얻었는데 그 값이 랭킹에 없거나, 근사값으로 저장될 수도 있음.

이부분을 주의해서 써야 한다.

- Hash : Key-Value안에 Sub Key-Value를 가질 수 있는 구조

 

Collection 주의 사항

- 하나의 컬렉션에 너무 많은 아이템을 담으면 좋지 않음.

- 10000개 이하 몇천개 수준으로 유지하는게 좋음.

- Expire는 Collection의 item 개별로 걸리지 않고 전체 Collection에 대해서만 걸림.

- 즉 해당 10000개의 아이템을 가진 Collection에 exprire가 걸려있다면 그 시간 후에 10000개의 아이템이 모두 삭제