[NoSQL & Cache] Redis vs Memcached ( 왜 Redis 를 사용해야 하는가? )

저는 Memcached 를 이용하여 프로젝트를 한적이 있습니다.
그리고 개인적으로 캐시 솔루션에 관심이 많습니다. (회사에서 하는 업무도 이쪽이 많습니다.)

여튼…

저희 팀원분과 어제 새벽에 Memcached 와 Redis 에 관해 채팅으로 의견을 주고 받다가 팀원분이 한번 읽어보라고 주신 글이 있는데
2014년 10월글 이지만 (아직 Redis 3.0 이 나오기 전글) Redis 와 Memcacheed 의 차이점을 알수있고 가볍게 읽어보기 좋은글 같아서
공유를 하고 제 생각을 조금 넣어서 해석을 해서 포스팅 하니 참고가 되었음 좋겠습니다. (대강 해석 했으니 원문보며 참고만 하세요. ^^)

원문 : http://www.infoworld.com/article/2825890/application-development/why-redis-beats-memcached-for-caching.html

————————————————————————————————————————-

Redis 는 더 강력하고 다루기 쉽기 떄문에 보통 캐시 솔루션을 선택할때 Redis 를 선택합니다, 그러나 Memcached 는 여전히 쓰여지고는 있습니다. (저도 쓰고 있습니다.)

Memcached 와 Redis 중에 어떤것이 더 좋을까? 이것은 최근 데이타 베이스 기반 웹 어플리케이션에 관해서 최대한 성능을 뽑아내기 위헤 토론할떄 항상 나오는 질문 입니다.
이것들은 유명한 캐시 엔진들로 비슷한점도 있지만 매우 중요한 차이점이 있습니다.
하지만 역시 Redis 는 Memcached 보다 더 새롬고 다양한 기능이 있기 때문에 대부분 Redis를 선택 하곤 하지만 그렇지 않은 경우도 있습니다.

유사점들

일단 유사한 부분부터 보도록 하겠습니다.

Memcached 와 Redis 는 in-memory 위에서 동작하는 key-value 스토리지로 둘다 NoSQL 에 속하는 데이타 관리 솔루션 이며 둘다 같은 key-value 데이타 모델을 기반으로 동작합니다.
모든 데이타는 메모리 안에 있으며 이는 때문에 캐시 관점에서 매우 유용합니다. 퍼포먼스 측면에서 두 데이타 스토리지는 처리량이나 지연속도 등 동일한 특성을 나타냅니다.
게다가 in-memory 데이타 스토리지들인 Memcached, Redis 둘다 인기 있는 완성된 오픈소스 프로젝트 입니다.

Memcached 는 원래 2003년에 Brad Fitzpatrick 에 의해 LiveJournal 웹사이트를 위해 개발 되었으며 그뒤로 Memcached 는 C 로 다시 개발되었습니다. (최초에는 perl 로 개발됨) 그리고 공개 되었고 새로운 웹 어플리케이션의 패러다임의 초석이 되었습니다. 그리고 지금까지 Memcached 는 새로운 기능보다는 안정성과 최적화에 중점을 두고 개발되고 있습니다.

Redis 는 2009년에 Salvatore Sanfilippo 애 의해 만들어 졌고 그는 여전히 Redis 의 개발을 리드하는 사람이고 혼자서 프로젝트를 작업하는 사람 입니다.
Redis 는 때로 “약빤 Memcached (ㅎㅎ)” 라고 묘사 됩니다. 이는 Memcached 를 사용하면서 좋은점을 기반으로 개발되었기 떄문 입니다.

Redis 는 Memcached 에 비해 기능이 많아 더 강력하고 다루기 쉽지만 좀더 복잡 합니다.

많은 회사들의 셀수도 없는 어플리케이션의 운영 환경에서 개발자들은 다양한 언어의 클라이언트 라이브러리들을 사용하여 Memcached 와 Redis 를 사용하고 있습니다.
사실상 웹 어플리케이션에서 둘중 하나를 사용하지 않는다는 것은 매우 드문이 입니다.

왜 Memcached 와 Redis 는 왜 엄청 인기가 있는것일까요? 뿐만 아니라 매우 효과적이고 상대적으로 심플한것일까요?
둘중 어떤것이든 개발자가 쉽게 사용하기 위해 고려되어있고 이로인해 불과 몇분만에 어플리케아션에 캐시를 적용할수 있습니다.
이것은 매우 작은 시간만 투자해서 즉시 효과를 볼수있고 일반적으로 정렬에서 성능에 극적으로 영향을 끼치며. (보통 데이타 베이스 기반에서 어떠한 데이타를 select 해올때 많은 비용을 차지하는 부분이 order 부분일 것 입니다. 하지만 이런 in-memory 기반의 Memcached 나 Redis 는 메모리에 저장되어 있어서 매우 빠른 정렬이 가능하다는 이야기 같습니다.)
그것은 마치 마법처럼 성능에 있어 간단한 해결책과 큰 이점을 주고 있습니다.

그러면 언제 Memcached 를 사용해야 할까요?

Redis 는 최근에 나왔고 새로운 기능들에 있어 Memcached와 비교된다. Memcached 보다 Redis 를 선택하는것이 항상 더 좋은 선택 이지만 Memcached 가 더 좋은 두가지의 상황이 있습니다.

첫번째로 작고 변하지 않는 데이타 예를들어 HTML 코드의 부분을 캐싱할때 내부 메모리 관리가 Redis 만큼 복잡하지 않아 능률적이기 떄문에 Memcached 는 메타 데이타에 있어 비교적 작은 메모리를 사용합니다. Memcached 에서 지원하는 유일한 데이타 타입인 String은 오로지 읽기 전용이고 더이상 처리가 필요 없기 때문에 데이터를 저장하기에 좋습니다.

두번째로 Memcached 는 여전히 Redis 에 비해 수평적 확장에서 약간의 좋은점이 있습니다. 기능 구현과 디자인 확장을 하는데 있어서 쉽지만. 사실 Redis 도 이런 목적으로(Memcached 처럼 수평적 확장이 쉽도록) 한대 이상으로 확장을 위한 클러스터링이 3.0 이후에 포함되어 있습니다.

언제 Redis 를 사용해야 할까요?

당신이 일할때 강제적을 Memcachd 를 사용해야 하거나 위의 2가지 사항이 아니고서는 항상 Redis 를 사용하는 것이 맞습니다.

당신을 Redis 를 캐시 용도로 매우 강력하게 사용할수 있고. 예를들어 캐시한 콘텐츠를 미세하게 튜닝하거나 그리고 지속성에 및 전반적인 효율성등을 조정할수 있습니다.

Redis 는 분명 캐쉬관리적인 측면에서 확실하게 우월하며. 캐쉬는 새로운 데이타를 캐시하기 위해 오래된 데이타를 지우는 방식의 메카니즘을 사용하고 있습니다. Memcached 도 데이타 관련 메카니즘은 LRU 알고리즘을 사용하고 있으며 Redis 는 이와는 대조적으로 6가지의 데이타 추출 정책이 있습니다. 또한 Redis 는 좀더 정교한 메모리 관리 방식을 사용한다.

Redis 는 당신이 어떠한 오브젝트들을 캐시할수 있도록 엄청 편리한 기능을 제공하며. 반면 Memcached 는 키의 이름이 250 바이트로 제한 되며 캐시 값의 용량은 1메가바이트로 제한됩니다. (10M였나? 그정도로 늘릴수도 있긴함) 그리고 오로지 문자열만 캐시할수 있다. Redis 는 키명과 값의 용량을 각각 512메가 바이트까지 크게 사용할수 있고 그것들은 안전한 바이너리로 관리 됩니다. Redis 는 6가지의 데이타 형식이 있어서 좀더 정교하고 효율적으로 데이타를 캐시하며 이로인해 어플리케이션 개발자에게 좀더 가능성 있는 세상을 열어줍니다.

대신 직렬화된 오브젝트를 저장해야하고 개발자는 Redis 의 해시 를 이용해 오브젝트의 필드 그리고 값을 유니크 하게 관리할수 있습니다. Redis의 해시는 개발자들이 필요한 기능을 제공합니다. 전체 문자열을 가지고 온다던지 역직렬화하고 그것의 값을 업데이트 하고 다시 시리얼 라이즈를하고 또 문자열을 바꾼다던지 자잘한 모든 업데이트 기능을 지원합니다. 그리고 그것은 작은 리소스를 소비하여 개발자의 퍼포먼스를 낼수 있게 한다는 것이좋습니다. 또한 Redis 가 제공하는 다양한 데이타 타입이 있는데 List 그리고 Set 이 있고 더 복잡한 캐시관리에 사용될수 있습니다.

또 다른 Redis 의 중요한점은 데이타를 저장하는 방식이 불투명하지 않다는 것입니다. 이 뜻은 데이타를 저장할떄 서버가 데이타를 직접적으로 조작한다는 것으로 Redis 에 있는 160가지 이상의 명령들은 서버측 내장 명명어로 데이타 를 처리하고 조직하며 이들의 내장된 명령어와 유저의 스크립트 들은 당신에게 손쉽게 데이타 처리를 다른 시스템에 네트웍으로 전달하지 않고 직접적으로 핸들링 할수 있도록 제공합니다.

Redis 는 캐시의 지속성(유사시에 데이타 백업의 의미) 옵션을 제공합니다, 이는 서버가 의도 되지 않게 오류가 나거나 셧다운이 일어났을때 재기동하면서 다시 복구될수있게 디자인 되었으며. 우리는 데이타를 캐시 하는동안 캐시는 휘발성의 성격이지만 이 데이타를 디스크에 저장 시킴으로서 캐싱 시나리오에서 매우 도움이 될수 있습니다. 그러니까 캐시 데이타가 Redis 에서 따로 백업 용도로 저장한 디스크에 존재하면 Redis 서버가 재시작후에 캐쉬를 다시 메인 데이타 스토리지에서 가지고 오는 부하를 덜수 있다는 소리 입니다.

마지막으로 Redis 는 리플레케이션을 제공 합니다. 리플리케이션은 어플리케이션에서 안정적인 캐시를 제공합니다. 생각해보면 캐시의 장애는 오로지 매우 짧은 순간에 유저경험이나 어플리케이션의 성능적인 측면에서 검증이 된 솔루션을 가지고 캐시의 내용 및 가용성을 보장 합니다. 이것은 대부분의 케이스에서 가장 좋은 장점으로 작용 합니다. (아 이부분은 뭔소린지 해석이 잘….. 대략 리플리케이션을 사용할수 있어서 장애를 최소화 할수 있다는 이야기 입니다.)

오픈소스 소프트웨어는 오늘날에 사용할수 있는 최고의 기술을 계속 제공 합니다. 캐시로 인해 어플리케이션의 성능을 개선할떄 Redis 와 Memcached 는 자연적으로 캐시 솔루션에 후보에 올라갔습니다. 그렇지만 좀더 괜찮은 기능과 좀더 발전된 디자인 으로 설계된 Redis 가 당신의 모든 시나리오에서 첫번쩨 선택이 될 것입니다.

————————————————————————————————————————-

지금은 유일하게 Redis 대비 Memcached 의 장점이었던 수평적 확장도 Redis 3.0 이 나오면서 사라지게 되었네요.. ㅜㅜ
결론은 닥치고 Redis 써라 !

[NoSQL & Cache] Redis vs Memcached ( 왜 Redis 를 사용해야 하는가? )”에 대한 2개의 생각

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다