Memcached vs Redis

Memcached

Redis(Remote Dictionary Storage)

Memcached

정의

Memcached는 범용 분산 캐시 시스템이다. 외부 데이터 소스(예: 데이터베이스나 API)의 읽기 횟수를 줄이기 위해 데이터와 객체들을 RAM에 캐시 처리함으로써 동적 데이터베이스 드리븐 웹사이트의 속도를 높이기 위해 종종 사용된다.

데이터 베이스의 부하를 줄여 동적 웹 어플리케이션의 속도 개선을 위해 사용되기도 한다. DB나 API 호출 또는렌더링 등으로부터 받아오는 결과 데이터를 작은 단위의 Key-Value 형태로 메모리에 저장하는 방식으로 동작한다.

Memcached는 필요량보다 많은 메모리를 가졌을 때, 시스템으로부터 메모리를 사용하고 필요로하는 메모리가 부족한 경우 이를 쉽게 가져다 사용할 수 있도록 만들어 준다.

작동 원리

Memcached를 사용하지 않을 땐 분리되어 있는 메모리에 대해 각각의 서버에서 사용할 수 있는 것은 할당된 메모리 크기만큼인데 Memcached를 적용할 경우에는 논리적으로 결합되어 있기 때문에 각 웹서버는 전체 메모리 캐시만큼의 용량을 사용할 수 있다. 즉, 효율성 있게 메모리 운영이 가능해진다는 것이다.

• Memcached를 사용하지 않을 경우

각 노드는 완벽하게 독립적임

이 경우 고전적으로 사용되던 방식으로 총 캐시 크기가 웸팜(여러 대를 사용해서 웹사이트를 구축한 형태)의 실제 용량의 일부분으로만 사용이 가능하다는 점에서 낭비가 심하다. 각각의 서버에 할당된 캐시 크기만큼 사용할 수 있으므로 웹팜의 캐시 사이즈는 128MB이지만 각 서버에서 사용할 수 있는 사이즈는 64MB이다.

• Memcached를 사용할 경우

Memcached로 묶인 모든 서버는 동일한 가상 메모리 풀을 공유한다. 이것은 특정한 항목이 주어졌을 때, 전체 웹 클러스터에서 동일한 위치에 저장되고 검색 되어짐을 뜻한다. 또한 응용에 대한 수요가 증가하여 서버 증설에 대해 필요성을 느낄 때, 정기적으로 접근되어야 하는 데이터의 관점에서도 수요가 증가한다고 볼 수 있다.

Memcached를 적용하면 분산 메모리 캐시를 적용하게 되는 것이므로 캐싱을 통해 DB나 API 호출에 대한 횟수를 줄이 수 있고, 이로 인해 응용의 수요나 DB 데이터 접근에 대한 부하를 줄여 성능을 향상 할 수 있다.

Redis

정의

오픈소스로서 데이터 베이스(NOSQL DBMS)로 분류가 되기도 하고 Memcached와 같이 인메모리 솔루션으로 분류되기도 한다.

데이터를 메모리에 저장하기 때문에, 기존 데이터베이스보다 빠른 장점이 있다.

성능은 Memcached에 버금가면서 다양한 데이터 구조체를 지원함으로써 Message Queue, Shared Memory, Remote Dictionary 용도로도 사용될 수 있으며, 이런 이유로 인스타그램 , Line, StackOverflow, Blizzard, digg 등 여러 소셜 서비스에 널리 사용되고 있다.

NoSQL 관점에서 Redis는 가장 단순한 Key-Value 타입을 사용하고 있다. 데이터 모델이 복잡할수록 성능이 떨어지므로 Redis는 단순한 구조를 통해 높은 성능을 보장한다고 할 수 있다.

장점

• 데이터 저장소로 가장 입/출력이 빠른 메모리를 채택
• 단순한 구조의 데이터 모델인 Key-Value 방식을 통해 빠른 속도를 보장
• 캐시 및 데이터 스토어에 유리
• 다양한 API 지원

Redis, Memcached, 구아바 라이브러리 등 인메모리 캐시 방식을 적용한 제품 중 Redis는 global cache 방식을 채택하였다. global cache 방식은 네트워크 트래픽이 발생하기 때문에 java heap 영역에서 조회되는 local cache보다 성능이 떨어지지만, WAS 인스턴스가 증가할 경우엔 캐시에 저장되는 데이터 크기가 커질수록 Redis가 유리하다.

Redis는 급격하게 사용자가 집중되는 상황이나 대규모의 확장이 예정되어 있는 환경에 적합하다. global cache 방식이 적용되어 WAS 인스턴스 확장에는 유리하지만 cache 및 redis 세션 등 관리 포인트가 늘어난다는 단점이 있다.

특징

• Key-Value 저장 방식

• 다양한 데이터 타입

  • string
  • set
  • sorted set
  • hashes
  • list

• Persistence: Redis는 데이터를 디스크에 저장할 수 있다. memcached의 경우 메모리에만 데이터를 저장하기 때문에 서버가 shutdown된 후에 데이터가 유실되지만, redis는 서버가 shutdown된 후 restart 되더라도, 디스크에 저장해놓은 데이터를 다시 읽어서 메모리에 Load하기 때문에 데이터가 유실 되지 않는다. Redis가 데이터를 저장하는 방법은 snapshotting 방식과 AOF 두 가지가 있다.

  • snapshotting (RDB): 순간적으로 메모리에 있는 내용을 디스크에 전체를 옮겨 담는 방식이다. SAVE와 BGSAVE 두 가지 방식이 있는데, SAVE는 blocking 방식으로 순간적으로 Redis 동작을 정지시키고, 그 때의 snapshot을 디스크에 저장한다. BGSAVE는 non-blocking 방식으로 별도의 process를 띄운 후, 명령어 수행 당시의 메모리 snapshot을 디스크에 저장하며, 저장 순간에 redis는 동작을 멈추지 않고 정상적으로 동작한다.

장점: 메모리의 snapshot을 그대로 뜬 것이기 때문에, 서버 restart 시 빠르다.

단점: snapshot을 추출하는데 시간이 오래 걸리며, 추출된 후 서버가 down 되면, snapshot 이후의 데이터는 유실된다.

• AOF(Append on File): Rdis의 모든 write/update 연산 자체를 모두 log 파일에 기록하는 형태이다. 서버가 재시작될 때 기록된 wirte/update operation을 순차적으로 재실행하여 데이터를 복구한다. operation이 발생할 때마다 매번 기록하기 때문에, RDB 방식과는 달리 특정 시점이 아니라 항상 현재 시점까지의 로그를 기록할 수 있으며, 기본적으로 non-blocking call이다.

장점: log file에 대해서 append만 하기 때문에, write 속도가 빠르며 어느 시점에 서버가 down 되더라도 데이터 유실이 발생하지 않는다.

단점: 모든 write/update operation에 대해서 log를 남기기 때문에 로그 데이터 양이 RDB 방식에 비해서 과대하게 크며, 복구 시 저장된 write/update operation을 다시 reply하기 때문에 재시작 속도가 느리다.

• Pub/Sub 모델: 1:1 형태의 Queue 뿐만 아니라 1:N 형태의 Publish/Subscribe 메시징도 지원한다. (Publish/Subscribe 구조에서 사용되는 Queue를 일반적으로 Topic이라고 한다). 하나의 Client가 메시지를 Publish 하면, 이 Topic에 연결되어 있는 다수의 클라이언트가 메시지를 받는 구조이다.

  

  일반적인 Pub/Sub 시스템의 경우 Subscribe하는 하나의 Topic에서만 Subscribe하는데 반해서, redis에서는 pattern matching을 통해서 다수의 Topic에서 message 를 subscribe할 수 있다. 예를 들어 topic 이름이 music.pop, music.classic 이라는 두개의 Topic이 있을때, "PSUBSCRIBE music.*"라고 하면 두개의 Topic에서 동시에 message를 subscribe할 수 있다.

참고자료: 불곰님 티스토리 블로그