Journal Archive

키-값 데이터 모델을 저장 시스템 기준으로 크게 두 가지 범주로 나누면 인 메모리와 온 디스크로 분류할 수 있다.

첫 번째 인 메모리 기반 키-값 데이터 모델은 메모리 내에서 데이터 저장소가 실행되면 데이터가 메모리에 완전히 로드 되므로 모든 작업이 메모리에서 실행된다[14]. 일반적으로 시스템에서는 데이터를 디스크에 주기적 또는 비동기적으로 저장하지만 모든 데이터는 메모리에서 검색한다[10]. 또한, 백업 및 시스템 종료를 위해 메모리 내 데이터를 디스크에 복사한다. 인 메모리 데이터 저장소의 주요 이점은 대기 시간이 짧고 처리량이 향상된다는 것이다. 또한, 메모리 내 키-값 저장소는 클라이언트와 서버 간 낮은 네트워크 통신 오버헤드가 필요로 하므로 높은 처리량에 크게 기여한다. 대표적인 인 메모리 데이터 저장소는 Redis 및 Memcached 데이터베이스가 있다[7],[15].

두 번째 온 디스크 기반 키-값 데이터 모델은 분산형 스토리지 시스템 또는 단일 노드 플랫폼에서 메모리에 자주 액세스하는 데이터가 있는 하드 디스크의 데이터를 저장하는 저장소 또는 메모리에 데이터를 저장할 수 있는 데이터 저장소가 될 수 있지만, 저장소를 연결하는 것도 허용한다[10]. 온 디스크 기능의 이점은 스토리지의 바이트 당 비용을 줄이고 스토리지 용량을 증가시키는 것이다. 실제로 디스크 공간에서 메모리 공간이 부족하거나 부족이 예상될 경우 디스크 데이터 저장소가 메모리 저장 유형의 대안으로 사용될 수 있다. 대표적인 키-값 데이터 모델인 분산형 데이터베이스로는 BerkeleyDB, Voldemort 및 Riak 등과 같은 것들이 있다[16].

Redis 데이터베이스는 캐시(Cache) 및 메시지 브로커(Message Broker)로 사용되는 오픈 소스(BSD 라이센스) 인 메모리 데이터 구조인 저장소이다[15]. 문자열(Strings), 목록(Lists), 집합(Sets), 정렬된 집합(Sorted Sets), 해시(Hash), HyperLogLogs 및 비트맵(Bitmaps)과 같이 다양한 종류의 데이터 형식이 지원되지만, 키-값 구조의 데이터 모델이다[15].

Redis에는 복제 기능이 내장되어 있으며 마스터-슬레이브(Master-Slave) 모델을 사용하여 복제할 수 있으며 마스터는 여러 개의 종속을 가질 수 있다[3],[15]. Redis는 TCP 소켓과 간단한 프로토콜을 사용하는 클라이언트/서버 모델을 사용하여 전송되는 일련의 명령을 통해 변경 가능한 데이터 구조에 대한 액세스를 제공한다. Redis는 LRU (Least Recently Used) 캐시로 사용할 수 있으며, 근사치 LRU 알고리즘을 사용하여 새 데이터가 추가될 때 기존 데이터를 제거할 수 있다. 또한, C로 작성되었고 Redis에 내장된 강력하고 가벼운 스크립팅 언어인 Lua를 사용하여 스크립팅 기능을 제공한다.

Redis는 Redis Sentinel이라는 기능을 사용하여 마스터가 예상대로 작동하지 않는 경우 자동 장애 조치를 지원한다. 이 기능은 슬레이브가 마스터로 승격된 장애 조치 프로세스를 시작하고 추가 슬레이브도 새 마스터를 사용하도록 재구성된다. Sharding은 Redis 클러스터를 통해 실행된다. 플랫폼에서는 데이터가 여러 Redis 노드에 자동으로 분할된다.

Redis의 Architecture는 그림 2와 같이 크게 3가지 영역인 메모리, 파일, 프로세스 영역으로 구성되어 있다[17].

Fig. 2. 
Redis Architecture

SSDB는 Redis의 새로운 대안으로 개발되고 있는 데이터베이스로 수십억 개의 요소를 저장하는 빠른 NoSQL 데이터베이스이다. SSDB는 Redis와 같은 키-값 데이터 모델로 구성되어 있으며, 문자열, 목록, 집합, 정렬된 집합, 해시를 포함하고 있는 데이터 구조를 지원한다.

SSDB는 그림 3과 같이 C/C++로 개발된 Google의 LevelDB를 스토리지 엔진으로 사용하고 있으며 Redis의 네트워크 프로토콜과 오픈 소스 Redis 클라이언트를 지원하는 아키텍처로 구성되어 있다. 또한, Redis와 같은 복제(Master-Slave), 로드 밸런스 기능을 갖고 있으며 개발과 배포를 위한 사용하기 쉬운 클라이언트 API를 지원하고 있다[18].

Fig. 3. 
SSDB Architecture

본 논문에서 진행하는 벤치마킹 프로세스는 단일 노드 인스턴스를 사용하여 Redis와 SSDB에 대한 NoSQL 데이터베이스의 성능을 비교하는 데 목적이 있다. 성능 분석 도구는 앞 장에서 말한 YCSB를 사용했으며 워크로드의 A타입부터 F 타입까지 실행하는 방식을 사용하였다. 실험을 위한 시스템 환경은 표 1과 같다.

성능 비교의 결과는 제안한 것처럼 Redis의 대안으로 SSDB의 적합성을 입증하는 것이다. 성능 비교를 위해 선택한 벤치마크 도구는 YCSB이다. YCSB는 클라우드 서비스의 성능을 측정하기 위한 벤치마크 도구로써 쿼리 패턴이나 분포를 설정하여 분석할 수 있다. YCSB의 사용 목적은 NoSQL 도입을 검토하려 할 때 특정 상황에 맞는 벤치마킹 환경 및 측정 결과를 제공함으로써 해당 NoSQL이 선정에 적합한지 판단할 기준을 제공한다. YCSB는 플러그인 기반 아키텍처를 가지고 있으며 스크립트를 사용하여 쉽게 확장성을 제공하므로 Redis와 SSDB를 벤치마킹할 수 있는 NoSQL 벤치마크 프레임워크이다[2]. YCSB 아키텍처는 두가지로 구성이 되어있다. 첫 번째는 확장 워크로드를 생성하는 YCBS Client가 구성되어 있으며, 두 번째는 확장 워크로드 생성기에서 실행되는 워크로드 시나리오 세트를 제공해주는 Core workloads로 구성되어 있다. 따라서 YCBS를 사용하여 실제 서비스 요청과 같은 유사한 패턴 결과를 얻을 수 있다. 그림 4는 YCSB의 아키텍처를 나타내고 있다[3].

Fig. 4. 
The YCSB Architecture

YCSB를 사용하여 CRUD의 연산 비중을 다르게 설정하여 요청 패턴을 실험할 수 있으며 제공되는 대표적인 YCSB의 워크로드는 표 2와 같다. 대표적인 워크로드는 A타입부터 F타입까지 있으며 성능 비교에 필요한 측정값을 얻을 수 있다[2]. 표 2에서 Operations는 실행하는 워크로드의 연산 비중을 뜻한다. 예를 들어 워크로드 A의 Update heavy를 전체 연산 중에서 50%로 Read 연산을 진행하며, 50%로 Update 연산을 진행하는 것을 뜻한다. 또한, Record selection은 어떤 방법으로 연산할 레코드를 검색할지를 뜻한다. 지프 분포를 적용해 레코드를 탐색하는 Zipfian가 있고, 최근 데이터를 기준으로 레코드를 탐색하는 Latest가 있으며, Continuous Uniform Distribution으로 연속 균등 분포를 통한 확률 분포로 레코드를 탐색하는 Uniform이 있다. 표 2의 설정값들은 기본 설정이 되어있으며, 변경이 필요하다면 Operation 비중과 Record Select 타입을 실험 환경에 맞게 변경할 수 있다. 각각 연산에서 사용되는 쿼리문의 경우, 임의 값을 삽입하여 데이터를 입력하고, 수정 및 삭제, 탐색은 기본 키값에 의해 진행한다.

본 연구에서 임의의 랜덤 값을 이용하여 CRUD를 각 워크로드별로 비교하였으며 스레드의 증가에 따른 데이터의 수를 1000, 5000, 10000개까지 늘리며 각 100회씩 실험을 진행하였으며 그 결과를 기본적으로 제공하는 각 워크로드를 기준으로 도식화했다.

워크로드 A는 Update heavy로 작업한 결과를 나타내고 있다. SSDB는 스레드 수가 증가함에 따라 Redis 보다 성능이 우수하고 처리량이 크게 분산되고 있다. 그림 4와 같이 스레드의 수가 증가하면 SSDB의 성능이 향상된다는 것을 보여준다.

Fig. 4. 
Performance comparison of Workload A

워크로드 B는 Read mostly로 작업한 결과를 나타내고 있다. 결과는 Update heavy 작업과 유사하다. 그림 5와 같이 SSDB는 Redis 보다 성능이 우수하다. 그러나 그림 5(c)와 같이 레코드 건수가 10000개에 이르면 Redis 보다 성능이 떨어지는 것을 확인할 수 있다.

Fig. 5. 
Performance comparison of Workload B

워크로드 C는 Read only로 작업한 결과를 나타내고 있다. 그림 6과 같이 SSDB의 처리량은 배포된 스레드 수가 증가함에 따라 Redis의 처리량과 큰 차이를 나타내고 있다.

Fig. 6. 
Performance comparison of Workload C

워크로드 D는 Read latest로 작업한 결과를 나타내고 있다. 그림 7과 같이 SSDB 처리량 결과가 Redis의 처리량을 어떻게 초과하는지 보여준다. 또한, 스레드 수가 10으로 증가함에 따라 처리량이 크게 향상됨을 나타내고 있다.

Fig. 7. 
Performance comparison of Workload D

워크로드 E는 Short ranges로 작업한 결과를 나타내고 있다. 그림 8과 같이 SCAN 작업에서는 Redis가 처리량 측면에서 SSDB보다 뛰어난 성능을 보여준다. 이는 SCAN 작업에서 SSDB는 스레드 수를 증가하더라도 성능 향상에 영향을 미치지 못함을 나타내고 있다.

Fig. 8. 
Performance comparison of Workload E

워크로드 F는 Read-modify-write 작업한 결과를 나타내고 있다. 그림 9는 워크로드 D와 유사하다. SSDB는 스레드 수가 1에서 4까지 Redis와 유사한 성능을 나타낸다. 그러나 스레드의 수가 증가되면 성능의 격차가 커지는 현상을 보여주고 있다.

Fig. 9. 
Performance comparison of Workload F

앞 절에서 진행된 실험에서는 Redis와 SSDB 두 데이터베스의 단일 노드의 인스턴스만 사용되었다. SSDB는 Heavy Read 작업에서 Redis의 처리량보다 약 2배 이상의 큰 효과를 나타냈다. 그러나 Short ranges 작업과 같은 SCAN 작업에서는 약 10배 가까운 상당한 감소를 나타냈다. 이는 개발자가 Update, Heavy Read 및 Read-Modify-write 작업을 수행하는 응용프로그램 시나리오에서 탄력성을 위해 SSDB를 채택하는 것을 고려할 수 있음을 보여준다. Redis의 새로운 대안이라고 주장하는 SSDB는 6가지 워크로드 중 5가지 작업에는 유효한 성능을 보인 반면 SCAN 작업이 많은 워크로드 E는 성능면에서 Redis가 높은 성능을 보였다. 또한, 일부 워크로드에서는 스레드 수가 증가할수록 Redis 보다 SSDB가 우수한 성능을 나타내고 있지만 워크로드 E에서는 스레드의 수가 증가되면 SSDB보다 Redis가 우수한 성능을 나타내고 있어 SCAN 작업이 우선시 되는 응용프로그램 시나리오에서는 데이터베이스 선택에 있어 SSDB 보다 Redis가 더 적합하다는 것을 측정 결과로 나타내고 있다.