록스DB 같은 데이터 엔진은 메타데이터 액세스의 병목 현상을 막는 데 중요한 역할을 하고 있다. 대규모 시스템으로 갈수록 이런 데이터 엔진은 유용하다. 록스DB의 경쟁 오픈소스 기술인 스피DB도 한번 살펴보자.
시뮬레이션, IoT 및 센서와 결합한 스트리밍 애플리케이션, 비정형 데이터와 같은 데이터 집약적인 사용 사례가 급격히 많아지고 있다. 자연스레 애플리케이션 확장 과정에서 빠르게 데이터베이스를 운영하는 것은 점점 중요해지고 있다. 데이터 읽기 및 쓰기 같은 과정을 신속하게 하려는 것이다. 하지만 CPU를 통한 스토리지 및 네트워크 계층에서 애플리케이션 GUI에 이르기까지, 시스템의 거의 모든 구성 요소가 잠재적으로 병목 현상을 일으킬 수 있다.
데이터 병목 현상의 주요 원인 중 하나는 데이터를 정렬하고 인덱싱하는 소프트웨어 스택 때문이다. 그중에서도 스토리지 엔진이라고도 하는 데이터 엔진에서 데이터를 운영하는 방식은 병목 현상에서 매우 중요한 요소다. 데이터 엔진은 원래 메타데이터를 저장하기 위해 만들어졌는데, 이는 기업이 볼만한 영화나 구매할만한 제품을 추천하는 데 활용하는 중요한 ‘데이터에 관한 데이터’이다. 이런 메타데이터는 데이터가 언제 생성되었는지, 정확히 어디에 저장되었는지 등을 알려준다.
메타데이터의 비효율성은 종종 무작위적인 읽기 패턴, 느린 쿼리 성능, 일관성 없는 쿼리 행동, I/O 중단 및 쓰기 정지의 형태로 나타난다. 이러한 문제들이 악화됨에 따라, 이 계층에서 발생하는 문제들이 다른 스택에도 영향을 주며 최종 사용자도 이로 인한 불편함을 느낄 수 있다. 대표적으로 느린 읽기 및 쓰기 속도, 쓰기 증폭, 공간 증폭, 확장 불가능 등 같은 문제가 있다.
병목 현상을 없애는 새로운 아키텍처
미래의 데이터 엔진은 상당한 확장성과 성능이 필요하다. 또한 지연 시간이 짧고 데이터 집약적인 워크로드의 요구에 대응해야 한다. 이들은 쓰기 증폭, 읽기 증폭, 공간 증폭 등 엔진이 수행하는 3가지 유형의 증폭 또는 데이터 쓰기 및 다시 쓰기를 조정하여 보다 세밀한 성능 튜닝을 가능하게 한다. 또한 엔진이 데이터를 찾고 저장하는 방법에 대한 추가적인 수정 작업도 지원한다.
필자가 근무하는 스피DB(Speedb)는 사실상 업계 표준인 록스DB(RocksDB)를 바로 대체하기 위해 데이터 엔진을 설계했다. 스피DB는 지난 2년간 엔터프라이즈 에디션으로 제공된 기술을 기반으로 개발자 커뮤니티에 오픈소스 형태로도 제공한다.
많은 개발자가 IO 바운드 워크로드를 위해 많은 CPU를 활용하도록 최적화된 데이터 엔진인 록스DB를 이용한다. 메타(구 페이스북)이 만든 록스DB는 LSM(log-structured merge) 트리 기반 데이터 구조를 사용하여 쓰기 집약적인 사용 사례를 효율적으로 처리하는데 뛰어나다. 그러나 LSM 읽기의 성능은 작은 크기의 무작위 형태로 데이터가 접근될 경우 성능이 저하될 수 있으며, 특히 메타 데이터와 같이 작은 파일의 볼륨이 큰 애플리케이션에서 애플리케이션이 확장됨에 따라 문제가 커질 수 있다.
스피DB(Speedb) 최적화
스피DB는 데이터 및 메타데이터 확장성을 최적화하기 위한 3가지 기법을 개발했다. 록스DB 및 기타 데이터 엔진보다 진보된 기법을 제공하는데 구체적으로 다음과 같다.
압축(Compaction)
다른 LSM 트리 기반 엔진과 마찬가지로 록스DB는 압축을 사용하여 디스크 공간을 회수하고 로그에서 이전 버전의 데이터를 제거한다. 추가 쓰기는 데이터 리소스를 소모하고 메타데이터 처리 속도를 저하시키며, 이를 완화하기 위해 데이터 엔진이 압축을 수행한다. 그러나 2가지 주요 압축 방법인 수평 압축 방법과 범용 압축 방법은 이러한 엔진이 데이터 집약적인 워크로드를 효과적으로 처리하는 능력에 영향을 미친다.
각 방법을 자세히 알아보면 쉬운 기술이 아니라는 것을 알 수 있다. 수평 압축은 디스크 공간 오버헤드를 매우 적게 발생시킨다(기본값은 약 11%). 그러나 대규모 데이터베이스의 경우 I/O 증폭에 큰 불이익이 따른다. 수평 압축은 ‘병합’ 방식으로 운영된다. 즉, 각 레벨은 일반적으로 훨씬 큰 다음 레벨과 병합된다. 결과적으로, 각 레벨은 두 레벨의 크기 사이의 비율에 비례하는 읽기 및 쓰기 증폭을 추가한다.
범용 압축은 쓰기 증폭이 더 작지만, 최종적으로 데이터베이스는 전체 압축이 필요하다. 이렇게 전체 압축을 수행하려면 전체 데이터베이스 크기보다 크거나 같은 공간이 필요하며 새 업데이트 처리가 지연될 수 있다. 따라서 범용 압축은 대부분의 실시간 고성능 애플리케이션에서 사용할 수 없다.
스피DB의 아키텍처는 업데이트를 차단하지 않고 추가 공간에서 작은 오버헤드로 매우 큰 데이터베이스에 대한 쓰기 증폭을 줄이는 하이브리드 압축을 지원한다. 하이브리드 압축 방법은 전체 데이터베이스의 크기에 비해 데이터의 크기가 작은 모든 상위 수준에서 범용 압축과 같이 작동하며 업데이트된 데이터의 상당 부분이 유지되는 최하위 수준에서만 수평 압축과 같이 작동한다.
멤테이블 테스트(아래 그림 1)는 덮어쓰기가 17%, 읽기 및 쓰기 혼합 워크로드(읽기 90%, 쓰기 10%)가 13% 증가한 것으로 나타났다. 개별 블룸 필터 테스트 결과 읽기 랜덤 워크로드에서 읽기 누락이 130% 개선되고(그림 2) 메모리 사용량이 26% 감소했다(그림 3).
레디스에서 실행되는 테스트는 레디스 온 플래시 구현에서 스피DB가 록스DB를 대체했을 때 성능이 향상되었음을 보여준다. 스피DB를 사용한 테스트는 또한 애플리케이션의 읽기/쓰기 비율에 구애받지 않았으며, 이는 여러 개의 서로 다른 애플리케이션이나 시간이 지남에 따라 액세스 패턴이 달라지는 애플리케이션에서 성능을 예측할 수 있음을 나타낸다.
메모리 관리
임베디드 라이브러리의 메모리 관리는 애플리케이션 성능에 중요한 역할을 한다. 현재 솔루션은 복잡하고 너무 많은 매개 변수가 얽혀 있어 사용자가 필요에 맞게 최적화하기 어렵다. 환경이나 워크로드가 변화함에 따라 도전과제가 늘어난다.
스피DB는 사용하기 쉽게 만들고 리소스 활용도를 높이기 위해 메모리 관리를 재설계할 때 전체적인 접근 방식을 취했다.
복잡한 데이터를 관리하는 기술을 이용하면 향상된 플러시 스케줄러를 활용할 수 있다. 이 과정에서 사용자 개입 없이 사전 예방적 접근 방식을 취하고 전반적인 메모리 효율성과 시스템 활용도를 개선할 수 있다.
스피DB는 처음부터 다양한 사용 사례에서 성능, 확장성 및 사용 편의성을 달성하기 위해 추가 기능이 자체적으로 조정할 수 있다.
흐름 제어
스피DB는 록스DB의 흐름 제어 메커니즘을 재설계하여 사용자 대기 시간이 급격히 늘어나지 않도록 한다. 새로운 흐름 제어 메커니즘은 이전 메커니즘보다 훨씬 더 온건하고 시스템 상태에 더 정확하게 조정되는 방식으로 속도를 변경한다. 그것은 필요할 때는 속도를 늦추고 할 수 있을 때는 속도를 높인다. 이를 통해 정지상태가 제거되고 쓰기 성능이 안정적이게 된다.
데이터 엔진 비효율성의 근본 원인이 시스템에 깊이 묻힐 경우 이를 찾는 것이 어려울 수 있다. 동시에 근본 원인이 깊을수록 시스템에 미치는 영향도 커진다. 옛말에 있듯이, 사슬은 가장 약한 고리만큼만 강하다.
스피DB와 같은 차세대 데이터 엔진 아키텍처는 메타데이터 성능을 높이고, 대기 시간을 단축하며, 검색 시간을 가속화하고, CPU 사용을 최적화할 수 있다. 하이퍼스케일 애플리케이션을 확장함에 따라 새로운 데이터 엔진 기술은 민첩하고 확장 가능하며 성능이 뛰어난 최신 아키텍처를 활성화하는 데 중요한 요소가 될 것이다.
* Hilik Yochai는 스피DB의 공동 설립자이자 최고 과학자다.
dl-ciokorea@foundryco.com
