탕구리's 블로그

Redis & memcached 정리 본문

Conception

Redis & memcached 정리

탕구리당 2019. 10. 28. 00:47
반응형
  • 일단 기본적으로 redis는 memcached의 단점을 보안하고자 만들어짐
  • 두개는 비슷한듯 다르기 때문에 장단점을 볼수 있음

공통점

  • redis와 memcached 모두 In-Memory 메모리 기반이다.
  • key-value 형식의 No-sql이다.

Redis

  • 자료구조가 다양합니다. String, Set, Sorted Set, Hash List 등 다양한 자료구조를 제공합니다.
  • 현재는 JSON 타입에 대해서도 지원한다.
  • 메모리 뿐만 아니라 디스크도 사용하기 때문에 데이터 복구시 유용하다.
  • 싱글 스레드를 사용한다.
  • 다양한 Eviction 정책을 동에 세밀한 Eviction 제어가 가능하다

redis maxmemoy-policy

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가 발생한다.

       

  • 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

반응형
Comments