nosql 등장배경

NoSQL

Not-Only-SQL이라고도 표현되는 NoSQL은 2009년 이후 Last.fm과 Facebook, Twitter, Google Analytics 등에서 데이터의 폭발적인 증가로 빅데이터 분산 처리 및 저장 기술과 함께 발달된 분산 데이터베이스 기술이다. 다양한 빅데이터 처리기술 가운데 NoSQL은 비관계형(non-relational) 데이터 저장소(data store) 역할을 한다. 관계형 데이터베이스(RDB, Relational Database)와 같이 데이터베이스를 구축하지만 사용되는 용도가 다르므로 NoSQL 적용을 고려하고 있다면 RDB와 NoSQL의 정확한 용도를 이해하고 접근할 필요가 있다.
NoSQL을 수용함으로써 기대할 수 있는 효과는 HashMap처럼 키밸류(KeyValue) 형식의 데이터를 분산ㆍ저장함으로써 기존 관계형 데이터베이스에서는 처리하기 힘들었던 테라바이트에서 엑사바이트 단위의 데이터베이스 구축이 가능한 점이다. 키밸류 속성정보를 메타데이터 구조정보에 별도로 보관하기 때문에 데이터 용량이 방대해도 빠르게 조회할 수 있으며, 데이터를 다수의 서버에 분산ㆍ저장하기 때문에 동시 접속 클라이언트 수가 많더라도 디스크 및 네트워크 병목 현상 없이 우수한 성능의 서비스를 기대할 수 있다.
하지만 RDB에서처럼 각 필드 간 관계를 정의하기보다 키밸류 형식의 원자 데이터를 분산해서 응집화(Aggregation)와 역정규화(Denormalization)로 비정형 데이터를 쌓아가는 점에 주의할 필요가 있다. 다시 말해 조인(join)과 같은 복잡한 작업을 서버 측에서 수행하기엔 적합하지 않기 때문에 NoRelation이라는 이름도 어울리지만, NoSQL로 불리는 이유를 염두에 둬야 한다.

CAP

SQL을 사용하는 모든 RDB에는 ACID라는 속성이 존재한다. ACID1)는 데이터베이스 트랜잭션이 정상적으로 처리되기 위한 4가지 필수 속성인 Atomicity, Consistency, Isolation, Durability를 말한다. NoSQL은 이러한 필수 조건을 과감히 버리고 에릭 브레워2)의 CAP 정리에 기반을 둔다. SQL과 관계형 데이터베이스의 기본 이론인 ACID까지 배제한다는 의미에서 NoSQL이란 이름을 붙이지 않았나 싶다. NoSQL에 다시 SQL 언어를 접목시키는 프로젝트가 진행되고 있다. CAP(Consistency, Availability, Partition Tolerance)은 사실 NoSQL 기술이 화두가 되기 훨씬 전인 2000년에 발표되었으며, 분산(distributed) 또는 확장(scalable) 시스템을 위한 정리였다. 하나의 공유된 데이터 시스템은 이 중 최대 2개의 CAP 속성만 만족할 수 있다는 것을 골자로 한다.

• Consistency: 모든 노드가 동시에 동일한 데이터를 조회함을 보장
• Availability: 성공 또는 실패를 막론하고 모든 요청에 대한 응답을 보장
• Partition Tolerance: 미리 예측할 수 없는 데이터 손실 또는 시스템 구성 요소 중 일부의 실패(Failure)에도 전체 시스템은 항상 정상 작동을 보장

2개의 속성을 만족해야 하므로 시스템은 CP, AP, CA 타입으로 나뉜다. Coda Hale3)은 ‘분산 데이터베이스에서 Partition Tolerance가 필수적인 요소’라고 강조한다. 이론적으로는 CA도 가능하지만 현실적으로 최소한의 서비스 성능과 응답 속도를 기대하기 어렵다고 한다. 정리하면 NoSQL은 크게 CP와 AP 시스템으로 나뉜다.

[그림 Ⅱ-2-1] CAP 정리

CP는 데이터의 무결성을 만족하고 시스템 일부의 오류를 허용하기 위해 사용자 쿼리 응답에서 지연이 생길 수 있다. CP에는 다음과 같은 NoSQL이 있다.

Redis, MemchacheDB, BerkleyDB, Scalaris, Bigtable, HBase, Cloudata, HyperTable, MongoDB, Terrastore

AP는 서비스 가용성을 만족하는 동시에 성능을 위해 데이터 무결성을 희생한다. 그러므로 사용자 쿼리 응답에 지연은 없지만, 일정시간 무결성이 보장되지 않을 수 있다. AP에는 다음과 같은 NoSQL이 있다.

Dynamo, Voldemort, Tokyo Cabinet, KAI, Cassandra, SimpleDB, CouchDB, Riak

스스로를 CA로 일컫는 NoSQL도 있다. Neo4j나 FlockDB같은 Graph 데이터베이스는 CP나 AP 범주에 들어가지 않는다. HP의 버티카(Vertica)와 같이 분산 데이터베이스 환경에 SQL을 탑재한 클라우드 DB 제품도 대부분 CA에 해당한다.

NO SQL의 필요성

NoSQL 활용

NoSQL의 자세한 설명에 들어가기에 앞서 자신이 구성할 시스템에 NoSQL이 과연 적합한지를 확인해 보자. NoSQL이 유행하기 때문인지, 나중에 커질 데이터를 미리 대비하기 위해서인지 요즘은 데이터가 조금만 늘어나도 NoSQL을 접목하려 한다. 하지만 대부분 생소한 용어와 개념, 운영 기술의 어려움 때문에 제대로 경험하지 못하거나, 중간에 다른 데이터베이스 시스템으로 교체하는 사례도 많다. NoSQL 제품별로 동작 방식이나 활용 용도가 다름에도, 데이터 모델이나 시스템 요구사항에 맞지 않는 NoSQL을 접목시킨 후 원하는 쿼리 성능이 나오지 않아 실망부터 하는 경우도 있다. 이러한 자원낭비를 피하기 위해 NoSQL의 적절한 활용 사례부터 알아보자.

왜 필요한가?

계획하는 애플리케이션 또는 비즈니스 모델을 관계형 데이터베이스에서 처리할 수 있을까? 데이터베이스 시스템을 RDB에서 NoSQL로 변경함으로써 얻을 수 있는 가장 큰 이점은 분산 환경이다.샤딩4)(sharding) 기술로 데이터를 하나 이상의 서버로 분산시킴으로써 그만큼 스토리지 공간도 늘어나게 되고, 한 서버에 집중되던 디스크 및 네트워크 I/O의 분산으로 전체적인 데이터 처리 스루풋도 올라간다. CAP 정리에서 보듯이 노드 하나가 단절되어도 나머지 노드가 클라이언트 요청에 응답하므로 서비스 가용성도 올라간다. 구축하려는 애플리케이션이 단일 노드 RDB에서 감당할 수 없을 정도의 데이터를 처리해야 한다면, NoSQL을 고려해야 할 것이다. NoSQL은 요구되는 자원량과 가용성에 따라 확장 가능한 장점도 있다.
과거, 빅데이터 DW(data warehouse) 구축 프로젝트 중 전처리 단계에서 DW로 데이터를 로드하는 과정이 있었다. A라는 RDB를 DW용 데이터베이스로 사용해 매시간 300GB(약 백만 레코드)의 데이터를 로드했다. 여기서 최대 동시 발생 세션은 약 500개 내외였는데, DB가 부하를 견디지 못하고 커넥션 자체를 맺지 못하는 이슈가 발생했다. 이때 NoSQL을 적용해 필요한 만큼 클러스터를 확장해 문제를 해결할 수 있었다. 커넥션을 여러 대의 서버에서 분산 처리함으로써 데이터가 원활하게 로드되면서 RDB에서 발생했던 문제가 해결됐다.

NoSQL 적용시 고려사항

다른 빅데이터 기술과는 다르게 분산 데이터베이스는 대체 가능한 다른 유형의 데이터베이스 기술들이 존재한다. 물론 대표적으로 RDB가 그 중 하나다. 그럼에도 분명한 사유 없이 NoSQL을 적용하려 한다. NoSQL 적용 이유를 나중에 들어보면 “그냥 기술 보유 차원에서 써봤다, 검색해 보니 이 솔루션의 읽기 속도가 빠르다고 하더라, 고객이 원해서 그랬다, 마케팅 차원에서” 등이다. 이렇게 해서 개발된 애플리케이션은 초기 생산 비용이 적지 않게 발생했을 테고, 제 역할을 하지 못하는 분산 데이터베이스는 결국 제 성능을 내지못할 것이다. 분산 데이터베이스를 적용할 때는 설계 단계에서 충분한 조사와 전문가의 조언을 토대로 타당한 솔루션을 찾을 필요가 있다. NoSQL을 도입한 후 다음과 같은 리스크를 경험할 수 있다.

비용

빅데이터 관련 제품 소개 사이트를 방문해 보면 대부분 ‘오픈소스, 저비용’이라는 배너가 눈길을 끈다. 제품 설명에 ‘Commodity Hardware’에서 작동한다는 문구도 자주 보인다. 하지만 분산 데이터베이스에서 오픈소스 소프트웨어는 결코 저비용으로 도입ㆍ운영할 수 있는 솔루션이 아니다. 여기서 말하는 범용 서버는 해당 제품을 운용하기 위한 최소한의 사양이지, 다루고 싶은 대용량 데이터를 처리하는데는 충분하지 않다. NoSQL 클러스터 구성에는 요구되는 디스크와 메모리 사양이 기본적으로 높다. 시간당 300GB씩 유입되는 데이터를 보관하려면 충분한 스토리지가 필요하다. 캐시나 memstore 등의 기술로 메모리를 집약적으로 사용하는 NoSQL 솔루션이 많고, 메모리 기반 데이터베이스는 더욱 그렇다. 일부 NoSQL은 샤딩 재구성과 Major Compaction 등과 같이 데이터 구조가 변경되거나 이동되는 과정이 있다. 이때에도 충분한 메모리와 CPU 코어 수, 네트워크 처리 속도가 요구된다. 성능을 하나하나 늘려가다 보면 고성능 서버가 돼 있을 것이다. 복합적인 서버의 호스팅 및 운영 비용도 간과하면 안된다.
오픈소스가 아닌 상용 소프트웨어라면, 추가 비용이 든다. 컨설팅부터 설치, 교육, 라이선스, 장비 비용까지 모두 비용 리스크에 포함된다. 라이선스나 장비비용 대신 보관중인 데이터량, 네트워크 처리량, 트랜젝션 수와 같이 정략적인 요금이 책정되는 제품도 있으므로 제품 선택 시 유의해야 한다.

지원

상용 솔루션을 사용하다 문제가 발생하면 전화 한 통화로 전문가의 지원을 받을 수 있다. 문제 유형에 따라 바로 해결할 수도 있고 한 달이 걸릴 수도 있지만, 최대한의 고객 만족을 위해 최선을 다하는 기술 지원자들이 있다. 따라서 도입사는 비즈니스 모델에 집중할 수 있다.
오픈소스 솔루션에는 전문가 대신 ‘커뮤니티’ 지원 창구가 있다. 사용자 문서, 메일링 리스트, 블로그, 동료 기술자 등이 있지만, 여기서 원하는 해결책을 찾기 위해서는 ‘시간’이라는 소중한 자원이 필요하다.

제약된 쿼리

분산 데이터베이스는 역정규화와 응집화를 기본 개념으로 비정형 데이터 구조를 구성하기 때문에 애플리케이션측에서 join과 같은 복잡한 쿼리는 수행하기 어렵다.

데이터 모델링

NoSQL에는 데이터 모델이 없다고 생각할 수도 있지만, 실제로는 그렇지 않다. 키-디자인 또는 컬럼-디자인 같은 데이터 모델링은 NoSQL 성능과 데이터 크기에 직접적인 영향을 주므로 전문성이 필요한 부분이다. RDBMS에 익숙한 개발자에겐 다소 생소한 부분일 수도 있다.

NoSQL 선택

NoSQL을 학습하고 활용할 때 어려운 점은 매우 다양한 종류와 제품이 있다는 것이다. 아쉽게도 관계형 데이터베이스에서의 Oracle 같은 올인원 제품은 없다. 각기 그 유형과 용도, 장단점이 다르기 때문에 각 제품을 충분히 숙지하고 있어야 한다. 하지만 [그림 Ⅱ-2-2]처럼 너무도 많은 NoSQL이 있음을 염두에 둬야 한다.

[그림 Ⅱ-2-2] 다양한 NoSQL 솔루션

다음 절에서는 NoSQL을 5가지 모델로 분류하고 각 모델에 대한 특성과 관련 제품들을 소개한다. 각 모델에 대한 개발 기술을 보유한다면, 충분한 경쟁력을 갖춘 NoSQL 전문가라고 할 수 있을 것이다.