linuxism

Why MongoDB
MongoDB @ foursquare / Biggest reason : Auto-sharding
포스퀘어의 Harry Harry Heymann 이 직접 발표한 동영상 , 발표자료 슬라이드

최근 1,000만 이용자를 돌파한 서비스인 Foursquare. Foursquare는 매일 300만 건의 checkins 과 총 7억5천만 건의 checkins 데이터가 쌓여 있다. Foursquare 서비스의 환경은 Amazon EC2(Amazon Elastic Compute Cloud) 위에 40대의 장비, 그리고, 8 Clusters – Sharding과 Replica Sets – 로 구성된 mongodb로 가동되고 있다. Foursquare에서 mongodb를 사용한 가장 큰 이유는 Auto-Sharding (오토샤딩)이라고 한다.

Why MongoDB ? Biggest reason (by far): auto sharding

이 글에서는 MongoDB의 아래 2가지 특징 에 대해 알아보겠다.

• Replication (Replica Sets) : 안전성과 높은 가용성(safety and high availability)을 위한
• Auto-sharding : 분산확장(scale-out)을 위한

Replication, Replica Sets

기존 DB들에서 Master-Slave 구조를 통한 Replication을 제공한다. 복제를 통한 안전성과 높은 가용성을 확보했다.

1) Master/Slave Replication

[그림1] Master/Slave Replication

일반적인 개념의 Master/Salve Replication 구조 읽기 부하 분산 : Slave들은 Read 전용 단점 Master에 Write 부하증가 가능성 높음 Master Fail시 대응하기 위한 별도 조치 필요 (예, HA구성, 멀티Node Master 구성)

2) Replica Sets

[그림 2] Replica Sets

• Replica set은 자동 장애 넘김 기능이 있는 Master-Slave 클러스터
• 장애 시 자동 처리
  • 주 서버가 장애가 발생했을 경우 보조서버 중 우선순위가 높은 서버가 자동으로 주 서버가 됨
  • 우선순위는 Priority 가 0이 아닌 노드들 중 높은 순으로 선택
    동일 우선순위 일 경우 최신의 데이터 복제본을 가진 서버가 우선
  • 장애난 서버는 복구 후 보조서버로 다시 편입
• Priority 가 0 인노드 : 절대 주 서버가 될 수 없음, 백업/복구 등의 용도로 사용

3) MongoDB에서 Slave 활용

• 데이터 유실이나 마스터 노드에서 장애 발생시 요청 넘김
• 백업
• 읽기 부하 분산
• 통계 등 데이터 처리용 업무 수행

이 경우에도 마스터 노드로의 쓰기(DB Write) 부하는 줄일 수 없다.
이 쓰기 부하를 줄이기 위해 Auto-Sharding 을 통한 분산확장(Scale-Out)이 가능하다.

Auto-Sharding
샤딩(Sharding)은 데이터를 분할해 다른 서버에 나누어 저장하는 과정을 말한다. 데이터를 여러 서버에 분할함으로써,
Scale-Up을 하지 않고도 더 많은 데이터를 저장, 처리 가능하게 한다.
샤딩은 거의 모든 DBMS가 지원한다. 어플리케이션 단에서 처리, 관리하는 수동 샤딩의 어려움을 MongoDB에서는
Auto-Sharding(자동 샤딩)을 제공으로 해결한다.

1) Sharding 구조

• 샤드 키로 설정된 칼럼의 범위를 기반으로 각각의 값에 맞는 Shard에 저장이 된다.
  필요 시 Shard를 추가하여 Migration 하여 확장이 가능하다.
  [그림 3] Sharding 개념
• 사용하는 Application 단에서는 MongoS 라는 라우팅 프로세스로만 연결함으로써 Shard의 구조에 대해서는 알 필요도,
  구조변경에 따른 수정도 필요 없다.

2) Sharding을 사용해야 할 때

• 쓰기(DB Write)가 빈번 할 경우
• 현재 장비에 디스크 공간이 부족할 경우
• 애플리케이션에 영향을 주지 않고 증가하는 부하와 데이터를 처리하기 위해 장비 추가. 즉, Scale-Out

효과적으로 MongoDB를 사용하기 위해
Replica Sets + Auto-Sharding 구성
대용량 처리를 위한 분산확장이 가능하고 안전성과 높은 가용성 보장을 위해 Auto-sharding 과 Replica Sets 으로 구성

[그림 4] Sharding+Replica set 구성

그러나, 조심해야 할 것
1) Fragmentation

• 단편화, 조각화 문제
• 빈번한 삭제나 업데이트는 단편화를 발생시키고, 실제 데이터 보다 훨씬 많은 메모리를 사용 함
• 데이터 삭제 또는 이전해도 사용량은 그대로 유지
  -> repairDatabase를 통해 복구 해야함
• Foursquare 서비스 장애에 대한 사후 토의 참고
  (http://groups.google.com/group/mongodb-user/browse_thread/thread/528a94f287e9d77e?pli=1)

2) Monitoring

• 최선은 Monitoring : Monitoring is your friend
• 메모리 상주 크기, 디스크 입출력 속도, 쿼리 입력/수정/삭제 비율, 클라이언트 대기열

준비할 사항

• kth 내부에서도 mongodb, cassandra 등 서비스별로 NoSQL 적용중/준비중에 있음
• Scale-out을 위한 Configuration 가이드 및 운영 전담 필요
• 운영실과 Monitoring 공조체제 구축 필요

출처 - http://dev.kthcorp.com/2011/07/08/mongodb-atfoursquare-biggest-reason-auto-sharding/

원문 슬라이드 : Why we chose mongoDB for guardian.co.uk

 가디언은 트렌드의 변화에 적응을 하기 위해 여러 방법에 대해서 고민은 하고 시스템에 적용을 하였습니다. 아래는 다윈의 말을 인용하며, Mongodb를 선택하기까지의 과정을 함축적으로 나타내고 있습니다.

“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change. (강한 種이 살아남는다고 할 수 없다. 지적인 종이 살아남는다고도 할 수 없다. 오직 변화에 가장 잘 적응하는 종만이 살아남는다.)”

MongoDB까지 오기에는 “Early Period”, “Mid Period”, “Modern Period”, “Sticking Plaster”, “Future”로 5단계의 과정을 거쳤습니다. 아래는 각 단계별로 가디언이 해왔던 부분에 대해서 적었습니다.

1) Early Period

• 1995년경으로 Perl, CGI, apache로 구성된 실험적이고 bespoke software(가디언에 특화된 소프트웨어)
• RDBMS, script, static file들을 사용 합니다.

2) Mid Period

• 2000년경으로 벤더의 CMS을 사용하는 시기.
• vignette/AOLserver(open source), TCL(script), Apache, Oracle등을 이용한 온라인 publishing으로 초기 단계 배달에 중점.
• HTML, JavaScript, TCL, SQL, PL-SQL등이 템플릿에 뒤죽박죽 되어 있고, 어플리케이션 계층의 모델이 없고 오직 RDBMS 스키마만 있을 뿐, 가디언이 원하는 것을 할 수 없음.
• 몇 년이 흐르면서 이러한 스키마에 의존적인 구조로 인하여 확장을 하기 어려움.

3) Modern Period

• J2EE 모놀리식(Monolithic )개발 단계로 Spring/Hibernate 프레임웍 사용, DDD/TDD 방식으로 접근, database 는 ORM을 통해 추상화 함.
• 문제점 발생 => 모든 발간(신문, 주간지)은 스키마의 업그레이드가 필요했고, 이시간 동안은 저널리스트들은 일을 할 수 없음.
• 현재도 계속 복잡성은 증가 하고 있음. => 300개 이상의 테이블, 1만라인 이상의 hibernate xml config, database 매핑을 위한 1천개의 도메인 객체들, Database와 매우 밀접한 7만 라인의 이상의 도메인 객체 코드 등.
• ORM도 해결책은 될 수 없다. 데이터베이스는 도메인 모델에 강한 영향을 미친다. 많은 도메인 객체들은 RDBMS에서 복잡한 매핑 조인들을 만든다. 복잡한 hibernate 기능들은 인터셉터, 프록시와 같은 복잡한 hibernate 기능들은 최적화를 위해 복잡한 캐싱 전략을 많이 쓴다. 또한 아직도 복잡한 SQL 쿼리 코드를 사용한다.
• 이러한 것들은 시스템 부하가 이슈가 되고, RDBMS는 확장이 어려워 문제가 된다.

4) Sticking Plaster(땜빵?)

• 부분적으로 NoSQL을 적용한 09 ~ 10년의 시기임.
• 실질적인 NoSQL이라기 보다는 Memcached를 적용하여 RDBMS로부터 READ에 대한 부하를 줄인 것으로 보임.
• 현재까지는 부하문제를 어느정도 해결했지만, “앞으로도 가능할까?”에 대한 답변은 …
• 현재까지는 RDBMS 테이블, java 객체, JSON API의 세가지 모델을 가지고 있음.
• 이 모델들 중 JSON은 멀티 도메인 컨셉을 하나의 문서에 표현하는 것이 가능하며, 앞으로의 확장도 가능하기 때문에 앞으로 사용해야 할 모델의 가장 중요한 모델로 선택함.

5) Future

• 완전한 NoSQL을 사용하기 위한 단계로 현재 개발 중
• 여러 NoSQL(CouchDB, Cassandra, mongoDB ) 중에 가디언의 현 상황에 맞는 DB를 고르는 것이 핵심이며, JSON을 중요 모델로 선택할 때 MongoDB를 사용함.
  • CouchDB – Simple keystore. Too simple?
  • Cassandra: 확장성이 대단히 좋으나 스키마 디자인이 어려움.
  • MongoDB: 사용하기 쉽고, RDBMS의 쿼리와 유사하게 실행할 수 있음.

   

• 아래와 같은 이유로 MongoDB를 선택함.
  • 문서 기반의 데이터베이스 –JSON과 유사한 방식의 Binary JSON 사용
  • 복잡한 쿼리를 사용 가능.
  • Consistency에 대해 유연한 대처가 가능 – 컬럼그룹 기반으로 HBase나 카산드라와 달리 문서형 데이터 모델을 사용, 관계형 데이터베이스와 유사한 사용법 유지, 순서기반분할(Order-preserving partitioning) 자동샤딩(Automatic Sharding)을 구현하여 노드간 데이터 분리 및 확장이 투명하게 이루어짐
  • 런타임에 쉽게 변경 할 수 있는 유연한 스키마를 가짐.
  • 규모가 크거나 작은 모든 곳에 사용 가능.

3. 가디언이 앞으로 해야 할 일

1. 현재의 시스템
   • login/registration => TCL/PLSQL로 되어 있음.
   • 300만 이상의 관계형 데이터베이스에 있음.
   • 매우 복잡한 스키마와 PL-SQL
   • 새로운 시스템이 필요하며, 과연 현재 사용하고 있는 오라클을 NoSQL로 마이그레이션 할수 있을까?
2. 미래의 시스템
• 개발될 API는 새로운 MongoDB와 함께 기존 Oracle도 함께 연동 되어야 함.
• 마이그레이션 후에 Oracle은 제거함.

4. 결론

앞에서 소개된 내용들은 대부분 많이 알고들 있는 부분이며, 새로운 기술에 대한 내용은 아닌 것 같습니다. 우리가 그 동안 해왔던, 그리고 현재도 고민하는 내용들을 가디언도 동일하게 하고 있었으며, 고민만 한 것이 아니라 여러 방법으로 시스템을 변경하며 개발을 했습니다. 다윈의 말처럼 가장 강하거나 똑똑한 종이 살아 남는 것이 아니라, 변화에 적응을 잘해야 살수 있습니다.

kth는 강하거나 똑똑하지는 않지만, 포털중심에서 스마트 모바일로 트렌드의 변화에 적응하고 있는 것처럼 최후까지 살아남는 개발자 개인 또는 회사가 되기를 희망 합니다.

출처 - http://dev.kthcorp.com/2011/10/13/why-guardian-chose-mongodb/

NoSQL 분류 기준

저장시스템 같은 플랫폼뿐만 아니라, 컴퓨터 자체를 포함하여 서비스를 만들기 위한 모든 플랫폼은 읽기와 쓰기가 기본입니다. 운동 경기에서 공격과 수비가 기본인 것과 마찬가지 입니다. 몇 가지 예를 들어 보겠습니다.

컴퓨터의 원형 모델이라고 하는 폰노이만 구조의 내장 프로그램 컴퓨터의 이론적 근간은 Turing machine이라 불리는 수학적 모델입니다. 이 모델은 다음과 같은 구성 요소로 이루어져 있습니다.

•           무한히 길고, 셀로 구성되며, 각 셀에는 하나의 기호를 쓸 수 있는 테이프

•           셀에서 기호를 읽거나 쓰고 왼쪽이나 오른 쪽으로 한 칸 움직일 수 있는 헤드

•           상태 전이 테이블

•   (현재 상태, 현재 셀에서 읽은 기호) → (다음 상태, 셀에 쓸 기호, 왼쪽/오른쪽)

상태 전이 테이블을 프로그램을 ‘서비스’라 생각하면 플랫폼이 해주는 일은 읽기/쓰기 입니다.

이러한 읽기/쓰기는 CPU micro architecture부터 클라우드 서비스까지 시스템 규모에 상관없이 반드시 있어야하는 기본 기능입니다.

•           Intel core2 micro architecture: 하드웨어 구성 측면에서 pipelining 부분과 out-of-order execution,ALU를 빼고 생각하면, 나머지 부분은 모두 읽고 쓰는 연산을 위한 구성입니다.

•           MS Windows Azure: Azure같은 클라우드 시스템에서도 읽고 쓰는 Storage 부분이 핵심 부분입니다.

쓰기를 한 데이터를 읽고 이렇게 읽은 데이터를 바탕으로 계산하고 다시 중간 결과 데이터를 쓰고 이러한 읽기-계산-쓰기 작업을 반복하는 것이 프로그램입니다.

인터넷 서비스 또한 마찬가지입니다.

‘읽고 쓰기가 기본’이라는 The Platform 독자들이라면 당연히 아시는 이야기를 장황하게 하는 이유는 그 기본에서 NoSQL같은 저장시스템이 갖춰야할 핵심 기능을 생각해볼 수 있기 때문입니다.

앞으로 논의할 NoSQL 시스템을 분류하는데 사용할 기준을 미리 정리해 보겠습니다.

데이터 모델 및 쿼리 모델

Turing machine은 테이프 한 셀만 읽기/쓰기를 하지만, 실제 시스템에서는 그보다는 훨씬 다양하고 복잡한 읽기/쓰기가 필요합니다. 읽기/쓰기의 대상이 되는 저장 모델을 데이터 모델이라 하고 읽고 쓰는 명령어 모델을 쿼리 모델이라 하겠습니다. 쿼리 모델을 API라고 할 수도 있지만, 저장 모델에 대한 읽기/쓰기 연산이라는 점을 강조하기 위해서 RDBMS에서 주로 사용하는 용어인 쿼리를 사용하겠습니다. 데이터 모델과 쿼리 모델은 동전의 양면처럼 서로 밀접한 관련성이 있습니다. 객체 지향 관점의 예를 들어보면 클래스 instance와 클래스에 정의된 method와 같은 관계입니다.

데이터 분산

한 컴퓨터에서 서비스가 요구하는 쿼리를 처리하지 못하는 경우가 발생합니다. 이러한 상황은 쿼리를 처리하기 위해 사용하는 CPU, 메모리, 디스크, 네트워크의 용량/처리량의 한계때문에 발생합니다. 이러한 문제를 해결하기 위해서 한 컴퓨터의 처리량을 높이는 scale-up 접근 방식은 비용이 많이 들기도 하지만 아키텍처 특성상 처리 요구량을 감당하지 못하는 경우가 많습니다. 이러한 이유로 두 대 이상의 컴퓨터에 서비스가 요구되는 쿼리 처리를 위한 자원을 분산하는 방식을 취할 수 밖에 없는데 이러한 접근 방식을 scale-out 접근 방식이라 합니다.

큰 스케일의 서비스를 위한 분산의 기본 원칙은 서비스의 요구 수준 내에서 나누면 나눌수록 쿼리 처리량이 늘어나야 한다는 것입니다. 무한하게 scale-out 하는 방식이 있으면 좋겠지만, 하나의 scale-out 접근 방식이 모든 scale-out 요구사항에 적합할 것이라는 가정을 하는 것은 현실적이지 않기 때문에“서비스의 요구 수준 내에서” 라는 조건이 들어갑니다.

가용성을 높이기 위한 복제

한 시스템에 저장된 데이터는 쿼리를 처리하기 위해 필요한 프로그램이나 리소스의 동작 실패로 인해서 읽거나 쓸 수 없는 상태로 빠질 수 있습니다. 따라서 서비스의 고 가용성을 위해서는 데이터와 쿼리 처리를 위한 리소스를 두 곳 이상의 장소에 분산 저장시켜야 하고 이를 복제라고 합니다. 복제는 다음과 같은 세가지 모델로 분류할 수 있습니다[1]

•           Transactional replication: 2PC(Two Phase Commit) 프로토콜 등을 이용해서 트랜잭션 단위의 복제를 하는 모델입니다.

•           State machine replication: 복제 대상 시스템을 Finite State Machine으로 보고 원본 시스템에서 발생하는 event(연산)를 atomic broadcast (total ordering된 메시지 전달)을 통해서 복제를 하는 방식입니다

•           Virtual Synchrony: Group communication 등에서 사용되는 메시지 전달 기술입니다. 프로세스 그룹 내의 동시적 event 발생에 대한 동일한 순서의 메시지 전달을 보장하는 방식입니다. (이 방식은 in-memory 데이터에 대한 방식이라고  합니다.)

연산에 대한 데이터 일관성 모델

RDBMS에는 ACID(Atomicity, Consistency, Isolation, Durability) 속성으로 대변되는 트랜잭션 개념이 있습니다. 트랜잭션은 하나 이상의 쿼리를 논리적으로 묶은 개념이고, 이러한 트랜잭션이 DBMS에 적용되었을 때 시스템이 어떠한 속성을 보장해서 DBMS에 저장된 데이터에 대한 일관성을 유지하는지 밝히는 것입니다. NoSQL 시스템도 마찬가지로 사용자가 시스템에 가한 연산에 대해 시스템이 어떻게 데이터 일관성을 유지해주는지에 대해 밝혀야만 합니다.

RDBMS  NoSQL

여러 NoSQL 시스템이 어떠한 특징을 가지고 있는지 알아보기 전에, 어떤 연유에 의해서 NoSQL 저장시스템이 나타나게 되었는지에 대해 알아 보는 것이 좋을 것 같습니다.

Antithesis로서의 NoSQL

NoSQL을 ‘No SQL’로 생각해 보면, RDBMS와 대립하는 시스템으로 생각할 수 있습니다. RDBMS의 대립물로 나오게 되는 논리적 흐름은 다음과 같습니다.

•           RDBMS는 관계(relation, table) 형태로 모델링 할 수 있는 데이터 조작 방법으로 SQL 언어를 정의하고 ACID 속성의 트랜잭션 개념을 지원합니다

•           인터넷 스케일 서비스의 매우 높은 데이터 처리량 요구에 의해서 데이터를 분산 처리해야 하는 scale-out 접근 방식이 절실해 졌습니다.

•           기존 RDBMS의 scale-out 접근 방식은 RDBMS의 핵심이라고 할 수 있는 관계 모델과 트랜잭션의 연산 일관성 속성을 유지하는 것을 목적으로 하고 있습니다.

위와 같은 속성을 유지하면서 scale-out하는 것은 어렵습니다. 이는 데이터의 분산과 복제시에도 발생하는 문제입니다.

그래서 DBMS가 보장하는 ACID 기반의 transaction 속성이나 복제 일관성 모델을 완화해서 scale-out 하는 방식을 취합니다

RDBMS의 scale-out

RDBMS에서 scale-out 하는 것은 어렵습니다. 사견입니다만 RDBMS에서 수백 수천대로 scale-out 할 수 있다면 Oracle 등의 전통적 DBMS 강자들이 이미 관련 제품을 내놓지 않았을까요?

RDBMS의 테이블이 여러 컴퓨터에 분산되어 있고, 고 가용성을 위해서 각 데이터는 복제 되어 저장된다고 생각해 봅시다.

우선 ACID를 만족시키며 분산 transaction을 수행하는 것은 scale-out 하기 어렵습니다.

•           ACID 속성 중 atomicity를 만족하기 위해서는 2PC 프로토콜과 같은 분산 트랜잭션 프로토콜이 특정 트랜잭션에 관련되어 있는 시스템간에 이뤄져야 합니다.

•           ACID 속성 중 isolation level을 맞추기 위해서는 일반적으로 데이터를  locking해야합니다. Locking의 단위는 레코드, 테이블, 인덱스 등이 될 수 있습니다.

•           따라서 분산된 환경에서 Atomic과 Isolated 속성을 만족하기 위해서는 분산 트랜잭션 프로토콜이 진행되는 동안에 관련된 모든 lock이 각 시스템에 걸려 있어야 함을 의미하고, 이러한 방식은 시스템의 서비스 부하가 높아 질수록 많은 lock 경합이 이루어지는 것을 의미합니다. 이러한 경합 때문에 scale-out 하기 어려워 집니다.

그 다음으로 데이터를 복제 분산해서 scale-out 하는 것은 한계가 있습니다.

•           2PC 방식의 transactional replication 방식은 복제 관계에 있는 시스템 중의 하나가 failure 상태로 가는 경우 트랜잭션이 실패하게 되어서 비가용 상태로 빠지는 문제점이 있습니다. 또한 복제 관계에 있는 시스템이 여러 대 있을 때 성능 저하가 일어나는 방식입니다.

•           다른 방식으로 DBMS의 WAL(Write Ahead Logging) 데이터를 복제 시스템으로 전달해서 이를 반영하는 방식을 생각할 수 있습니다. 데이터의 변경이 이루어지는 시스템을 master(또는 primary)라고 하고 데이터의 변경이 적용되는 시스템을 slave(또는 backup)라고 했을 때, master-slave 나 multi-master와 같은 구성을 하게 됩니다.

•   Master slave 구성을 하는 경우: 가장 일반적인 복제 방식입니다. 이 방식에서 복제 관계에 있는 시스템이 늘어나면 속도가 이에 비례해서 낮아지게 됩니다

•   Multi-master 구성을 하는 경우: 여러 master에서 일어나는 데이터의 쓰기 작업이 상호 충돌을 일으키는 경우 이를 방지하거나 발생했을 때 해결하는 것은 매우 어렵습니다. [2]에서 저자인 Jim Gray는 여기에 대한 연구를 했습니다.^[1] (데이터베이스와 트랜잭션 처리 관련된 공적으로1998년에 Turing Award 수상)

개발자에 의한 sharding

일반적인 관점에서 DBMS의 데이터 모델에서 ACID 속성을 만족 시키면서 scale-out 하기는 매우 어렵습니다. 따라서 DBMS 기반으로 scale-out 하기 위해서는 데이터 모델 자체를 단순하게 구성해 데이터를 N개의 서로 독립적인 데이터로 분할하는 방식을 취하고 이 분할 된 데이터 안에서 쿼리가 이루어지도록 개발합니다.

분할 된 데이터 단위를 shard라고 하고 N개의 shard를 M 대의 DBMS 서버에 나누어 서비스 합니다. Shard를 관리하는 것은 DBMS가 아니라 서비스 개발자가 잘 해야 할 일이 됩니다.

이러한 개발자 중심의 sharding 방식은 다음과 같은 어려움이 있습니다.

•           Shard 를 정의하는 작업이 일단 필요하겠습니다.

•           Shard mapping

•   DBMS에서 저장의 기본 단위는 테이블 입니다. 한 테이블에 하나 이상의 shard가 들어가게 되는데 특정 shard가 어느 데이터베이스instance의 어느 테이블로 mapping 되는지 알아야 합니다. 응용 프로그램이 이 정보를 알고 있어서 해당되는 shard 테이블의 위치를 알아야 합니다

•           Shard 분산/재분배:

•   각 shard가 똑같지 않으므로 처리량 요구사항이나 데이터 사이즈가 shard 마다 다를 수 있습니다. 이 경우 새로운 데이터베이스 instance를 추가/제거 하고 shard를 재분배 작업이 일어나야 하는데, 개발자가 일일이 신경 써야 하므로 인적 장애가 많이 생길 수 있는 부분이 발생합니다

•   분산/재분배에 의해서 변경된 mapping 정보는 응용 프로그램에 반영이 되어야 합니다

•   변경에 따르는 복제 설정 등의 관리 작업을 해야 합니다

NoSQL의 접근 방식

인터넷 스케일의 데이터 저장시스템은 데이터의 분산을 통한 scale-out 방식의 확장을 지향하고, 고 가용성을 위해 복제를 합니다. RDBMS에서 제공하는 관계 모델과 ACID 속성의 트랜잭션을 지원하는 방식 하에서 scale-out이 어렵다는 것을 알아 보았습니다. 이제 NoSQL 진영에서는 어떠한 접근 방식을 취하는지 알아 보겠습니다.

데이터 모델을 단순화해서 sharding을 한다

쿼리 연산의 데이터 closure가 분산의 기본단위가 되고, 이 단위를 모아서 적당한 수준의 shard를 만들 수 있도록 데이터 모델이 단순하게 구성됩니다. 분산의 기본단위는 key입니다.

•           가장 간단한 모델은 데이터를 하나의 immutable 객체로 봐서 데이터 전체에 대한 읽기 쓰기 만을 지원하는 모델입니다. key-value storage중에서 blob 형태의 데이터 모델을 지원한다고 하는 Dynamo, Membase 가 이 부류에 속한다고 할 수 있습니다.

•           Google file system에서 하나의 파일의 구성 단위인 chunk는 globally unique한 64bit identifier를 가지며 기본적으로 chunk에 대한 연산은 chunk의 byte range에 대한 read/write/append(마지막 chunk의 경우) 연산을 지원합니다. 사용자에게 제공되는 저장 abstraction은 파일이지만 이 파일에 대한 연산은 API level에서 chunk 단위로 환원됩니다.

•           Blob 형태의 immutable 객체 모델 보다 좀더 복잡한 데이터 모델을 제공하는 시스템도 있습니다.

•   Key-Value DB: 데이터를 list, set과 같은 ADT(Abstract Data Structure)로 모델링 해서 해당 구조체에 대해 가능한 연산을 쿼리로 제공하는 database. Redis나 Tokyo Cabinet등이 대표적

•   Document-oriented: Object representing notation을 이용해서 임의의 비정규화된 object를 저장하고 object의 property 기반으로 쿼리를 제공해주는 CouchDB나 MongDB가 대표적

•           Bigtable, Cassandra와 같이 row-column-timestamp나 row-column family-column 구조의 multi-dimensional map 형태의 데이터 모델을 지원하는 시스템

기본적으로 쿼리는 이 분산 단위의 읽기 쓰기를 지원하지만, 여러 분산 단위에 대한 집계 연산 등을 하기 위해서 map-reduce와 같은 별도의 쿼리 방식을 지원하기도 합니다. 또한 MongoDB와 같은 document-oriented 저장시스템은 document ID 이외에 document의 특정 property에 대해 index 를 걸 수 있도록 해서 빠른 접근 경로를 추가적으로 사용자가 정의할 수 있도록 하고 있습니다.

분산

•           Hash 기반

•   key 자체의 의미를 따지지 않으므로, 처리량 요구나 데이터 크기에 대해서 자연적인 분산이 이루어 집니다.

•   node의 추가/삭제에 의한 mapping 및 재분배 문제를 최소화 하기 위해서 consistent hashing 기반의 분산을 주로 합니다.

•           Index 기반

•   key 기반의 order-preserving을 유지해서 범위 쿼리가 가능하도록 합니다.

•           메타데이터 서버 기반

•   분산 단위의 위치 정보를 별도의 메타데이터 서버에서 관리하는 방식입니다.

쿼리의 ACID 속성을 완화한다

쿼리 연산의 일관성을 RDBMS의 ACID 속성보다 완화한 형태를 사용합니다. 복제까지 포함해서 생각해 보면 이와 같은 쿼리 속성 완화 현상은 두드러집니다. CouchDB처럼 ACID 속성을 유지해주는 시스템도 있지만, 많은 경우 고가용성을 위해, Consistence나 Isolated를 완화합니다.

몇몇 시스템이 어떻게 완화 하는지 구체적으로 알아 보겠습니다.

•           GFS에서는 여러 클라이언트가 동시에 한 파일에  쓰기를 하거나 record append 연산을 할 수 있습니다. 여러 클라이언트의 동시적인 쓰기 작업은 비록 모든 replica에 대해서 동일한 값을 보게 되지만, 각 클라이언트의 write는 (논문 표현으로는) undefined 입니다. Record append 연산은 각 replica에 대해서 적어도 한번은 atomic 하게 쓰인다는 형태의 파일 영역에 대한 일관성 보장을 해줍니다.

•           Dynamo의 경우 ‘always writeable’ 해야 하는 서비스 요구에 의해서 quorum 프로토콜의 변형인 sloppy quorum 방식의 복제 및 읽기에 대한 view consistency를 보장하는 방식을 사용합니다. Quorum 프로토콜 방식은 네트워크의 분할이 발생하더라도 정보의 불일치가 생기지 않도록N개의 복제 관계에 있는 시스템간에 R (읽기), W(쓰기) 각 연산에 대해 수행 되야 하는 시스템의 정원의 개수를 정하는 방식입니다 (R + W > N, W > N/2). Dynamo의 경우는 시스템이 일시적 장애에 대비하기 위해서 Hinted-handoff 방식으로 다른 시스템이 자신이 담당하고 있지 않은 key에 대한 쿼리 연산을 할 수 있도록 합니다 (sloppy quorum). 발생할 수 있는 데이터의 불일치는 각 시스템이 데이터에 대한 버전을 관리하고, vector clock 기법을 사용해서 복제 관계에 있는 시스템 들이 유지하는 데이터의 변경에 대한 causal order 를 판단할 수 있도록 해서 읽기 연산을 수행할 때에 시스템이 자동적으로 최신의 (reconciled) 데이터를 판단하거나, 판단이 불가능 한 경우 여러 버전의 데이터를 클라이언트에 전송해서 클라이언트가 판단하도록 합니다.

•           Cassandra의 경우 N개의 복제 관계에 있는 node에서 몇 개가 읽기나 쓰기가 성공해야만 하는지에 대해 사용자가 지정을 할 수 있도록 해서 일관성 수준을 조절할 수 있도록 해줍니다. 쓰기의 경우 (Zero, Any, One, Quorum, All) 읽기의 경우 (One, Quorum, All) 지정할 수 있는 option을 제공합니다. Dynamo와 유사하게 timestamp 기반의 ordering을 통해서 read-repair 해서, 읽기 시의 consistency (view consistency)를 제공합니다.

NoSQL 시스템을 분류해 보자

대표적인 NoSQL 저장시스템을 분류해 보겠습니다.

^a 전체 시스템이 하나 존재하는 Master node가 replication 관계에 있는 chunk server (replica) 중 하나에 chunk에 대한 쓰기 권한을 빌려주는 방식을 사용합니다. Lease를 받은 replica를 primary라고 부릅니다. Master node에 대한 부담을 줄이기 위해 primary가 살아있는 동안 lease를 연장하는 방식을 사용합니다 (heart beat 메시지에 piggy backing 함)

^b 기본적으로 consistent hashing을 하지만 설정으로 Partitioner를 결정할 수 있도록 해 줍니다. (random, order preserving, collating order preserving)

^c User defined index 생성 가능

^d ID 및 Sequence Number에 대한 index. Sequence Number는 update 마다 증가

어떤 저장시스템을 써야 하지?

“내가 만드는 서비스에 어떤 저장시스템을 써야 하지?” 에 대해 고려할 사항을 적어보겠습니다.

RDBMS는 아직도 기본

우선적으로 고려해야 합니다. 읽기/쓰기 연산이 ACID 형태의 일관성을 요구하는 경우에는 더욱 필수입니다. RDBMS 구성과 추가적인 저장시스템으로 많은 경우 서비스 부하를 분산시킬 수 있습니다.

•           복제를 통한 읽기 분산

•           MySQL Cluster와 같이 OLTP 영역에서의 RDBMS scale-out 기술도 고려 대상이 될 수 있습니다. ^[2]

•           RDBMS + Cache + Storage system

• RDBMS 자체의 성능이 부담이 되는 경우, 자주 사용하거나 쿼리 수행 시간이 오래 걸리는 item에 대해서 Arcus와 같은 caching system을 사용할 수 있습니다. 물론 cache하는 데이터에 대한 일관성 모델을 잘 고려해야 합니다.

• 대량의 데이터 저장에 대한 요구가 있다면, 이러한 데이터에 대해서 OwFS와 같은 별도의 storage system을 사용할 수도 있습니다.

•           마지막으로 개발자 구현하는 sharding 기법이 있습니다. 복제, 장애 처리, 복구, shard 분산/재분배의 어려움을 이겨내야 하지만 말입니다.

NoSQL

RDBMS 기반으로는 구현하려는 서비스를 제대로 만들 수 없다고요? 그럼 NoSQL을 사용해야죠. NoSQL의 공통적인 장점은 복제, 장애 처리, 복구, shard 분산/재분배의 어려움을 시스템이 해결해 주는 것입니다. 서비스가 요구하는 데이터 모델 및 일관성과 NoSQL 시스템의 궁합이 맞으면 아주 좋은 선택이 될 수 있습니다. 데이터 모델 별로 장/단점을 알아보도록 하겠습니다.

•           Key-Value(blob)

• 단순한 모델인 만큼 속도가 빠른 것이 주 장점입니다.

• Key 단위의 원자적 쓰기/읽기 만을 지원하는 경우가 많습니다. 이 경우 여러 key의 value에 동시 처리를 하면서 serialize 할 수 있는 방법은 없습니다.

• 메모리를 저장소로 사용하는 경우 아주 빠른 get/put을 지원하는 것을 목적으로 하고 있습니다.(내가 서비스하려는 데이터의 양이 메모리 안에 다 들어가는 경우가 제일 좋겠죠.)

• Key에 대한 단위 연산이 빠른 것이지, 여러 key에 대한 연산은 고정적으로 네트워크 전송 지연이 포함되기 때문에 느릴 수 있습니다. (RDBMS테이블에 10만  row 데이터를 select 하는 것과 Key-value 단위로 10만 번 읽는 것은 비교할 수 없을 정도로 Key-Value DB가 느립니다. 10만 건이 아니더라도 10개 100개만 되더라도 성능 차이가 납니다.)

•           Key-Value(Structure)

• List, Set 과 같은 ADT를 제공하는 모델이고, 장점은 한 key에 대해 여러 값을 저장할 수 있는 것입니다. Key-BLOB모델에서는 단일 값만Value로 사용할 수 있어서 여러 Key를 사용해 저장해야하는 데이터를 하나의 key만 사용하여 저장할 수 있습니다.

• 단순히 get/set하는 모델보다는 처리 시간이 오래 걸립니다. (하지만 그리 많은 차이가 나지는 않습니다. 데이터 모델에 기인한 성능 차이는 시스템을 어떻게 효율적으로 잘 구현했는가로 극복할 만한 수준이라 생각됩니다.)

•           Document oriented

• schema 없이, 임의의 property 를 추가할 수 있는 데이터 모델입니다.

• 이름에서 드러나듯 JSon이나 XML 같은 문서 데이터를 저장하기 적합한 구조입니다.

• Document id나 특정 property 값 기준으로 order-preserving 하는 경우가 많습니다. (이 경우 해당 key 값의 range에 대한 효율적인 연산이 가능해 지므로 이에 대한 쿼리를 제공합니다.)

• 쿼리 처리에 있어서 데이터를 parsing 해서 memory 연산을 해야 하므로 처리 overhead가 key-value나 key-structure 모델보다 크다 할 수 있습니다. (큰 크기의 document를 다룰 때 성능 저하가 발생합니다.)

•           Multi-dimensional map

• Bigtable의 경우 row-column-timestamp에 의해서 데이터를 mapping 하고, 데이터 자체는 binary 값입니다.

• Cassandra의 경우 row-column families-column 형태로 데이터를 mapping 하고 데이터 자체는 binary 값입니다.

• 두 모델 모두 데이터 (column)에 대한 grouping 과 access 방식을 구조화 하는 방식으로 데이터를 모델링 할 수 있도록 해줍니다. 자세한 모델링 방법은 이 문서에 적기에는 좀 어렵네요. Cassandra 홈페이지와 [10]번을 참고하시길 바랍니다.

나가며

변하는 데에서 변하지 않는 것을 찾는 것이 학문을 하는 사람이 취해야 할 자세라면, 변하지 않는 부분을 변화시켜  보는 것이 문제를 푸는 개발자의 자세가 아닌가 생각해 봅니다.

Not Only SQL을 위해서~

참고 문헌

[1].        WIKI: Replication(computer science)

http://en.wikipedia.org/wiki/Replication_(computer_science)

[2].       Jim Gray, Pat Helland, Patrick O’Neil, Dennis Shasha – The Danagers of Replication and a Solution: In ACM SIGMOD ‘96

[3].        The problems with ACID, and how to fix them without going NoSQL - http://dbmsmusings.blogspot.com/2010/08/problems-with-acid-and-how-to-fix-them.html

[4].        Werner Vogels, Amazon.com: Eventually Consistent. In ACM Queue Vol6, Issue 6

[5].        Dan Pritchett, E-bay: BASE: An ACID Alternative. In ACM Queue Vol6, Issue 3

[6].        Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung: The Google File System

[7].        Fay Chang , Jeffrey Dean , Sanjay Ghemawat , Wilson C. Hsieh , Deborah A. Wallach , Mike Burrows , Tushar Chandra , Andrew Fikes , Robert E. Gruber: Bigtable: A distributed storage system for structured data

[8].        A Lakshman, P Malik – Cassandra: a decentralized structured storage system, In ACM SIGOPS Operating Systems Review, 2010

[9].        Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall and Werner Vogels – Dynamo: Amazon’s Highly Available Key-Value Store In ACM SIGOPS 2007

[10]. http://arin.me/blog/wtf-is-a-supercolumn-cassandra-data-model

출처 - http://blog.naver.com/PostView.nhn?blogId=naverdev&logNo=120116324222&categoryNo=8&parentCategoryNo=0&viewDate=&currentPage=1&postListTopCurrentPage=&userTopListOpen=true&userTopListCount=5&userTopListManageOpen=false&userTopListCurrentPage=1

NoSQL을 여행하는 히치하이커를 위한 안내서, 송기선 

이 안내서는 The Platform 2010년 10월호 NoSQL 특집편을

쉽게 읽을 수 있도록 제작한 안내서이다.

NoSQL 세계에는 도무지 친해질래야 친해질 수 없는 개념과 용어들이 많다.

이 안내서를 읽고나서 NoSQL 세계에서 당황하지 않도록 해보자.

출처 - http://blog.naver.com/PostView.nhn?blogId=naverdev&logNo=120116323974&parentCategoryNo=8&viewDate=&currentPage=1&listtype=0