JoJun Blog

 

Redis(레디스)는 오픈소스로 제작된 key-value store 소프트웨어이며,

REmote DIctionary Server 라는 뜻으로 Redis 라는 이름을 붙혔다고한다.

 

2009년 4월에 처음 등장하여 현재는 VMware의 지원을 받아 제작되고 있다.

 

웹호스팅 업체 cafe24에서는 이미 사용을 하고 있다고 합니다.

http://www.cafe24.com/?controller=product_page&type=special&page=redis

 

관련 기사

http://news.naver.com/main/read.nhn?mode=LSD&mid=shm&sid1=105&oid=092&aid=0002029272

 

 

 

레디스를 사용하는 장점

 

1) 리스트, 배열형식의 데이터 처리에 특화됨

- value 값으로 문자열, 리스트, set, sorted set, hash 형 등 여러 데이터 형식을 지원함

- 리스트형 데이터의 입력과 삭제가 mysql 에 비하여 10배정도 빠르다.

 

2) 여러 프로세스에서 동시에 같은 key 에 대한 갱신을 요청할 경우 Atomic 한 처리로 데이터 부정합 방지 Atomic 처리 함수를 제공한다.

 

3) 메모리를 활용하면서 영속적인 데이터 보존

- 명령어로 명시적으로 삭제하거나 expires 를 설정하지 않으면 데이터를 삭제하지 않는다.

- 스냅샷 기능을 제공하여 메모리의 내용을 *.rdb  파일로 저장하여 해당 시점으로 복구할 수 있다.

 

4) 여러대의 서버 구성

- Consistent hashing 혹은 master-slave 형식으로 구성가능함

 

레디스 심화

 

1) 지원하는 데이터 타입과 처리

- 레디스는 5가지 데이터 형을 제공하며, 각각의 데이터형에 맞는 처리 명령어가 별로로 존재한다.

 

[String]

Strings (일반적인 Key-Value)

- string 이라고 해서 문자열만 저장할 수 있는게 아니라,

- 이진 데이타도 저장이 가능하다.(참고로 redis 에는 정수형, 실수형 이 따로 없다.)

- key 에 넣을 수 있는 데이타의 최대 크기는 512 mb 이다.

 

* 데이타형의 값은 정수인 경우는 int 로 아니면 raw 로 encoding 된다.

 

[List]

Lists (Array 형태로 Key 1개에 n개의 값을 가짐, 중복 값 가능)

 

- 배열이라고 생각해도 된다.

- 한 key 에 넣을 수 있는 요소의 최대 개수는 4,294,967,295 개이다.

 

* 데이타형의 값은 설정파일에서 정해준 조건보다 큰 경우는 linkedlist 아니면 ziplist 로 encoding 된다.

 

[Set]

Sets (group 형태로 Key 1개에 n개의 중복되지 않은 값을 가짐)

 

- 정렬되지 않은 집합 형으로 key 에 중복된 데이타는 존재하지 않는다

- 추가, 제거 및 존재체크 시 소모되는 시간이, sets 에 포함된 요소의 수에 관계없이 일정하다

- 한 key 에 넣을 수 있는 요소의 최대 개수는 4,294,967,295 개이다

 

* 데이타형의 값은 설정파일에서 정해준 조건보다 큰 경우는 hashtable 아니면 intset 로 encoding 된다.

 

[Sorted sets]

Sorted Sets (group 형태이나 각 member에 score 값을 가짐 Key-Member-Score)

 

- sorted sets 는 가장 진보한 redis 데이타 형이라고 한다.

- 요소의 추가, 제거, 업데이트는 매우 빠른 방법으로 진행되는데 이는 "요소의 개수의 로그" 에 비례하는 시간이 사용된다.

- 링킹 시스템 등에서 사용되기 좋다.

- sets 의 각요소마다 score 라는 실수 값을 가지고 있는 형태로 score 값으로 오름차순 정렬된다.

- key 에 중복된 데이타는 존재하지 않지만 score 값은 중복 가능하다

 

* 데이타형의 값은 설정파일에서 정해준 조건보다 큰 경우는 skiplist 아니면 ziplist 로 encoding 된다.

 

[Hashes]

Hashes (Object 형태의 Key-Field-Value)

 

- lists 와 비슷한데 "필드명", "필드값" 의 연속으로 이루어져 있다.

- 한 key 에 포함할 수 있는 field-value 쌍의 최대 개수는 4,294,967,295 개이다.

 

* 데이타형의 값은 설정파일에서 정해준 조건보다 큰 경우는 hashtable 아니면 zipmap 로 encoding 된다.

 

2) 여러 프로세스에서 동시에 같은 key 에 대한 갱신을 요청할 경우 Atomic 한 처리로 데이터 부정합 방지 Atomic 처리 함수를 제공한다.

 

3) 메모리를 활용하면서 영속적인 데이터 보존

 

[Expires 명령]

- redis 의 각 key 에는 만기시각을 설정해줄 수 있다. 이는 redis 명령 중 expire 명령으로 설정해줄 수 있다.
- 만기시각이 지난 key 는 자동적으로 메모리에서 제거된다.
- 메모리가 full 된 상태에서 LIMITS 설정에서 선택한 정책에 따라 만기시각이 지정되지 않거나 만기시각이 남은 key 라도 삭제될 경우가 있다.

 

[Persistence]

- redis 는 메모리 기반 DB 이기 때문에 전원이 꺼지면 데이타가 모두 날라가게 된다. 이를 보완하기 위하여 파일에 메모리상의 데이타를 저장해두고 redis 서버 실행시 다시 그 파일에서 데이타를 읽어와 메모리상에 올리는 기능을 제공한다
- redis 는 RDB 와 AOF 의 두가지 지속성을 제공한다.

RDB >

- 메모리상의 데이타를 모조리 파일로 덤프를 뜨게 된다.
- command 중 bgsave(비동기적) or save(동기적) 를 실행하면 이 지속성으로 파일을 쓰게할수 있다.
- 설정파일에서 SNAPSHOTTING 부분이 이 지속성과 관련된 부분이다.
- 저장 파일은 보통 .rdb 를 확장자로 쓴다.


•프로세스
1.redis 는 fork 로 자식 프로세스를 생성한다.
2.자식 프로세스는 임시 rdb 파일에 data 를 쓴다.
3.자식 프로세스가 임시 rdb 파일에 data 쓰기를 마치면, 임시 rdb 파일로 옛날 rdb 파일을 덮어 씌운다.

•장점
◦특정 시점의 백업 및 복구에 유리하다.
redis-server 디스크에 저장하는 시점까지 disk i/o 가 일어나지 않으므로 성능을 극대화 할수 있다.
◦AOF 에 비해 더 빨리 메모리 에 data 를 올리고 redis-server 를 시작 할수 있다.

•단점
◦사고 발생시 백업이 일어나는 시점들 사이에 일어나는 변경사항이 손실된다.
◦백업시 fork() 로 자식 프로세스를 생성해서 백업 작업을 시행하는데 이때 데이타가 크다면 순간적으로 많은 cpu 부하가 발생할 수 있다.

 

 

AOF >

- 실행한 명령들을 계속 파일에 추가해나가는 방식. mysql 의 바이너리로그 와 비슷하다고 볼 수 있다.
- command 중 BGREWRITEAOF 을 실행하면 이 지속성으로 파일을 쓰게할 수 있다.
- 설정파일에서 APPEND ONLY MODE 부분이 이 지속성과 관련된 부분이다.
- 저장 파일은 보통 .aof 를 확장자로 쓴다.
- AOF 는 설정파일에서 파일을 쓰는 시점에 대해 3가지 옵션을 제공하는데 보통 기본값인 everysec 를 사용하면 된다.

•Log rewriting
◦쓰기 내용이 많아져서 불필요할정도로 aof 파일이 커진 경우 BGREWRITEOF 명령의 실행에 의해 데이타 내용을 살릴수 있는 짧은 명령을 쓰게 된다.

•AOF 손상 확인 방법 : aof 파일을 쓰는 중 정전등의 문제로 파일이 손상될 수 있다. 이 때 redis-check-aof 툴로 복구가 가능하다.
1.aof 파일을 복사한다.
2.redis-check-aof --fix <aof복사본파일> 을 실행해 복사본 파일을 수정(복구)한다.
3.(옵션사항)diff -u 명령으로 두 파일을 비교한다.
4.수정된 파일을 이용해 redis-server 를 다시 시작한다.

•장점
◦사고 발생시 손실되는 데이타가 최소화된다.
◦정전등의 문제로 aof 파일에 문제가 생긴다 해도 redis-check-aof 로 aof 파일의 복구가 가능하다.
◦aof 파일은 포맷이 단순하여, 문제가 있는 쿼리만 삭제하고 복구에 사용한다던가 하는 작업이 가능하다.

•단점
◦rdb 파일에 비해 보통 사이즈가 커지게 된다.
◦AOF 는 fsync 정책에 따라 RDB 보다 느릴수 있다.(아무래도 RDB 보다 쓰기가 많이 일어나게 되므로)

 

[메모리 설정]

 

•maxclients 128
redis 서버에서 클라이언트의 접속을 동시에 몇 개 까지 받아들일지 설정하는 부분.
◦0 으로 할 경우 무제한으로 접속을 받아들인다.
◦설정된 수를 초과하여 클라이언트 접속이 시도되는 경우 에러를 반환해준다.

•maxmemory
◦서버에서 사용할 물리적 메모리 양을 결정한다. 이 메모리양에는 실제 데이타는 물론 각종 설정 상태를 기억하는 부분 까지 포함된다.

◦그냥 숫자만 쓰면 바이트 단위가 되며, 다음과 같은 표기도 가능하다.
■1k : 1000 bytes
■1kb : 1024 bytes
■1m : 1000000 bytes
■1mb : 1024*1024 bytes
■1g : 1000000000 bytes
■1gb : 1024*1024*1024 bytes

•maxmemory-policy volatile-lru
◦maxmemory 에서 설정한 메모리 를 초과해서 데이타를 쓰려고 할 경우의 정책 설정 부분으로 아래와 같은 옵션이 있다.

■volatile-lru : (기본값) 만기시각이 설정된 key 들 중에서 LRU algorithm 에 의해 key 를 골라 삭제
■allkeys-lru : LRU algorithm 에 의해 key 를 골라 삭제
■volatile-random : 만기시각이 설정된 key 들 중에서 랜덤하게 key 를 골라 삭제
■allkeys-random : 랜덤하게 key 를 골라 삭제
■volatile-ttl : 만기시각이 설정된 key 들 중에서 만기시각이 가장 가까운 key 를 골라 삭제
■noeviction : 어떤 key 도 삭제하지 않고 error on write operations 를 돌려준다.

 

4) 여러대의 서버 구성

 

•slave-serve-stale-data yes
◦마스터노드와의 연결이 끊겼을 경우 슬레이브노드로 들어오는 명령에 어떻게 대처할지 설정해주는 부분


■yes : 슬레이브노드에서 읽기나 쓰기 명령을 모두 받고 처리해준다.
■no : 슬레이브노드로 들어오는 모든 명령에 에러상태를 되돌려준다. 쉽게 말해 읽기 쓰기 모두 처리 안해준다.

 

•repl-ping-slave-period 10
◦슬레이브노드에서는 주기적으로 마스터노드에 ping 명령을 날려 마스터노드와의 접속상태를 확인하는데 그 주기(초단위)를 설정하는 부분. 기본값은 10초 이다.

•repl-timeout 60
◦이 값은 대량의 I/O 와 data 에 대한 timeout 을 설정해주는 부분인데, repl-ping-slave-period 값 보다 크게 설정해줘야 한다.
◦단위는 초단위 이고 기본값은 60초 이다.

 

마스터 - 슬래이브 구조에서 마스터가 죽을경우 처리 할 수 있게 하려면 REDIS 에서 제공하는 sentinel 설정을 통하여 서버 상태를 모니터링하다가 마스터 서버가 다운되면 슬래이브 중 1대를 마스터로 설정하는 처리를 할수 있다.

 

출처 : http://cafe.naver.com/junes81/6088, http://dsmoon.tistory.com/92

 

 

 

 


댓글(Comment) +0