어휘를 묶어서 공부해요!

아래의 그림에서 표현된 노드가 연결된 구조를 링(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 원칙을 이해하기 위..

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를..

이제는 Column Family에 관해 설명하겠습니다. 가장 쉽게 이해하는 방법은 엑셀의 시트를 예로 드는 것입니다. 앞서 예로 든 학생 정보를 엑셀의 시트에 입력한다면 어떤 모양이 될까요? 아마도 우리는 다음과 같이 첫 줄에 번호, 이름, 나이, 핸드폰번호, 유선전화번호, 이메일을 입력할 것입니다. 우리는 아래의 표에서 세로줄을 한국어로는 '열', 영어로는 Column이라고 부릅니다. 번호 이름 나이 핸드폰번호 유선전화번호 이메일 1 홍길동 14 02-1234-4567 hong@gmail.com 2 이순신 14 010-222-5678 lee@gmail.com 학생 정보 시트는 다음의 항목들을 가집니다. 번호, 이름, 나이, 핸드폰번호, 유선전화번호, 이메일 그런데 항목마다 학생이 가지는 값이 다릅니다...

Key: Value를 설명하면서 Value에 여러 값이 들어가는 예를 들었습니다. Key Value 1학년:1반:1번 이름: 홍길동, 나이: 14, 전화번호: 010-111-1234, 이메일: hong@gmail.com 위의 예와 같이 Document는 여러 값의 묶음이라 할 수 있습니다. 그러나 여러 값을 묶을 때 따라야 할 규칙이 있습니다. 앞서 Value 안의 여러 값을 구분하기 위해 Value 내에서도 Key를 지정한다고 설명했습니다. 마찬가지로 Document의 여러 값을 구분하기 위한 Key를 지정해야 합니다. JSON, XML 형식은 Key와 Value를 표현하는 데 매우 유용합니다. 위의 Key: Value 내용을 JSON과 XML로 표현한 예를 보겠습니다. JSON 형식 { "이름": "..

NoSQL의 저장방식의 한 종류로 Key: Value 형식이 있습니다. 다른 형식의 NoSQL은 Key: Value의 확장형이라 해도 좋을 만큼 Key: Value는 NoSQL 저장 방식의 근간을 이루고 있습니다. Document 형식이나 Column Family 형식도 그 안을 들여다 보면 Key: Value의 묶음으로 구성됩니다. Key: Value는 매우 단순한 구조입니다. 학생을 예로 들어 생각해 보겠습니다. 한 학급의 학생은 이름과 번호를 가집니다. (단, 여기서 번호는 1, 2, 3, ... 자연수로 부여한 번호입니다.) 서로 다른 번호 때문에 같은 이름의 학생이 있더라도 번호로 구분됩니다. 즉, 1번 '홍길동'과 10번 '홍길동'은 다른 학생인 것입니다. 번호가 Key 역할을 하는 것입니다...