3주차 문제 - 6장 (키-값 저장소 설계) ~ 7장 (분산 시스템을 위한 유일 ID 생성기 설계)

[hodadako]

6장 (키-값 저장소 설계)

• CAP 정리의 세 가지 시스템 중 실세계에 존재하지 않는 시스템은 무엇인가요?
  CA 시스템
• 머클 트리에 대해 설명해 주세요.
  영구장애처리에서 반엔트로피 프로토콜(데이터 일관성의 불확실성이나 무질서도를 줄이는 방법)을 구현하여 사본들을 동기화할때 사용합니다. 사본 간의 일관성이 망가진 상태를 탐지하고 전송 데이터의 양을 줄이기 위해서는 머클 트리를 사용합니다. 서버 내의 키 공간을 여러 개의 버킷으로 나누고 모든 키에 균등 분포 해시를 적용한다. 버킷 별로 해시 값을 계산 하고 해당 해시 값을 레이블로 갖는 노드를 만든다. 자식 노드의 레이블로 부터 새로운 해시 값을 계산하여 이진트리를 상향 식으로 구성해 나간다. 이후에 루트 노드의 해시값 비교를 통해서 다르거나 같은 데이터들만 갖는 버킷들을 찾아서 동기화할 수 있다.

7장 (분산 시스템을 위한 유일 ID 생성기 설계)

• 다중 마스터 복제의 문제점을 설명해 주세요.
• 여러 데이터 센터에 걸쳐 규모를 늘리기 어렵다.
• 서버를 추가하거나 삭제할 때도 동작하도록 만들기 어렵다.
• 시계 동기화를 해결하기 위해 사용하는 가장 보편적인 방법은?
  NTP (Network Time Protocol), GPS, PTP

[oxix97]

6장

• 멀티캐스팅의 경우 서버 장애를 감지하는 가장 손쉬운 방법이지만 서버가 많을 수록 비효율적입니다. 그렇다면 분산형 장애 감지 솔루션은 어떤 것이 있을까요?
• 데이터일관성의 수준을 결정하는 일관성 모델 종류 3가지

7장

• UUID는 단순하게 생성가능하며 서버 사이의 조율도 필요가 없는 좋은 방법입니다. 그렇다면 단점을 말해주세요
• 유일 ID를 생성할 때 auto_increment 속성이 설정된 관계형 데이터베이스의 기본키를 사용하면 안되는 이유를 설명해주세요

[Hju95]

6장

• 해시 트리에는 버킷에 포함된 각각의 키에 ? 함수를 적용하여 해시 값을 계산하는 단계가 있다.
  A : 균등 분포 해시
• 데이터 다중화에서 가상 노드를 사용한다면 N개의 노드가 대응될 실제 물리 서버의 개수가 N보다 작아질 수 있는데, 이 문제를 피하려면 어떻게 해야하나요?
  A : 노드를 선택할 때 같은 물리 서버를 중복 선택하지 않도록 해야한다.

7장

• 스노우 플레이크 ID 의 구조를 설명해주세요
  

• UUID가 동기화 이슈가 없는 이유는?
  A : 서버 간 조율 없이 독립적으로 생성 가능하기 때문에

[yoonseon12]

문제

6장

• 데이터를 다중화하면 가용성은 높지만 사본 간 일관성이 깨질 가능성은 높아진다. 이 문제를 해결하기 위해 (1)과 (2) 기술이 등장했다.
• 실세계에 CA 시스템이 존재하지 않는 이유는?

7장

• UUID는 총 몇 자리의 문자열로 만들어질까요?
• 분산 시스템에서 auto_increment 속성이 설정된 관계형 데이터베이스의 기본 키를 유일 ID로 사용할 수 없는 이유는?

답변

6장

• (1) : 버저닝, (2) : 벡터 시계
• 실세계에서 네트워크 장애는 피할 수 없는 일로 여겨지므로, 분산 시스템은 반드시 파티션 문제를 감내할 수 있도록 설계되어야 한다. 그러므로 실세계에 CA 시스템은 존재하지 않는다.

7장

• 32개의 16진수 문자(0-9 및 a-f)와 4개의 하이픈('-')으로 이루어진 36자리의 문자열
• 여러 노드가 자체적으로 auto-increment 값을 생성하면 중복된 ID가 발생할 수 있기 때문

[GBGreenBravo]

6장 (키-값 저장소 설계)

<그림1>
<그림1>은 다음 상황을 나타낸 것입니다.
안정 해시(노드 8개)를 채택하여, 데이터 파티션을 하고 있습니다.
높은 가용성과 안정성을 위해 서버에 비동기적으로 다중화를 하고 있습니다. 사본 개수가 3인 경우 <그림1>과 같은 읽기/쓰기 처리를 합니다.
쓰기 연산에 대한 정족수와 읽기 연산에 대한 정족수는 모두 2로 설정돼 있습니다.
<그림1>의 경우에는 노드가 ( )이/가 되어 클라이언트와 노드 사이에서 프록시(Proxy) 역할을 합니다.

1. <그림1> 설명의 괄호 안 빈칸에 알맞은 단어를 작성해주세요.

• 중재자; 프록시(Proxy)는 “대리”의 의미

2. <그림1>에서는 강한 일관성이 보장돼 있습니다. ( O / X )

• O; 해설: 2 + 2 > 3. W(쓰기 연산에 대한 정족수) + R(읽기 연산에 대한 정족수) > N(사본 개수) : 강한 일관성이 보장됨. 사본 개수 ≠ 노드개수. 사본 개수를 노드 개수와 헷갈리면 안됨.

3. 은행권 시스템의 경우는 CP시스템과 AP시스템 중 어떤 것을 선택하는 것이 적절할까요?

• CP 시스템; 은행권 시스템은 보통 데이터 일관성을 양보하지 않는다.

7장 (분산 시스템을 위한 유일 ID 생성기 설계)

4. (다중 마스터 복제, 티켓 서버, 트위터 스노플레이크 접근법과 비교한) UUID의 단점 3가지를 설명해 주세요.

• 1. ID가 128비트로 길다. 2) ID를 시간순으로 정렬할 수 없다. 3) ID에 숫자가 아닌 값이 포함될 수 있다.

[c0olcode]

6장

• CAP 정리에 대해 설명해주세요.
  • 데이터 일관성(consistency), 가용성 (availability), 파티션 감내(partition tolerance), 세 가지의 요구사항을 동시에 만족하는 분산 시스템을 설계하는 것은 불가능하다는 정리다. 실생활에서는 네트워크의 장애 같은 문제로 파티션이 생기는 일은 무조건 있기 때문에, CP시스템과 AP시스템이 쓰인다.
• 일시적 장애를 처리하기 위해 느슨한 정족수 접근법을 사용한다. 간단하게 말하면 장애 서버로 가는 요청은 다른 서버가 잠시 맡아 처리하는 방법인데, 이 때 그동안 발생한 변경사항은 장애 서버가 복구되었을 때 일괄 반영되어서 데이터 일관성을 보존해야 한다. 이를 위해 쓰기 연산을 처리한 서버는 그에 관한 단서를 남겨두는데 이 방법을 무엇이라 하나요?
  • 단서 후 임시 위탁
• 장애 감지를 위해 모든 노드 사이에 멀티캐스팅 채널을 구축하면, 서버가 많아졌을 때 비효율적이게 됩니다. 이 때 장애를 감지하기 위해 멀티캐스팅 채널을 구축하는 대신 채택할 수 있는 솔루션은 무엇인가요?
  • 분산형 장애 감지 솔루션을 채택할 수 있다. 그 중에서도 책에 나온 방법은 가십 프로토콜이다. 이름 그대로 가십 거리가 금방 소문나듯 랜덤으로 노드를 지정하여 자신의 박동 카운트(가십)를 소문낸다. (멀티캐스팅 채널은 모든 노드와 소통함.) 각자의 노드는 자신의 박동 카운트를 일정 시점마다 업데이트하고, 다른 노드로부터 박동 카운트를 받으면 그 내용도 업데이트 한다. 만약 일정 시간 이상 박동 카운트가 업데이트 되지 않으면 장애 상태로 간주한다.
  • Gossip Protocol

7장

• 티켓 서버의 단점은 무엇인가요?
  • 티켓 서버가 SPOF(Single Point Of Failure)가 된다. 이 서버에 장애 발생하면 모든 시스템이 영향 받음 → 티켓 서버 여러대 준비하면 데이터 동기화 이슈 등의 새로운 문제가 발생한다.