분산 시스템 면접 퀴즈

네트워크 분단(partition)이 일어난 순간에 일관성과 가용성 중 하나를 고르는 문제입니다. 평상시에는 둘 다 만족하므로, "우리는 CP" 같은 말은 분단 상황의 동작을 뜻합니다.

CAP 정리

CAP 세 가지 속성

• Consistency: 모든 노드가 같은 데이터 반환
• Availability: 모든 요청에 응답 (에러 아닌 정상 응답)
• Partition Tolerance: 네트워크 단절에도 동작

실무 선택

끊기지 않은 평상시의 선택

CAP 는 분단이 일어난 순간만 말합니다. 그런데 시스템은 대부분의 시간을 끊기지 않은 상태로 보냅니다. 그 시간에도 선택이 남습니다.

사본이 여러 곳에 있으면, 읽을 때 모든 사본에 물어 최신값을 확인할지 가까운 사본 하나만 읽을지 고릅니다.

그래서 실제 설계는 분단일 때의 선택과 평상시의 선택을 따로 정합니다. 분단에서 일관성을 고른 시스템이 평상시에는 지연을 위해 옛 값을 허용하는 조합도 흔합니다.

연산마다 다르게 정한다

시스템 전체를 하나로 정할 필요가 없습니다. 잔액 조회는 최신값이 필요하고 상품 설명은 잠깐 옛 값이어도 됩니다. 같은 저장소에서 연산마다 다르게 두는 것이 실제에 가깝습니다.

면접에서 "우리는 AP 입니다" 로 끝내지 않고, 어느 연산에서 무엇을 포기했는지까지 말하면 설계를 실제로 해 본 것으로 읽힙니다.

실무 포인트

• 네트워크 파티션은 반드시 발생 → P는 필수 → 실제론 CP vs AP 선택
• 대부분의 서비스: 최종 일관성(Eventual Consistency) 채택
• 면접 빈출: "CAP에서 왜 셋 다 만족 못하나요?"

복제는 같은 데이터를 여러 곳에 두는 것(복제 지연이 생긴다)이고, 샤딩은 다른 데이터를 나눠 두는 것(샤드 키가 핵심)입니다. 목적이 다릅니다.

복제와 샤딩

복제 (Replication)

• 목적: 가용성, 읽기 성능 향상
• Master-Slave: 쓰기는 Master, 읽기는 Slave 분산
• 복제 지연(Replication Lag) 주의

샤딩 (Sharding)

• 목적: 데이터 분산 저장 (수평 확장)
• 키 기반 샤딩: user_id % N
• 범위 기반 샤딩: 날짜별 분할

복제 지연이 만드는 문제

읽기를 사본으로 보내면 방금 쓴 것이 아직 안 보이는 구간이 생깁니다. 사용자에게는 자기가 한 일이 사라진 것으로 보입니다.

전체를 강하게 만들 필요가 없습니다. 그 사용자에게만 보장하면 대개 충분합니다.

샤딩은 마지막에 꺼낸다

샤딩은 되돌리기가 가장 어려운 결정입니다. 그 전에 쓸 수 있는 것을 먼저 씁니다.

읽기가 부족하다: 복제를 늘린다
같은 것을 반복해 읽는다: 캐시를 둔다
오래된 데이터가 대부분이다: 옛것을 따로 옮긴다
그래도 쓰기와 저장이 부족하다: 샤딩

샤딩 뒤에 잃는 것이 큽니다. 조각을 넘는 조인과 트랜잭션이 안 되고, 조각 수를 바꾸는 재분배가 매우 어렵습니다. 그래서 나누는 키를 고를 때 몇 년 뒤의 쏠림까지 보고 정해야 합니다.

실무 포인트

• 복제 먼저 도입 → 그래도 부족하면 샤딩
• 샤딩 후 크로스 샤드 조인 불가 → 설계 시 신중히
• 리샤딩(데이터 재분배)은 매우 어려운 작업

복제 지연 때문에 방금 쓴 값이 사본에서 안 보일 수 있습니다. 남의 변경이 늦는 것은 대개 괜찮고 자기 쓰기가 안 보이는 것은 거의 항상 문제입니다.

최종 일관성과 읽기 정합성

왜 방금 쓴 데이터가 안 보이나

쓰기 → [Primary] --복제 지연 50ms--> [Replica]
읽기 →                               [Replica]  아직 이전 값

• 최종 일관성은 언젠가 같아진다는 약속일 뿐, 언제까지는 말해주지 않는다
• 사용자가 체감하는 버그는 대부분 이 지연 창 안에서 발생한다

필요한 보장들

누가 어긋남을 느끼나

같은 지연이라도 누가 보느냐에 따라 결함인지 아닌지가 갈립니다.

첫째와 셋째만 다루면 대부분 해결됩니다. 고친 사람은 잠시 원본에서 읽게 하고, 판단하는 배치는 복제본을 쓰지 않게 합니다. 나머지 트래픽은 복제본으로 보내 부하를 나눕니다.

화면에서 어긋남을 감추는 법

값이 늦게 오는 것을 사용자가 결함으로 느끼지 않게 만들 수 있습니다.

고친 결과를 화면에 먼저 반영하고 서버 응답을 기다린다
실패하면 되돌리고 알린다
목록으로 돌아갈 때 다시 부르지 않고 방금 고친 값을 쓴다

둘째가 없으면 거짓말이 됩니다. 화면에는 성공한 것처럼 보이는데 서버에는 안 들어간 상태가 남습니다. 먼저 반영하는 것과 실패를 알리는 것은 한 몸입니다.

실무 포인트

• 글 작성 직후 목록 조회를 Primary로 보내는 것이 가장 값싼 해법이다
• 읽기 분산을 위해 복제본을 늘리면 지연 창과 불일치 가능성도 함께 늘어난다
• 잔액과 재고처럼 강한 일관성이 필요한 경로만 골라 비싸게 처리한다. 전체를 강하게 만들 필요는 없다
• DynamoDB처럼 요청 단위로 강한 읽기를 선택할 수 있는 저장소도 있다. 비용은 읽기 단가로 지불한다