NoSQL이라고 일컫는 분산 데이터베이스들이 요즘 트렌드다. 뛰어난 확장성과 가용성으로 각광을 받고 있다. 실제로 여러 소셜게임업체들이 NoSQL을 사용하며, 넷플릭스 또한 NoSQL인 Hbase와 Cassandra를 주요 저장소로 사용한다. 그리고 페이스북의 메신저 시스템 및 실시간 분석 시스템 또한 HBase기반으로 만들어졌다. NoSQL을 사용하면 RDBMS에서의 불편한 것들이 모두 해결되고 높은 확장성을 가진 시스템을 구축할 수 있는 것 같지만 현실은 그렇지 못하다. 대부분의 서비스들은 특수한 경우를 제외하고는 NoSQL이 아닌 RDBMS로 구현되어 있다. 일반적인 시스템을 구현하는데 있어서 NoSQL은 그다지 쓸만하지 않다. Google Trend of NoSQL and RDBMS

대부분의 서비스는 RDBMS를 주요 저장소로 사용한다

아직까지는 구글을 제외한 대부분의 다른 서비스들은 NoSQL을 제대로 사용하고 있지 못하다. 거의 대부분의 기업들은 주요 저장소로 RDBMS를 사용하고 있는 것이다. 대표적으로 몇 가지 사례를 들어보면 다음과 같다.

  • 페이스북은 MySQL을 사용한다. 2012년 3월 기준으로, 페이스북의 MAU는 9억명을 넘었다. 이 정도의 추세라면 2012년 중순에는 10억명을 돌파할 것이라고 한다. 이렇게 엄청난 수의 사용자 트래픽을 감당하기 위해서는 아주 특별한 방법을 통해 데이터를 저장해야 될 것 같지만, 실제로는 MySQL을 사용하여 저장 및 관리한다. 물론 일반적인 방식대로 MySQL을 사용하고 있지는 않다. 데이터는 Key-Value형태로 저장되며, 이 데이터에 대한 Join연산은 웹 서버의 어플리케이션에서 직접 담당한다고 한다. 심지어 최근에 적용된 기능인 타임라인도 MySQL을 사용하여 구현되었다. 앞서 언급된 메세징 시스템이나 실시간 분석 시스템 등의 정도만 NoSQL을 이용하여 구현되었다. 대용량 데이터를 처리하기 위해 데이터를 샤딩하여 여러대의 MySQL 서버에 나누어 저장한다. 페이스북에서도 대부분은 여전히 RDBMS를 쓰고 있는 것이다.

  • 트위터도 MySQL을 사용한다. 트위터의 경우, 많이 들어오는 경우 초당 수 천건의 트윗이 들어온다. 올해 초의 슈퍼볼 결승전 때는 초당 트윗이 만건을 넘기기도 하였다. 이렇게 엄청난 양의 트래픽을 처리하는 트위터 또한 주요 저장소로 MySQL을 사용한다. 처음에는 Cassandra로 바꾸려고 했었지만 결국 MySQL 시스템을 유지하기로 결정하였다. 이렇게 엄청난 수의 트윗에 대한 아이디를 발급하기 위해 Snowflake를 사용한다. 트위터 또한 대용량 데이터를 처리하기 위해 NoSQL을 사용하기 보다는 데이터를 샤딩하여 여러대의 MySQL서버에 저장하는 것이다. 또한 Gizzard를 통해 데이터 레이어를 추상화 하여 MySQL에 데이터를 저장한다. Glizzard라는 미들웨어를 이용하여 RDBMS 이용하면서도 NoSQL에서 제공되는 분산 및 복제 기능을 가질 수 있는 것이다.

  • 텀블러도 아직은 MySQL가 주요 저장소다. Tumblr는 엄격하게 말하면 블로깅 서비스이긴하지만, 체류시간이 페이스북 다음으로 두번째로 긴 소셜 서비스로 소개된다. 이렇게 수많은 사람들이 사용하는 Tumblr에서도 실제 데이터는 MySQL을 사용하여 저장하며, 제한적으로 NoSQL을 사용한다. HBase같은 것들은 URL Shorter나 데이터 분석 등 제한적으로 사용되며, 메인 데이터는 샤딩하여 MySQL에 저장하는 것이다. 데이터를 사딩할때, 시간 순서대로 샤딩하는데, 특정 MySQL 샤드에 로드가 집중된다. 이는 Master-Slave구성으로 자주 일어나는 읽기 연산을 여러 Slave에 분산하는 것으로 해결하였다고 한다.

  • 핀터레스트도 MySQL을 주요 저장소로 사용한다. Pinterest는 특정 주제로 사진을 게시 및 공유 할 수 있는 서비스로, 단기간에 사용자 3000만명을 넘기며, 그것도 80%이상이 여성 사용자를 확보하면서 큰 주목을 받고 있다. Pinterest는 데이터 분석을 위해 Hadoop을 이용 하긴 하지만, 실제 데이터는 MySQL에 저장한다. 역시 샤딩하여 데이터를 저장하고, 그리고 캐시 전략을 잘 사용하여 부하를 해결한다고 한다.

  • 인스타그램은 PostgreSQL을 사용한다. 인스타그램은 1500만명 이상이 사용하는 사진 공유 서비스이다. 그리고 페이스북에 인수되기도 하였다. 인스타그램에서는 RDBMS중 하나인 PostgreSQL을 사용한다. 인스타그램은 초기에 3명의 엔지니어가 개발하였으며, 12개의 EC2를 이용하여 PostgreSQL을 돌린다. PostgreSQL 인스턴스들은 오픈소스를 이용해 Master-Replica 형태로 운영된다. 그 외 시스템은 여러가지 오픈 소스를 이용하여 구성되어 있다. 이미 잘 구현된 기술이 있다면 새로운 기술을 가져다 쓰기보다는 오픈소스를 최대한 가져다 쓰라고 권하고 있다. 인스타그램이 적은 수의 엔지니어로 서비스를 만들 수 있었던 비결일 것이다.

  • 에버노트도 MySQL을 사용한다. 에버노트는 클라우드 노트 서비스이다. 2011년 한해동안 600만명에서 2000만명으로 유저가 증가할 정도로 엄청난 속도로 성장하고 있는 서비스이며 수 많은 노트들을 다양한 채널을 통해 관리할 수 있는 환경을 제공한다. 에버노트는 MySQL을 저장소로 사용하며, NoSQL이 아니라 RDBMS를 사용하는 이유에 대해서도 기술 블로그에 올라왔었다. RDBMS를 사용하는 이유는 ACID 때문이다. NoSQL에서는 일반적으로 높은 레벨의 트랜잭션이 지원되지 않는다.

이처럼 대규모 트랜잭션을 처리해야하는 서비스들도 주요 저장소로 아직은 RDBMS를 사용한다. 페이스북의 메신저 시스템과 실시간 분석 시스템, 텀블러의 주소 길이 단축 시스템 정도만 HBase와 같은 NoSQL을 실험적으로 도입하는 단계이다. NoSQL을 전면적으로 도입하려다 그만 둔 트위터도 있고 심지어 처음부터 잘되어있는걸 가져다 쓰라는 Instagram도 있다. 에버노트는 NoSQL을 쓰지 않는 이유를 명확히 밝혔다. 획장성이 가장 중요한 이슈일 것 같은 많은 서비스들이 아직도 NoSQL을 사용하지 않는 이유는 자명하다.

NoSQL 기술은 아직은 걸음마 단계이다

오픈소스로 공개되어 있는 NoSQL은 굉장히 많다. 많은 기업들이 NoSQL을 도입하기 위해 여러가지 시도들을 하고 있다. 하지만 아직까지 주요 데이터 저장소로 RDBMS를 사용하는 경우가 거의 대부분인 것이 현실이다. 왜 그럴까? 많은 이유가 있을 수 있겠지만, 그 중 중요한 하나는 배포 중인 NoSQL들이 범용적으로 사용하기에는 아직 부족한점이 너무도 많다는 것이다.

서비스를 구현하는데 반드시 필요한 것들이 있다. 바로 인덱싱과 트랜잭션이다. 이것들 없이도 어떻게든 잘 구현할 수 있는 특수목적의 시스템을 제외하면 이런 기능들은 제대로된 서비스를 만들기 위해서 반드시 필요하다. 이런 기능들이 제공되지 않으면 범용적인 사용이 불가능하며, 충분히 추상화되지 못한 상태에서 구상적인 문제를 해결하기 위해 쓸데없는 시간을 보낼 것이다. 현재 배포되어 있는 NoSQL들은 이와 같은 기능이 아예 없거나 제한적이다. Transaction의 경우 NoSQL상에서 분산 트랜잭션을 구현하기 위한 Transaction을 구현하기 위한 시도들이 있었다. Elastras와 CloudTPS이다. 하지만 그다지 효용은 없었던 것 같다.

사실 HBase에는 TransactionalTable 같은 트랜잭션을 제공하기 위한 프로젝트가 존재하기는 한다. 하지만 2011년 초에 사용하려고 써봤지만, 그닥 제대로 동작하는 것 같진 않았다. 심지어 더 이상 프로젝트가 유지 보수 되지 않는다고 한다. 이유는 잘 모르겠지만 Omid라는 프로젝트에서 이 프로젝트가 제대로된 트렌젝션을 지원하지 못한다고 언급하는 것을 보면 그냥 망한 것 같다. 또한 HAcid나 HBaseSI등과 같은 여러가지 프로젝트들도 있다. 하지만 성능이 절대적인 매우 떨어지는 것 뿐만 아니라 성능에 대한 선형 확장성이 없다. 앞서 잠깐 언급한 Omid라는 프로젝트도 엄밀히 말해서는 선형 확장성이 없다고 볼 수 있다. NoSQL을 쓰는 가장 중요한 이유를 무용지물로 만들어버리는 것이다. 구글을 제외한 다른 기업들은 걸음마 단계이다

구글만은 모든 문제를 해결하였다

Transaction과 관련하여 구글이 2010년에 논문을 내놓았다. Percolator인데 BigTable구조의 스토어에서 분산트랜잭션을 구현하는 방법에 대해 기술해 놓았다. 완벽하게 동작히며 선형 확장성도 있다. 이미 구글의 실제 돌아가는 시스템에서 성공적으로 사용되고 있다. HBase상에서 돌아가는 분산트랜잭션인 HBaseSI를 소개하는 프리젠테이션에서는 자신들의 방법이 살짝 부족하긴 해도 알고봤더니 구글의 Percolator와 비슷한 방법이라고 자랑질을 할 정도이니 더 이상 언급하지 않아도 될 것 같다. 그리고 이미 구글의 클라우드 서비스인 AppEngine에서는 BigTable을 기본 데이터 저장소로 사용할 수 있도록 해주며, 인덱싱과 트랜잭션을 완벽하게 제공한다. 바로 구글의 Datastore 서비스인데, Megastore라는 시스템상에서 돌아간다. 이런 기능들이 제공되는 뿐만아니라 여러 데이터베이스간 분산 저장을 한다고하니 정말 대단하다.

결론

거의 대부분의 서비스에서는 NoSQL을 사용하지 않는다. 그리고 그 이유는 트랜잭션과 같은 일반적인 서비스 구현에 필요한 기능들이 전혀 준비되어 있지 않기 때문이다. 사실 트랜젝션이나 인덱싱이 필요하지 않거나 중요하지 않은 특수한 시스템을 구현한다고 한다면, NoSQL에서 제공되는 기능으로도 충분한 것이다. 오히려 NoSQL을 사용하는 것이 시스템 구현에 있어서 편리한 부분이 있을 수 있다. 하지만 일반적인 서비스를 구현하기에 부족한 점이 너무나 많다. 하지만 구글의 경우 모든 것을 해결한 시스템을 BigTable상에 구현했으며 이미 몇 년동안 서비스하고 있다. 내리고 싶은 결론은 두 가지다.

  • 구글을 찬양하자.
  • 바퀴를 만들지 말자.

서비스를 구현하는데 주된 데이터 저장소로 NoSQL 사용을 고려하고 있다면, 구글을 제외한 다른 업체에서 일반적인 서비스를 구현하는데 있어서 NoSQL을 주된 저장소로 사용하고 있지 않다는 사실을 알고 결정하자. 구현하려는 시스템이 NoSQL로 충분히 구현할 수 있고 NoSQL을 이용하여 도움이 될떄 NoSQL을 선택해야할 것이다. 구글이 아니라면 말이다.

사실 현재 일하고 있는 VCNC에서 비트윈이라는 서비스를 돌리고 있는데, 주저장소로 HBase를 쓰고 있다. 여러가지 이유가 있기는 하지만 비트윈에서 가장 많이 사용하는 기능은 메세징이며, 메세징은 서비스의 구현이 그다지 복잡하지 않다. 따라서 NoSQL로도 어느정도 처리가 가능하며, Line에서 주저장소로 HBase를 이용하는 것도 같은 이유에서 일 것이다.