Amazon Dynamo 계열의 NoSQL의 개요와 장단점 정리

분산 환경 기반의  NoSQL은 예전 포스팅에서도 설명했듯이 크게 Google의 BigTable 논문을 기반으로한 시스템과, Amazon의 Dynamo를 기반으로 한 시스템 두가지로 나뉘어 진다.
Dynamo 계열의 NoSQL의 장단점을 간단히 정리해보면

Dynamo 계열 NoSQL의 개요

1. Ring과 Consistent Hasing
먼저 Dynamo 계열 (Cassandra, Riak) 의 NoSQL의 특징은 Ring 토폴로지를 기본으로 하고 있다. Ring 구성이란, 전체 데이타를 1~N (2^160과 같이 큰 범위로) 이라는 특정 레인지로 정의한후 전체 데이타 저장 구조를 Ring 형으로 정의한 후에, 이 Ring을 피자 조각을 나누듯이 여러 Slice로 나눈다. 이를 Partition이라고 하는데, 각 Partition은 데이타를 저장하는 구간 정보를 가지고 있다. 예를 들어 전체 Ring이 1000개의 데이타를 저장한다고 하고, 각 Partition의 수를 10개로 지정하면 첫번째 파티션은 0~999, 두번째는 1000~1999 까지의 키를 가지는 데이타를 저장한다. 이르 통해서 저장하고자 하는 데이타의 키를 알면 어느 파티션에 저장할 수 있는지 쉽게 찾아갈 수 있기 때문에, 각 Partition을 저장하는 하드웨어(Node)에 부하를 분산 시킬 수 있는 구조를 갖는다. 이런 방식을 Ring 기반의 Consistent Hashing이라고 이야기 한다.

2. N-Value & Quorum
이 경우 특정 파티션을 저장하고 있는 Node가 장애가 났을때, 특성 파티션의 데이타 유실이 발생할 수 있는데, 이를 방지하기 위해서 Node간의 데이타 복제를 수행한다. 몇 개의 복제본을 갖느냐를 정해야 하는데, 이 복제본의 수를 보통 "N-Value" 또는 "Quorum" 이라고 정의하며, 이 Quorum의 수는 일반적으로 3개 정도로 지정한다.
이 N-Value를 3으로 지정하는 이유는 여러가지가 있겠지만, 장애 대응면에서 최소한 하나의 복제본을 가져야하기 때문에 2개의 복제본이 필요하고, 예측된 작업(패치,서버 교체)시에도 장애를 대응하기 위해서 최소한 두개의 복제본을 유지해야 하기 때문에 일반적으로 3개의 복제본을 생성한다. (이 N-Value는 NoSQL 설정에서 조정할 수 있다.)

3. R-Value, W-Value
앞에 설명한 것 처럼, N-Value의 복제본을 가지게 되는데, Dynamo Architecture는 R-Value와 W-Value라는 특성을 유지 한다. 이 값은 "성능과, 데이타 정합성간의 Trade-Off"를 위한 값인데, 데이타 복제는 실시간으로 이루어지지 않는다. 약간의 Delay가 발생한다 (수 밀리세컨드, 데이타 센터간에는 조금더 길 수 있다.)
N-Value를 3이라고 가정하자. 첫번째 Node에 Write를 한후에,  두번째 Node와 세번째 Node에 데이타가 복제 되어야 한다. 이 복제과정에서 데이타를 읽을때, 이 3 노드 중에서 데이타를 몇개의 노드에서 데이타를 읽어올지를 결정하는 것이 R-Value이며. 동시에 몇개의 Node에 Write할것인가를 결정하는 것이 W Value이다.
만약에 W-Value가 2이면 Write시에 동시에 두개의 Node에 Write한다. R-Value가 1보다 클 경우 R-Value 노드 에서 데이타를 읽어오고, 두 개의 데이타가 다를 경우 최근 데이타를 사용한다.

이런 이유로 R-Value + W-Value > N-Value이면 Data Consistency가 보장된다.
예를 들어 N=3일때, R=2,W=2이면, Write시 적어도 두개의 복제본에 썼기 때문에, 하나가 복제가 안되어 있다하더라도, R-Value가 2이기 때문에, 꼭 하나는 새로운 데이타가 읽어지게 되고, 새로운 데이타를 Winning하는 정책 때문에 항상 최신의 데이타를 읽을 수 있다. (여기서 새로운 데이타를 판단 가능하게 하는 방법을 Vector-Clock이라고 한다. 이는 나중에 따로 포스팅 예정)

참고 : http://wiki.apache.org/cassandra/ArchitectureOverview 

Consistency

See also the API documentation.

Consistency describes how and whether a system is left in a consistent state after an operation. In distributed data systems like Cassandra, this usually means that once a writer has written, all readers will see that write.

On the contrary to the strong consistency used in most relational databases (ACID for Atomicity Consistency Isolation Durability) Cassandra is at the other end of the spectrum (BASE for Basically Available Soft-state Eventual consistency). Cassandra weak consistency comes in the form of eventual consistency which means the database eventually reaches a consistent state. As the data is replicated, the latest version of something is sitting on some node in the cluster, but older versions are still out there on other nodes, but eventually all nodes will see the latest version.

More specifically: R=read replica count W=write replica count N=replication factor Q=QUORUM (Q = N / 2 + 1)

• If W + R > N, you will have consistency

• W=1, R=N
• W=N, R=1
• W=Q, R=Q where Q = N / 2 + 1

Cassandra provides consistency when R + W > N (read replica count + write replica count > replication factor).

You get consistency if R + W > N, where R is the number of records to read, W is the number of records to write, and N is the replication factor. A ConsistencyLevel of ONE means R or W is 1. A ConsistencyLevel of QUORUM means R or W is ceiling((N+1)/2). A ConsistencyLevel of ALL means R or W is N. So if you want to write with a ConsistencyLevel of ONE and then get the same data when you read, you need to read with ConsistencyLevel ALL.

4. Masterless Architecture
또다른 특징 중에 하나는 Masterless 아키텍쳐이다. Ring을 구성하고 있는 아무 Node에나 요청을 보내도 처리가 되고, 전체 설정 정보를 가지고 있는 마스터 노드나 Admin 노드가 없다.
10개의 노드를 가지고 있는 Ring의 아무 Node에나 Request를 하더라도, 각 Node는 해당 데이타가 다른 어느 Node에 저장되어야 하는지를 Consistent Hash를 통해서 알 수 가 있고, 해당 노드로 Request를 Routing한다. 이때 자기가 데이타를 가지고 있지 않더라도 첫번째 요청을 받은 Node가 데이타를 처리하는 이 노드를 Coordinator Node라고 정의한다.

지금까지 대략적인 Dynamo 아키텍쳐의 특성에 대해서 알아보았다. 그러면 어떤 장단점이 있을까?

장점
1. High Availibility & Partition Tolerence
위와 같은 특성 때문에, 분산 시스템의 CAP 이론에서 A와 P에 최적화 되어 있다. 특정 노드가 장애가 나더라도 서비스가 가능하며 (A-Availibility) Node간의 네트워크 통신이 끊어지더라도 서비스가 가능하다 (P-Partition Tolerance : Vector Clock을 이용하여 데이타의 정합성을 처리가 가능하고 각 노드가 독립적으로 서비스가 가능

2. No Sigle Failure Point. No Master Node
그리고 Masterless 아키텍쳐로 인해서 Single Failure Point (SFP)가 없다. 이는 대규모 분산 환경에서 아주 큰 장점 중의 하나인데, 무제한 확정된 클러스터라도, 특정 노드 장애에 대해 종속이 되어 버리면 시스템의 안정성에 많은 영향을 미친다.

단점
반대로 단점은
1. Cannot Change Ring Size
일반적인 Dynamo 기반의 아키텍쳐는 Ring Size (Partition 수)를 변경할 수 없다. 데이타가 이미 Partition 별로 분산 저장되어 있기 때문에 파티션의 개수를 변경하면 다시 데이타를 변경된 파티션 수 에 따라 재 분배해야 한다. 이는 데이타의 이동을 초래하고, 많은 IO 부하를 유발하기 때문에 운영환경에서는 거의 불가능하다고 봐야 한다.

2. Data InConsistency
앞에서 설명한 바와 같이 데이타 복제가 실시간이 아니기 때문에 데이타에 대한 불일치가 발생한다. 물론 R,W Value를 조정해서 Consistency를 보장받는 방안은 있지만, 이 값을 높일 경우 동시에 여러 노드에 Read 또는 Write를 해야 하기 때문에 성능저하가 발생할 수 있고, 또한 Node간에 네트워크가 단절되는 Partitioning이 발생했을 때도 서비스는 되기 때문에, 다시 장애가 극복되었을때는 당연히 Data InConsistency가 발생하게 된다.

3. Sibling (Data Conflict 발생)
특히 네트워크 Partitioning이 발생하거나 또는 동시에 두개의 Client가 Write를 했을때, Vector-Clock 값이 똑같아서 어느 데이타가 더 최근 데이타인지 판단할 수 없는 Data Conflict (Sibling현상)이 발생한다. (Sibling의 자세한 개념은 나중에 Vector Clock 설명에 같이 추가)