테마
NoSQL과 선택 기준 2
데이터를 여러 서버에 나눠 두면 서버 사이 네트워크가 끊기는 순간이 반드시 온다. 그때 "최신 값을 보장할지, 일단 응답할지"를 골라야 한다는 것이 CAP 정리(CAP theorem)이고, 응답을 고른 저장소가 약속하는 것이 최종 일관성(eventual consistency)이다. 이 두 가지를 이해하면 NoSQL(Not only SQL, 비관계형 데이터베이스)과 관계형 DB 중 무엇을 고를지 기준이 선다.
CAP 정리
CAP 정리(CAP theorem)는 데이터를 여러 서버, 곧 노드(node)에 나눠 둔 분산 저장소가 세 가지 성질을 동시에 모두 보장할 수는 없다는 정리다. 2000년에 에릭 브루어(Eric Brewer)가 추측으로 발표했고, 2002년에 세스 길버트(Seth Gilbert)와 낸시 린치(Nancy Lynch)가 증명했다. 장애에 대비해 같은 데이터의 사본을 여러 노드에 복제(replication)해 두는 경우가 많은데, 이때 사본끼리 값이 어긋날 수 있다는 것이 CAP의 출발점이다.
- 일관성(Consistency): 모든 읽기가 가장 최근에 쓴 값을 받거나, 아니면 오류를 받는다.
- 가용성(Availability): 고장 나지 않은 노드는 모든 요청에 응답한다. 다만 최신 값이 아닐 수 있다.
- 분할 내성(Partition tolerance): 노드 사이 네트워크가 끊겨 메시지가 사라지거나 늦어져도 시스템이 계속 동작한다.
"셋 중 둘을 고른다"는 설명은 오해를 부른다. 분산 시스템에서 네트워크 분할(network partition)은 피할 수 없는 사고라 분할 내성은 빼놓을 수 없다. 그래서 실제 선택은 분할이 났을 때 일관성과 가용성 중 무엇을 지킬지다. 분할이 없는 평소에는 둘 다 지킬 수 있다.
다이어그램 로딩…
분할이 없을 때도 선택은 남는다. 모든 사본에 쓰기가 반영될 때까지 기다리면 일관성은 좋지만 응답이 늦어진다. 이 지연과 일관성의 교환까지 넣은 설명을 PACELC(Partition·Availability·Consistency·Else·Latency·Consistency)라 부른다. 분할(Partition)이 나면 가용성(Availability)과 일관성(Consistency) 중 하나를, 그렇지 않으면(Else) 지연(Latency)과 일관성(Consistency) 중 하나를 고른다는 뜻의 머리글자다. 또 CAP의 일관성은 "모두가 같은 최신 값을 본다"는 뜻으로, ACID(Atomicity·Consistency·Isolation·Durability, 원자성·일관성·격리성·지속성)의 일관성인 "제약 규칙을 깨지 않는다"와 다른 개념이다.
BASE와 최종 일관성
가용성을 앞세운 저장소가 약속하는 성질을 ACID와 대비해 BASE(Basically Available, Soft state, Eventually consistent)라 부른다. 대체로 늘 응답하고(Basically Available), 새 쓰기가 없어도 사본끼리 맞춰 가며 상태가 바뀔 수 있고(Soft state), 결국에는 일관된다(Eventually consistent)는 뜻이다.
최종 일관성(eventual consistency)은 "새 쓰기가 멈추면 결국 모든 읽기가 마지막 값을 돌려준다"는 약속이다. 반대로 말하면 그 전까지는 노드마다 다른 값을 볼 수 있다. 게시글 좋아요 수가 잠깐 기기마다 다르게 보이는 것은 괜찮지만, 계좌 잔액이 그렇게 보이면 곤란하다. 요즘은 요청마다 사본 몇 개가 응답해야 성공으로 볼지 정해 일관성 수준을 고르게 하거나 트랜잭션(transaction)을 지원하는 NoSQL 제품도 있어서, 제품별로 무엇을 보장하는지 확인해야 한다.
무엇을 고를까
| 관계형 DB가 맞을 때 | NoSQL을 검토할 때 |
|---|---|
| 여러 테이블을 조인해 다양하게 조회한다 | 조회가 키 기준으로 단순하고 미리 정해져 있다 |
| 돈·재고처럼 여러 행을 한 트랜잭션으로 바꿔야 한다 | 쓰기량·데이터가 서버 한 대를 넘는다 |
| 외래 키(foreign key)·제약 조건(constraint)으로 데이터 규칙을 DB가 지켜야 한다 | 레코드마다 구조가 크게 다르다 |
| 조회 방식이 앞으로 계속 늘어난다 | 관계를 여러 단계 따라가는 탐색이 핵심이다(그래프 DB) |
실무에서는 하나만 고르기보다 섞어 쓰는 경우가 많다. 주문·회원 같은 원본은 관계형 DB에 두고, 자주 읽는 값은 키-값 저장소(key-value store)에 캐시하고, 검색은 검색엔진에 맡기는 식이다. 이때도 원본이 어디인지, 복사본은 얼마나 늦게 맞춰져도 되는지를 먼저 정한다.
면접 포인트
- CAP: 분할은 피할 수 없으므로 분할 시 일관성(오류) vs 가용성(옛 값). "셋 중 둘"은 오해. CAP의 C ≠ ACID의 C.
- PACELC: 분할이 없어도 지연과 일관성을 맞바꾼다.
- BASE·최종 일관성: 쓰기가 멈추면 결국 같아지지만 그 전엔 노드마다 다를 수 있다. 제품마다 보장 수준이 다르다.
- 선택 기준: 관계·트랜잭션·제약·다양한 조회면 관계형, 단순 키 접근·대규모 쓰기·구조 다양성이면 NoSQL. 섞어 쓰기가 흔하다.
