[입 개발] memcached 는 predictable 하고 Redis는 unpredictable 하다.

가끔씩 Redis와 memcached 둘 중에 어떤 것이 좋은가에 대한 질문이 들어옵니다. 이 질문에 대한 답변은 그때 그때 달라요입니다.  예를 들어, 캐시로만 사용할 것인지? 아니면 데이터 스토어로 사용할 것인지? 데이터 스트럭처의 사용이 필요한가 여부 등 여러가지 판단을 할 수 있는 기준이 있습니다. 여기서는 오직 캐시의 목적으로만 볼 때에 대한 그래서 AOF, RDB는 제외하고 이에 대해서 간단하게 얘기해볼려고 합니다.

보통의 제 답변은 생산성<성능 이면 Memcached, 생산성>성능 이면 Redis를 추천합니다. 데이터 스트럭처를 제공한다는 것은 개발자에게 엄청나게 편의성을 제공해주니깐요. 그럼 이제 위의 제목에 관심을 가지게 될 것 같습니다. 왜 memcached는 predictable 하고 Redis는 unpredictable 한가?  먼저 이 과정은, 많은 데이터가 set/get/del 될 때라는 가정입니다. 그리고 이는 내부의 메모리 할당 구조의 차이 때문입니다. 모두들 아시다시피, Redis는 필요한 크기 만큼에 대한 메모리를 할당해서 이를 사용합니다. 그런데 memcached는 slab 할당을 이용해서, redis 보다 이런 부분에서 조금 더 나은 성능을 보여줍니다. 이로 인해서 redis의 메모리는 좀 더 fragmentation 이 발생하기 쉽고,  이로 인해 memcached의 성능이 좀 더 predictable 하다고 할 수 있는 것입니다.

 

그런데, 이게 사실 그렇게 단순한 것 만은 아닙니다. memcached의 경우는 4G 메모리를 할당하면, 데이터 영역만 4G이므로, 이를 관리하기 위해서 메모리를 더 많이 사용하게 됩니다. 이로 인해서 의도한 것 이상으로 메모리를 사용하게 됩니다. 그런데 Redis는 딱 전체 메모리를 설정한 것 만큼만 사용하게 됩니다.(기본은 무한대로 계속 사용합니다.) 이럴 경우, swap 확률이 덜해서,  Redis가 좀 더 안정적인 성능을 보여줄 수도 있습니다.  다만 BGSAVE를 사용하면, 또 메모리 사용량이 늘어나게 됩니다.

 

그럼 이것만으로 끝일까요? Redis를 여러 대 사용한다면, 한 서버에 여러대의 Redis 인스턴스를 돌리게 되는데,( memcached 도 마찬가지입니다. ) 다음과 같은 구조가 됩니다.

ms

 

이렇게 되면 하나의 서버가 죽더라도 전체 데이터가 날라가지 않는 일부만 사라지거나, 문제가 적지만, AOF/RDB를 사용해야 한다면 성능상 문제가 발생할 수 있습니다.

즉, 간단한 캐시 레이어 하나를 설계하더라도, swap의 발생 가능성이 다양하고, 여러가지 의존관계가 생기게 됩니다. 그리고 이런 구조를 이해하는 것이 적절한 캐시 성능을

보장하게 됩니다.