RadonDB: 대륙의 뉴타입 슈주쿠(Shùjùkù, 数据库, database) !?
최근에 알게 QingCloud (칸클라우뜨, 칭클라우드, 청나라 구름?! ) 에서 오픈소스로 공개한 RadonDB (0) ( 레이돈디비, 라둥디비?! 동(氡)디비?! ) 에 대해서 알아 보겠습니다.
RadonDB 는 MySQL 데이터베이스를 이용하여 대용량 데이터 처리를 쉽게 하기 위해 클러스터 구성이 가능하도록 지원하는 솔루션으로 보입니다. RadonDB 솔루션명이 DB 라고 되어 있는데 사실은 DB 라고 부르기에는 애매한 점이 있는데 이 부분은 뒤에서 설명하겠습니다. 그런데, 몇일전까지만해도 QingCloud 였는데, RadonDB ( http://radondb.io ) 란 홈페이지가 생기고, Yunify Technologies Inc. 란 회사로 되어 있네요. 엊그제 올라온 블로그 소개 동영상 ( http://www.10tiao.com/html/742/201805/2650745626/1.html ) 에 R.A.D.O.N.D.B 란 큰 사인이 있길래. 분명 팀단위 조직일텐데, 중국은 입구에 저렇게도 하는구나라고 생각을 했었는데, 회사를 스타트업시켰나 봅니다. 잠깐 홈페이지를 보니까! 급하게 한게 티가 나네요. 아마도 외부개발자, DBA 들과 글로벌하게 키우기 위해서 별도의 회사를 차린 것 같습니다. ( http://www.10tiao.com/html/742/201805/2650745635/1.html )
1. 넌 누구냐?!
RadonDB = NewSQL + MySQL ( https://github.com/radondb/radon )
RadonDB is an open source, cloud-native MySQL database for building global, scalable cloud services RadonDB is a new generation of distributed relational database (MyNewSQL) based on MySQL.
저도 위의 문구를 보고 놀랐습니다. MyNewSQL 라니!! 개발자들의 위트로 보여집니다. 저는 뉴타입이라고 칭하겠습니다. 개발사의 말대로라면 RadonDB 는 글로벌하고 확장 가능한 클라우드 서비스를 구축 할 수있는 MySQL 기반의 "차세대 분산 데이터베이스" 라고 합니다. 요즘은 이러한 MySQL or PostgreSQL 호환성을 가지거나, 기반한 분산 데이터베이스들이 쉽게 찾아 볼 수 있습니다. 그리고, 구글이 공개한 스패너(Spanner) (1) 전과 후로 나뉠 수 있습니다. 이전이라면 전통적으로 MySQL or PostgreSQL 기반으로 한 분산 아키텍처 형태이고, 이후라면 MySQL or PostgreSQL Protocol 과 ANSI SQL 을 지원함으로써, 클라이언트 입장에서는 소스 수정없이 기존 데이터베이스와 동일하게 사용이 가능합니다. 유틸리티, 3rd party 연동은 필요에 따라서 지원하는 형태입니다.
그 다음과 같은 종류들이 있습니다. ( PostgreSQL vs MySQL 기반 분류 기준으로는 BSD vs GPL 라이센스 이슈도 있습니다. )
PostgreSQL 기반
Pivotal - GreenPlum : PostgreSQL 기반 MPP ( Massive Parallel Processing ) 데이터베이스 입니다. 오픈소스와 상용버전이 있습니다. PostgreSQL 10 최신버전이 반영되고 있지 않습니다.
CitusData - Citus : PostgreSQL 기반 MPP ( Massive Parallel Processing ) 데이터베이스 입니다. 오픈소스와 상용버전이 있습니다. PostgreSQL 10 최신버전이 반영되고 있습니다.
Cockroach Labs - CockroachDB : PostgreSQL Protocol 을 지원하는 분산 SQL 데이터베이스 입니다. 구글의 스패너 (Spanner) 에 기반한 대표적인 분산 데이터베이스입니다. ( MySQL Protocol 지원여부에 대해서 단순히 PostgreSQL Protocol 문서가 잘되어 있어서 먼저 했다고 합니다. 향후에 MySQL Protocol 지원도 충분히 가능하리라 봅니다. )
MySQL 기반
Clustrix - Clustrix : MySQL 호환하는 분산 데이터베이스 입니다. 오픈소스 버전은 없고, 사용버전만 존재합니다. 국내에서 MySQL Scale-out 이슈에 때문에 도입한 곳들이 있는 걸로 알고 있습니다.
MemSQL - MemSQL : MySQL 호환하는 분산 데이터베이스 입니다. Y Combinator 펀딩과 Execute Plan to Binary 형태로 동작하는 참신함, Spark - MySQL/MemSQL Connector 등으로 상당히 이슈화가 되었고, 현재는 리얼타임 분석 데이터베이스를 표방하고 있습니다. 예전에는 커뮤니티 에디션도 공개했는데, 지금은 slack 을 통해서만 배포하는 것 같습니다. 기본적으로 상용입니다.
Vitessio/PlanetScale - Vitess : Youtube 에서 MySQL 기반으로 만든, GreenPlum 과 유사하게 MySQL 을 단순히 데이터를 저장하는 용도로만 쓰고, 분산 아키텍처를 구현한 데이터베스입니다. 작년에 메인 개발자가 퇴사하여 PlanetSclae 이란 회사를 창업하였습니다.
PingCap - TiDB : 현재로써는 CockroachDB 와 대칭점에 있는 MySQL 프로토콜을 지원하는 분산 HTAP ( High Transaction Analytic Processing ) 데이터베이스 입니다. 특이한 점은 RadonDB 와 마찬가지로 중국회사이며, 대부분의 개발자가 중국개발자입니다.
필자입장에서 결론부터 말씀드리자면... MySQL 을 기반으로 한 Proxy Database 라고 보는 것이 더 정확할 것 같습니다. 그렇지만, ProxySQL (2) 과 같이 쿼리 라우팅 ( query routing ) , 쿼리 캐싱 ( query caching ), 통계 ( statistics ) 등과 같은 Proxy 로써의 역할보다는 자동 테이블샤딩 ( auto table sharding ), 분산처리 ( distributed transaction ), 커넥션풀 ( connection thread pool ) 등과 같이 분산처리에 대한 기능이 더 강하고, 지금은 없어진 ShardQuery (3) 와 매우 유사한 아키텍처와 컨셉입니다. 가장 흔하게 생각할 수 있는 shard key 를 가지고 MySQL 데이터베이스에 auto partitioning 을 해주고, MySQL 쿼리를 파싱해서 분산 처리를 구현하는 것입니다. IN ( 1, 2, 3, ... n ) 절이 대표적으로 쉽게 병렬처리 ( parallel processing ) 를 구현할 수 있습니다. 그리고, 또하나 비교할 수 있는 것이 Spider Engine for MySQL (4) 입니다. 일본개발자가 개발한 MySQL Storage Engine 으로써, 별도의 솔루션이 없이 MySQL 만 가지고 Scale-Out 아키텍처를 구현할 수 있습니다. Spider Engine 과의 차별점이라면 HA ( High Availability ) 에 대한 고민인 것 같습니다. 이 부분은 아래에서 다시 설명하겠습니다.
RadonDB Architecture
위 그림은 RadonDB 의 아키텍처입니다. Distributed SQL Nodes (stateless) 즉 Radon 서버이고, Storage Nodes 가 MySQL Master-Slave 입니다. Compute Nodes 는 현재로써 제공된 정보가 없습니다. 향후에 추가로 공개할 것 같습니다. 이런 아키텍처의 장점이라면 몇가지가 있습니다. 첫번째, MySQL Server 5.6/5.7/8.0 등 버전에서 어느 정도 자유롭습니다. 물론, MySQL Protocol 이 바뀌는 부분은 어쩔 수 없이 맞춰야 하지만, MySQL Server 에 대한 의존성이 거의 없기 때문에 편합니다. 둘째, MySQL 아키텍처 특유의 Pluggable Storage 에 대처가 편하고, 활용도가 높다. 가령 특정 노드/테이블은 InnoDB Engine 으로 구성하고, 또다른 노드/테이블은 TokuDB 으로 쓸 수 있습니다. 이 부분은 QingCloud RadonDB 에서도 언급하고 있습니다. 셋째는 Storage Nodes - MySQL Server 가 예전 방식 그대로 동작하기 때문에 개발, 운영/관리, 교육, 백업/복구 등의 추가적인 비용(cost) 가 발생하지 않습니다.
Sharding Architecture for RadonDB
위의 그림은 실제 샤딩하는 구조를 설명하고 있습니다. 한 개의 MySQL 서버에 shard key 로 partitioning 된 t1_0000 ~ t1_0031 개의 테이블이 생기고, range (segment) 값은 128 ( [0, 127], [128, 255] ) 로 나눕니다. 그러나, 실제로는 t1_0000 ~ t1_0029 개의 테이블이 생기고, range (segment) 값은 128 ( [0, 128], [128, 256], ... ) 등으로 처리되는 것 같습니다. 아마도, 예전 발표자료와 최근 수정한 것이 일치하지 않는 것 같습니다. 자세한건 src/ctl/v1/shard.go 를 확인해봐야 할 것 같습니다. 결국 Client <-> MySQL wire protocol <-> Radon 상에서는 Client 는 xTBL 이란 1개 테이블을 바라보고 있고, 실제로 Storage Nodes - MySQL Server 에는 xTBL_0000 ~ xTBL_0031 이란 테이블이 가상테이블처럼 존재하는 것입니다. 물론, shard key 를 가지고 slots 를 조정할 수 있습니다. QingCloud RadonDB 홈페이지에는 Auto Rebalancing 이 된다고 하는데, 온라인으로는 안된다고 하는 것 같습니다. (구글번역기) 아마도 변경된 shard key 로 batch job 을 수행할 것 같습니다.
그리고, 위에서 설명했던 Spider Engine 과의 차별점에 대해서 설명하였습니다. 바로 Xeon (0) ( The MySQL Cluster Autopilot Management with GTID and Raft, https://github.com/radondb/xenon ) 이란 부분을 제공합니다. Spider Engine 의 경우는 말그대로 MySQL 의 Pluggable Storage Engine 이기 때문에 HA ( High Availability ) 는 별도로 제공하지 않습니다. 사용자가 원하는 MySQL HA 로 구성해야 합니다. 그러나, RadonDB 의 경우에는 Xeon 을 통해서 손실없는 빠른 장애극복(Failover), 스트리밍 & 빠른 백업/복구, MySQL 운영 및 유지보수, 비중앙 집중식 제어 그리고 쉬운 배포, 클라우드 앱서비스 등을 제공합니다. 특이한 점은, Master-Slave 간에 GTID + Semi-Sync Replication 을 지원하고, HA ( High Availability )와 Replication 에 Raft Protocol 을 사용했다고 합니다. 성능을 위해서 Semi-Sync 를, Cloud 서비스기반이라서 그런지 Raft 를 쓰는 것도 같습니다.
RadonDB = Radon + Xeon
추가적으로, MySQL 8.0 은 지원하지 않고 있고, 역시 클라우드 업체에서 개발해서 인지, CLI ( Command Line Interface ) 보다는 Web UI 를 고려한 RESTful API, JSON 방식으로 설정합니다. 현재로써는 Web UI 는 없습니다. CLI 는 MySQL Client 를 이용합니다. 접속시에 다음과 같은 접속정보를 보여줍니다.
Server version: 5.7-Radon-1.0
2. 장점
사용법이 정말정말 심플합니다!! Architecture 도 심플합니다. 뉴타입이라면 당연히 핀 판네르를 쓸 줄 알아야 합니다. 그러나, 그 수가 제한적이긴 합니다. oTL. 그래도, 일정 규모에서는 크게 문제가 되지 않을 것 같습니다. 그래도, Scale-out 하다고 보기는 어려울 것 같습니다. 그리고, Sharding 은 되지만, Auto Sharding 이라고 보기는 힘들고, 그렇기에 Resharding 에 대한 고민이 필요합니다. ( Vitess 도 Golang 인데, 잘하면 가져다가... )
3. 단점
요즘 PlanetScale Vitess, PingCAP TiDB, Cockroach Labs CockroachDB, 등 Google Spanner 의 계기로 각성한 뉴타입들이 많습니다. 이 경쟁에서 현재로써는 많이 부족합니다. 타 뉴타입에 비해서 실제 라이브하게 쓰기에는 레퍼런스도 부족하고, 성능과 기능에 대한 검증도 필요하고, 유틸리티와 3rd party 연동에 대한 이슈들이 많습니다. 그리고, ProxySQL 로도 충분히 대체가 가능합니다. 차라리 ProxySQL 이 더 나을 수도...
4. 결론
뉴타입이 아니었습니다. 뉴타입 클론정도!? ㅠㅠ
작년에는 Vitess 개발자가 Google (Youtube) 을 퇴사해서 PlanetScale 이란 스타업을 시작했고, 아직까지는 뉴타입들이 큰 레퍼런스와 인기를 못 얻고 있지만, 몇년안에는 MySQL 호환 뉴타입과 PostgreSQL 호환 뉴타입들이 많이 확산되리라 봅니다. 또, RadonDB 를 계기로 대륙의 클라우드들이 비슷하게 오픈소스화하지 않을까란 기대도 해봅니다.
그래서, 앞으로 기대해볼만 합니다. ㅠㅠ