거대한 변화, NewSQL vs NoSQL

임백준

MIT 교수인 마이클 스톤브레이커(Michael Stonebraker)는 관계형 데이터베이스 시스템에 대한 최고 권위자중 한 명이다. 그가 1973년에 개발한 인그레스(Ingres)라는 데이터베이스 시스템은 당시까지 추상적인 개념으로만 존재하던 관계형 데이터베이스를 최초로 구현한 사례였다.

인그레스가 사용한 비트리(B-trees), 제약조건(constraints), 트리거(trigger)와 같은 기법은 오라클, DB2, 사이베이스로 이어지는 주요한 데이터베이스 시스템 설계에 많은 영향을 끼쳤다. 스톤 브레이커 교수가 인그레스 데이터베이스를 개발하면서 동료들과 함께 작성한 코드는 훗날 사이베이스와 마이크로소프트 SQL 서버에서 사용되기도 했다.

오랫동안 캘리포니아 버클리 대학에서 교수생활을 하던 그는 2001년에 MIT로 자리를 옮겨서 지금까지 연구와 벤처회사 등을 통한 왕성한 활동을 벌이고 있다.

스톤브레이커 교수는 지난 12월 5일에 업로드가 된 팟캐스트 방송 “소프트웨어 엔지니어링 라디오”에 출연해서 상당히 흥미로운 인터뷰를 했다.

최근에 업계에서는 NoSQL이 많은 주목을 받고 있는데, 그는 이러한 흐름에 대해서 설득력 있는 비판을 가하면서 전통적인 관계형 데이터베이스를 새롭게 구축하는 전략을 의미하는 NewSQL이라는 개념을 주창했다. 귀가 따가울 정도로 들려오는 NoSQL이라는 ‘버즈워드(buzzword)’ 때문에 어지러움을 느꼈던 사람이라면 스톤브레이커 교수의 차분한 분석을 경청해볼 만하다.

스톤브레이커 교수는 NoSQL이라는 흐름이 형성되기 전인 2006년에 논문을 발표해서 전통적인 방식의 관계형 데이터베이스 아키텍처가 설 자리를 잃고 있다고 주장한 바 있다. 이번 인터뷰에서는 그는 한 걸음 더 나아가서 전통적인 아키텍처가 설 자리는 이제 어디에도 없다고 주장했다. 이유는 이렇다.

데이터베이스 시장은 크게 3개 영역으로 나눠진다. 첫 번째는 데이터 분석과 리포트를 위한 데이터 웨어하우스 영역이다. 두 번째는 일반적인 트랜잭션 처리를 다루는 OLTP(Online Transaction Processing) 영역이다. 마지막 세 번째는 기존의 관계형 데이터베이스와 패러다임을 달리하는 NoSQL, 그래프 데이터베이스, 배열 데이터베이스, 하둡 등으로 이루어지는 백가쟁명의 영역이다.

세 번째 영역에서 전통적인 관계형 데이터베이스 아키텍처가 설 자리가 없다는 사실은 자명하다. 패러다임 자체가 다르기 때문이다. 스톤브레이커 교수에 의하면 첫 번째 데이터웨어하우스 시장은 속도가 50배에서 100배 정도 더 빠른 열 중심 데이터베이스로 이동하고 있고, 두 번째 OLTP 시장은 메모리 가격 하락과 맞물려 차츰 인메모리(in memory) 데이터베이스로 변해가고 있다. 전통적인 아키텍처는 이렇게 데이터베이스 시장을 구성하는 세 개 영역 모두에서 설 자리를 잃었기 때문에 존재의 의미를 상실했다.

여기에서 ‘전통적인’ 아키텍처란 바로 스톤브레이커 교수 자신이 인그레스를 통해서 출발신호를 알린 관계형 데이터베이스들의 공통적인 아키텍처를 의미한다. 오늘날 가장 널리 사용되고 있는 오라클, 사이베이스, DB2, SQL 서버, MySQL 등이 전통적인 아키텍처를 사용하고 있음은 물론이다.

이러한 전통적인 아키텍처는 기본적으로 데이터를 행(row) 중심으로 저장한다. 이러한 데이터는 일정한 크기의 데이터 블록으로 묶여 하드디스크에 저장되는데, 데이터 블록의 물리적인 모습은 회사마다 다르다. 데이터베이스 시스템이 하드디스크에서 데이터를 읽으면 메인메모리에 있는 캐시인 버퍼풀(buffer pool)에 저장하고, 멀티쓰레드와 관련된 오류를 피하기 위해서 행 수준의 잠금장치(record level lock)를 이용한다.

또한인덱스를 구현하기 위해 비트리(B-tree)를 사용하고 질의문으로 SQL을 이용하고, 최적의 성능을 위해 내부적으로 질의 최적화기(query optimizer)를 이용한다.

스톤브레이커 교수가 전통적인 아키텍처를 구현한 데이터베이스가 동작하는 과정을 정밀하게 분석한 결과에 따르면 데이터베이스가 가장 핵심적인 동작인 데이터 레코드를 찾아서 “읽고 쓰는데” 소모하는 시간은 놀랍게도 10% 정도에 불과하다. 90%의 시간이 메모리에서 버퍼풀을 관리하거나 멀티쓰레딩과 관련된 동작을 제어하는데 사용되기 때문이다.

스톤브레이커 교수가 주장하는 NewSQL의 핵심은 새로운 아키텍처를 도입해서 이렇게 CPU 사이클을 심각한 수준으로 낭비하는 오버헤드를 제거하는데 있다.

새로운 아키텍처를 구성하는 요소는 크게 세 가지 정도로 생각해볼 수 있다. 첫 번째는 데이터를 하드디스크가 아니라 메모리에 저장함으로써 디스크에 접근하는 I/O 연산을 최소화하고, 그와 동시에 버퍼풀이라는 중간 단계를 완전히 제거하는 것이다.

인메모리 데이터베이스의 접근방식을 따르는 것으로 볼 수 있다. 두 번째는 멀티쓰레딩과 관련된 오버헤드를 제거하기 위해 전과 다른 방식을 사용하는 것이다. 복잡하게 들리긴 하지만 멀티버전 동시성 통제(multi version concurrency control)라는 방법과 타임스탬프 오더링(timestamp ordering)라는 방식이 있다.

앞의 것은 일반적인 컴퓨터 프로그래밍 진영에서 활발하게 논의되고 있는 소프트웨어 트랜잭션 모델(STM)과 비슷한 개념이고, 뒤의 것은 스톤브레이커 교수가 개발한 최신형 데이터베이스인 볼트디비(VoltDB)에서 이용하고 있는 방법이다.

이러한 방법을 통해서 버퍼풀 관리와 멀티쓰레딩 코드로 인해서 발생하는 오버헤드를 제거하면 데이터베이스의 성능이 과거에 비해서 비교할 수 없을 정도로 향상된다. NewSQL의 핵심은 이러한 아키텍처의 재구성을 통해서 성취하는 혁명적인 성능개선에 놓여 있다.

스톤브레이커 교수는 현재 MIT 대학에 있는 데이터베이스 과목들이 대부분 (이제는 쓸모가 없어진) 전통적인 아키텍처를 가르치는데 시간을 소모하고 있다고 지적하면서 대신 칼럼 스토어(column stores), 인메모리 데이터베이스, 배열 데이터베이스, 그래프 데이터베이스, NoSQL 시스템 등에 대해서 공부하는데 더 많은 시간을 할애해야 한다고 말한다.

이러한 새로운 접근방식들은 모두 NewSQL의 흐름을 구성하는 핵심적인 요소라고 볼 수 있다.

NoSQL에 대한 그의 비판은 ‘NoSQL’의 정확한 이름은 아마도 ‘NotYetSQL’이라고 봐야 할 것이라는 주장으로 압축된다. 스톤브레이커 교수가 보기에 NoSQL 시스템이 전통적인 관계형 데이터베이스의 한계를 통렬하게 지적하고 ‘SQL’을 부정하면서 출발했지만, 시간이 흐르면서 차츰 전통적인 관계형 데이터베이스의 틀 안으로 되돌아 올 수밖에 없다.

하둡만 해도 그렇다. 하둡은 가장 아래에 있는 파일시스템을 의미하는 HDFS, 중간에 존재하는 알고리즘인 맵리듀스(map reduce), 그리고 질의문을 구성하는 하이브(Hive)와 같은 테크놀로지, 이렇게 세 개 계층으로 구성된다.

하둡을 사용하는 대표적인 기업인 페이스북은 처음에 하이브를 이용해서 성공을 거두었지만, 얼마 지나지 않아서 HDFS와 맵리듀스가 기본적으로 배치처리를 중심으로 설계되었으며 그에 따르는 많은 오버헤드를 안고 있기 때문에 성능을 저하시킨다는 문제에 봉착했다.

스톤브레이커 교수는 페이스북이 발생시키는 트래픽의 95%가 SQL과 다를 것이 없는 하이브를 통해서 발생하는 트래픽이고 겨우 5% 정도만 맵리듀스를 통한 병렬처리의 덕을 볼 수 있는 트래픽이라고 지적한다. 이것은 곧 페이스북이 하둡이라는 묵직한 테크놀로지를 통해서 이득을 볼 수 있는 부분이 5%에 불과하다는 뜻이다.

나머지 95% 부분은 하둡을 사용하기 때문에 오히려 성능이 저하된다. 이런 의미에서 하둡은 병렬처리가 가능한 최신의 관계형 데이터베이스의 성능에 미치지 못한다.

페이스북은 이러한 단점을 극복하기 위해서 최근에 맵리듀스 계층을 제거한 프레스토(Presto) 엔진을 도입했는데, 스톤브레이커 교수는 이러한 엔진이 결국 기존 데이터베이스 엔진과 별로 다를 바 없다고 이야기한다. 이러한 엔진이 개념적으로 NoSQL이 아니라 NewSQL의 범주에 속한다고 판단하는 것처럼 보인다.

영어로는 흔히 “embarrassingly parallel”이라고 표현하는, 우리말로 하자면 황당할 정도로 당연히 병렬처리를 필요로 하는 소수의 영역을 제외하면 NoSQL이나 하둡이 불필요한 오버헤드에 불과하다. 그렇기 때문에 NoSQL의 구성요소들은 새롭게 구현되고 있는 데이터베이스 아키텍처로 수렴할 수밖에 없다. SQL의 품으로 되돌아오는 것이다.

NoSQL이든 NewSQL이든 70년대 이후로 40년이 넘게 사용되어온 전통적인 관계형 데이터베이스의 아키텍처가 완전히 새로운 방식으로 재구성되고 있다는 사실만큼은 누구도 부정할 수 없다. 새로운 아키텍처의 모습은 몽고DB와 같은 NoSQL일 수도 있고, Neo4j와 같은 그래프 데이터베이스일 수도 있고, SAP의 해나(Hana)와 같은 인메모리 데이터베이스일 수도 있다. KDB나 테라데이터(Teradata)와 같은 열 중심 데이터베이스일 수도 있다.

NoSQL이라는 버즈워드가 귀에서 윙윙거린다고 해서 무조건 수용을 하거나 배척할 것이 아니라, 이렇게 전면적인 변화가 일어나고 있는 지형에서 NoSQL이 점하는 위치가 어디인지를 생각하며 큰 그림을 보려고 노력하는 것이 필요하다. 그러한 노력을 통해서 자신이 현재 수행하고 있는 프로젝트와 미래의 프로젝트를 위해서 좋은 선택을 내릴 수 있으리라고 생각한다.

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.