레디스(Redis, Remote Dictionary Server)

레디스(Redis, Remote Dictionary Server) 는 인-메모리(In-Memory) 기반의 키-밸류 스토어(Key-Value Store)입니다. 성능은 데이터를 메모리에 바로 처리하므로 메모리 기반의 데이터베이스에 비해서 속도가 빠릅니다. 또한 저장할 수 있는  데이터 타입의 경우에 다른 저장소는 기본적인 프리미티브 타입(Primitive Type)만을 제공하는데 반해서 레디스는 문자열(String), 스트링 집합(Set), 해쉬(Hash), 리스트(List)등의 다양한 데이터 타입을 지원하고 있으며, 데이터에 대한 검색, 추가, 삭제등의 기능을 기본적으로 제공합니다. 

프리미티브 타입(Primitive Type)   프리미티브(Primitive)란 원초적인, 초기의 뜻을 가지고 있습니다. 여기에 속하는 데이터 타입은 Boolean, 정수(byte, short, int, long, char), 부동 소수점(float, double)이 속합니다.   [ 자바 데이터 타입의 종류 ]

 

 

 

아래의 그림은 레디스의 구조도 입니다. 레디스 인스턴스(Radis Instance)는 가상 머신 (또는 물리 서버) 위에서 실행되며, 하나의 가상 머신에 1개 이상의 인스턴스를 가동시킬수 있습니다. 아래의 그림에서 3개의 샤드(Shard)로 구성되어 있으며 각각의 샤드는 마스터/슬레이브 구조로 이중화되어 있습니다. 각각의 샤드에는 전체 데이터의 일부가 저장되어 있으며, 마스터 노드의 복제본을 슬레이브에서 가지고 있는 구조입니다.

 

[ 레디스의 구조도 ]

레디스의 데이터 타입 설명

레디스의 장점은 값 영역에 들어갈 수 있는 데이터 타입이 프리미티브 타입 뿐만 아니라 다양하고 풍부한 데이터 구조를 넣을 수 있습니다. 이러한 데이터 구조는 하나의 키당 총 2^32개의 데이터를 이론적으로 저장할 수 있으나 최적의 성능을 낼 수 있는 것은 일반적으로 1,000~5,000개 사이로 알려져 있습니다.

[ 레디스 데이터 구조 ]

Strings

레디스의 가장 기본적인 데이터형으로 키당 하나의 값을 저장할 수 있습니다. 스트링이라고 해서 문자열만 저장할 수 있는 것이 아니라 이진(Binary)데이터도 가능합니다.

 

키당 넣을 수 있는 데이터의 최대 크기는 512M 바이트이며, 데이터의 값이 정수인 경우에는 ‘int’로 아닌 경우에는 ‘raw’로 인코딩(Encoding) 됩니다. 참고로 레디스에서는 정수형, 실수형을 구분하지 않습니다.

 

Sets

Sets은 정렬되지 않은 집합형을 말합니다. 집합이기 때문에 한 키에 중복된 데이터는 존재하지 않습니다. 왜냐하면 동일한 키에 “ABCD” 값을 두번 추가해도 Sets 상에는 “ABCD” 값은 하나만 존재하게 됩니다.

 

이 데이터형의 장점은 데이터의 검색, 추가, 삭제시 소모되는 시간이 Sets 안에 포함된 수에 상관없이 일정하다는 것입니다. 또한 집합간의 연산을 지원하며 교집합, 합집합, 차집합등의 연산을 매우 빠르게 수행할 수 있습니다. 한 키에 넣을 수 있는 데이터의 최대 개수는 4,294,967,295 (2^32-1) 개입니다. 

[Set의 구조 ]

Sorted Sets

Sets의 각 요소마다 ‘score’라는 실수값을 가지고 있는 형태입니다. 요소들은 정렬된 형태로 보여지는데, ‘score’ 값을 기반으로 오름차순 정렬을 합니다. Sets와 마찬가지로 동일한 키에서 각 데이터들의 값은 유일합니다.

 

데이터의 추가, 제거, 갱신은 매우 빠른 방법으로 진행되는데 이런 특징으로 인하여 랭킹 시스템이나 다른 데이터 형의 정렬을 위한 인덱스 값으로 활용할 수 있습니다. 예를 들어 Hashes로 사용자 데이터를 저장하는데 나이에 따른 정렬이 필요한 경우, Sorted Sets에 데이터의 ‘score’ 에는 나이 값을 넣어주고, 값으로는 사용자 ID를 넣어주면 됩니다.

[ Sorted Set의 구조 ]

Hashes

해싱(Hashing)은 키 값에 직접 산술적인 연산을 적용하여 항목이 저장되어 있는 테이블의 주소를 계산하여 항목에 접근하는 방법입니다. 값의 연산에 의해 직접 접근이 가능한 구조를 해시 테이블(hash table)이라 부르며, 해시테이블을 이용한 탐색을 해싱(Hashing)이라 부릅니다.

 

해시 함수(Hash function)은 탐색키를 입력받아 해시 주소(Hash address)를 생성하고 이 해시 주소가 배열로 구현된 해시 테이블(Hash table)의 인덱스를 구합니다.

[ 해싱의 방법 ]

리스트(List)

순서를 가지고 일렬로 나열한 원소들의 모임으로 정의할 수 있습니다. 순서가 있다는 점에서 집합과 구별되며, 일렬로 나열되어 처음과 끝이 각각 하나씩만 있다는 점에서 트리나 그래프와도 구별됩니다. 일반적으로 이러한 구조를 링크드 리스트(Linked List)라고 부릅니다.

 

링크드 리스트는 데이터를 저장할 때 그 다음 순서의 데이터가 있는 위치 정보를 데이터에 포함시키는 방식으로 자료를 저장합니다.

[ 연결 리스트(Linked List) 구조 ]

인-메모리 상태에서의 데이터 저장 방법

레디스는 메모리 기반 데이터베이스 이기 때문에 전원이 꺼지면 모든 데이터가 모두 사라지게 됩니다. 이러한 경우를 방지하기 위해서 파일에 메모리 내용을  저장해 두고 레디스 서버 실행시 다시 그 파일에서 데이터를 읽어와 메모리상에 올리는 기능을 제공하는데 이를 Persistence(지속성) 이라고 부릅니다.

 

레디스에서 데이터를 저장하는 방법은 Snapshotting 방식과 AOF(Append On File) 두가지 방식이 제공하고 있습니다. 두가지 방식은 하나만 선택하는 것이 아니라 두가지 모두 병합하여 사용할 수 있습니다. 두가지 방식을 모두 사용하도록 설정한 상태에서 레디스 서버를 실행하면 보통은 AOF를 이용하여 데이터를 메모리로 가져오게 됩니다.

 

RDB 방식

RDB 방식은 메모리상의 데이터를 모두 파일로 덤프를 뜨게 됩니다. ‘save’ 와 ‘bgsave’ 두가지 방식이 있습니다. ‘save’는 동기식(Blocking) 방식으로 순간적으로 레디스의 모든 동작을 정지 시킨 후에 메모리 내용을 디스크에 저장합니다.

 

‘bgsave’는 비동기식(Non-Blocking) 방식으로 백그라운드에 별도의 프로세스(Process)를 실행시킨 후에 수행 당시의 메모리 내용을 디스크로 저장하며, 레디스는 동작을 멈추지 않고 정상적으로 작업을 수행합니다. 저장 파일은 보통 ‘.rdb’ 확장자를 사용합니다.

 

레디스가 메모리의 내용을 디스크에 덤프하는 과정은 다음과 같습니다.

 

① 레디스의 포크(fork)로 자식 프로세스를 생성한다.

② 자식 프로세스는 임시 rdb 파일에 데이터를 저장한다.

 ③ 자식 프로세스가 새로운 rdb 파일에 데이터 쓰기를 마치면 임시 rdb 파일로어전 rdb 파일을 덮어 씁니다.

 

이 방식의 장점은 특정 시점의 백업 및 복구에 유리하며, 레디스 서버가 디스크에 저장하기 전까지는 디스크 I/O가 발생하지 않으므로 성능을 극대화 시킬수 있습니다. 마지막으로 AOF에 비해 더 빨리 메모리에 데이터를 올리고 작업을 시작할 수 있습니다.

 

단점으로는 사고 발생시 백업이 일어난 시점이후의 데이터는 유실할 수 있으며, 백업 작업시 fork()로 자식 프로세스를 생성해서 백업 작업을 수행하는데, 이 시점에 저장할 데이터가 많아서 순간적으로 CPU에게 과부하를 줄 수 있습니다.

 

AOF(Append On File) 방식

AOF 방식은 레디스의 모든 write/update 연산 자체를 모두 로그(Log) 파일에 기록하는 형태입니다. 서버가 재 시작될 때 기록된 write/update 동작을 순차적으로 재 실행하여 데이터를 복구합니다. 저장되는 파일의 확장자는 ‘.aof‘ 를 사용합니다.

 

AOF는 설정에서 파일을 쓰는 시점에 3가지 옵션을 선택할 수 있는데, 기본값인 ‘everysec’를 사용합니다. 또한 정전등의 문제로 AOF 파일이 손상될 수 있습니다. 이 경우에는 ‘redis-check-aof’ 툴을 사용하여 복구가 가능합니다.   

 

이 방식의 장점은 사고 발생시 손실되는 데이터가 최소화되며, 정전등의 문제로 AOF 파일에 문제가 생긴다고 해도 ‘redis-check-aof‘ 툴을 사용하여 복구가 가능합니다. 또한 AOF 파일의 형식이 단순하여, 문제가 있는 부분만 삭제하고 복구를 해도 됩니다.

 

발행자(Publish)와 구독자(Subscribe) 프로토콜(Protocol)

이 프로토콜은 양방향을 제공해 주기 때문에 레디스를 pub/sub (publish/subscribe, 발행자와 구독자의 의미) 메시지 센터로서 사용될 수 있게 해줍니다. 클라이언트는 메시지 채널을 구독할 수 있고 레디스는 다른 클라이언트가 구독된 채널에 메시지를 발행하면 클라이언트에게 발송해 줍니다.

[ Publish/Subscribe 구조 ]

(여기서 채널을 구독하고 발행한다는 의미는 방송국과 TV의 관계를 생각하면 될 것 같습니다. TV는 채널을 보게 되면 구독하게 되고 방송국은 컨텐츠를 TV에 발행합니다. 하지만 여기서 틀린 점은 TV에서 방송국으로 정보를 보낼 수 있습니다. 즉 TV와 달리 양방향 채널이라는 점이 틀린점 입니다.)

 

 

복제 토폴로지(Replication Topology)

레디스는 NoSQL 계열의 키-밸류 스토어인데도 확장성(Scalability)을 지원하지 않습니다. 이로 인하여 확장성과 성능에 제약사항이 있는데, 마스터(Master)/슬레이브(Slave) 구조의 복제를 지원하기 때문에 확장성 부분에서 어느 정도 융통성을 가집니다.

토폴로지(Topology)   토폴로지는 컴퓨터 네트워크의 요소들(링크, 노드 등)을 물리적으로 연결해 놓은 것 또는 그 연결 방식을 말합니다.    [ 토폴로지의 다양한 구조 ]

마스터(Master)/슬레이브(Slave) 복제(Replication)

마스터/슬레이브 복제란 마스터 노드에 있는 내용을 복제를 통해서 슬레이브 노드에 복제하는 것을 의미합니다. 1개의 마스터 노드는 N개의 슬레이브 노드를 가질 수 있으며, 각 슬레이브 노드도 다른 슬레이브 노드를 가질 수 있습니다.

 

[ 마스터 / 슬레이브 복제 구조 ]

 

마스터/슬레이브 간의 복제는 Non-Blocking 상태에서 이루어집니다. 이 말은 마스터 노드가 어떤 동작을 수행하고 있을 때에도 백그라운드에서 슬레이브 노드로 데이터를 복제할 수 있다는 것을 의미합니다. 이 경우에 슬레이브 노드에서 데이터를 조회할 경우 이전 내용이 조회될 수도 있습니다.

 

Query Off Loading을 통한 성능 향상

마스터 노드의 내용을 슬레이브로 복제하는 이유는 조회 성능을 높이기 위해서입니다. Query Off Loading은 마스터 노드에서는 쓰기 동작을 담당하고 슬레이브 노드에서는 조회 동작을 담당합니다. 이렇게 쓰기와 조회를 분리하는 이유는 대부분의 데이터베이스의 트랜젝션은 쓰기동작이 10~20%, 조회 동작에서 70~80%의 시간을 사용하기 때문에 조회 동작을 여러 노드로 분산시킨다면 속도를 비약적으로 증가시킬수 있습니다.

 

Sharding을 통한 용량 확장

레디스가 클러스터링을 통한 확장성을 제공하지 않기 때문에 일반적으로 Sharding 아키텍처를 이용합니다. Sharding은Query Off Loading과 마찬가지로 RDBMS나 다른 NoSQL에서도 많이 사용하는 아키텍처입니다. 여러 개의 레디스 서버를 구성한 후에 데이터를 일정 구역별로 나누어서 저장하는 방법입니다. 데이터 분산에 대한 통제권은 클라이언트가 가집니다. 샤딩(Sharding)은 데이터를 여러 개의 데이터베이스에 분할해서 저장하는 방법입니다. 분할하는 방법에 따라서 수평적 샤딩(Horizontal Sharding) 과 수직적 샤딩(Vertical Sharding)으로 나눌 수 있습니다.

 

수평적 샤딩(Horizontal Sharding)

수평 분할(Horizontal Partitioning)은 스키마가 동일한 데이터를 행을 기준으로 두 개 이상의 테이블에 나누어 저장하는 방법을 말합니다. 수평 분할로 인하여 각 테이블의 데이터와 인덱스의 크기가 감소하고 작업 동시성이 늘어나 성능 향상을 기대할 수 있습니다.

[ 수평 분할 ]

수평적 샤딩은 물리적으로 다른 데이터베이스에 데이터를 수평 분할방식으로 분산 저장하고 조회하는 방법을 말합니다. 수평적 샤딩은 성능상의 이익뿐만 아니라 하나의 데이터베이스 인스턴스에 넣을 수 없는 큰 데이터를 분산하여 처리하기 위해서 사용됩니다. 분할된 각 데이터베이스를 ‘Shard’ 또는 ‘Database Shard’라고 부릅니다.

[ 수평적 샤딩 ]

수직적 샤딩(Vertical Sharding)

수직적 샤딩은 데이터베이스를 수직으로 나누어서 분산 저장하는 방식을 말합니다.

[ 수직적 샤딩 ]