어휘를 묶어서 공부해요!

카산드라가 여러 개의 노드(클러스터)로 구성되었다면 모든 노드에 동일한 데이터 세트가 저장될까요? 만약 모든 노드에 동일한 데이터 세트를 저장한다면 아래의 그림처럼 모든 노드가 '홍길동', '이순신', '김유신' 데이터를 가진 모습일 것입니다. 물론 Availability는 매우 증가합니다만, 노드가 증가할수록 모든 노드에 동일 데이터를 복제하기 위해 카산드라는 매우 바쁘게 일해야 할 것입니다. 그리고 대용량의 데이터를 모든 노드에 저장하는 것은 그만큼의 디스크를 확보해야 하므로 비용적인 측면에서는 매우 비효율입니다. 카산드라는 데이터를 모든 노드에 복제하기보다는 아래의 그림처럼 특정 노드에 할당합니다. 그러면 데이터를 모든 노드에 복제하기 위해 바쁠 필요가 없습니다. 그리고 이웃한 한 두 개의 노드에 ..

카산드라는 데이터를 여러 노드에 분산하여 저장합니다. 즉, 노드마다 할당된 데이터가 다릅니다. 클라이언트는 카산드라에 접근하기 위해 특정 노드에 접속합니다. 아래 그림의 ①번에 해당합니다. 이처럼 클라이언트가 접속한 노드를 코디네이터라 합니다. 데이터 읽기 코디네이터는 클라이언트가 요청한 데이터가 클러스터의 어느 노드에 있는지 확인 후 해당 노드에 데이터를 요청합니다. 아래 그림의 ②번에 해당합니다. 해당 노드는 요청받은 데이터를 코디네이터로 전달합니다. 아래 그림의 ③번에 해당합니다. 끝으로 코디네이터는 전달받은 데이터를 클라이언트로 전달합니다. 아래 그림의 ④번에 해당합니다. 데이터 쓰기 코디네이터는 클라이언트가 저장하려는 데이터가 클러스터의 어느 노드에 저장되어야 하는지 확인 후 해당 노드에 데이터..

아래의 그림에서 표현된 노드가 연결된 구조를 링(Ring)이라 합니다. 카산드라는 링을 구성하는 여러 노드가 모두 동등합니다. 즉, 마스터(Master) 역할을 하는 노드가 존재하지 않습니다. 그러나 상식적으로 클라이언트는 카산드라의 노드에 접근할 때 특정 노드를 지정할 수밖에 없습니다. 아래의 그림에서는 7번 노드를 예로 들었습니다. 이처럼 클라이언트가 접근한 노드는 특별한 역할을 합니다. 이를 코디네이터(Coordinator)라 합니다. 클라이언트에서 카산드라에 접근하려면 접속할 노드를 지정해야 합니다. 해당 노드는 코디네이터 역할을 하며 다음과 같은 일을 합니다. - 클라이언트가 요청한 데이터를 해당 노드에서 읽어서 클라이언트로 전달 - 클라이언트가 입력한 데이터를 해당 위치의 노드에 저장

카산드라를 구성하는 가장 단순한 구조는 하나의 서버에 하나의 노드(Node)를 설치하는 것입니다. 이 경우 모든 데이터는 하나의 노드에 저장됩니다. 그러나 해당 노드에 장애가 발생하면 카산드라의 서비스는 중단됩니다. 그러므로 카산드라는 Availability와 Partition tolerance를 충족하기 위해 여러 개의 노드를 연결하는 구조로 구성합니다. 노드 간의 연결을 링(Ring)이라 하며 아래와 같이 표현할 수 있습니다. 카산드라의 노드를 위의 그림처럼 논리적으로 표현할 수 있지만 실제로는 아래의 그림에 더 가깝습니다. 위의 링 구조를 물리적으로 구성한 구조를 클러스터(Cluster)라 합니다. 클러스터를 단순하게 표현하면 하위의 노드가 랙(Rack)으로 묶여 데이터 센터에 포함됩니다. 그리고 ..

카산드라는 CAP 원칙에서 A(Availability)와 P(Partition tolerance)*를 지향합니다. Availability와 Partition tolerance를 충족하기 위해 카산드라는 일반적으로 여러 개의 물리적 노드(Node)로 구성합니다. 그런데 물리적으로 분리된 여러 개의 노드로 구성하더라도 노드가 설치된 건물에 정전이 발생할 수 있습니다. 이 경우에는 Availability와 Partition tolerance를 충족하기 어렵습니다. 그래서 노드를 다른 건물이나 시설에 분리하여 구성합니다. * CAP 원칙 참조 카산드라 구성 시 랙(Rack)은 노드의 논리적인 그룹이라고 정의하며 데이터 센터(Data Center)는 랙의 논리적인 그룹이라 정의합니다. 이를 쉽게 그림으로 표현하면..

먼저 짚고 갈 것은 CAP Theorem에 대한 번역입니다. 버클리 대학교의 명예 교수인 에릭 브루어(Eric Allen Brewer)는 1998년 가을에 CAP 원칙을 소개하였습니다. 당시에는 이론으로서 발표되었으나 2002년에 MIT 교수인 낸시 린치(Nancy Ann Lynch)와 세스 길버트(Seth Gilbert)에 의해 공식적으로 증명되었습니다. 이로써 CAP Theorem이라 명명되었습니다. Theorem은 증명된 이론으로 한국어로 번역하자면 '정리'라 할 수 있습니다. CAP 이론, CAP 정리, CAP 원칙 등 다양한 명칭으로 알려졌지만, 본질을 훼손하는 명칭이 아닌 이상 특정 용어를 강요할 필요는 없습니다. 본 블로그에서는 'CAP 원칙'을 사용하기로 합니다. CAP 원칙을 이해하기 위..

NoSQL 연구소의 허 수석입니다. ​ NoSQL의 이해와 활용을 목적으로 본 블로그를 개설하였습니다. ​ NoSQL의 활용처가 계속 증가하고 RDB로 한정되었던 영역까지도 NoSQL을 도입하려는 시도는 NoSQL의 무한한 가능성을 시사합니다. ​ 수 많은 DB들이 NoSQL 진영에서 태어났고 지금도 계속 진화하고 있습니다. 본 블로그는 진화하는 NoSQL 지식을 기록하려고 합니다. NoSQL에 관심을 갖는 모든 분들에게 쓸모있는 지식을 전달하는 채널이 되기 위해 노력하는 연구소가 되겠습니다.

2012년 Netflix 서비스가 중단되는 사태가 발생하였습니다. 크리스마스이브에 발생한 사고입니다. 크리스마스 시즌이라서 가장 활발한 유입이 예상되던 시기였기에 Netflix 입장에서는 치명적인 사고로 기억될 것입니다. 서비스 중단의 원인은 당시 Netflix 서비스를 제공하던 AWS(Amazon Web Services)의 장애 때문이었습니다. 한 곳의 AWS 존(Zone)에서 Netflix 서비스를 제공한 것이 원인이었습니다. 해당 존에서 발생한 장애는 Netflix 서비스를 통째로 마비시켰던 것입니다. 이렇게 하나의 장애가 전체의 장애를 초래하는 것을 Single Point Of Failure라고 합니다. 아무리 훌륭한 서비스라도 중단된다면 고객의 신뢰를 잃게 됩니다. Netflix는 이때의 경험을..

Scalability의 사전적 의미로 설명을 하면 다음과 같습니다. "Scalability는 작업량이 증가할 때 리소스를 추가하여 처리하는 시스템의 특성이다." Scalability를 한국어로 번역을 하면 '확장성'이라고 말할 수 있습니다. '확장성'이라는 말은 늘어나는 성질을 의미하므로 Scalability의 성격을 잘 대변하는 단어라 할 수 있습니다. 그러나 '확장성'이라는 말은 줄어드는 성질을 표현하기에는 무리가 있습니다. 리소스를 축소하는 경우도 충분히 예상해 볼 수 있으므로 '확장성'만으로 Scalability를 온전히 표현하는 것은 무리가 있습니다. 그래서 Scalability를 굳이 번역하여 표현하지 않습니다. 요즘은 클라우드라는 IT 용어를 IT와 관련 없는 사람들도 쉽게 사용합니다. 그만..

실력이라는 것은 평가하는 기준에 따라 달라집니다. 요리를 잘하는 두 사람을 예로 들어 설명해 보겠습니다. A라는 사람은 최상의 요리를 만듭니다. 그러나 한 번에 소수의 사람만 먹을 수 있을 정도의 양만 만들 수 있습니다. B라는 사람은 최상의 맛은 아니더라도 맛있는 한 끼로 손색없는 요리를 만듭니다. 그리고 한 번에 만들 수 있는 양도 수백 명이 먹을 수 있을 정도로 많습니다. A와 B의 경우 요리 실력이 더 뛰어난 사람은 누구일까요? 맛이 기준이라면 A이겠지만 많은 손님을 대접해야 하는 상황이라면 B일 것입니다. 따라서 특별한 한두 명의 손님을 대접해야 하는 경우는 A를 요리사로 선택하겠지만 수백 명의 하객을 대접해야 한다면 B를 선택할 것입니다. 이처럼 상황은 선택에 영향을 미칩니다. Netflix를..