지난 금요일에 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
'01_Note' 카테고리의 다른 글
Windows 에서 PHP 실행하기 (0) | 2017.10.02 |
---|---|
APMSETUP PHP version upgrade (1) | 2013.05.05 |
eula.1028.txt 의 정체 (9) | 2011.09.26 |