들어가며
세션에 대해 조금씩 이해를 하고 있지만, 세션을 어떻게 활용해야 잘 활용할 수 있는 것인지에 대해 정리해보고 싶었습니다. 세션을 쓸 때 어떤 것들을 고려해야 하는지에 대해 더 늦기 전에, 기초를 쌓고 싶어서 개념을 정리해보고자 합니다. 무지를 반성하는 마음으로 이 글을 적습니다.
In-memory DB 중 어떤 DB를 저장소로 사용해야 할까?
지난 시간 세션 저장소로 In-Memory Database를 사용하기로 하였습니다. 하지만, In-Memory Database에는 다양한 데이터베이스들이 존재합니다. 그렇다면 세션 객체를 저장하기 위해서 어떤 데이터베이스를 활용하면 좋을까요? 그전에 먼저 세션 객체가 어떤 형태로 구성되어 있는지부터 알아보겠습니다.
세션 객체는 어떤 형태로 구성되어 있을까?
세션 객체는 Key에 해당하는 SESSION ID와 이에 대응하는 Value로 구성됩니다. Value에는 세션 생성 시간, 마지막 접근 시간 및 User가 저장한 속성 등 이 Map 형태로 저장됩니다. 세션 객체가 저장되는 방식과 유사하게 Key-Value 형태로 데이터를 저장하는 데이터베이스가 있습니다. 이를 Key-Value 데이터베이스 혹은 Key-Value Model NoSQL이라고 합니다.
이러한 데이터베이스의 특징은 저장구조가 Key-Value 형태로 단순하다는 점입니다. 이로 인해 관계형 데이터베이스와 같이 복잡한 조회 연산을 지원하지 않지만, 단일 키 처리만을 지원하기 때문에 고속 읽기와 쓰기에 최적화된 경우가 많습니다. 특히, 세션에 저장되는 데이터의 경우에는 대부분 비교적 간단한 연산을 통해 처리를 할 수 있습니다. 이러한 점에서 Key-Value 형태의 데이터베이스가 세션 저장소로써 적합하다고 볼 수 있습니다. 그중에서도 세션 저장소로 가장 많이 사용되는 것이 바로 Redis와 Memcached입니다!
엄밀히 말하면 Memcached는 캐시 솔루션으로써 전원이 꺼지게 되면 데이터가 사라지기 때문에 영속성을 보장할 수 없다는 점에서 데이터베이스 혹은 저장소는 아닙니다. 'Redis의 경우도 마찬가지 아닌가?'라고 생각하실 수 있으나, Redis는 AOF와 RDB 기능을 통해서 디스크에 데이터를 저장하여 영속성을 보장할 수 있습니다. 하지만 세션의 경우, 영속성이 크게 영향을 미치지 않기 때문에 해당 논제에 대해서는 더 이상 언급하지 않겠습니다. 그렇다면 Redis와 Memcached는 어떤 부분에서 차이가 있는지 더 자세하게 알아보겠습니다.
Redis와 Memcached 어떤 점이 다를까?
Memcached와 Redis는 In-Memory 기반으로 동작한다는 점과, Key-Value 형태로 데이터를 저장한다는 점에서 공통적인 특성을 지니고 있습니다. 이러한 특성은 두 저장소 모두 빠르게 데이터를 처리할 수 있다는 장점으로 이어집니다. 그렇다면 어떤 차이점을 가지고 있을까요?
첫 번째는 Replication의 지원 여부입니다. Replication이란 두 개 이상의 DBMS 시스템을 Master / Slave로 나눠서 동일한 데이터를 저장하는 방식입니다. Redis의 경우, Replication을 지원하기 때문에 서버 하나에 장애가 발생하더라도 복제된 Slave 서버를 Master로 승격시켜서 서비스를 중단 없이 운영할 수 있도록 합니다.
하지만, Memcached의 경우에는 Replication을 지원하지 않습니다. 대신에 서비스 중단을 최소화하기 위해서 'Consistent Hashing'이라는 알고리즘을 통해 여러 대의 Memcached 서버에 데이터를 분산 저장하여 관리하게 됩니다. Consistent Hashing으로 인하여 서버 1대가 장애가 발생하더라도, 나머지 노드에 있는 데이터들은 재배치할 필요 없이 장애가 발생한 노드의 데이터들만 손실되기 때문에 나머지 노드들은 지속적으로 운영이 가능합니다.
이러한 방식의 경우, Memcached 서버의 숫자를 늘리게 되면 그 피해를 감소시킬 수 있습니다. 예를 들어, 3대 중 1대에 장애가 발생하면, 약 33%의 데이터를 손실하지만, 4대 중 1대에서 장애가 발생한다면, 25%의 데이터만 손실됩니다. 그러므로 노드가 많을수록 서비스 장애에 대한 피해는 줄어듭니다.
Memcached가 Replication을 지원하지 않기 때문에 이렇게 손실을 감안하고 운영을 하는 경우도 있지만, 각 노드에 BackUp 서버를 배치하여 직접 failover를 구현하고, 가용성을 보장할 수 있습니다. BackUp 노드를 만드는 방법은 MySQL BinLog를 이용하거나, Primary-Secondary 서버 각 2대의 서버에 데이터를 쓰고 관리하는 방법 혹은 Repcached라는 패치를 통하여 Replication을 구현하는 등 다양한 방법이 존재합니다.
이렇듯 Redis와 Memcached의 경우, 각자의 방법으로 failover를 지원합니다. 다만 Redis의 경우 Replication을 솔루션 자체에서 지원을 하기 때문에 보다 더 쉽게 failover 기능을 구현할 수 있다는 장점이 있습니다.
두 번째로 응답 속도에서 차이를 보입니다. Redis의 경우, 대규모 트래픽이 발생하면 Memcached에 비해 응답속도의 안정성이 떨어질 수 있습니다. 이유는 Redis는 메모리 할당을 하는 데 있어서 jemalloc 알고리즘을 사용하여 매번 malloc과 free를 통하여 메모리를 할당하기 때문입니다. 이는 메모리 단편화 문제를 발생시키고, 이러한 단편화 문제로 인하여 할당 비용으로 인해 응답속도가 느려질 수 있기 때문입니다.
반면, Memcached의 경우 메모리 할당에 있어서 slab allocator를 사용하기 때문에 내부적으로 메모리 할당을 다시 하지 않고 관리할 수 있습니다. 이러한 결과, 응답속도가 일정한가에 대해서는 Memcached가 조금 더 좋은 성능을 보이는 듯합니다. 이 또한 극단적인 예시이기 때문에 Redis의 응답속도는 절대적으로 불안하다고 생각하시면 안 됩니다! "대규모 트래픽이 들어왔을 때, Memcached보다 응답속도 안정성이 떨어질 수 있다." 정도로 이해하시면 될 것 같습니다.
세 번째로 Redis는 Memcached에 비해 다양한 자료구조를 지원합니다. String만 지원하는 Memchached에 비해 Redis는 String, Set, Sorted Set, List, Hash와 같은 다양한 자료구조를 지원합니다. 이는 Redis가 다른 인메모리 솔루션들과의 차이점 중 가장 강점을 갖는 부분입니다.
마지막으로 Redis는 싱글 스레드로 수행되고 Memcached는 멀티 스레드로 수행된다는 점 입니다.
싱글 스레드로 수행되는 Redis는 atomic을 보장하고 , race condition(경쟁)을 회피할 수 있지만 long-time 명령 수행 시 다른 명령어들을 처리할 수 없는 상태가 되기 때문에 매우 비효율 적으로 동작하게 됩니다. 따라서 long-time 명령의 수행들을 피해야 합니다. 반면에 Memcached는 멀티 스레드를 지원하기 때문에 scale-up을 통한 서버 확장에 용이합니다.
또한 Memcached가 멀티 스레드를 지원하긴 하지만 수행 시간적인 측면에서 Redis와 큰 차이가 나지 않습니다. 그 이유는 Memcached의 경우 파싱 과정은 멀티 스레드 형태로 동작하지만 실제 데이터에 접근하는 연산 과정에서 Global cache lock으로 인해 싱글 스레드처럼 동작하기 때문입니다.
여기까지 보았을 때, Redis와 Memcached 각각 다른 방식으로 캐시를 처리하고 있음을 알 수 있습니다. 두 솔루션 모두 장점과 단점을 지니고 있지만, 위에서 보았듯이 사용할 수 없을 정도로 치명적인 단점을 갖는 솔루션은 없습니다. 그렇다면 결정적으로 이 두 솔루션의 Performance를 비교한 결과를 통해 어떤 솔루션을 사용하는 것이 나을지 알아보겠습니다.
Redis vs Memcached 실제로 어떤 솔루션이 빠를까?
해당 실험의 경우, 아래 논문을 통해 확인한 결과입니다. 각 서버의 환경에 따라 결과가 달라질 수 있으므로 이 결과가 절대적인 것은 아니니, 참고용으로만 확인하시길 바랍니다.
A performance evaluation of in-memory databases
The popularity of NoSQL databases has increased due to the need of (1) processing vast amount of data faster than the relational database management s…
www.sciencedirect.com
결과를 표를 통해 각각 요약해 보겠습니다.
해당 표에서 볼 수 있듯이 Memcached의 경우 Write 연산에 있어서, Redis 보다 좋은 성능을 보임을 알 수 있습니다. 하지만, Read 연산에 있어서는 Redis가 더 좋은 성능을 보입니다. 이를 비교해보았을 때, Redis가 세션을 저장하는 데 더 적합하다는 점을 알 수 있습니다. 세션 관련 작업의 경우, 쓰기 연산보다는 읽기 연산이 압도적으로 높은 작업이기 때문에 읽기 성능이 더 좋은 Redis를 사용하는 것이 더 효율적임을 알 수 있습니다.
마지막으로 Redis가 Read/Write에 있어서 메모리를 더 효율적으로 사용하는 것을 볼 수 있습니다. 위 결과를 종합한 결과, 쓰기 성능에서는 Memcached가 앞서지만 메모리 사용 효율과 처리속도를 모두 고려한다면 Redis가 상대적으로 더 나은 선택임을 알 수 있습니다. 다음에는 Redis를 세션 저장소로 활용하는 방법에 대해 알아보겠습니다.
마치며
공부를 하며 그동안 아주 기초적인 것들을 제대로 공부하지 않았다는 것을 깨닫습니다. 좋은 기술을 배우는 것도 좋지만, 기술의 기반이 되는 기초적인 지식을 먼저 쌓는 것이 중요하다는 것을 다시금 깨달았습니다. 기초가 튼튼한 개발자가 되고 싶습니다.
출처
다중 서버 환경에서 Session은 어떻게 공유하고 관리할까? - 4편(Redis vs Memcached)
개요 지난 시간 세션 저장소로 In-Memory Database를 사용하기로 하였습니다. 하지만, In-Memory Database에는 다양한 데이터베이스들이 존재합니다. 각각의 데이터베이스는 저장하는 데이터의 형태 및
hyuntaeknote.tistory.com
Session storage로 적합한 데이터 베이스는 무엇일까? (Redis vs Memcached)
Session storage로 적합한 데이터 베이스는 무엇일까? (Redis vs memcached) 지난시간에 포스팅했던 서버가 두 개 이상일 경우 발생하는 세션 불일치 문제 해결하기에서 별도의 세션 스토리지를 구성하여
1-7171771.tistory.com
'Web' 카테고리의 다른 글
| [Web] 안전하게 로그인 처리하기 (0) | 2022.02.04 |
|---|---|
| [Web] JWT 토큰을 알아보자 (0) | 2022.01.14 |
| [Web] 다중 서버에서 세션을 관리해보자 - 3 (feat 세션 스토리지 선택) (0) | 2022.01.08 |
| [Web] 다중 서버에서 세션을 관리해보자 - 2 (feat 세션 불일치) (0) | 2022.01.05 |
| [Web] 다중 서버에서 세션을 관리해보자 - 1 (feat Scale-up, Scale-out) (0) | 2021.12.29 |
