네트워크 분단(partition)이 일어난 순간에 일관성과 가용성 중 하나를 고르는 문제입니다. 평상시에는 둘 다 만족하므로, "우리는 CP" 같은 말은 분단 상황의 동작을 뜻합니다.
CAP 정리
CAP 세 가지 속성
- Consistency: 모든 노드가 같은 데이터 반환
- Availability: 모든 요청에 응답 (에러 아닌 정상 응답)
- Partition Tolerance: 네트워크 단절에도 동작
실무 선택
| 선택 | 포기 | 예시 |
|---|
| CP | 가용성 | MongoDB, HBase |
| AP | 일관성 | Cassandra, DynamoDB |
끊기지 않은 평상시의 선택
CAP 는 분단이 일어난 순간만 말합니다. 그런데 시스템은 대부분의 시간을 끊기지 않은 상태로
보냅니다. 그 시간에도 선택이 남습니다.
사본이 여러 곳에 있으면, 읽을 때 모든 사본에 물어 최신값을 확인할지 가까운 사본 하나만
읽을지 고릅니다.
| 평상시 선택 | 얻는 것 | 잃는 것 |
|---|
| 사본 여럿에 물어본다 | 최신값을 본다 | 가장 느린 사본을 기다린다 |
| 가까운 사본만 읽는다 | 빠르다 | 잠깐 옛 값을 볼 수 있다 |
그래서 실제 설계는 분단일 때의 선택과 평상시의 선택을 따로 정합니다. 분단에서 일관성을
고른 시스템이 평상시에는 지연을 위해 옛 값을 허용하는 조합도 흔합니다.
연산마다 다르게 정한다
시스템 전체를 하나로 정할 필요가 없습니다. 잔액 조회는 최신값이 필요하고 상품 설명은 잠깐
옛 값이어도 됩니다. 같은 저장소에서 연산마다 다르게 두는 것이 실제에 가깝습니다.
면접에서 "우리는 AP 입니다" 로 끝내지 않고, 어느 연산에서 무엇을 포기했는지까지 말하면
설계를 실제로 해 본 것으로 읽힙니다.
실무 포인트
- 네트워크 파티션은 반드시 발생 → P는 필수 → 실제론 CP vs AP 선택
- 대부분의 서비스: 최종 일관성(Eventual Consistency) 채택
- 면접 빈출: "CAP에서 왜 셋 다 만족 못하나요?"
Q.CAP 정리를 설명해주세요
분산 시스템에서 셋 중 둘만 고를 수 있다는 정리입니다.
| 항목 | 의미 |
|---|
| 일관성(C) | 모든 노드가 같은 값을 본다 |
| 가용성(A) | 요청에 항상 응답한다 |
| 분할 내성(P) | 노드 사이 통신이 끊겨도 동작한다 |
정확히 이해할 점이 있습니다. 분할 내성은 선택 사항이 아닙니다. 네트워크는 반드시 끊기므로 여러 대로 나눈 시스템은 P 를 가져야 합니다.
그래서 실제 선택은 분할이 일어났을 때 무엇을 포기할지입니다.
| 선택 | 분할 시 행동 | 맞는 데이터 |
|---|
| CP | 정확성을 지키려고 응답을 거부한다 | 잔액. 틀린 값보다 잠시 안 되는 것이 낫다 |
| AP | 응답하되 옛 값을 줄 수 있다 | 상품 목록. 옛 값이라도 보여주는 것이 낫다 |
흔한 실수: CA 시스템을 고를 수 있다고 답하는 것. 단일 노드가 아니면 CA 는 없습니다. 그리고 분할이 없는 평시에는 일관성과 가용성을 함께 가질 수 있어서, CAP 은 장애 시의 행동 규칙을 말하는 정리입니다.
Q.CP vs AP 시스템 예시를 들어주세요
| 성향 | 예 | 분할 시 행동 |
|---|
| CP | ZooKeeper, etcd, HBase | 과반을 못 모으면 쓰기를 거부한다 |
| CP | 단일 리더 관계형 DB 구성 | 리더를 잃으면 새 리더 선출까지 쓰기가 멈춘다 |
| AP | Cassandra, DynamoDB 기본 설정 | 받아 두고 나중에 수렴시킨다 |
| AP | DNS | 옛 값을 주더라도 응답한다 |
CP 쪽 도구가 하는 일을 보면 이유가 보입니다. 분산 잠금이나 리더 선출은 틀린 답이 곧 사고입니다. 두 노드가 동시에 리더라고 믿으면 데이터가 갈라집니다. 그래서 확신이 없으면 응답하지 않습니다.
AP 쪽은 반대입니다. 좋아요 수나 방문자 통계가 잠시 어긋나도 서비스가 계속 도는 편이 낫습니다.
같은 시스템에서 설정으로 바꿀 수 있는 경우도 많습니다. 쓰기와 읽기의 정족수를 조절해 성향을 옮기는 방식입니다.
흔한 실수: 제품 이름으로 성향을 외우는 것. 대부분의 저장소는 설정으로 성향이 바뀝니다. 어떤 설정에서 어떻게 동작하는지로 말하는 편이 정확합니다.
Q.실무에서 CAP을 어떻게 적용하나요?
시스템 전체를 하나로 정하지 않고 기능 단위로 나눠 정합니다.
| 기능 | 선택 | 이유 |
|---|
| 결제, 재고 차감 | 일관성 | 틀린 값이 곧 손실 |
| 로그인 세션 | 가용성 | 잠깐 옛 값이어도 큰 문제가 아니다 |
| 상품 목록, 검색 | 가용성 | 몇 초 지난 값이어도 된다 |
| 좋아요 수, 조회수 | 가용성 | 어긋남을 눈치채지 못한다 |
| 계정 권한 변경 | 일관성 | 회수한 권한이 남아 있으면 사고다 |
그리고 대부분의 시간에는 분할이 없습니다. 그래서 실무에서 더 자주 마주치는 판단은 평시의 지연 대 일관성 쪽입니다. 정족수를 높이면 정확하지만 느려지고, 낮추면 빠르지만 어긋날 수 있습니다.
이것을 다루는 방식이 그래서 이렇습니다.
| 방법 | 내용 |
|---|
| 요청별 수준 | 같은 저장소에서 중요한 읽기만 강한 일관성으로 |
| 경계 분리 | 정확성이 필요한 데이터만 별도 저장소로 |
| 보정 | 어긋남을 감지해 뒤에서 맞추는 절차를 둔다 |
흔한 실수: 전 시스템을 강한 일관성으로 맞추는 것. 필요 없는 곳에서 지연과 가용성을 잃습니다.
Q.BASE란 무엇인가요?
ACID 의 대안으로 제시된 성질입니다. 강한 일관성을 포기하고 가용성을 취하는 쪽입니다.
| 글자 | 의미 |
|---|
| BA | 기본적으로 가용하다. 일부가 죽어도 응답한다 |
| S | 상태가 변할 수 있다. 쓰기가 없어도 값이 바뀔 수 있다 |
| E | 결국 일치한다. 시간이 지나면 수렴한다 |
| 항목 | ACID | BASE |
|---|
| 일관성 | 항상 | 결국 |
| 가용성 | 정확성을 위해 포기할 수 있다 | 우선한다 |
| 규모 확장 | 수직 확장에 유리 | 수평 확장에 유리 |
| 맞는 곳 | 금전, 재고 | 통계, 피드, 추천 |
두 번째 글자는 복제가 전파되는 동안 같은 값을 두 번 읽으면 다를 수 있다는 뜻입니다. 쓰기를 하지 않았는데도 조회 결과가 바뀝니다.
흔한 실수: BASE 를 "정합성을 포기한다"로 읽는 것. 포기가 아니라 언제 맞출지를 미루는 것입니다. 그래서 얼마나 걸려 수렴하는지, 그동안 사용자가 무엇을 볼 수 있는지를 설계해야 합니다.
먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.
읽었으면 문제로 확인해보세요
분산 시스템 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.