요구사항과 포기할 것 정하기

기능이 단순하므로 비기능과 범위 밖에 집중합니다.

가장 중요한 항목은 분단 중에도 쓰기를 받는다와 노드 두 대가 동시에 죽어도 데이터가 남는다입니다. 앞의 것이 구조를, 뒤의 것이 사본 수를 정합니다.

흔한 실수: 범위 밖을 말하지 않는 것. 여러 키를 묶는 트랜잭션 하나만 남겨도 노드 사이 합의가 필요해지고 아래의 모든 선택이 달라집니다. 무엇을 뺐는지가 이 설계에서는 특히 큰 차이를 만듭니다.

리더를 포기하고, 같은 키에 두 값이 생기는 것을 받아들입니다.

네트워크가 갈라졌을 때 양쪽이 각자 쓰기를 받아야 합니다. 리더가 한쪽에 있으면 반대쪽 사용자는 쓰기를 할 수 없습니다.

리더가 있으면: 리더 쪽만 쓰기를 받는다
리더가 없으면: 양쪽이 받는다. 대신 값이 갈린다

그래서 어느 사본이든 쓰기를 받고 사본끼리 나중에 맞춥니다. 고른 것은 가용성이고 낸 값은 충돌 해소라는 새 숙제입니다.

흔한 실수: 가용성을 골랐다고만 말하고 대가를 말하지 않는 것. 면접에서는 곧바로 "그러면 같은 키에 두 값이 생기면 어떻게 하나요" 가 이어집니다. 선택과 대가를 한 문장에 담는 것이 이 결정을 이해했다는 신호입니다.

셋입니다. 요구사항이 노드 두 대의 동시 사망을 견디라고 했기 때문입니다.

사본이 둘이면 두 대가 함께 죽을 때 그 데이터가 사라집니다. 셋이면 하나가 남습니다.

셋보다 많으면 저장 비용이 그만큼 늘어납니다. 100TB 에 사본 셋이면 실제 저장량이 300TB 입니다.

견뎌야 하는 동시 사망 대수 + 1 = 필요한 사본 수

요구사항이 두 대까지라고 정했으므로 셋에서 멈춥니다. 더 두는 것은 요구사항 없이 비용을 늘리는 일입니다.

흔한 실수: 사본 수를 관례로 정하는 것. 셋이 흔한 값이지만 이유는 요구사항에서 나와야 합니다. 랙이나 지역 단위 장애까지 견뎌야 한다면 사본 수뿐 아니라 배치 규칙도 함께 정해야 하고, 그 요구가 없으면 셋으로 충분합니다.

정확한 순서나 즉시 일관성이 필요한 데이터입니다. 잔액과 재고가 대표적입니다.

리더가 없으므로 "가장 최근 값" 을 아무도 확정해 주지 않습니다. 읽는 쪽이 낡은 값을 볼 수 있고, 두 값이 함께 반환될 수도 있습니다.

이 성질을 응용에 알려야 합니다. 저장소가 감당하지 못하는 것을 응용이 모르면, 문제가 생겼을 때 원인을 저장소 장애로 오해합니다.

흔한 실수: 나중에 강한 일관성을 옵션으로 붙이겠다고 답하는 것. 리더가 없는 구조에서 강한 일관성은 읽기와 쓰기 모두를 느리게 만드는 별개의 설계입니다. 요구사항이 가용성을 골랐다면 그 대가를 응용과 나누는 편이 정직합니다.