키 하나로 읽고 쓰는 API는 단순하지만, 동시에 성공한 쓰기와 뒤처진 사본은 자동으로 사라지지 않습니다. 정족수 숫자보다 충돌 책임과 수리 완료 조건을 먼저 정합니다.
시스템 디자인 운영자 · coreline-ai
개념 이해면접 답변운영 관점진도 저장
▦30초 핵심 요약
N=3·W=2·R=2의 교집합만으로 최신 값이 자동 결정되지는 않습니다. 충돌한 형제 버전을 보존하고 업무 병합·read repair·anti-entropy까지 연결해 갈라진 사본이 다시 수렴하는 조건을 명시합니다.
데이터 세트 (설계 가정)100억 키 · 약 10TB
복제 후 저장량 (계산 결과)N=3 → 약 30TB
정족수 예시 (설계 가정)N=3 · W=2 · R=2
01 · REQUIREMENTS
무엇을 보장해야 하는가?
# 요구사항
관계형 질의가 아닌 키 기반 접근을 전제로 하되, 용량·처리량·장애 빈도는 계속 증가한다고 가정합니다.
F1단순한 API
put(key, value)와 get(key)에 버전 컨텍스트를 함께 전달합니다.
F2수평 확장
노드 증감 때 전체 데이터를 옮기지 않고 일부 키만 재배치합니다.
F3장애 허용
일부 사본·경로가 실패해도 선택한 정족수만 만족하면 응답합니다.
F4충돌 가시화
동시 쓰기를 숨기지 않고 버전·병합 책임을 명시합니다.
02 · HIGH-LEVEL DESIGN
코디네이터와 세 복제본
# 아키텍처
요청을 받은 코디네이터가 일관된 해싱 링에서 담당 복제본을 계산하고, 쓰기에는 W개의 ACK, 읽기에는 R개의 버전을 모읍니다.
복제·정족수 읽기/쓰기 흐름 SVG DIAGRAM · N=3, W=2, R=2는 설계 가정
교집합의 한계 · W + R > N은 읽기·쓰기 사본의 교집합을 만들지만, 동시 쓰기 순서·버전 비교·실패 감지가 부정확하면 선형 일관성이 자동으로 생기지 않습니다.
DESIGN DECISION · 설계 판단
동시 쓰기가 갈라졌을 때 어느 값을 정본으로 둘 것인가?
예시 데이터 세트약 10TB
계산 결과
예시 피크 QPS읽기 50만 · 쓰기 20만
설계 가정
예시 복제 계수N = 3
설계 가정
최종 선택
조절 가능한 Quorum + 형제 버전 보존 + 의미 기반 병합
N=3·W=2·R=2를 기본으로 쓰되, 동시에 생긴 버전은 시각으로 덮어쓰지 않습니다. 형제 버전을 업무 서비스가 병합하고 read repair와 anti-entropy로 세 사본을 수렴시킵니다.
선택 이유
장애 구간에도 쓰기를 이어가면서 어떤 값이 갈라졌는지 숨기지 않습니다.
장바구니·사용자 설정처럼 도메인 의미가 있는 병합을 저장소의 임의 타임스탬프보다 우선합니다.
형제 버전 수, hinted handoff 체류, Merkle 차이를 복구 완료 지표로 사용할 수 있습니다.
포기한 대안
물리 시각 기반 last-write-wins
구현은 단순하지만 네트워크 단절과 클록 오차가 겹치면 사용자가 방금 쓴 값을 조용히 잃습니다. 충돌을 숨기기보다 버전 문맥을 보존합니다.
감수한 단점
클라이언트나 업무 서비스가 형제 버전 병합 규칙을 가져야 합니다.
충돌을 허용할 수 없는 잔액·재고 키는 리더나 합의 기반 조건부 쓰기로 분리해야 합니다.
Hinted Handoff와 anti-entropy가 오래 밀리면 일시 충돌이 장기 불일치로 바뀝니다.
03 · READ / WRITE FLOW
읽기와 쓰기는 어떻게 끝나는가?
# 처리 흐름
1키 배치 계산
일관된 해싱과 가상 노드로 담당 N개 복제본을 찾습니다.
2병렬 쓰기
W개 ACK를 받으면 성공 응답하고 나머지는 힌트로 보관합니다.
3병렬 읽기
R개 버전을 비교해 최신 값 또는 충돌 버전 집합을 반환합니다.
4사본 수리
읽기 수리와 Merkle Tree 안티 엔트로피로 장기 불일치를 줄입니다.
04 · TRADEOFFS
정족수와 충돌 해결의 선택
# 트레이드오프
정족수를 높일수록 항상 좋은 것은 아닙니다. 지연·가용성·충돌 책임이 함께 바뀌므로, 이 문서에서는 충돌을 감추기보다 보존하고 업무 규칙으로 병합하는 쪽을 선택합니다.
선택
강점
주의점
적용 예
N=3, W=2, R=2
읽기·쓰기 사본 교집합
느린 사본 2개면 요청 실패
일반 데이터
W=1
낮은 쓰기 지연
읽기 시 충돌·오래된 사본 가능성 증가
가용성 우선
서버 병합
클라이언트 단순
도메인 의미를 모르면 잘못 병합
카운터·집합
클라이언트 병합
업무 의미 반영
SDK·UX 복잡도 증가
장바구니 등
05 · FAILURE MODES
장애 시나리오와 대응
# 장애 대응
!노드 장애
복제본 하나가 응답하지 않아도 요청은 계속 들어옵니다.
대응 · hinted handoff로 임시 사본을 보관하고 복귀 후 전달합니다.
⌁네트워크 분단
양쪽에서 쓰기가 허용되면 버전이 갈라질 수 있습니다.
대응 · 벡터 클록·병합 정책으로 충돌을 명시적으로 반환·해결합니다.
↗핫 파티션
특정 키 범위에 QPS가 집중되어 한 노드만 느려집니다.
대응 · 가상 노드, 키 분할, 캐시와 파티션별 편차 관측을 사용합니다.
◷시계 역행
물리 타임스탬프만으로는 오래된 값을 최신으로 오판할 수 있습니다.
대응 · 논리 버전 우선, 클록 스큐 알림, 잘못된 덮어쓰기 추적을 적용합니다.
06 · OPERATIONS
보안·관측·비용
# 운영
영역
확인할 것
판단 기준
주의점
보안·삭제
전송/저장 암호화, 삭제 전파
힌트 사본까지 삭제 완료
복제본 하나만 지워서는 불충분
관측
p99, 정족수 미충족, 분기 수
파티션별 QPS·Merkle 차이
W/R을 낮추기 전 원인부터 분석
비용
복제 N, 수리 주기, 핫 키
원본 10TB × N=3 = 30TB
모두 설계 가정 기반 예시
출처
Dynamo 논문·Cassandra 문서
검토일 2026-08-29
제품별 기본값으로 일반화하지 않음
면접 모드 · 추가 질문05:00
“N=3에서 W=1, R=1을 선택하면 어떤 장애와 일관성 문제가 생기며, 고객 장바구니와 결제 잔액에 같은 정책을 적용할 수 있을까요?”
요구사항부터 분리W/R 트레이드오프충돌 책임 위치
답변 구조 보기 4단계
규모·가용성 우선순위로 CAP 지점을 먼저 선언한다.
파티셔닝(일관된 해싱) → 복제(N) → 정족수(W,R) 순으로 설계를 쌓는다.
충돌 시나리오를 직접 만들어 해결 책임 위치를 설명한다.
장애 감지(가십)와 사본 수리(Merkle)로 운영 관점을 마무리한다. 이번 선택: 장바구니처럼 병합 가능한 데이터는 가용한 쓰기와 형제 버전을 허용한다. 깨지는 신호: 형제 버전과 hinted handoff 체류가 늘면 실패 감지·복제 배치를 먼저 확인한다. 다음 검증: 단절 중 동시 쓰기, 복구 뒤 병합, anti-entropy 완료까지를 장애 주입으로 재현한다.