Redis는 무엇인가??

1. Redis란?

간단히 말해 메모리 안에 키-값 형태의 데이터베이스를 만들 수 있게 해 주는 친구이다.

 

일반적으로 우리가 데이터베이스에서 데이터를 가져온다는 것은 하드디스크에서 가져온다는 뜻인데,

 

하드디스크는 속도로 따지면 최하위권이다.

 

그래서 가져올 데이터의 용량이 크다면 그만큼 로딩에 시간이 걸리게 되고, 이는 웹서비스에서 마이너스 요소가 된다.

 

그래서 자주 변경되지 않는 데이터는 캐시 메모리에 넣어놓고 쓰면 용량이 큰 데이터도 매우 빠른 속도로 로딩이 가능해진다.

 

Remote에 위치한 프로세스로 존재하는 In-Memory 기반의(보통 메모리에 상주하면서 RDBMS의 캐시 솔루션으로 사용

 

"키-값" 구조 데이터 관리 시스템 비관계형이며, 키-값 구조이기 때문에 별도 쿼리 없어도 간단히 데이터를 가져올수 있다.

 

(NoSQL)

 

2. 사용하게 된 이유

프로젝트 중 실시간 채팅이 필요해졌다. 그러는 도중 채팅 관련하여 구글 검색 도중 Django 공식 문서 에서

Redis를 사용하여 채팅기능을 구현하였다. 그 당시에는 Redis는 캐시데이터 인것만 알고 진행 하였다.

 

로컬 서버에서는 성공 하였지만 서버 배포 이후에 채팅기능이 되지 않아서 Redis이 도대체 무엇인지 명확하게

파악하고 싶어졌다.

 

3. 특징

1.Key-Value Store

 

레디스는 거대한 맵(Map) 데이터 저장소이다.

Key와 value가 매핑된 단순한 맵 데이터 저장소로서 데이터를 레디스에 쉽고 편하게 읽고 쓸 수 있습니다.

 

장점은 익히기 쉽고 직관적인 데 있다.

단점은 Key-value 형태로 저장된 데이터를 레디스 자체내에서 처리하는 것이 어렵다.

 

2.다양한 데이터 타입

 

Key로 참조되는 Value 타입을 다양하게 지정하여 저장 할수 있다.

List, String, Set, Sorted set 등 여러 데이터를 지정하여 손 쉽고 편리하게 데이터를 저장 할수 있다.

 

1. String
   • 일반적인 문자열로 최대 512mbyte 길이까지 지원한다. Text 문자열뿐만 아니라 Integer와 같은 숫자나 JPEG 같은 Binary File까지 저장할 수 있다.
2. Set
   • set은 String의 집합이다. 여러 개의 값을 하나의 Value 내에 넣을 수 있다고 생각하면 되며 블로그 포스트의 태그(Tag) 등에 사용될 수 있다. 재미있는 점은 set 간의 연산을 지원하는데, 집합인 만큼 교집합, 합집합, 차이(Differences)를 매우 빠른 시간 내에 추출할 수 있다.
   • 중복된 데이터를 담지 않기 위해 사용하는 자료구조이다. 중복된 데이터를 여러번 저장하면 최종 한번만 저장된다.
     이걸 사용했을 때 모든 데이터를 전부 다 갖고올 수 있는 명령이 있으므로 주의해서 사용해야 한다.

1. Sorted Set
   • set에 “score”라는 필드가 추가된 데이터 형으로 score는 일종의 “가중치” 정도로 생각하면 된다. sorted set에서 데이터는 오름차순으로 내부 정렬되며, 정렬이 되어있는 만큼 score 값 범위에 따른 쿼리, top Rank에 따른 query 등이 가능하다.
   • 
2. Hashes
   • hash는 value 내에 field/string value 쌍으로 이루어진 테이블을 저장하는 데이타 구조체이다. RDBMS에서 PK 1개와 string 필드 하나로 이루어진 테이블이라고 이해하면 된다.
   • 
3. List
   • list는 string들의 집합으로 저장되는 데이터 형태는 set과 유사하지만, 일종의 양방향 Linked list라고 생각하면 된다. List 앞과 뒤에서 PUSH/POP 연산을 이용해서 데이터를 넣거나 뺄 수 있고, 지정된 Index값을 이용하여 지정된 위치에 데이터를 넣거나 뺄 수 있다.
   • 

Persistence(Disk에 저장이 가능하면서 생긴 영속성)

Redis는 데이터를 disk에 저장할 수 있다고 한다.

 

따라서 Redis는 서버가 shutdown된 후에 restart 하더라도 disk에 저장해놓은 데이터를 다시 읽어서 데이터가 유실되지 않습니다.

 

redis의 데이터를 disk에 저장하는 방식은 snapshot, AOF 방식이 있다고 한다.

• Snapshot : 스냅샷은 RDB에서도 사용하고 있는 어떤 특정 시점의 데이터를 DISK에 옮겨담는 방식을 뜻합니다. Blocking 방식의 SAVE와 Non-blocking 방식의 BGSAVE 방식이 있다고 한다.
• AOF : Redis의 모든 write/update 연산 자체를 모두 log 파일에 기록하는 형태입니다. 서버가 재시작할 시 write/update를 순차적으로 재실행, 데이터를 복구합니다.

레디스 공식문서에서의 권장사항은 RDBMS의 rollback 시스템같이 두 방식을 혼용해서 사용하는 것이라고 한다.

 

주기적으로 snapshot으로 백업하고 다음 snapshot까지의 저장을 AOF 방식으로 수행하는 것이다.

 

4. 언제 쓰는 것이 좋은가?

서비스 사용자가 증가했을 때,

 

모든 유저의 요청을 DB 접근으로만 처리하게 된다면 DB 서버에 무리가 갈 수 밖에 없다.

 

물론 데이터베이스는 데이터를 디스크에 저장하기 때문에 서버의 장애와는 별개로 데이터를 유지할 수는 있지만,

 

요청이 증가하는 상황에서는 기존 성능을 기대하기 힘들다.

 

이런 맥락에서 캐시는 나중에 요청된 결과를 미리 저장해두었다가 빨리 제공하기 위해 사용한다.

 

보통 우리가 사용하는 Redis Cache 는 메모리 단 (In-Memory) 에 위치한다.

 

따라서 디스크보다 수용력(용량) 은 적지만 접근 속도는 빠르다.

 

그렇다면 이 캐시는 어떻게 사용할까?

• 일반적인 패턴 : Look aside cache

  1.  웹 서버는 클라이언트 요청을 받아서, 데이터가 존재하는지 캐시를 **먼저** 확인

  2. Cache에 데이터가 있으면 그걸 꺼내주는데, 만약 없으면
  3. DB에서 읽어서 -> 먼저 캐시에 저장한다음 클라이언트에게 데이터를 돌려줌
• 처리순서
• Write Backinsert를 1개씩 500번 수행하는 것보다 500개를 한번에 삽입하는 동작이 훨씬 빠름에서 알 수 있듯이,
• write back방식도 성능면에서 뒤쳐지는 방식은 아니다.
• 하지만 어쨋든 여기서 데이터를 일정 기간동안은 유지하고 있어야하는데, 이때 이걸 유지하고 있는 storage는 메모리 공간이므로 서버 장애 상황에서 데이터가 손실될 수 있다는 단점이 있다.
• 그래서 다시 재생 가능한 데이터나 극단적으로 heavy한 데이터에서 write back방식을 많이 사용한.
• 데이터를 캐시에 전부 저장해놓았다가 특정 시점마다 한번식 캐시 내 데이터를 DB에 insert하는 방법이다.

 

 

참조: https://velog.io/@swhan9404/Redis-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80