2019.07.11

RDBMS·NoSQL 장점만 모았다··· '분산 관계형' 데이터베이스 5종

Martin Heller | InfoWorld
1980년대부터 써온 관계형 SQL 데이터베이스는 흔히 중앙 처리 장치나 단일 서버에서 실행됐다. 그것밖에 없었기 때문이다.
 
ⓒ Getty Images Bank

당시에는 데이터베이스의 처리 데이터양이나 실행 속도를 개선하려면 성능이 더 좋고 더 많은 CPU, 메모리, 디스크가 있는 더 큰 서버에 데이터베이스를 배치해야 했다. 즉, 수직 확장성, 즉, '스케일 업(Scale-Up)'에 의존했다. 여기서 가용성 개선을 위해 수동 전환 기능이 필요하다면, 핫 백업 서버와 활성 서버를 '액티브-패시브' 클러스터에 함께 배치했는데, 이때는 공유 스토리지를 이용하는 것이 일반적이다.
 
네트워크 분할, 정전 등의 오류 시에도 데이터베이스 트랜잭션이 항시 제대로 수행되게 하려면 4가지 ACID 속성(원자성(A), 일관성(C), 고립성(I), 지속성(D))이 준수돼야 한다. 이 ACID 측면에서 단일 서버에 있는 데이터베이스는 ACID 속성을 전부 만족하기가 비교적 쉽다.

반면 분산 데이터베이스는 이행하기가 약간 더 까다롭다. 실제로 2009년경부터 확산한 NoSQL 데이터베이스는 '수평 확장성(Scale-Out, 다수의 서버에서 실행 가능하다는 의미)'의 장점이 있었지만 ACID 전체를 따르지 못하는 경우가 많았다. 또한 독자적인 SQL 언어를 쓰는 경우도 많았다.
 
이는 NoSQL 데이터베이스가 개념부터 달랐기 때문이다. 즉 '궁극적 일관성'이라는 개념을 사용했다. 한 서버의 데이터베이스에 작성한 내용을 즉시 다른 서버로부터 읽으면 방금 작성한 서버로부터 읽는 것과는 같은 결과를 보지 못할 수도 있다는 의미다. 물론 조금 시간이 지나면 새로운 데이터가 클러스터 내 모든 서버에 복제되고 궁극적으로 일관성을 갖게 된다. 이러한 '궁극적 일관성' 개념은 온라인 카탈로그와 같은 일부 애플리케이션에서는 충분히 효과적이지만 재무 데이터까지 적용하기에는 부족했다.
 
이런 가운데 최근 수평으로 확장 가능한 '스케일 아웃' SQL 데이터베이스가 새롭게 부상하고 있다. 가장 큰 장점은 여러 지역에 분산된 서버에서도 일관성이 희생되지 않는다는 것이다. 물론 매우 멀리 떨어진 서버 노드는 거리의 한계 때문에 로컬 노드보다 업데이트 시간이 오래 걸린다. 그러나 이 문제를 완화할 방법이 몇 가지 있다. 예를 들면, 합의 그룹 쿼라와 초고속 네트워킹 및 스토리지를 사용하면 된다.
 
일반적으로, 그동안 사용해 온 데이터베이스와 앞으로 사용하고 싶은 새로운 분산 데이터베이스는 최대한 호환이 돼야 스키마와 애플리케이션 전환 비용을 최소화할 수 있다. 가장 단순한 경우에는 스키마와 데이터를 옮긴 후 해당 애플리케이션에서 연결 스트링을 변경하기만 하면 된다. 가장 복잡한 경우에는 데이터 전환 절차를 거쳐야 하고 저장된 프로시저와 트리거를 전체적으로 다시 작성해야 한다. 또한, SQL 쿼리를 비롯한 애플리케이션의 데이터 계층을 대대적으로 다시 작성해야 한다.

아마존 RDS와 아마존 오로라
아마존 RDS(Relational Database Service)는 일종의 웹 서비스다. 클라우드에 관계형 데이터베이스를 손쉽게 설치, 운영, 확장할 수 있다. 마이SQL, 마리아DB, 포스트그래SQL, 오라클 데이터베이스, 마이크로소프트 SQL 서버 등을 지원한다.

아마존 RDS 데이터베이스는 수동 전환을 위한 동기 보조 인스턴스로 구성해 고가용성을 확보할 수 있다. 안타깝지만, 대기 상태의 보조 인스턴스에서는 데이터를 읽을 수 없다. 마이SQL, 마리아DB 또는 포스트그래SQL 읽기 전용 복제본을 사용해 읽기 범위를 늘리는 방법이 있지만, 복제는 동시에 진행되지 않음으로 복제 상태는 기본 인스턴스 상태보다 뒤처져 있을 수 있다.

아마존 오로라(Aurora)는 아마존 RDS 내의 서비스 중 하나다. 속도가 빠른 분산 스토리지에서 마이SQL 및 포스트그래SQL 데이터베이스의 고성능 클러스터를 제공한다. 읽기 전용 쿼리를 지원하기 위해 데이터베이스 클러스터에 최대 15개의 오로라 복제본을 만들 수 있다. 또한, 여러 개의 가용성 구역(AZ)에 복제본을 만들어 광역 분산을 가능하게 할 수도 있다.

아마존에 따르면, 오로라는 마이SQL 처리량의 최대 5배, 포스트그래SQL 처리량의 최대 3배까지 가능하며 기존 애플리케이션 대부분은 변경할 필요가 없다. 또한, 오로라 읽기 복제본 업데이트에는 약 20밀리초의 시차가 존재한다고 아마존 측은 주장한다. 이는 이론적으로 마이SQL 읽기 복제본보다 훨씬 빠르다.

애저 SQL 데이터베이스
애저 SQL 데이터베이스는 완전 관리 관계형 클라우드 데이터베이스 서비스다. 폭넓은 SQL 서버 엔진 호환성을 제공하고 데이터베이스 자원을 자유자재로 확장, 축소할 수 있다. 애저 SQL 데이터베이스에는 지리적으로 분산된 보조 데이터베이스인 활성 지리 복제본 생성 옵션도 포함돼 있다. 똑같은 지역이나 다른 지역에서 최대 4개의 보조 데이터베이스가 지원된다. 보조 데이터베이스는 읽기 전용 쿼리에 사용할 수도 있다. 기본 데이터베이스를 보조 데이터베이스로 자동 전환해야 할 경우 수동으로 또는 API를 통해 할 수 있다.

클러스트릭스DB
이제는 마리아DB에서 소유한 클러스트릭스DB(ClustrixDB)는 스케일 아웃, 클러스터화 관계형 HTAP(hybrid transaction/analytical processing) 데이터베이스다. 미공유(SN) 아키텍처로 설계됐으며, 마이SQL, 마리아DB와 대부분 호환된다. 필자가 클러스트릭스DB를 리뷰했을 당시에는 공간 확장 유형과 전문(full-text) 검색 지원이 부족했다. 최신 릴리스 기준으로 두 가지 모두 여전히 부족한 상태다.

클러스트릭스DB에 노드를 추가하면 읽기와 쓰기 모두 확장된다. 클러스트릭스DB는 계획되지 않은 구역 장애 도중에 장애 허용이 가능하도록 클러스터를 여러 구역에 걸쳐 배치할 수 있다. 한 독립 연구소에서 실행한 테스트에서(인포월드에서 실행한 것은 아님) 클러스트릭스DB는 초당 4만 건의 트랜잭션을 처리했다. 90% 읽기에 10% 쓰기 작업 기준으로 지연 시간은 15밀리초였다. 이 정도면 전자 상거래가 급증하는 “사이버 먼데이”를 감당할 만한 확장성이다.

코크로치DB
코크로치DB(CockroachDB)는 오픈 소스에 수평 확장 가능한 분산 포스트그래SQL 호환 SQL 데이터베이스다. 구글 클라우드 스패너(Spanner)에 능한 전직 구글 직원이 개발했다. 코크로치DB는 데이터 저장 시스템의 설계를 스패너에서 빌려왔으며, 노드 간 합의에 래프트(Raft) 알고리즘을 사용한다. 덕분에 코크로치DB는 스패너와 동기화하는 다른 것이 필요 없다.

코크로치DB는 트랜잭션을 처리하고 일관되게 키값을 저장하는 공간, 즉 록스DB(RocksDB)위에 구축됐다. 기본적인 설계 목표는 ACID 트랜잭션 지원, 수평 확장성, 그리고 (무엇보다도) 생존 가능성이다. 생존력 높은 ‘바퀴벌레’라는 뜻의 이름을 갖게 된 것도 이 때문이다. 코크로치DB는 기본적으로 직렬화 가능한 고립 모드를 사용한다. 이는 대부분의 다른 데이터베이스에서 실행하는 것보다 더 강력한 형태의 고립이다.

필자가 2018년 초 코크로치DB를 리뷰했을 당시 조인(JOIN) 성능이 별도 좋지 않았지만 이후 많이 보완됐다. 코크로치DB는 클러스터 하나를 여러 개의 가용성 구역에 걸쳐 분산할 수 있도록 지원한다. 또한, 구글 클라우드 플랫폼이나 아마존 웹 서비스(AWS)에 완전한 관리 방식의 클라우드 데이터베이스 클러스터를 제공한다.

구글 클라우드 스패너
구글 클라우드 스패너는 관리 분산 데이터베이스로, SQL 호환성, 관계형 스키마, ACID 트랜잭션, 외부 일관성을 유지하면서도 NoSQL 데이터베이스의 확장성을 지원한다. 스패너는 CAP 정리 해결에 매우 근접해 있다. 스패너는 샤딩되고, 광역 분산, 복제된 상태로, 노드 간 합의에 도달하기 위해 팩소스(Paxos) 알고리즘을 사용한다. 강력한 일관성을 위해 2단계 커밋을 사용하지만, 팩소스 그룹을 트랜잭션의 구성원으로 간주한다. 각 팩소스 그룹은 구성원 100%가 아닌 쿼럼 하나만 있어도 이용할 수 있다.
 
구글 스패너는 내부적으로 사용할 때 99.999% 이상의 가용성을 보여줬다. 즉, 1년간 정지 시간이 5분 미만임을 의미한다. 그 정도면 충분한 성능이므로 프로그래머 대부분은 스패너에 가용성을 강화하기 위한 별도의 코드를 굳이 작성하지 않는다. 스패너는 ANSI 2011 SQL의 일종인 구글 커먼 SQL(Common SQL)을 사용한다. 커먼 SQL은 포스트그래SQL, 마이SQL, SQL 서버나 오라클 데이터베이스에서 사용하는 SQL 문법과 정확히 일치하지는 않는다. 데이터 유형에서 약간 다르고 데이터 조작 분야에서는 더 차이가 두드러진다. ciokr@idg.co.kr


2019.07.11

RDBMS·NoSQL 장점만 모았다··· '분산 관계형' 데이터베이스 5종

Martin Heller | InfoWorld
1980년대부터 써온 관계형 SQL 데이터베이스는 흔히 중앙 처리 장치나 단일 서버에서 실행됐다. 그것밖에 없었기 때문이다.
 
ⓒ Getty Images Bank

당시에는 데이터베이스의 처리 데이터양이나 실행 속도를 개선하려면 성능이 더 좋고 더 많은 CPU, 메모리, 디스크가 있는 더 큰 서버에 데이터베이스를 배치해야 했다. 즉, 수직 확장성, 즉, '스케일 업(Scale-Up)'에 의존했다. 여기서 가용성 개선을 위해 수동 전환 기능이 필요하다면, 핫 백업 서버와 활성 서버를 '액티브-패시브' 클러스터에 함께 배치했는데, 이때는 공유 스토리지를 이용하는 것이 일반적이다.
 
네트워크 분할, 정전 등의 오류 시에도 데이터베이스 트랜잭션이 항시 제대로 수행되게 하려면 4가지 ACID 속성(원자성(A), 일관성(C), 고립성(I), 지속성(D))이 준수돼야 한다. 이 ACID 측면에서 단일 서버에 있는 데이터베이스는 ACID 속성을 전부 만족하기가 비교적 쉽다.

반면 분산 데이터베이스는 이행하기가 약간 더 까다롭다. 실제로 2009년경부터 확산한 NoSQL 데이터베이스는 '수평 확장성(Scale-Out, 다수의 서버에서 실행 가능하다는 의미)'의 장점이 있었지만 ACID 전체를 따르지 못하는 경우가 많았다. 또한 독자적인 SQL 언어를 쓰는 경우도 많았다.
 
이는 NoSQL 데이터베이스가 개념부터 달랐기 때문이다. 즉 '궁극적 일관성'이라는 개념을 사용했다. 한 서버의 데이터베이스에 작성한 내용을 즉시 다른 서버로부터 읽으면 방금 작성한 서버로부터 읽는 것과는 같은 결과를 보지 못할 수도 있다는 의미다. 물론 조금 시간이 지나면 새로운 데이터가 클러스터 내 모든 서버에 복제되고 궁극적으로 일관성을 갖게 된다. 이러한 '궁극적 일관성' 개념은 온라인 카탈로그와 같은 일부 애플리케이션에서는 충분히 효과적이지만 재무 데이터까지 적용하기에는 부족했다.
 
이런 가운데 최근 수평으로 확장 가능한 '스케일 아웃' SQL 데이터베이스가 새롭게 부상하고 있다. 가장 큰 장점은 여러 지역에 분산된 서버에서도 일관성이 희생되지 않는다는 것이다. 물론 매우 멀리 떨어진 서버 노드는 거리의 한계 때문에 로컬 노드보다 업데이트 시간이 오래 걸린다. 그러나 이 문제를 완화할 방법이 몇 가지 있다. 예를 들면, 합의 그룹 쿼라와 초고속 네트워킹 및 스토리지를 사용하면 된다.
 
일반적으로, 그동안 사용해 온 데이터베이스와 앞으로 사용하고 싶은 새로운 분산 데이터베이스는 최대한 호환이 돼야 스키마와 애플리케이션 전환 비용을 최소화할 수 있다. 가장 단순한 경우에는 스키마와 데이터를 옮긴 후 해당 애플리케이션에서 연결 스트링을 변경하기만 하면 된다. 가장 복잡한 경우에는 데이터 전환 절차를 거쳐야 하고 저장된 프로시저와 트리거를 전체적으로 다시 작성해야 한다. 또한, SQL 쿼리를 비롯한 애플리케이션의 데이터 계층을 대대적으로 다시 작성해야 한다.

아마존 RDS와 아마존 오로라
아마존 RDS(Relational Database Service)는 일종의 웹 서비스다. 클라우드에 관계형 데이터베이스를 손쉽게 설치, 운영, 확장할 수 있다. 마이SQL, 마리아DB, 포스트그래SQL, 오라클 데이터베이스, 마이크로소프트 SQL 서버 등을 지원한다.

아마존 RDS 데이터베이스는 수동 전환을 위한 동기 보조 인스턴스로 구성해 고가용성을 확보할 수 있다. 안타깝지만, 대기 상태의 보조 인스턴스에서는 데이터를 읽을 수 없다. 마이SQL, 마리아DB 또는 포스트그래SQL 읽기 전용 복제본을 사용해 읽기 범위를 늘리는 방법이 있지만, 복제는 동시에 진행되지 않음으로 복제 상태는 기본 인스턴스 상태보다 뒤처져 있을 수 있다.

아마존 오로라(Aurora)는 아마존 RDS 내의 서비스 중 하나다. 속도가 빠른 분산 스토리지에서 마이SQL 및 포스트그래SQL 데이터베이스의 고성능 클러스터를 제공한다. 읽기 전용 쿼리를 지원하기 위해 데이터베이스 클러스터에 최대 15개의 오로라 복제본을 만들 수 있다. 또한, 여러 개의 가용성 구역(AZ)에 복제본을 만들어 광역 분산을 가능하게 할 수도 있다.

아마존에 따르면, 오로라는 마이SQL 처리량의 최대 5배, 포스트그래SQL 처리량의 최대 3배까지 가능하며 기존 애플리케이션 대부분은 변경할 필요가 없다. 또한, 오로라 읽기 복제본 업데이트에는 약 20밀리초의 시차가 존재한다고 아마존 측은 주장한다. 이는 이론적으로 마이SQL 읽기 복제본보다 훨씬 빠르다.

애저 SQL 데이터베이스
애저 SQL 데이터베이스는 완전 관리 관계형 클라우드 데이터베이스 서비스다. 폭넓은 SQL 서버 엔진 호환성을 제공하고 데이터베이스 자원을 자유자재로 확장, 축소할 수 있다. 애저 SQL 데이터베이스에는 지리적으로 분산된 보조 데이터베이스인 활성 지리 복제본 생성 옵션도 포함돼 있다. 똑같은 지역이나 다른 지역에서 최대 4개의 보조 데이터베이스가 지원된다. 보조 데이터베이스는 읽기 전용 쿼리에 사용할 수도 있다. 기본 데이터베이스를 보조 데이터베이스로 자동 전환해야 할 경우 수동으로 또는 API를 통해 할 수 있다.

클러스트릭스DB
이제는 마리아DB에서 소유한 클러스트릭스DB(ClustrixDB)는 스케일 아웃, 클러스터화 관계형 HTAP(hybrid transaction/analytical processing) 데이터베이스다. 미공유(SN) 아키텍처로 설계됐으며, 마이SQL, 마리아DB와 대부분 호환된다. 필자가 클러스트릭스DB를 리뷰했을 당시에는 공간 확장 유형과 전문(full-text) 검색 지원이 부족했다. 최신 릴리스 기준으로 두 가지 모두 여전히 부족한 상태다.

클러스트릭스DB에 노드를 추가하면 읽기와 쓰기 모두 확장된다. 클러스트릭스DB는 계획되지 않은 구역 장애 도중에 장애 허용이 가능하도록 클러스터를 여러 구역에 걸쳐 배치할 수 있다. 한 독립 연구소에서 실행한 테스트에서(인포월드에서 실행한 것은 아님) 클러스트릭스DB는 초당 4만 건의 트랜잭션을 처리했다. 90% 읽기에 10% 쓰기 작업 기준으로 지연 시간은 15밀리초였다. 이 정도면 전자 상거래가 급증하는 “사이버 먼데이”를 감당할 만한 확장성이다.

코크로치DB
코크로치DB(CockroachDB)는 오픈 소스에 수평 확장 가능한 분산 포스트그래SQL 호환 SQL 데이터베이스다. 구글 클라우드 스패너(Spanner)에 능한 전직 구글 직원이 개발했다. 코크로치DB는 데이터 저장 시스템의 설계를 스패너에서 빌려왔으며, 노드 간 합의에 래프트(Raft) 알고리즘을 사용한다. 덕분에 코크로치DB는 스패너와 동기화하는 다른 것이 필요 없다.

코크로치DB는 트랜잭션을 처리하고 일관되게 키값을 저장하는 공간, 즉 록스DB(RocksDB)위에 구축됐다. 기본적인 설계 목표는 ACID 트랜잭션 지원, 수평 확장성, 그리고 (무엇보다도) 생존 가능성이다. 생존력 높은 ‘바퀴벌레’라는 뜻의 이름을 갖게 된 것도 이 때문이다. 코크로치DB는 기본적으로 직렬화 가능한 고립 모드를 사용한다. 이는 대부분의 다른 데이터베이스에서 실행하는 것보다 더 강력한 형태의 고립이다.

필자가 2018년 초 코크로치DB를 리뷰했을 당시 조인(JOIN) 성능이 별도 좋지 않았지만 이후 많이 보완됐다. 코크로치DB는 클러스터 하나를 여러 개의 가용성 구역에 걸쳐 분산할 수 있도록 지원한다. 또한, 구글 클라우드 플랫폼이나 아마존 웹 서비스(AWS)에 완전한 관리 방식의 클라우드 데이터베이스 클러스터를 제공한다.

구글 클라우드 스패너
구글 클라우드 스패너는 관리 분산 데이터베이스로, SQL 호환성, 관계형 스키마, ACID 트랜잭션, 외부 일관성을 유지하면서도 NoSQL 데이터베이스의 확장성을 지원한다. 스패너는 CAP 정리 해결에 매우 근접해 있다. 스패너는 샤딩되고, 광역 분산, 복제된 상태로, 노드 간 합의에 도달하기 위해 팩소스(Paxos) 알고리즘을 사용한다. 강력한 일관성을 위해 2단계 커밋을 사용하지만, 팩소스 그룹을 트랜잭션의 구성원으로 간주한다. 각 팩소스 그룹은 구성원 100%가 아닌 쿼럼 하나만 있어도 이용할 수 있다.
 
구글 스패너는 내부적으로 사용할 때 99.999% 이상의 가용성을 보여줬다. 즉, 1년간 정지 시간이 5분 미만임을 의미한다. 그 정도면 충분한 성능이므로 프로그래머 대부분은 스패너에 가용성을 강화하기 위한 별도의 코드를 굳이 작성하지 않는다. 스패너는 ANSI 2011 SQL의 일종인 구글 커먼 SQL(Common SQL)을 사용한다. 커먼 SQL은 포스트그래SQL, 마이SQL, SQL 서버나 오라클 데이터베이스에서 사용하는 SQL 문법과 정확히 일치하지는 않는다. 데이터 유형에서 약간 다르고 데이터 조작 분야에서는 더 차이가 두드러진다. ciokr@idg.co.kr


X