일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- #Swagger
- 프로세스
- SRE
- 북딜
- docker
- Site Reliability engineering
- #Swagger-ui
- Reducer
- AWS
- IP
- javascript
- #스웨거
- Kubernetes
- 프로세스 통신
- React.js
- 쿠버네티스
- ecs
- 쿠버네티스 컨트롤러
- #Swagger-editor
- React
- fluentd
- 기술PM
- #api 문서화
- server
- 모캠
- action
- 모두의캠퍼스
- Redux
- #Swagger-codegen
- 카카오게임즈
- Today
- Total
탕구리's 블로그
Redis & memcached 정리 본문
- 일단 기본적으로 redis는 memcached의 단점을 보안하고자 만들어짐
- 두개는 비슷한듯 다르기 때문에 장단점을 볼수 있음
공통점
- redis와 memcached 모두 In-Memory 메모리 기반이다.
- key-value 형식의 No-sql이다.
Redis
- 자료구조가 다양합니다. String, Set, Sorted Set, Hash List 등 다양한 자료구조를 제공합니다.
- 현재는 JSON 타입에 대해서도 지원한다.
- 메모리 뿐만 아니라 디스크도 사용하기 때문에 데이터 복구시 유용하다.
- 싱글 스레드를 사용한다.
- 다양한 Eviction 정책을 동에 세밀한 Eviction 제어가 가능하다
Memcached
- 멀티스레드 아키텍처를 지원한다.
- 참고한 블로그에 "Single Thread인 Redis에 비해 Memcached는 Multi Thread를 지원하기 때문에 서버 Scale up에 유리하다"라고 나와있는데, 멀티스레드와 스케일업의 상관관계에 대해서 좀 더 생각해볼 필요성이 있겠다.
- Redis 보다 적은 메모리를 요구한다.
- Redis와 Memcached 사이에 기본적으로 데이터를 저장하고 캐싱하는 방식에 차이가 있는 것 같다. Memcached는 정적인 데이터 저장에 유리하다. Redis는 Copy-on-Write 방식을 사용하기 때문에 실제 사용하는 메모리보다 더 많은 메모리를 요구한다.
Redis에서 실제 사용하는 메모리보다 더 많은 메모리를 요구하는 이유는?!
- Redis의 Copy on Write가 가장 기본적인 이유
- 리눅스에서는 자식 프로세스 생성에 대해 메모리 공간을 공유한다.
- 하지만 부모 프로세스가 데이터를 넣거나, 수정하거나, 지우게 되면 메모리 공간을 공유할 수 없게된다. 이때 부모 프로세스는 해당 페이지를 복사한 다음 수정한다.
- 그렇기 때문에 Redis에서는 실제 사용하는 메모리보다 임시로 데이터를 복사하고 수정하기 위해 더 많은 메모리 영역을 필요로 하는 것이다.
Copy-on-Write는 언제 발생하는가?
- save 파라미터
- BGSAVE 명령
- BGSAVE 명령이 실행될 때 RDB파일을 새로 쓴다. 위와 같은 경우이다. 하지만 SAVE 명령에는 COW가 발생하지 않는다. (레디스 프로세스가 직접 수행하기 때문)
- 복제 Replication
- auto aof-rewrite-percentage 파라미터
- redis.conf 파일에 디폴트로 "auto-aof-rewrite-percentage 100" 이런 파라미터가 있다. 의미는 appendonly 파일이 100% 커지면 appendonly 파일을 다시 쓰라는 것이다. 다시 쓰기는 AOF 자식 프로세스가 생성되어 작업하는데, 이때도 COW가 발생한다.
- redis.conf 파일에 디폴트로 "auto-aof-rewrite-percentage 100" 이런 파라미터가 있다. 의미는 appendonly 파일이 100% 커지면 appendonly 파일을 다시 쓰라는 것이다. 다시 쓰기는 AOF 자식 프로세스가 생성되어 작업하는데, 이때도 COW가 발생한다.
-
BGREWRITEAOF
-
BGREWRITEAOF 명령을 수행하면 자식 프로세스가 생성되어 appendonly 파일을 다시 쓴다. 이때도 COW가 발생한다.
-
-
redis.conf에 default value로 "save 60 10000" → 60초 동안 1만 개의 키가 새로 입력되면 RDB 파일을 새로 작성, 새로 파일을 작성할 때 자식 프로세스가 생성되어 작업을 진행하는 과정에서 COW 발생
-
redis.conf에 default value로 "save 60 10000" → 60초 동안 1만 개의 키가 새로 입력되면 RDB 파일을 새로 작성, 새로 파일을 작성할 때 자식 프로세스가 생성되어 작업을 진행하는 과정에서 COW 발생
Copy-on-Write를 방지하기 위해서는?
- RDB save 파라미터: 사용하지 말 것을 권한다. 대신 AOF를 everysec로 사용한다.
- RDB BGSAVE 명령: 꼭 필요한 경우에만 서버 부하가 적을 때 사용한다.
- RDB 복제: 새 슬레이브 연결은 부하가 적은 때를 이용한다. 기존 슬레이브에 문제가 생겨서 전체 데이터 복제(full resync)는 어쩔 수 없다.
- AOF auto-aof-rewrite-percentage 파라미터: 사용하지 말 것을 권한다. 즉 0으로 설정해서 disable 한다.
- 그럼, AOF 파일이 계속 커지는 것을 걱정할 것이다. 서버 부하가 적을 때 BGREWRITEAOF 명령을 수행해서 크기를 줄인다. 이에 대한 자세한 내용은AOF Backup을 보세요.
- AOF BGREWRITEAOF 명령: 서버 부하가 적을 때 사용한다. appendfsync everysec 설정과 관련하여 문제를 발생시키지 않는 방법은AOF Backup을 보세요.
AOF (append only file)?
- redis에서 사용할 수 있는 RDB 스냅샵의 대안이다. 레디스가 변경 커맨드를 받을 떄 마다, AOF 파일에 커맨드를 추가한다.
- AOF 사용하기를 설정하고 레디스를 재시작하면 모든 커맨드를 순서대로 실행하여 복구할 수 있다.
- RDB 파일은 바이너리인 반면 AOF 파일은 로그 파일이다.
- save 파라메터나 BGSAVE 명령을 실행하지 않아도 자신이 마스터이고 슬레이브가 연결되면 전체 데이터 동기가 발생하여 이때도 RDB 파일을 만들게 되므로 COW가 발생한다.
- appendfsync : AOF에 기록하는 시점을 정합니다.
- always: 명령 실행 시 마다 AOF에 기록합니다. 데이터 유실의 염려는 없으나 성능이 떨어집니다.
- everysec: 1초마다 AOF에 기록합니다. 1초 사이 데이터 유실될 수 있으나, 성능에 거의 영향을 미치치 않으면서 데이터를 보존할 수 있어, 일반적으로 권장합니다.
- no : AOF에 기록하는 시점을 OS가 정합니다. 일반적으로 리눅스의 디스크 기록 간격은 30초 입니다. 데이터가 유실될 수 있습니다.
ReJSON에 관하여 : https://redislabs.com/blog/redis-as-a-json-store/
Redis Eviction & LRU cache policy : https://americanopeople.tistory.com/179
COW 발생 시점과 해결방법 : http://redisgate.kr/redis/configuration/copy-on-write.php
redis conf 과련 설정 : http://redisgate.kr/redis/configuration/persistence.php
'Conception' 카테고리의 다른 글
형상관리(Configuration Management) (0) | 2020.08.03 |
---|---|
RPC(Remote Procedure call)에 대해 알아보자! (3) | 2020.05.03 |
OAuth2.0에 대해서 알아보자! (2) | 2019.10.17 |
스트림과 버퍼에 대해 알아보자! (4) | 2018.12.17 |
하태핫해! 핫한 Webpack에 대해 알아보자! (0) | 2018.12.15 |