본문 바로가기

소프트웨어 이야기/데이터 저장소 + 시각화

[Cache]Redis vs Memcached

 VS 


캐시를 사용할 때, Redis와 Memcached 중 어떤걸 선택해야하는지

고민이 될 때가 있다.


그래서 실무에서 발생하던 사건들과 책과 구글에서 본 내용을 기반으로, 어떤 경우에 두 캐시가 각각 유용한지 정리해보려고 한다.


Redis 장점

- 디스크에 데이터를 기록하고 있기 때문에, Redis 메모리가 날라가도 데이터를 복구할 수 있다.

( 스냅샷을 떠서, 이를 사용하는 RDB 방식과 Write / Update Event를 로그에 남겨서 이를 기반으로 복구하는 AOF 방식 두가지가 있다. )

- 다양한 데이터 포맷을 지원한다. 

  String, List, Set, Sorted sets, Hash 등의 데이터 포맷을 지원한다. 그래서 애플리케이션 단에서 편하게 데이터를 저장하고, 사용할 수 있다.

- Memcached 보다 좀더 다양한 API를 지원한다.

  예를 들어, 아래의 경우에는 Redis API가 Memcached API보다 유용하다.

  여러개의 캐시를 한번에 업데이트해야하는 경우, Redis에서는 mset이라는 함수를 사용하면된다. 

  그런데 Memcached에서는 여러개의 캐시 데이터를 가져오는건 가능하지만, 여러개의 캐시 데이터를 업데이트하는 API는 지원하지 않는다.

  많은 양의 캐시를 업데이트해줘야하는 상황에서 Memcached를 사용하면, 업데이트 해야하는 데이터 양만큼 set API를 호출해야한다.

  반면, Redis에서는 데이터의 크기를 쪼개서 mset을 호출하면, Memcached로 데이터를 밀어넣을 때보다 빠르게 데이터를 밀어넣을 수 있다.


Redis 단점

- 메모리 파편화가 발생하기 쉽다. 

- 메모리를 2배로 사용한다. 

   레디스는 싱글 스레드이다. 그래서 스냅샷을 뜰 때, 자식 프로세스를 하나 만들낸 후 

   새로 변경된 메모리 페이지를 복사해서 사용한다. ( 참고 블로그 )

   레디스는 copy-on-write 방식을 사용하고 있지만, 

   보통 레디스를 사용할 때는 데이터 변경이 잦기 때문에 실제 메모리 양만큼의 메모리를 자식 프로세스가 복사하게 된다.

   그래서 실제로 필요한 메모리 양보다 더 많은 메모리를 사용하게 된다.


Memcached 장점

- memcached는 DB / API 통신을 줄이기 위해 데이터를 캐싱처리하는 데에 사용하면 좋은 캐시이다. 

- 레디스는 트래픽이 몰리면, 응답속도가 불안정하다고 한다. ( 참고 글 : Redis 성능 관리 )

   반면, 트래픽이 몰려도 Memcached의 응답 속도는 안정적인 편이라고 한다. 

- memcached는 내부적으로 slab 할당자를 사용하고 있어서, 메모리 할당이 잦지 않다. ( 참고 슬라이드 쉐어 : Cache governance )


Memcached 단점

- 레디스처럼 데이터 타입과 API가 다양하지 않다. 

  그런데 이건 단점이라기 보다는, 레디스와의 다른 점이라고 생각한다.



결론

메모리가 날라가도, 원본 데이터로 즉시 복구할 수 있는 데이터는 Memcached에 저장하는게 좋을 것 같다.

- 메모리가 날아가면 서비스 장애가 발생할 수 있는 상황이라면, Redis에 저장하는게 좋을 것 같다.

- 통신 속도를 향상 시키기 위한 목적이면 Memcached를 사용하는게 좋다. 

   그러나 서비스의 특정 기능을 위한 목적으로 캐시 데이터를 사용한다면, Redis를 사용하는게 좋다. 

   ( 복구가 가능하니까! 데이터 타입도 다양하니까! )