구글은 정말 대단한 회사이다. 구글의 미션은 “세상의 정보를 체계화하여 누구나 편리하게 이용할 수 있도록 하는 것”이며 이를 위해 다양한 서비스를 제공한다. 세상의 거의 모든 데이터를 자신들의 데이터센터에 모으기 위해 노력하고 있으며 다양한 서비스를 통해 원하는 정보에 쉽게 접근할 수 있게 해준다. 이를 위해 다양한 기술을 발전 시켰으며 이제는 거대한 데이터를 처리하여 웹서비스로 제공하는 능력만큼은 어떤 회사도 따라 갈 수 없을 정도가 되었다. 이 글은 구글이 데이터 처리 능력이 얼마나 위대한지 생각을 정리해보기 위한 글이다.

구글의 논문으로부터 시작된 빅데이터 기술들

요즘 빅데이터 기술이 많은 각광을 받고 있다. IT에 관심이 있다면 빅데이터라는 단어와 함께 하둡이라는 오픈소스에 대해 언급하는 것을 많이 접했을 것이다. 엄청나게 많은 데이터를 처리하고 분석하기 위해 실제로 가장 널리 사용되는 솔루션이 하둡이며 HDFS, MapReduce, HBase와 그 외 여러가지 다른 솔루션들을 제공한다. 이런 기술들이 실제 서비스에 적용되어 사용하기 시작한지 그다지 오래되지 않았고 이제야 널리 상용화 되는 단계라고 볼 수있다. 이 기술들은 구글이 발표한 논문들로부터 시작되었다. 더욱 놀라운 것은 이 논문들이 발표한 시점에 구글은 이미 상용에서 널리 사용하고 있었다는 것이다.

  • HDFS: Hadoop File System은 대용량 데이터를 저장하기 위한 분산 파일시템이다. 거대한 데이터를 여러 컴퓨터에 나누어 저장하는 파일시스템 레이어를 제공하여 데이터의 양이나 시스템의 연산 능력에 선형확장성을 부여한다. HDFS는 구글이 2003년에 발표한 Google File System (GFS)을 클론한 것이다.
  • MapReduce: MapReduce는 큰 태스크를 분산시스템에서 효과적으로 처리하기 위한 기술이다. 비교적 간단한 연산을 구현하면 수 많은 컴퓨터를 이용하여 일을 분산 처리할 수 있도록 해준다. 2004년에 구글이 같은 이름으로 낸 논문이 있으며 하둡의 MapReduce는 구글의 MapReduce를 클론한 것이다.
  • HBase: HBase는 HDFS상에서 구현된 NoSQL이다. 여러 업체에서 제한된 용도로 사용된다. (비트윈에서는 메인 데이터베이스로 사용한다) HBase 또한 구글의 2006년에 발표한 BigTable을 클론한것이다.

위에서 언급된 하둡 솔루션들은 그에 대응하는 구글의 구현체와 설계가 매우 유사하다. 이 기술들이 개발이 시작된 시기도 구글이 논문을 발표한 시기 이후다. 실제로 Doug Cutting이 Nutch라는 오픈소스 검색엔진 크롤러를 만들다가, 구글에서 발표한 GFS, MapReduce 논문을 보고 데이터를 저장하고 처리하는 부분을 만들었는데, 나중에 이 부분을 Yahoo!와 함께 따로 분리하여 시작된 프로젝트가 바로 하둡이다.

그런데 구글의 논문들의 발표 시기를 살펴보면 지금으로부터 10년이나 된 것도 있다. 그런데 논문을 읽어보면 구글이 구현 후 서비스에 적용하여 어느 정도 돌려보고 실제 사용성이 입증되고 나서 발표한 것이라는 것을 알 수 있다. GFS 논문에는 GFS를 구글 서비스 백엔드에 적용하면서 많은 문제에 직면했었고 오랜시간동안 Linux코드를 고쳐가면서 적용했다는 이야기가 있다. MapReduce 논문에는 그 당시에 이미 수 많은 MapReduce 프로그래밍 매일 매일 구글 클러스터에서 실행되고 있다는 내용이 있다. BigTable논문의 경우 2년 반동안 디자인 개발 하고 실제 서비스에 배포까지 했었다는 이야기가 있다. 구글이 이 논문들을 발표한 시점에 구글은 이미 이 기술들을 서비스에 적용할 정도로 완성도 있었다는 것이다. 다시 말해, 하둡은 구글은 이미 서비스에 적용한 기술들의 논문을 보고 시작한 것이며, 구글이 아닌 다른 곳에서는 이제서야 본격적으로 사용을 시작하고 있는 것이다.

구글의 막강한 NoSQL 기술들

일반적인 웹 서비스를 구현할때에는 RDBMS가 널리 사용된다. 트래픽이 많은 글로벌 서비스들도 NoSQL과 같은 분산데이터베이스를 메인 서비스 개발에 사용하지 않는다. 여러가지 이유가 있겠지만 NoSQL이 트랜잭션이나 인덱싱이과 같은 기능들이 제대로 제공되지도 않아 어플리케이션 개발에 어려운 점이 많고, 신경써서 개발하면 RDBMS로도 확장성 있는 시스템을 충분히 개발할 수 있기 때문이다. 일반적인 NoSQL에서는 Row단위의 ACID 정도만 제공하는 것이 일반적이므로, 복잡한 서비스를 개발하기에는 불편한 점이 많다.

하지만 NoSQL과 같이 높은 확장성과 안정성을 보장하면서도 RDBMS 처럼 트랜잭션이나 인덱싱 같은 어플리케이션 개발에 유용한 기능이 있는 데이터베이스가 있다면 정말 좋을 것이다. 어플리케이션 레벨에서 확장성에 대한 신경쓰지 않아도 되고 일반적인 어플리케이션 구현에도 사용할 수 있을 것이다. 이런 데이터베이스를 만들어내기 위한 방법은 여러가지가 있을 수 있겠지만, 그 중 하나는 NoSQL상에서 트랜잭션이나 인덱스를 구현하는 것이다. 이를 위해 HBase상에서 트랜잭션을 구현하기 위한 여러 노력들이있었지만 대부분 실패했다고 볼 수 있다. HBase에서 트랜잭션을 제공하기 위한 프로젝트인 HAcid나 HBaseSI는 절대적인 성능이 크게 떨어질뿐만 아니라 선형 확장성도 없으므로 실제 서비스 구현에 사용할 수 없다. 아마존의 DynamoDB에도 트랜잭션 구현체가 있지만 성능이 매우 떨어지고 실제 서비스에 사용할 정도인지는 잘 모르겠다. 결국 많은 업체에서 메인 데이터베이스로 RDBMS를 이용하고 데이터를 잘 샤딩하는 방법으로 확장성있는 시스템을 만드는 방법을 채택한다. 하지만 구글은 이미 오래전에 이 문제를 해결하였다.

Percolator는 구글이 2010년에 발표한 BigTable상에서 돌아가는 트랜잭션 프로젝트이다. 검색결과 인덱스를 점진적으로 업데이트 하기 위해 Percolator를 구현 하였다. BigTable도 일종의 NoSQL이며 분산데이터베이스이므로, NoSQL에서 동작하는 트랜잭션을 구현했다고 보면 된다. Percolator 또한 앞서 살펴본 프로젝트들 처럼 논문이 발표된 시점에 이미 실제 돌아가는 서비스에 적용하여 사용 중 이었다. Percolator를 실제로 적용봤더니, MapReduce를 통해 배치로 인덱스를 업데이트했던 것에 비해 인덱스된 문서의 평균 나이가 50%정도로 줄어들었다는 내용이 있다. 구글은 이미 수 년 전부터 NoSQL상에서 트랜잭션을을 구현하여 실제 서비스에 적용하여 사용하고 있는 것이다.

Datastore를 보면 더욱 대단하다. Datastore는 구글의 App Engine이나 Compute Engine에서 사용이 가능한 데이터 저장소 서비스이다. 엔티티 모델을 제공하며 트랜잭션 뿐만 아니라 인덱싱 기능도 제공한다. 게다가 지리적으로 떨어진 여러 데이터센터 간 복제 저장이 되므로 높은 안정성을 보장한다. 이것은 구글이 2011년에 발표한 Megastore 위에서 구현 된 것 이 Megastore가 트랜잭션과 여러 데이터센터간 복제를 담당하는 것이다. Datastore가 Megastore상에서 구현되었다는 것은 구글 개발자 블로그 글에서 확인할 수 있으며, 2013년 Google I/O에서의 발표 자료에서도 언급되어 있다. 구글 Datastore는 오래전부터 App Engine상에서 사용에서 사용이 가능했으며, 최근에는 Compute Engine에서도 사용 가능하게 되었다. 구글은 이미 이런 기술들을 사내에서 널리 쓰고 있을 뿐만 아니라 App Engine이나 Compute Engine에서 서비스로 제공할 정도의 수준인 것이다.

차원이 다른 기술적인 우위

지금 까지만 정리한 내용만해도 구글의 기술력은 엄청나다. 그런데 구글은 이보다도 이미 더욱 진보된 기술을 개발하여 사용하고 있다. 구글에서 비교적 최근에 공개한 Colossus와 Spanner는 현재 구글의 기술이 구글이 아닌 외부의 분산시스템 기술들과 얼마나 큰 격차가 나는지 여실히 보여주는 좋은 예이다.

Colossus는 GFS의 단점을 보완하고자 만든 새로운 버전의 GFS이다. Colossus는 2009년 Jeff Dean의 프리젠테이션에서 처음으로 잠깐 언급되었고, 2010년 Faculty Summit에서 발표된 Andrew Fikes의 프리젠테이션에 특성에 대해 간단히 소개 된적이 있었다. GFS와 다른 가장 큰 특징은 메타데이터를 샤딩하여 여러 컴퓨터에 나누어 분산 저장할 수 있게 되었다는 것인데, 이는 매우 큰 규모로의 확장을 가능하게 해주며, 좀 더 작은 파일을 사용할 수 있게 하여 어플리케이션 작성을 좀 더 단순하게 할 수 있도록 해준다. 이에 반해, HDFS에서는 하나의 중앙 서버에서 메모리상에 메타데이터를 관리하는데, 이에 대한 한계에 대해 서술한 글이 있다. 이 글에서는 데이터량이 커져 파일이 굉장히 많아지고, 클라이이언트가 매우 많아지는 경우, 단일 네임노드 아키텍처가 갖는 한계에 대해 잘 서술되어 있는데, 이는 Colossus에서는 해결된 문제이다. 페이스북의 메시징 시스템에서는 이 문제를 여러 HDFS/HBase클러스터를 두는 것으로 해결 하였지만, 구글은 시스템 자체를 고친 것이다. 또한 Colossus에서 제공하는 Reed-Solomon error correction은 페이스북이 2010년부터 HDFS Raid에 적용하려고 노력하고 있지만 아직 이슈(MAPREDUCE-1969)는 해결되지 못했고 오픈 상태이다.

Spanner는 2012년에 발표된 구글의 새로운 분산 데이터베이스이다. 하지만 Spanner에 대한 첫 언급은 Jeff Dean의 2009년 프리젠테이션에서 였다. 역시 구글은 발표하기 한참 전부터 Spanner를 개발하고 있었던 것이다. Spanner는 Colossus상에서 구현된 데이터베이스인데, 지리적으로 멀리 떨어진 여러 데이터센터간 운영이 가능하다. 여러 데이터센터간 운영되는 분산 환경에서, 높은 수준의 트랜잭션 뿐만 아니라 Semi-Relational 모델과 일종의 테이블 구조, SQL을 확장한 질의 언어까지도 제공한다. 일반적으로 NoSQL에서 데이터 모델을 어떻게 가져가느냐가 큰 문제 중 하나인데, 앞서 소개한 Datastore에서는 부모/자식 관계를 가지는 엔티티 모델을 제공하여 이를 해결하였다. 비트윈에서 HBase를 사용할때에도 Row-Column을 추상화하여 Tree형태의 데이터 구조 API를 만들어 사용하는데, 구글의 Spanner에서는 이를 한참 뛰어넘은 것이다. Spanner에 대한 자세한 설명은 네이버의 개발자 블로그 글에서도 다룬적이 있다. 이 것 또한 이미 상용 서비스에 적용하여 사용하고 있는데, 이미 광고 플랫폼에 적용되어 있으며, Gmail, Google 캘린더에 적용할 예정이라고 한다.

결론

구글은 정말 대단한 회사이다. 보시다시피 다른 회사에 비해 엄청나게 뛰어난 데이터 처리 기술을 가지고 있다. 특히 지리적으로 멀리 떨어진 여러 데이터센터간 분산 저장 하는 것은 다른 업체에서는 거의 하지 못하는 일이다. Cassandra를 이용하여 여러 데이터센터간 배포하는 경우가 있기는 하지만, Strong Consistency를 만족시키면서 높은 수준의 트랜잭션을 제공하면서것과는 엄청난 차이가 있다. 이 처럼 다른 곳에서는 넘어서지 못한 레벨의 기술들을 고안하여 구현한지는 오래고 이미 상용 서비스에 적용하여 사용하고 있는것이 매우 놀랍다. 구글이 뛰어나기도 했지만 이런 해결책들이 필요한 문제를 많이 맞닥뜨리는 환경을 겪어왔기 때문에 크게 발전 할 수 있었던 것 같다. 그리고 구글이 뛰어난 기술을 가질 수 있었던 것은 문제가 생겼을때 기술적으로 정말로 올바른 방법을 찾기위해 지속적인 노력을 계속해왔기 때문이라고 생각한다. 물론 모두가 바퀴가 없다고 해서 바퀴를 만들 필요는 없다. 이미 존재하는 바퀴를 잘 조합해서 잘 돌아가는 시스템을 만드는 것이 옳은 방향인 경우가 대부분이며 뛰어난 능력이기도 하다. 하지만 좀 더 미래지향적인 방법을 선택하여 새로운 기술을 만들고 실제 서비스에 적용하여 성공시킬 수 있다면 정말로 뛰어난 기술지향회사라고 볼 수 있을 것이다. 뭐, 구글 처럼 돈 많이 벌면 이런 것에 투자할 여력도 많겠지. 역시나 결론은 구글 찬양.