Dynamo 는 2007년 경 Amazon.com에서 논문을 통해 공개하면서 처음 세상에 공개되었다. 그 후 2012년 1월경 AWS에서 서비스로 오픈하였는데 DynamoDB에 대해 자세히 알아보자.
NoSQL에 대해서 알아보면 NoSQL은 크게 구글에서 만든 Bigtable 게열과 Dynamo계열이 있다고 설명한 것을 볼 수 있다. 구글의 Bigtable과 Dynamo는 어떻게 다르며 Amazon은 왜 Dynamo 라는 분산저장시스템을 개발하였을까
1. Amazon 비즈니스 요구사항
먼저 구글의 Bigtable은 2006년 11월경에 발표되었고 Dynamo는 2007년 10월 정도에 발표되어 Dynamo가 1년 가량 늦게 발표되었다. 하지만 개발하는데 몇 년 이상 소요되었을 것이므로 서로 다른 요구사항으로 인해 독립적으로 개발되었다고 볼 수 있다. Dynamo는 어떤 비즈니스 요구사항으로 인해 탄생하였을까? 논문을 읽어보면 자세히 나와있다.
(1) 간단한 쿼리 모델
Dynamo는 get(key) 동작과 put(key,object)동작만을 지원하는데 Amazon.com에서 서비스하는 대부분이 Unique한 key만으로 조회하거나 쓰면 된다는 것이다. 여러 key를 동시에 조회해야 할 만큼 복잡한 쿼리도 필요없으며 관계형 DB가 필요하지도 않기 때문에 단순하지만 빠른 동작을 지원하는 아키텍처를 필요로 하게 되었다는 뜻이다. 오브젝트의 사이즈도 1MB 이내의 상대적으로 작은 경우에 적합하다. (구글의 Bigtable의 경우 큰 사이즈의 파일을 chunk라는 단위로 나누어 노드에 저장하도록 하고 있으며 상대적으로 큰 사이즈의 오브젝트를 저장할 때 유리함)
(2) 가용성을 살린 ACID(Atomicity, Consistency, Isolation, Durability)
RDBMS의 특징으로 항상 거론되는 ACID의 단점 중 하나는 가용성이 떨어진다는 것이다. 물론 RDBMS에서도 샤딩으로 가용성을 높일 수는 있지만 구성이 복잡하며 노드를 쉽게 추가하거나 제거할 수도 없다. 오라클의 RAC도 마찬가지..
Dynamo는 일관성인 C를 어느정도 포기하는 대신 가용성을 살린 ACID모델이라 할 수 있다.
분산모델에서 흔히 CAP모델을 사용하는데 보통 CAP에 대해 얘기하길 C(일관성)과 A(가용성)과 P(네트웍 분단허용)중 2개만 고를 수 있다고 설명한다. 옳은 설명이지만 언뜻 이해가 잘 가질 않는다.
이렇게 생각하면 더 편할 듯 하다.
” 네트웍 분단이 발생하면 일관성과 가용성 중 하나만 선택할 수 있다”
물론 하나만 선택할 수 있다고 해서 나머지 하나는 꼭 버려야 한다는 것은 아니며 둘 중에 하나는 약간 포기해야 한다 정도로 이해하면 되겠다.
DynamoDB는 AP를 선택한 모델이라고 볼 수 있다. 참고로 구글의 Bigtable은 일관성을 선택한 CP모델에 가까운데 아마존은 왜 AP모델을 선택했을까?
Amazon.com의 특징상 시스템이 잠시라도 멈추면 peak 시간대의 고객이 이탈하게 되고 금전적 손실이 많아진다는 사업모델의 특징 때문이다.
즉 일관성이 손상되는 한이 있더라도 항상 시스템이 가용하도록 하겠다는 것인데, 일관성은 필요 없다는 것인가? 아니면 극복할 방안을 마련하는 것일까?
결론부터 말하자면 필요시 어플리케이션(클라이언트)의 개입에 의해 일관성을 맞출 수 있는 방법으로 일관성 충돌을 극복한다.
2. Dynamo의 디자인
Amazon 비즈니스에서 필요로 하는 데이터 저장소의 요건은 위에서 대략 살펴보았으며 이제 Dynamo의 디자인 원칙에 대해 알아보자.
(1) 확장성(Scalability)
모든 NoSQL이 갖추고 있는 특징이기도 하지만 Dynamo도 확장성을 전제조건으로 한다. 시스템에 노드가 추가되거나 제거될 때 시스템에 주는 영향을 최소화해야 한다.
(2) 대칭성(Decentralization)
구글의 Bigtable과 가장 차이나는 부분 중 하나인데, 마스터 노드를 두는 Bigtable 과는 달리 Dynamo는 마스터 노드가 없으며 모든 노드가 동등한 역할을 한다. 아마존의 경험상 이런 대칭성이 시스템 프로비저닝과 유지보수을 더 쉽게 할 수 있다고 한다.
(3) 비집중화(Decentralization)
위에서 설명한 대칭성과 같은 의미인데, 읽기나 쓰기 요청을 수행하는 마스터노드의 개입이 없이 클라이언트와 노드가 직접 통신하는 구조의 Peer to Peer 를 사용한다는 것이다. 클라이언트가 노드를 찾아가는 방식에는 두 가지 방법이 있는데 로드밸런서가 클라이언트의 요청을 load balancing하는 방법과 클라이언트가 어플리케이션 로직을 통해 직접 노드를 찾아가는 방식이 있다. 후자의 방법이 네트웍 Hop이 적기 때문에 더 빠르다고 한다.
(4) 이질성(Heterogeneity)
이질성 단어만 보면 무슨 의미인지는 좀 헷갈리는데
Dynamo는 노드들의 성능에 따라 Load의 분배가 이루어진다. 더 좋은 성능의 Node가 추가되면 해당 노드가 로드를 더 받는다는 것이다. 노드의 성능을 업그레이드 할 때 전체를 Down시키고 업그레이드 하는 것보다 하나씩 추가하는 방법은 가용성 측면에서 필수 불가결한 방식이다.
(5) 항상 쓰기 가능
네트웍 단절이나 노드 장애가 발생한 상황이거나 동시쓰기가 들어오더라도 쓰기 요청은 하나라도 소실되지 않고 모두 기록된다. 이것이 Dynamo가 일관성을 약간 희생시킨 부분인데 동시 쓰기로 인해 충돌이 발생한 경우 충돌난 값을 모두 보여주어 클라이언트가 개입, 하나를 선택하도록 한다.
다음 글에서는 위에서 설명한 Dynamo의 디자인 특징을 구체적으로 어떻게 구현하였는지 자세히 알아보도록 한다.
wwarchblog 