In-Memory_DB를 선택한 이유

in memory-db는 말 그대로 메모리에 DB를 저장합니다. 따라서 메모리 계층구조에 의해서 disk based db보다 빠릅니다.

저희는 사용자의 정보를 session storage 방식으로 관리하기로 했습니다. 여기서 In-Memory-DB를 선택한 이유는 앞서 설명드린데로 성능이 빠르다는것과 유저의 로그인 체크 정도의 기능은 반드시 영속성이 필요하지도 않고 저장공간이 많이 필요하지도 않기 때문에 유저의 session 정보는 in-memory-db에 저장하는 방식을 선택했습니다.

Redis vs Memcached

그렇다면 이제 인메모리디비의 대표 주자인 redis와 memcached에 대해 알아보자.

Redis

Redis는 NoSql이면서 많은 사람들이 사용하는 대표적인 인메모리DB이기 때문에 NoSQL 과 In-Memory-DB를 동의어로 생각한다.

그렇다면 Redis의 장점들을 살펴보자.

1. CollectionAPI를 제공하기 때문에 리스트, 배열과 같은 데이터를 처리하는데 유용하다.

• value 값으로 문자열, 리스트, Set, Sorted set, Hash 등 여러 데이터 형식을 지원.

2. 여러 프로세스에서 동시에 같은 key에 대한 갱신을 요청할 경우,

   Atomic 처리로 데이터 부정합 방지 Atomic처리 함수를 제공한다.

3. 메모리를 활용하면서 영속적인 데이터 보존

• 명령어로 명시적으로 삭제, expires를 설정하지 않으면 데이터가 삭제되지 않는다.

• 스냅샷(기억장치) 기능을 제공하여 메모리의 내용을 *.rdb 파일로 저장하여 해당 시점으로 복구할 수 있다.

4. Redis Server는 1개의 싱글 쓰레드로 수행되며, 따라서 서버 하나에 여러개의 서버를

   띄우는 것이 가능하다.

• Master - Slave 형식으로 구성이 가능함

• 데이터 분실 위험을 없애주는 것이 바로 위 Master - Slave 방식이다.

위 기능을 이용하면 실시간으로 데이터를 다른 서버에 복제한다.

즉, Master server가 down되어도, slave server로 접속하면 바로 서비스를 계속할 수 있다.

그리고 레디스의 성능을 거의 떨어뜨리지 않고 디스크 쓰기 기능을 제공한다.

Memcached

Memcached는 기본적으로 Redis와 매우 흡사하다. 그렇다면 어떤 부분이 다를까?

기본적으로 Memcached는 캐쉬솔루션이며 여기서 저장소가 추가된게 Redis이다.

캐시는 빠른 속도를 위해서 어떤 결과를 저장해 두는 것을 의미하며

또한 데이터가 사라지면 다시 만들 수 있다는 전제를 내포하고 있다.

캐시 기능만을 고려한다면 디스크에서 불러오기만 하면 된다.

(= Load 기능만 수행되면 된다.) 그런데 저장소라는 개념이 추가되면

데이터가 유지되어야 한다는 특성을 가지게 된다.

(= Save기능도 필요하다.)

결론

1. 메모리가 날라가도 원본 데이터로 즉시 복구할 수 있는 데이터는

• Memcached를 사용하는 편이 좋을 수 있다. 또한, 통신 속도를 향상 시키기 위한 목적이면 Memcached를 사용하는게 좋다.

2. 메모리가 날아가면 서비스 장애가 발생 할 수 있는 상황이라면

• Redis를 사용하는 편이 좋을 수 있다. 서비스의 특정 기능을 위한 목적으로 캐시 데이터를 사용한다면 Redis를 사용하는게 좋다.

Redis 단점

그 밖에도 Redis의 단점으로 Memcached에 비해 대규모 데이터에 대한 응답 속도의 불안정성 문제가 있다. 대규모 트래픽으로 인해 많은 데이터가 업데이트되면 Redis는 Memcached에 비해서 속도가 불안정하다.

이것은 Redis와 Memcached의 메모리 할당 구조가 다르기 때문에 발생하는 현상이다.

Redis는 jemalloc을 사용하기 때문에 매번 malloc과 free를 통해서 메모리 할당이 이루어진다.

반면 Memcached는 slab 할당자를 이용하여 내부적으로는 메모리 재할당을 하지 않고 관리하는 형태를 취한다.

이로 인해서 Redis는 메모리 파편화가 발생하며 이 할당 비용 때문에 응답 속도가 느려진다.

다만 이는 극단적으로 봤을 때 발생하는 일이기 때문에 진행하는 프로젝트 규모의 수준에서는 문제가 없다고 생각한다.

현 서비스에서 Redis 선택 이유

사실 극한의 상황이 아니면 rdbms를 사용하던 redis를 사용하던 memcached를 사용하던 상관은 없지만 학습의 관점에서 레퍼런스가 많고 spring프로젝트에 쉽게 적용할 수 있는게 redis인게 가장 큰 이유입니다.

다음은 개인적으로 생각하는 redis를 선택한 이유입니다.

• Redis는 싱글쓰레드를 사용하며 추가적으로 멀티쓰레드를 사용하는 Memcached에 비해 쓰레드 스케쥴링처리가 필요없고 처리도중 에러가 발생할 확률이 적을것같다.
• Memcached에 비해 많은 API를 제공하기때문에 (Spring Redis제공) 사이드 프로젝트 개발 관점에서 상대적으로 진입하기 쉬울것같다.
• 손쉽게 master - slave 구조로 구성가능하기 때문에 Failover에 대응하기 쉽다.

참고 문헌
https://codingmania.tistory.com/18
https://goodgid.github.io/Redis/
https://aws.amazon.com/ko/elasticache/redis-vs-memcached/
https://bcho.tistory.com/654