[번역] Redis VS. Memcached

원문 : https://www.infoworld.com/article/3063161/why-redis-beats-memcached-for-caching.html

Why Redis beats Memcached for caching

17년도에 작성된 비교 글이기도 하고 Redis 찬사로만 도배되어있어서 좀 그렇기는 한데 Redis 관련 내용이 많아서 번역해봤다. 

맘에는 안든다. 

회사에서 Memcached에서 Redis로 바꾼다고 해서 조사차 했다. 

 

왜 캐싱 기능에서 Redis가 Memcached보다 유리한가. 

Memcached가 어쩌다 더 효율적이긴 하지만 Redis가 거의 항상 더 좋은 선택이다. 

Memcached를 쓸까 Redis를 쓸까? 현대 DB 기반 웹앱의 성능을 더 끌어올리기 위한 토론에서 거의 항상 떠오르는 질문(주제)이다. 성능 향상이 필요할 때 첫 번째 방안으로 사용되는 것이 캐싱이고, Memcached나 Redis난 대표적으로 가장 처음 언급(사용)된다. 

이렇게 잘 알려진 캐시 엔진은 많은 공통점을 가지지만, 또한 큰 차이점이 있다. 더 최신 캐시 소프트웨어이면서 더 기능이 많은 Redis가 대부분 더 좋은 선택이다. 

 

Redis vs Memcached

공통점부터 시작하자. Redis가 자료구조 단위 저장에서 더 정밀하다고 언급은 되지만, 두 방식 모두 메모리 기반에 key-value 단위 데이터 저장을 지원한다. 둘 모두 NoSQL 환경의 데이터 관리 솔루션에 속하고 key-value 데이터 모델을 기반으로 한다.(같은 내용을 반복하다니 별로 잘쓴 글은 아닌 것 같다. 라떼는 이렇게 쓰면 교수님한테 찢겼다.) 둘 모두 캐싱 계층에서 아주 유용하게 만들기 위해 RAM에 모든 데이터를 저장한다. 성능 면에서보면 두 방식은 매우 비슷하면서도 처리량과 지연율에서 거의 동일한 특징들을 보여준다. 

Memcached와 Redis 모두 어느 정도 안정됐고 매우 인기있는 오픈 소스 프로젝트다. Memcached는 LiveJournal이란 사이트를 위해 2003년에 Brad Fitzpatrick이 개발했다. 그 이후로 Memcached는 Perl로 개발되었던 오리지널 버전에서 C로 재작성되었고 공용(public domain)으로 풀리면서 현대 웹앱의 초석이 되었다. 현재 Memcached의 발전은 새로운 기능을 추가하는 것보다 안정성과 최적화에 초점을 두고 있다. 

Redis는 2009년에 Salvatore Sanfilippo에 의해 만들어졌고, 그는 오늘날의 프로젝트의 lead developer(programmer)가 되었다(...번역할수록 내가 틀리게 번역한건지 글이 이상한건지 의문이다. 의역하면 이게 맞는거같은데?). Redis는 Memcached를 사용하면서 얻은 교훈을 바탕으로 만들어져서 가끔씩은 "뽕 맞은 Memcached"라고도 불린다. Redis는 Memcached보다 더 많은 기능들을 가지고 있고 때문에 더 강력하고 유연하다. 

많은 기업에서 사용되고 셀 수 없이 많은 mission-critical 생산 환경에서, 둘 모두 생각할 수 있는 모든 개발 언어를 지원하고 개발자들을 위한 많은 패키지들에 내장되어 있다. 사실 Memcached나 Redis를 내장 지원하지 않는 웹 스택이 더 드물다. 

왜 이렇게 인기가 많을까? 얘네들은 극도로 효율적일 뿐만 아니라 상대적으로 매우 간단하다. 개발자에게 이 둘을 사용하는 것은 쉬운 작업이다. 설치하는에 몇 분밖에 안걸리고 앱과 함께 작동시킬 수 있다. 적은 시간 투자와 노력으로 바로 성능의 극적인 효과를 가질 수 있다. 마법과도 같이 간단한 솔루션으로 큰 이익을 얻을 수 있다. 

 

Memcached를 사용할 때

Memcached는 HTML 코드 파편(fragment)와 같은 상대적으로 작고 정적인 데이터를 캐싱할 때 선호된다. Redis만큼은 아니지만 Memcached의 내부 메모리 관리는  메타 데이터에 상대적으로 메모리 리소스를 덜 소모하기 때문에 간단한 유즈 케이스(use case)에 더 효과적이다. Memcached에서 지원되는 유일한 데이터 형인 Strings는 추가적인 처리를 요구하지 않기 때문에 읽기(read)만 될 데이터를 저장하는데 이상적이다. 

항상 더 많은 저장 공간을 필요로 하는 큰 데이터 셋은 자주 직렬화된(serialized) 데이터에 포함한다. Memcached 직렬화 데이터 저장에 제한된 반면, Redis에 데이터 구조는 직렬화 처리 시간을 줄이면서 네이티브 데이터를 그대로 저장할 수 있다. 

Memcached가 Redis보다 이점을 얻는 두번째 시나리오는 스케일링(scaling)에 있다. Memcached는 멀티 스레드를 지원하기 때문에, 캐시된 데이터의 일부 혹은 전체를 잃으면서 더 많은 연산 자원으로 스케일 업(scale up)을 쉽게 할 수 있다. 대부분 싱글 스레드인 Redis는 데이터의 손실 없이 클러스터링을 통해 수평적으로 스케일링을 할 수 있다. 클러스트링은 효과적인 스케일링 솔루션이지만, 상대적으로 설정하고 운영하기에는 더 복잡하다. 

 

Redis를 사용할 때 

너희들은 Redis를 그것의 자료 구조 때문에 쓰고싶어할 것이다. 캐시로서의 Redis로 넌 더 최적화된 캐시 컨텐츠와 내구성 등의 강력함과 전체적으로 더 큰 효율성을 얻을 것이다. 너가 한번 자료 구조를 사용해본다면, 특정 앱 시나리오에서의 효율성 증대가 굉장해질 것이다. 

Redis의 우월함은 캐시 관리의 모든 면에서 나타난다. 캐시들은 메모리에서 오래된 데이터를 삭제해서 새 데이터를 위한 공간을 만드는 'Data Eviction'이라는 메커니즘을 사용한다. Memcached의 Data Eviction 메커니즘은 LRU(Least Recently Used) 알고리즘을 사용하고 새 데이터와 비슷한 용량의 데이터를 독단으로 삭제한다. 

반면 Redis는 6개의 다른 삭제 정책 중 사용자가 골라서 사용할 수 있다. Redis는 또한 메모리 관리와 삭제 대상 선택에 더 정교한 접근법들을 사용한다. Redis는 더 많은 공간이 필요하거나 필요해질 것이라고 판단될때만 데이터가 삭제되는 lazy eviction과 active eviction을 모두 지원한다. 

Redis는 캐시를 할 수 있는 객체들을 고려하며 훨씬 더 많은 유연함을 준다. Memcached가 키 이름을 250바이트로 제한하고 plain string(단순 문자열)로만 작동하는 반면에 Redis는 키 이름과 값(key-value) 각각 512MB까지 허용하고 바이트 스트림으로 안전하게 저장한다. 또한 Redis는 5개의 원시 자료 구조(primary data structures-primitive data structure를 말하는 것 같다)를 골라 사용할 수 있다. 

 

데이터 지속성에서의 Redis

Redis 자료 구조들을 사용함으로서 캐싱 뿐만 아니라 데이터가 지속되고 항상 사용 가능하게 하고 싶은 것같이 여러가지 작업들의 단순화 및 최적화를 할 수 있다. 예를 들어 직렬화된 string값과 같은 객체를 저장하는 대신에 개발자들은 객체의 필드와 값을 저장하기 위해 Redis Hash를 사용할 수 있고 그것들을 유일키(single key)로 관리할 수 있다. Redis Hash는 개발자들이 사소한 수정건 때문에 전체 문자열을 가지고 와서 역직렬화하고, 값을 수정하고, 재직렬화해서 캐시에 전체 문자열을 교체하게 하는 작업에서 빠져나오게 해준다. 이것은 더 적은 리소스를 소모하고, 성능이 좋아진다는 소리다. 

Redis가 제안한 다른 자료구조들(lists, sets, sorted sets, hyperloglogs, bitmaps, geospatial indexes)은 더 복잡한 시나리오를 시행하는데 사용될 수 있다. 시간 연속성 데이터 발생 및 분석을 위한 Sorted sets은 엄청나게 줄어든 복잡성과 더 낮아진 대역폭 소모를 가능하게 해주는 Redis 자료 구조의 또다른 예시다. 

Redis의 또다른 중요한 이점은 저장된 데이터가 이해하기 쉬워 서버가 직접 다루기가 쉽다는 것이다. Redis에서 사용 가능한 180개 이상의 명령어의 대부분이 데이터 처리 기능(data processing operation)과 데이터 임베딩 로직(data embedding logic)에 심혈을 기울이고 있다. 이런 내장 명령어들과 유저 스크립트들은 네트워크를 통해 또다른 처리 시스템으로 데이터를 나를 필요 없이 Redis에서 데이터 처리 작업을 직접 처리할 수 있는 유연함을 보여준다. 

Redis는 고의적 종료나 예기치 못한 오류가 발생한 후에 캐시를 실행할 수 있도록 설계된 선택적이고 수정 가능한 데이터 지속 방안을 제공한다. 우리가 캐시 데이터를 휘발성에 임시적이라고 보는 동안, 디스크에 영속중인 데이터는 캐싱 시나리오를 따라 값을 메모리에 지속시킬 수 있다. 재실행 직후 즉시 데이터를 로드하여 캐시 데이터를 사용 가능하도록 하는 이 방식으로 캐시 기능을 더 빠르게 사용할 수 있고 원본 데이터로부터 캐시 내용물을 재활성화하고 재연산하는 로딩 구간을 없앨 수 있다. 

 

인 메모리 데이터 복제 

Redis는 관리하는 데이터를 복제할 수 있다. 복제는 오류를 견디고 중단되지 않는 서비스를 제공하는 매우 유용한 캐시 설치를 가능하게 해준다.  사용자 경험 영향과 앱의 성능에서 캐시의 실패가 아주 잠깐 일어날 뿐이어서, 캐시의 내용물과 서비스 유용성을 보장하는 검증된 솔루션으로서 큰 이점을 가진다.

기능 가시성의 측면에서, Redis는 기능의 용도와 비이상적 행동을 감시, 추적하는 많은 분석들과 내부 확인을 위한 명령어들을 제공한다. (데이터 베이스의 모든 측면들에 대한 실시간 통계, 실행되고 있는 모든 명령어의 출력, 클라이언트 연결의 나열 및 관리 등)

개발자들이 Redis의 영속성과 in-memory 복제 기능들의 효율성을 알아차리면, 고속의 데이터 분석 및 처리를 위한 주 데이터베이스로 사용하거나 이력(로그)를 저장하는 부 데이터베이스로 사용한다. 이런 방법들로 사용될 때, Redis는 분석 기능에서 이상적일 수 있다. 

 

데이터 분석을 위한 Redis

세가지 분석 시나리오가 바로 생각날 것이다. 첫 번째 시나리오는 대량의 데이터를 반복적으로 처리하는 아파치 스파크와 같은 것을 사용할 때, 스파크로 계산되기 전의 데이터를 전송하는 계층으로 Redis를 사용할 수 있다. 두 번째 시나리오에서는 너가 공유한 in-memory에 분산된 데이터 저장 공간으로서의 Redis는 스파크의 속도를 45에서 100만큼의 증가시킬 수 있다. 마지막으로 정말 평범한 시나리오는 보고서와 분석이 사용자에 의해 커스텀이 가능해야하는 것인데, 선천적으로(어쩔 수 없이) 하둡이나 RDBMS와 같은 일괄 데이터 저장 방식에서는 시간이 너무 오래 걸린다. 이런 경우에는 Redis와 같은 in-memory 자료 구조 저장 방식이 짧은 페이징 시간과 응답 시간을 가질 수 있는 실용 가능한 유일한 방법이다. 

극단적으로 큰 기능의 데이터 셋이나 분석량을 사용할 때에는 싹 다 in-memory에서 돌리기에는 비용 효율이 떨어질 수 있다. 저비용에 짧은 실행 시간의 효율을 얻기 위해, Redis 연구팀은 RAM-to-flash 비율을 설정할 수 있는 옵션을 추가하여 Ram과 flash 공간의 결합으로 실행할 수 있는 Redis를 만들었다. 이 기능이 업무 처리 속도를 늘려주는 새로운 방안들이 됐기 때문에, 개발자들에게는 flash 메모리 상에서의 캐시(cache on flash)를 쓸 수 있는 선택권이 생겼다. 

오늘날 오픈 소스 소프트웨어는 사용 가능한 최고의 기술들을 계속 제공하고 있다. 캐싱으로 앱 성능을 빠르게 해주기 때문에, Redis와 Memcached는 가장 인정받고 검증된 후보들이었다. 하지만 Redis의 기능이 풍부해지고, 개선되었고, 잠재력있는 사용법들이 있고, 규모 대비 비용 효율성이 좋아졌기 때문에, Redis는 거의 모든 경우에서 1순위가 되었다.