Dynamo NoSQL 란?

NoSQL이 처음 만들어지게 된 이유는 명확합니다. 기존의 단순한 값들을 Entity-Relationship 의 관계를 이용해서 나타내어서 사용하는 방식으로 사용을 했습니다.

그런데 세상이 바뀌게 되었습니다. 세상은 예전처럼 단순한 데이터를 처리하고 활용하는 시대가 지나게 되었습니다.

그래서 나오게 된 실용적으로 관계지향의 개념을 깨고 원하는 데이터끼리 뭉쳐서 더 큰 데이터를 활용하자는 목적에서 나오게 된 것이 바로 NoSQL이라는 개념입니다.

NoSQL의 의미는 혹자들은 "Not Only SQL" 이라는 범용적인 개념으로 해석하여서 엄청나게 큰 영역을 행사하려고 하지만 실상 NoSQL이라는 것은 그냥 "No SQL"입니다.

그냥 단지 SQL이 아니라는 의미입니다. 그렇게 언급되기 시작되었고 지금은 마치 SQL의 큰 산을 깨부시려고 하는 하나의 상징적인 이름으로 바뀌었습니다.

NoSQL의 시작은 Google의 Big Table 논문을 기반으로한 시스템과 Amazon의 DynamoDB의 논문을 기반으로 한 시스템 두가지로 시작되었습니다.

Dynamo 계열의 NoSQL의 장단점을 비교해보겠습니다.

Dynamo 계열 NoSQL의 개요

1. Ring과 Consistent Hashing

먼저 Dynamo 계열(카산드라, 리악)의 NoSQL의 특징은 Ring Topology를 기본으로 구성되어있습니다.

Ring 구성이란, 전체 데이터를 1~N 이라는 특정한 레인지로 정의하고, 전체 데이터를 Ring형으로 정의하여, 이 Ring으로 구성된 데이터들을 피자 조각으로 나누듯이 여러 Slice로 나눕니다.

Slice로 나누는 과정을 partition이라고 하는데 각 Partition은 데이터를 저장하는 구간 정보를 가지고 있습니다.

예를 들면, Ring형으로 10000개의 데이터가 형성되어 있다고 하고, 각 Partition의 수를 10개라고 지정하면 첫번째 파티션의 범위는 0~999, 두번째 파티션의 범위는 1000~1999

와 같은 식으로 범위가 저장되어집니다.

이를 통해서 저장하고자 하는 데이타의 키를 알면 어느 파티션에 저장할 수 있는 지는 범위를 보고 쉽게 찾아갈 수 있기 때문에,

각 Partition을 저장하는 하드웨어(Node)에 부하를 분산 시킬 수 있는 구조를 갖는다.

이런 방식을 Ring 기반의 Consistent Hashing 이라고 합니다.

2. N-Value & Quorum

특정 파티을 저장하고 있는 Node가 장애가 났을 때, 특정 파티션의 데이터 유실이 발생할 수 있는데, 이를 방지하기 위해서 Node간의 데이터 복제를 수행한다.

몇 개의 복제본을 갖느냐를 정해야하는데, 이 복제본의 수를 보통 "N-Value" 또는 "Quorum"이라고 정의하며 일반적으로 이 Quorum의 수는 3개정도 지정합니다.

이 N-Value 또는 Quorum을 3으로 지저아는 이유는 여러가지이지만, 장애 대응면에서 최소한 하나의 복제본을 가져야하기 때문에 2개의 복제본이 필요하고,

예측된 작업인 패치, 서버교체 시에 장애에 대응하기 위해서 최소한 두개의 복제본을 유지해야 하기 때문에 일반적으로 3개의 복제본을 생성합니다.

이 N-Value는 NoSQL의 설정에서 그 수를 조정할 수 있습니다.

3. R-Value, W-Value

바로 위에서 N-Value의 수에 맞는 복제본을 가지게 되는데, Dynamo Architecture는 R-Value와 W-Value라는 값을 가진다.

이 값들은 성능과 데이터 정합성 간의 Trade-Off를 위한 값이다.

데이터 복제는 실시간으로 이루어지지 않고, 약간의 Delay가 발생을 합니다. Delay는 수 밀리세컨드정도로 걸리게 됩니다.

N-Value를 3이라고 가정하면, 첫번째 Node에 Write하고, 두번째 Node와 세번째 Node에는 데이터가 복제되어야한다.

이 복제과정에서 데이타를 읽을 때, 이 3개의 Node 중에서 데이터를 몇개의 노드에서 데이터를 읽어올지를 결정하는 것이 R-Value이며,

동시에 몇개의 Node에 Write할 것인가를 결정하는 것이 W-Value입니다.

만약에 N-Value가 3인 상태에서 W-Value가 2이면 Write시에 복제본까지 총 3개인 공간에 동시에 두개의 Node에 Write합니다.

R-Value가 1보다 클 경우 R-Value 노드에서 데이터를 읽어 오고, 두 개의 데이터가 다를 경우 최근 데이터를 사용합니다.

이런 이유로 R-Value + W-Value > N-Value이면 Data Consistency가 보장이 됩니다.

예를 들어서, N=3일때, R=2.W=2이면, Write시 적어도 두개의 복제본에 썼기 때문에, 하나가 복제가 안되어 있다하더라도,

2개를 읽을 때, 정책적으로 최신 데이터를 읽기 때문에 이 경우 최신 데이터를 읽을 수 있다.

(여기서 새로운 데이터를 판단 가능하게 하는 방법을 Vector-Clock이라고 합니다.)

4. Masterless Architecture

또 다른 특징 중에 하나는 Masterless 아키텍쳐이다. Ring을 구성하고 있는 아무 Node에다 요청을 보내도 처리가 되고, 전체 설정 정보를 가지고 있는 마스터 노드나 Admin 노드가 없다.

10개의 노드를 가지고 있는 Ring의 아무 Node에나 Request를 하더라도, 각 Node는 해당 데이타가 다른 어느 Node에 저장되어야 하는 지를 Consistent Hash를 통해서 알 수가 있고, 해당 노드로 Request를 Routing한다.

이때 자기가 데이터를 가지고 있지 않더라도 첫번째 요청을 받은 Node가 데이터를 처리하는 이 노드를 Coordinator Node라고 정의한다.

지금까지 대략적인 Dynamo 아키텍쳐의 특성에 대해서 알아보았습니다. 이제는 장점과 단점에 대해서 이야기해보겠습니다.

장점

1. High Availability & Partition Tolerence

높은 이용성으로 인하여 분산 시스템의 CAP 이론에서 A와 P에 최적화 되어있습니다.

A는 Availability 로 특정 노드가 장애가 나더라도 서비스가 가능하며, P는 Partition Tolerance로 Node간의 네트워크 통신이 끊어지더라도 서비스가 가능합니다.

(Vector Clock을 이용하여 데이터의 정합성(두개의 데이터가 있는 경우 정확히 똑같은가라는 뜻)을 처리가 가능하고 각 노드가 독립적으로 서비스가 가능합니다.

2. No Single Failure Point, No Master Node

Masterless 아키텍쳐로 인해서 Single Point Of Failure(SPOF)가 없다. 즉, 단일점에서 고장이나 실패가 일어나면 전체 시스템에 영향을 끼치는 경우가 없다라는 이야기입니다.

이는 대규모 분산 환경의 큰 장점 중에 하나입니다. 무제한 확장된 클러스터라도, 특정 노드 장애에 대해 종속이 되어버리면 시스템의 안정성에 많은 영향을 미치기 때문입니다.

단점

1. Cannot Change Ring Size

일반적인 Dynamo 기반의 아키텍쳐는 Ring Size와 Partition의 수를 변경할 수 없습니다. 데이터가 이미 Partition 별로 분산되어서 저장이 되기때문에 파티션의 개수를 변경하면 다시 데이타를 변경된 파티션 수에 따라 재분배해야하는 문제가 있기 때문입니다. 이는 데이터의 이동을 초래하게 되고 많은 I/O 부하를 유발하기 때문에 운영환경에서는 거의 불가능하다고 볼 수 있습니다.

2. Data Inconsistency

앞에서 설명한 바와 같이 데이터 복제가 실시간이 아니기 때문에 데이터에 대한 불일치가 발생합니다.

물론 R-Value, W-Value를 조정해서 Consistency를 보장받는 방법이 있긴 하지만 이 값을 높일 경우 동시에 여러 노드에 Read 또는 Write를 해야 하기 때문에 성능저하를 가져옵니다.

또한, Node간에 네트워크가 단절되는 Partitioning이 발생했을 때도 서비스는 되기 때문에 나중에 장애가 다시 극복 되었을때 Data가 서로 Inconsistency가 발생한다는 단점이 있습니다.

3. Sibling (Data Conflict 발생)

네트워크 Partitioning이 발생하거나 또는 동시에 두개의 Client가 Write를 했을때, Vector-Clock 값이 똑같아서 어느 데이터가 더 최근 데이터인지 판단할 수 없는 Data Conflict(Sibling현상)이 발생합니다.

* 여기서 Vector Clock은 이벤트의 부분적 순서를 생성하는 분산시스템의 알고리즘이라고 생각하시면 됩니다. Lamport timestamps의 원리와 같습니다.

예를 들어서 3개의 process들의 시스템 vector clock에 대해서 보면, logical clock에 대해서 생각을 해야합니다. 하나의 process는 하나의 clock이 배정되어 있습니다.

- 일단 A,B,C를 왼쪽부터 시작합니다. 시간은 왼쪽에서 오른쪽으로 이동하게 됩니다.

- 진행되는 하나의 직사각형을 process라고 하고 그 프로세스의 정보는 벡터형식으로 방향성을 가지고 움직입니다.

- 예를 들면, 처음 C에서 시간 1이 증가하고 그 프로세스의 정보는 B로 이동하여서 B의 1을 증가시킵니다. 여기서 증가시키는 것은 time에 대한 stamp입니다.

- 이러한 식으로 해당 작업에 관한 time stamp가 높은 것이 최신 Data로 판정되어서, 동일 데이터가 충돌하는 경우를 방지합니다.

그런데 단점 3번의 Sibling이 발생하는 이유는 Partitioning이 되어서 동시에 RW작업이 가능하기 때문에 clock의 값도 똑같도 데이터도 똑같은 경우가 생기기 때문에 선택할 수 없는 에러입니다.

*Reference

- Amazon Dynamo 계열의 NoSQL의 개요와 장단점 정리 - http://bcho.tistory.com/622