Redis Architecture (번역문)

본 문서의 내은 아래 사이트의 내용을 번역한 내용 위주로 작성된 글입니다.

http://qnimate.com/overview-of-redis-architecture/

Redis 는 in-memory,  key-value 데이터 저장소이다. Redis는 가장 유명한 key-value 데이터 저장소이다. 또한 Redis는 세상의 모든 대형 IT 회사들이 사용한다. Amazon Elastic Cache 는 Redis  의 매우 강력하고 Key-value 데이터 저장소 기술로 활용된다. 이 포스트에서 redis.의 아키텍쳐에 대해 소개한다.

 

In- Memory, Key-value 저장소란 ?

키-밸류 저장소는 Key와  Value의 쌍으로 저장된 저장소이다. 우리가 흔히 In-memory key-value 저장소라 함은 메모리상에 key-value가 쌍으로 저장됨을 의미한다.  Redis 역시 이러한 구조이다.

Redis에서 key는 string이미지만 value는 string, list, sorted set 또는 hash 값을 갖을 수 있다.

이러한 몇가지 key-value 예는 아래와 같다.

 

name="narayan"

profession=["web", "mobile"]

 

여기에서 name과 profession은 key에 해당한다. 그리고 오른쪽에는 그에 해당하는 값들을 의미한다.

 

DBMS위에 Redis 와 장점과 단점

 

데이터베이스 시스템은 쓰기 명령을 기반으로 매우 느리게 기록되는는 이차(Secondary) 저장소이다. 하지만 redis는 모든 것을들 매우 빠른 속도로 읽기 및 저장하는 1차 저장소이다.

Primary memory의 크기는 제한적이다. 오직 작은 문자형 정보형들만 저장가능하다. 만약 우리가 메모리보다 더 큰 데이터를 쓰고자 하면 에러를 받을 것이다.

 

 

Redis Single Instance Architecture

 

Redis는 크게 2가지 client와 server 구성 프로스세로 나뉜다.

Redis client와 server는 단일 머신이나 또는 다른 2대의 computer에서 동작할 수 있다.

Redis server는 메모리상에 데이터를 저장하는 책임을 갖는다. Redis client는 console client나 또는 Redis API를 이용하여 다른 어떠한 프로그래밍 언어로도 사용 가능한다.

 

Redis Persistance

데이터를 저장하는데에는 크게 3가지 다른 방법이 존재한다. : RDB, AOF 그리고 SAVE

 

RDB Mechanism

RDB는 메모리상에 모든 데이터를 복사하고 그것들을 2차 저장소(디스크)에 저장한다. 이러한 행동들은 정해진 간격을 두고 행해진다. 그리고 이 때 RDB의 마지막 스냅샷을 기록한 이후부터는 데이터를 잃을 수 있는 가능성이 있다.

 

AOF

AOF는 모든 쓰기 명령들을 서버로부터 수신하여 기록한다. 그렇기 때문에 모든것들이 영구적이다. 다만 AOF는 모든 쓰기 명령들에 대해 기록하기 때문에 비용이 비싸며 RDB  파일보다 사이즈가 크다.

 

SAVE Command

사용자들은 언제든지 redis console clinet상에서 SAVE 명령을 이용하여 RDB 스냅샷을 강제 생성할 수 있다. 또한 최적의 결과를 얻기 위해 AOF와 RDB 둘 다 사용할 수도 있다.

 

Backup And Recovery Of Redis DataStore

Redis는 데이터 백업과 복원을 위해서는 어떠한 매커니즘을 제공하지 않는다. 그렇기에 하드디스크의 충돌(Crash)나 다른 어떠한 장애 상황을 대비해서 3rd party 서버 백업 솔루션이 필요할 것이다. 만약 당신이 redis 복제 환경을 구성했다면 백업 솔루션은 필요 없을 것이다.

 

Redis Replication

복제는 무장애를 만들 수 있는 기술이다. 복제환경상에서 많은 컴퓨터들을 동일한 데이터를 상호 교환함으로 만약 몇 대의 컴퓨터가 다운된다 하더라고 모든 데이터는 이용가능하다.

 

Persistance In Redis Replication

지금까지 예상치 못한 장애나 백엔드 단에서 안전하게 운영 및 유지하는 방안에 대해 살펴보았지만 단 한 경우 모든 복제 환경이 다운되었을 때 데이터를 잃을 수 있는 상황이 있다.

이러한 상황이 발생할 수 있는 이유는 모든 데이터가 Primary  메모리 상에 올라가기 때문에 발생한다. 그렇기에 우리는 마스터 또는 슬레이브 장비 중 하나에 대해 저장 속성(AOF 또는 RDB) 속성을 이용할 수 있다. 이러한 기능을 사용함으로 완전하게 안전하게 데이터를 저장 및 복제 운영할 수 있다.

Clustering In Redis

클러스터링 기술은 여러 컴퓨터들에데 데이터를 Shard (분산)하는 방식이다. 이 것의 가장 큰 장점으로는 컴퓨터들의 조합으로 인해 더 많은 데이터들을 저장 할 수 있다는 것이다.

예를 들어 우리가 하나의 redis server에 64GB의 메모리가 있다면 우리 데이터는 64GB 가 max 이다. 하지만 만약 우리가 10대의 컴퓨터에 클러스터링을 구성한다면 640GB의 데이터를 저장할 수 있게 된다.

 

위에는 4개의 노드로 샤드되어진 데이터를 볼 수 있다 .각각의 노드에서는 closter node 처럼 redis server가 구성되어져 있다.

만약 이 노드 중 하나의 노드가 멈추게 된다면 전체 클러스터가 멈추게 될 것이다.

 

 

Persistance In Cluster

데이터는 노드들의 primary  memory 상에서 저장되어져 있다. 여기서는 각각의 노드들에 persistance를 설정할 필요가 있다. 앞에서 언급했듯이 AOF 또는 RDF를 이용하여 모든 노드에서 persistance를 구정할 수 있다.

 

 

Clustering And Replication Together

 

디스크에서 Crash 가 발생하고 노드 중 하나가 멈추는 상황이 발생하면 전체 클러스터는 멈추게 되고 결코 되살아 나지 않을 것이다. 데이터들은 완전하게 잃을것이고 데이터를 복수 할 수 있는 상황을 없게 된다.

이러한 상황을 피하기 위해 각각의 노드들을 정기적으로 수동 백업을 할 수 있지만 매우 터프하고 부적절한 작업이 될것이다. 그렇기에 복제 기술로 이 문제를 해결할 수 있을 것이다.

 

 

위 그림에서 각각의 노드 서버들을 마스터 서버로 전환했다.  그리고 모든 마스터 노드들을 위한 slave를 유지했다. 그럼으로 만약 어느 노드라도 실패를 하게 되면 클러스터는 slave를 이용하여 클러스터 명령들을 수행할 것이다.

 

 

Redis Client

If you are first time getting yourself into redis then these links will be very helpful to install redis and learn redis client.

1. Try Redis: This is a awesome online Redis console client which will help you to learn how to use Redis console client.
2. Redis Quick Start: This article will help you to install redis and get started with it.
3. FAQ’s: You can see the frequently asked questions about redis on this link.

 

 

 

★닷넷에서 활요 가능한 Redis Client

 

출처: <http://redis.io/clients#c>

 

공식 페이지상에 여러 개의 3rd library 가 소개되어 있지만 개인적으로는 StackExchange 가 가장 쓰기 편한듯 싶다.