대용량 트래픽을 위해 확장성 있는 세션 구조 설계 #2

이전 글

jaesika.tistory.com/2

대용량 트래픽을 위한 세션 관리하기 #1

 

서버를 지속적으로 여러대 확장하기 위해서는 데이터의 변화가 많다면 Scale Out 방식이 정합하다고 생각합니다.

그렇다면 적합한 저장소로 어떤 것을 선택할 수 있을까요?

 

[ RDB (관계형 데이터베이스) & In-Memory DB ] 

RDB는 데이터를 저장하기 위해 디스크를 사용합니다. 반면 In-Memory DB는 말 그대로 디스크가 아닌 데이터의 저장을 위해 메모리를 사용합니다. 

 

둘의 차이점은 RDB는 디스크에서 데이터 입출력을 수행하기 때문에 데이터를 영구적으로 저장할 수 있는 대신 속도가 느리다는 것이고 In-Memory DB는 메모리에서 데이터 입출력을 수행하기 때문에 속도가 상대적으로 더 빠르나 기본적으로 영속성을 보장하지 않고 디스크 보다 저장공간이 훨씬 적습니다.

 

여기서 한가지 생각을 해봅니다.

 

세션 정보는 영속성이 필요한 부분일까요? 세션은 분명 필요한 정보긴 하지만 영구적으로 저장되어야할 정보는 아닙니다. 서버가 죽어버려서 세션이 없어진다고 하더라도 이는 짜증이 날 상황이긴 하지만 치명적이지 않는 부분입니다. 또한 세션 정보를 저장하기 위해서 큰 저장소 또한 필요 없습니다.

 

즉, 세션은 반드시 영속성이 필요한 것은 아니고 저장 공간도 많이 필요한 것도 아니기 때문에 In-Memory DB의 사용을 고려하였습니다.

[ Memcached vs Redis ]

www.memcached.org/

memcached - a distributed memory object caching system

redis.io/

Redis

In-Memory DB는 대표적으로 Memcached, Redis 이 2가지가 비교됩니다. 둘다 key - value 쌍으로 데이터를 저장하며 오픈소스입니다. 어느 것을 사용해야 할까요? 어떤 차이가 있을까요?

 

# 차이점

 

- Thread

Memcached는 멀티 스레드를 지원하기 때문에 Scale Up 방식을 통해 더 많은 처리를 할 수 있습니다. Redis는 싱글 스레드를 지원하기 때문에 1번에 1개의 명령어만 실행이 가능합니다. Redis에서 모든 데이터에 대해 탐색하고 삭제, 시간복잡도 O(n)에 해당하는 명령어를 실행한다면 다른 명령어는 실행할 수 없기 때문에 주의가 필요합니다.

 

- Data Structure

Memcached는 단순히 문자열을 최대 1MB까지 저장할 수 있지만 Redis는 다양한 데이터 구조 (list, set, hash ... )를 최대 512MB까지 저장할 수 있습니다. 그리고 둘 다 데이터를 메모리에 보관하기 때문에 빠른 응답 속도를 제공합니다.

 

- Replication

Redis에서는 Master - Slave 구조로 여러개의 복제본을 만들어 데이터 베이스 읽기를 확장할 수 있고 Master 노드가 죽어버린다면 Slave를 Master로 승격시켜 높은 가용성을 제공합니다.

 

- Transaction

Redis에서는 여러개의 작업을 하나로 묶어 처리하는 트랜잭션을 지원해 ACID의 특징을 지원합니다. Memcached는 원자적이지만 트랜잭션을 지원하지 않습니다.

 

- Disk I/O Dumping

Redis에서는 RDB방식과 AOF방식을 지원합니다.

RDB방식은 순간적으로 메모리에 있는 내용을 디스크로 옮기는 방식입니다. SAVE와 BGSAVE 2가지 방식이 있는데 SAVE는 Redis의 동작을 멈추고 디스크에 Snapshot을 저장합니다. BGSAVE는 별도의 프로세스를 띄워 명령어 수행 당시 Snapshot을 Redis를 멈추지 않고 저장합니다. 

AOF 방식은 Redis의 모든 연산을 log파일에 기록을 해놓고 서버가 재시작 되면은 파일에 있는 연산들을 재실행하여 데이터를 복구하는 방식입니다.

 

- Pub / Sub messaging (발행 / 구독)

Memcached는 지원하지 않는 기능이지만 Redis에서는 메시지를 발행하고 구독하는 기능을 제공합니다. 이는 채팅이나 SNS 및 서버 상호 통신과 같은 실시간 통신이 필요한 애플리케이션을 설계할 때 유용할 수 있습니다.

 

- Evict (제거) 정책

Memcached는 LRU알고리즘을 통해 새로운 데이터와 비슷한 크기의 데이터를 제거합니다. 하지만 Redis는 6가지의 Evict 정책을 지원하여 더욱 세세하게 제어를 할 수 있습니다.

 

- Memory

Memcached는 메모리를 새로 할당하는 방식이 아니라 한번 메모리를 할당받고 그 안에서만 관리를 하는 형태입니다. Redis는 매번 메모리를 할당하고 해제하면서 메모리 파편화가 발생할 수 있어서 응답이 느려질 수 도 있습니다.

 

Stack OverFlow에서 어떤 분이 10만개의 데이터를 저장하고 가져오는 실험을 했습니다. 그 결과

- Redis

• 10만개의 데이터를 저장하는데 걸리는 시간 18954ms
• 10만개의 데이터를 읽어오는데 걸리는 시간 18328ms

- MemCached

• 10만개의 데이터를 저장하는데 걸리는 시간 797ms
• 10만개의 데이터를 읽어오는데 걸리는 시간 38984ms

[ 정리 ]

어떤 데이터를 다루든지 가용성을 지원한다는 것은 정말 중요한 부분입니다. 장애는 언제든 발생할 수 있기 때문입니다.

세션이 영구적인 정보는 아니지만 어느정도 장애로부터 벗어나 안정적인 서비스를 제공해야할 필요성이 보입니다.

 

Memcached도 다른 라이브러리를 사용해서 가용성을 보완할 수 있지만 Redis는 자체적으로 솔루션들을 갖고 있기 때문에 좀 더 선택의 의미가 있습니다.

 

또한 대부분의 사람들은 현재 Memcached를 사용중인게 아니라면 Redis를 사용하는 것을 추천합니다. 왜나하면 Redis는 Memcached 의 단점들을 일부러 보완하여 기능을 만든것이 많기 때문에 더 유연하고 확장이 용이한 측면이 있고 문서화도 Redis가 잘 되어 있기 때문입니다.

 

그리고 현재 Spring 프로젝트를 진행하며 Spring은 세션 저장소로 Redis를 지원을 하고 있습니다. Spring을 사용하고 있다면 편의성 측면에서도 좋은 선택이라고 할 수 있을 것입니다.

 

[ 프로젝트 ]

github.com/f-lab-edu/star-dabang

f-lab-edu/star-dabang

[ 참고 ]

www.linkedin.com/pulse/memcached-vs-redis-which-one-pick-ranjeet-vimal/

www.baeldung.com/memcached-vs-redis