Redis

지난 금요일에 charsyam님 세미나가 있어 듣고 왔습니다. 

제 부실한 기억을 더듬고 그 세미나에서 메모했던 내용과

이후에 자료를 찾아보면서 내용을 조금 더하고 뺀 내용을 합쳐서

아래와 같이 정리해보았습니다. 

세미나 진행 내용 이외에 제 주관적인 생각이 일부 포함되어 있습니다. 

잘못 이해한 내용이 있으면 댓글 부탁 드립니다. 

Redis Management & Cell Architecture 

charsyam님 세미나 발표 자료. 

http://www.slideshare.net/charsyam2/redis-acc

#0 TIP 정리 

 - keys 쓰지 말것, Collection에 1만개 이상 넣지 말것

 - Key data는 미리 분산 및 탐색을 고려하여 설계 할 것 

 - Replication은 초기에 걸고 시작할 것

 - 일시적으로 MaxMemory 설정의 2배까지 늘어날 수 있음. 초기 구성시에 고려. 

 - 메모리 가격 절감을 위해 한 서버에 여러 redis 서버를 운영하는 것을 권장.

 - Master 에서는 File 저장 없이 Memory만 쓰고 Slave가 File 저장할 것 

#1 Single Thread

 - 오래 걸리는 명령어 쓰지 마세요. 대표적으로 keys

 - flushall 에서도 O(N) 합니다. 

 - 2.8 에서 key를 대체할 scan이 생기긴 했는데.. 이것도 좀.

#2 Collection (List, set 등) 

 - 하나의 Collection에 1만개 이상의 element는 넣지 않도록. 

 - Collection을 통째로 처리 할 때 부하가 생김. 

#3 Redis Memory 

#3-1 Memory Limit

 - 32bit: Max Memory 3G

 - 64bit: No max Memory => 실제 메모리 이상 쓰면 swap 하면서 뒤짐 

 - Max memory 이상 사용하는 경우 config 정책에 따라 다름 

#3-2 Memory 해제되는 경우 3가지 

 => 저장된 데이터가 사라지는 경우 

 - Expire Check when Key Access (값 읽을 때 만료된 데이터면 해제)

 - activeExpireCycle (아무나 몇 놈 뽑아서 만료된 데이터 해제)

 - Max Memory Strategies. (메모리 모자라면 기존 데이터 해제)

#3-3 Max Memory Strategies 종류 

 - volatile or allkeys (expire 만 볼 것인가, 전체 키를 대상으로 할 것인가)

 - LRU, TTL, Random (오래된 키, expire가 적게 남은 키, 아무 키)

 - 기본 값은 volatile-lru

#3-3 Max Memory Strategies 주의 사항 

 - Max memory 설정에 따라 날아가는 데이터가 다르다. 

 - Strategies 가 allkeys인 경우 expire 값과 관계 없이 기존 데이터 중 삭제.

 - Strategies 가 volatile인 경우 expire 값이 있는 키에 한해서 삭제.

 - 남은 key 중 expire가 없을 경우 기존 데이터 보존 위해 새로 들어온 데이터 무시. 

 

#4. Persistance 

 - RDB (Snapshot) 정확한 약자는 모르겠는데 Redis Data Binary 정도 되는듯.

 - AOF. Append-Only File. Reids 변경 사항을 모두 기록함. 

#4-1. RDB snapshot with fork 

 - RDB 는 Snapshot을 만드는 시점에서 

 - read lock을 걸지 않고 

 - copy 하는 시점의 메모리를 그대로 복사하기 위해 fork를 함. 

#4-2. fork risk

 - 요즘 OS에는 COW(Copy-On-Write) 라는 걸 지원해서 항상 2배를 할당하지는 않음. 

 - Write가 빈번하면 메모리 복사를 하게 되고. 최대 2배가 복사되는 건 동일함.

 - 실제 메모리보다 더 많은 메모리가 필요하므로.. 이 또한 swap 하면서 뒤짐 

#4-3. Fork가 일어나는 또 다른 시점 

 - AOF에서도 AOF 자체가 너무 커지면 주기적으로 파일 덤프로 찍음

 - Replication 에서 새로운 Slave와 최초 sycn할 때, Master RDS(Snapshot)을 찍음

 => 이미 Master가 write 부하가 큰 상태에서는 Replication 을 거는 것도 위험. 

 => Replication 구성 없이 Master 부하가 커지면 Redis는 망한다?!

#5. 추천 구성

#5-1. Replication 

 - Master - Slave Replication을 미리 구성한다.

 - Master 는 빠른 응답을 위해 RDB도 AOF 도 하지 않는다. 

 - Slave 는 필요에 따라 RDB 혹은 AOF 를 구성한다. 

 - Master 장애시 데이터가 날아간 상태가 sync 되지 않도록 주의한다. 

#5-2. Max memory 설정

 - 하나의  Redis-Server 인스턴스 당 Max-memory x2 의 메모리가 필요하다. 

 - Snapshot 시점을 잘 분산하여 N개의 서버를 동시에 운영 

 - ex1. 15GB메모리에서 Max-memory를 7.5GB 1대 운영시, 할당은 7.5GB 여유는 7.5GB 

 - ex2. 15GB메모리에서 Max-memory가 5GB 2개를 운영시, 할당은 10GB 여유는 5GB 

 - 두 redis가 동시에 snapshot을 찍지 않으면 메모리가 터질 위험은 적다. 

 - 결국 Redis 서버를 여러대로 나누면, 분산 처리가 포인트

#5-3. ZooKeeper 를 쓰는 것도 대안 

 - Zookeeper가 뭘까요. 

#5-4. Twemproxy 를 쓰는 것도 대안 

 - 어떤 redis로 갈지 알아서 hashing을 해줘서 내부 분산

 - SET/GET 정도 핵심 기능만으로 구성시 사용 가능

 - pub/sub 등 지원하지 않는 명령어가 발생하니 주의

#6. SEE ALSO

 - Redis Management & Cell Architecture http://www.slideshare.net/charsyam2/redis-acc

 - charsyam's blog redis http://charsyam.wordpress.com/category/cloud/redis/

 - Maxmemory policy http://dol9.tistory.com/200

 - ZooKeeper를 활용한 Redis Cluster 관리 http://helloworld.naver.com/helloworld/294797