Redis

김준엽·2022년 10월 28일

redis

개발공부

목록 보기

5/5

Remote Dictionary Server

remote dictionart server, 직역하면 외부의 딕셔너리 구조로 이루어진 서버이다.

KeyWord

Database
Cache
Message Broker
In-Memory Data Structure Store

IN-Memory?

Redis 를 사용하는 이유에 대해 접근을 해보려면 우선 메모리별 속도의 차이를 알아야 합니다.

다음 그림과 같이 메모리에는 계층이 존재 합니다. (메모리라고 다 같은 메모리가 아닙니다.)
일반적으로 위로 올라갈수록 속도가 빨라지며, 속도와 가격은 비례하며, 가격과 용량은 반비례 합니다.

보통 자료를 저장하거나 상태를 저장할때 DB에 저장한다고 합니다.
이 DB는 일반적으로 HDD(하드디스크), SSD 와 같은 비교적 용량에 비해 가격이 저렴하고 속도는 느린 메모리를 사용하게 됩니다.
거기에 캐시는 속도가 매우 빠르지만 저장할 수 있는 용량이 하드디스크에 비해 턱없이 작아서 많은 데이터를 저장하기엔 무리가 있습니다.
(그래서 캐시를 최대한 활용하기 위해 캐시에 hit되는 횟수를 늘리기 위해 캐싱알고리즘이 중요한 이유이기도 합니다.)
이제 그러면 캐시 아래에 있는 Main Memory에 눈이 가게 됩니다.
컴퓨터를 살 때 주요 스펙 중 하나인 RAM입니다.
당연히 하드디스크보다는 속도가 월등히 빠르며, 우리가 빠른 결과값, 수시로 변하는 데이터값 (주식차트, 코인차드 등등)을 DB를 이용해 처리를 하게 되면 속도 때문에 문제가 생길 수도 있습니다.
그러면 RAM이 짱이고 하드디스크는 쓸모 없는거 아니냐? 라는 의문이 들 수 도 있습니다.
RAM의 가장 치명적인 단점? 차이점?은 휘발성 메모리라는 점입니다. 전원이 꺼지면 모든 데이터가 휘발됩니다. (NVRAM이라는 비휘발성 메모리도 있기는 합니다!)
정리하자면, redis는 하드디스크를 사용하는 DB의 고질적인 속도 문제때문에, RAM을 캐시처럼 사용하기 위한 라이브러리라고 이해하면 될 것 같습니다.

여담: Redis는 오픈소스 라이브러리지만 메모리를 할당하는 알고리즘은 (jemalloc)을 사용합니다.

Redis의 특징

redis 변수

Strings
List
Set
Sorted Set (정렬 집합)
Hash
등이 있다고 합니다. (간단하게)

메모리 관리

Redis는 In-Memory Data Store 이기 때문에 물리적인 메모리 용량 이상을 사용하면 문제가 발생합니다.
즉 넘치는 데이터를 저장하기 위해 SWAP을 진행 하게 되는데 이러한 SWAP이 있다면 SWAP으로 인한 속도가 늦어집니다. (Redis를 사용하는 목적을 생각하면 치명적입니다.)
=> 그러면 MaxMemory를 설정하고 때려박으면 알아서 관리해주지 않을까?
Redis가 아는 메모리 용량과 물리적인 메모리 용량은 다르다.. 성능이 중구난방으로 튀게 됩니다.
(jemalloc 보다 더 효율적인 메모리 할당 알고리즘을 짤 수 있다면, 직접 짜보시면 될수도?)

메모리가 만약 부족하다면?

Migration..
당연하지만 있는 데이터 줄이기

O(N) 관련 명령어 주의

Redis는 single Threaded (싱글쓰레드) 이다.
- 여러 명령을 처리를 못한다.
대표적인 O(N) 명령어
KEYS
FLUSHALL, FLUSHDB
Delete Collections
Get All Collections

Redis Replication

Redis Replication은 redis를 복사하는 작업입니다.
위에서 언급했듯이 RAM은 기본적으로 휘발성 메모리이기 때문에, 서버가 다운되거나, 전원이 종료되면 모든 데이터가 휘발됩니다.
개인 컴퓨터의 RAM이 휘발되면 보통은 자소서가 날라가거나, 짜던 코드가 날라가거나.. 치명적인 문제이긴 하지만..
한 기업의 서버가 다운되어서 Redis의 데이터가 모두 휘발되면 엄청난 손해가 발생하게 됩니다.

즉 이런 휘발되는 단점때문에 Redis 데이터 자체를 이중화하는 작업이라고 이해하시면 쉽습니다.
기존의 서비스가 운영중이던 마스터 노드를 다른 레디스 노드에 복사하는 작업을 redis replication 이라고 이해하시면 됩니다.

redis replication 의 특징

비동기적으로 복제를 합니다.
마스터 노드는 여러 복제 서버를 가질 수 있습니다.
복제서버도 복제서버를 가질수 있습니다 (n중화)
자동 Failover(시스템 장애시 자동으로 대체 운영) 가 되지 않는다.

Redis message broker

결정적으로 redis에 관심을 가지게 된 이유입니다.
Redis는 단순히 DB보다 빠른 캐시 DB라고 단순하게 생각했었는데, 이를 Docker, Kubernatis와 연결하여 사용하는 Kafka vs Redis를 키워드로 많은 포스팅 글이 있어서 이를 계기로 학습을 하게 되었습니다.

MOM (Message Oriented Middleware)

메시지 브로커를 이해하기 위해 필요한 개념인 메시지 지향 미들웨어입니다.

여러 클라이언트간의 통신을 중간에서 관리해줌으로서, 시스템간의 종속성을 낮춰주는 역할을 한다.
=> 비유를 하자면 중간에서 라우팅을 해주는 공유기의 기능과 비슷하다고 생각하시면 됩니다. 이 경우에는 클라이언트와 클라이언트가 주고받는 메시지를 관리

그러면 메시지 브로커는 왜? 필요할까요?
그냥 클라이언트끼리 메시지를 주고받으면 안될까요?
클라이언트 끼리 메시지를 주고받으면 단일 서버에선 큰 문제가 안생길지도 모릅니다.

서버수가 여러개라면?
수신하는 측 서버가 다운되었다면?

매우 많은 문제를 야기합니다.
이러한 메시지간 어플리케이션 의존성을 제거함으로서 여러가지 문제를 해결합니다.

서버 수가 유동적이어도 정상적으로 동작합니다.

송신 측 서버가 늘어나도 메시지 브로커의 주소만 알고 있다면, 메시지를 보내는데는 문제가 없습니다.
수신 측 서버가 늘어나도 메시지 브로커의 주소만 알고 있다면, 메시지를 받아오는데는 문제가 없습니다.

수신 측 서버가 문제가 생겨도 정상적으로 동작합니다.

송신 측이 메시지를 보내면, Message Broker는 메시지를 받아 큐에 저장해놓고 수신 측이 받아가길 기다립니다.
수신 측 서버에 문제가 생겨 이 메시지를 받아가지 못하더라도 메시지 브로커에서는 정해둔 설정 값마다 다르겠지만 메시지를 유지하고 있습니다. 수신 측 서버가 정상적으로 돌아오면 그 유지해 두었던 메시지를 받아 올 수 있어 문제가 생겼던 기간의 메시지들도 받을 수 있습니다.

그럼, 만약 메시지 브로커 자체가 죽으면 어떻게 될까요?

브로커 자체가 죽는다고 송신 및 수신 측 서버에 부담이 가지 않습니다. 메시지 전송의 출구만 없어질 뿐 그 자체의 서버 역할을 하고 있을 것입니다. 하지만 당연히도 메시지 전송 기능 자체에는 문제가 발생할 수 있습니다.
하지만 메시지 브로커 서버는 일반 서버와 달리 메시지 전송과 메시지 큐 부분에만 집중을 둔 서버로서 고가용성을 목표로 만들어져있어 서버가 이상이 있을 위험이 더 적다고 합니다.
출처: https://binux.tistory.com/74

이를 redis에서는 특징으로 Point-to-point messaging 로 설명합니다.