티스토리 뷰

개요
데이터베이스 인터널스를 읽고 있다. 11장을 읽다가 정리를 해두고 싶어 적어둔다.
중요 용어 정리
일관성 모델
내결함성
이중화
장애 조치(failover)
데이터 복제
- 일관성 모델 (Consistency Model): 분산 시스템에서 모든 사용자에게 데이터가 언제, 어떤 값을 볼 수 있을지를 정해주는 규칙.
- 내결함성 (Fault Tolerance): 시스템 일부가 고장 나더라도 전체 기능을 유지할 수 있는 능력.
- 이중화 (Redundancy): 고장에 대비해 같은 구성요소를 여러 개 준비해두는 것.
- 장애 조치 (Failover): 주 시스템이 실패했을 때 자동으로 예비 시스템으로 전환하는 과정.
- 데이터 복제 (Data Replication): 데이터를 여러 위치에 동일하게 복사해두어 가용성과 안전성을 높이는 방법.
CAP 이론
분산 시스템은 세 가지 속성을 가지는데 동시에 세 가지를 모두 완벽하게 만족할 수는 없다는 이론. 세 가지 속성은 다음과 같다.
- Consistency(일관성): 모든 노드가 같은 데이터를 보여줌
- Availability(가용성): 요청하면 항상 응답을 줌 (실패하지 않음)
- Partition Tolerance(분할 내성): 네트워크가 분리돼도 시스템은 계속 작동함
클라이언트 입장에서 분산 시스템에 어떤 정보를 물었을 때에 분산 시스템의 어느 노드에 물었는지에 따라 값이 다를 수 있다면(일관성) 문제가 될 것이고, 물었는데 답이 바로 돌아오지 않는다면(가용성) 역시 문제가 될 것이다.
CAP 이론에 따라 세 속성중 두 가지만을 선택할 수 있다. 그런데 네트워크 분리가 없는 상황은 불가능에 가깝기에 실제로 우리가 선택할 수 있는 것은 CP 또는 AP이다.
- CP 시스템: 높은 일관성과 분할 허용
- 일관성을 맞추려다 보면 클라이언트에 대한 응답을 제때 못하게 된다. 가용성을 일부 포기하는 것이다.
- AP 시스템: 가용성 보장과 분할 허용
- 가용성을 위해 빠르게 응답하다 보면 노드들 간의 데이터의 일관성을 일부 포기하게 된다.
- CA 시스템: 이론상 가능하지만 네트워크 분리(P)가 없을 때만 가능. 현실에선 불가능에 가깝다.
CAP 이론에서 주의할 점은 여러 장애중에서 네트워크 파티션만을 다루고 있다는 것이다. 즉, 노드들 사이의 통신의 문제만을 다루지 노드 그 자체가 다운되거나 디스크, 메모리에 문제가 생기는 경우는 다루지 않는다.
수확율havest)과 산출율(yield)
일관성과 가용성은 어느 하나를 포기하는 것이 아니라 수확율과 산출율로 절충할 수 있다.
- 수확율: 하나의 요청에 대해 응답의 정확성 비율
- 산출율: 요청들에 대해 응답이 완료되는 비율
산출율은 높은데 수확율이 낮은 건 햄버거 가게에서 100개 주문했는데 내용물이 충실하지 않지만 아무튼 100개 가까이 만들어준 경우라 볼 수 있고(일관성 떨어짐), 반대로 수확율은 높은데 산출율이 낮다면 양질의 햄버거를 만들어주는데 주문 개수를 못맞춘 것으로 볼 수 있다(가용성 떨어짐)
공유 메모리
클라이언트 입장에서는 분산 시스템인지 여부는 알 바 아니다. 클라이언트에겐 하나의 큰 공유 메모리로 볼 수도 있다. 공유 메모리는 또한 가장 작은 단위의 읽기 쓰기 단위인 레지스터들의 배열로 볼 수 있다. 레지스터는 다음 세 유형으로 분류할 수 있다.
- 세이프 레지스터 (Safe Register): 동시에 읽고 쓰면 엉뚱한 값을 줄 수 있는 저장소.
- 일반 레지스터 (Regular Register): → 동시에 읽고 써도 이전 값이나 새 값 둘 중 하나는 정확히 주는 저장소로, 메모를 적고 있는 사람 옆에서 읽었을 때 적기 전이거나 다 적은 후 중 하나는 알아볼 수 있는 것과 같다.
- 원자적 레지스터 (Atomic Register): 읽기와 쓰기를 순서대로 정확히 처리해주는 저장소로, 줄 서서 한 명씩 차례대로 메모지를 쓰고 읽는 것처럼 완벽히 작동하는 것과 같다.
일관성 모델
분산 시스템을 공유 메모리라 보았을 때 여러 클라언트가 동시에(concurrent) 접근해서 읽거나 수정했을 때에 어떻게 처리할 지를 정의한 것이 일관성 모델(Consistency Model)이다. 클라이언트에게 분산 시스템이 이런 동작을 보장한다는 계약서로 보면 되겠다.
일관성 모델은 CAP 이론에 동기화에 들어가는 비용까지 고려한 것으로 보면 된다.
1. 엄격한 일관성(Strict Consistency)
- 정의: 어떤 프로세스가 데이터를 업데이트하면, 모든 다른 프로세스가 즉시 그 값을 볼 수 있어야 하는 모델.
- 예시: A가 변수 x에 1을 저장하면, 전 세계의 어떤 프로세스든 바로 x = 1로 보임.
- 현실에서는 네트워크 지연 때문에 구현이 거의 불가능하다.
2. 선형화 가능성(Linearizability)
- 정의: 모든 연산이 하나의 실제 시간 순서대로 일어난 것처럼 보이도록 보장함. 하나의 실제 시간이라는 개념이 포인트
- 예시: A가 먼저 x = 1을 저장하고 B가 나중에 읽으면, B는 반드시 x = 1을 읽음.
- 실제 시간(real-time)을 반영하며, 강력한 일관성 모델이지만 구현이 복잡하고 성능에 영향을 줄 수 있다.
3. 순차 일관성(Sequential Consistency)
- 정의: 실제 어떤 순서로 일이 일어났는지는 상관없고, 전체 시스템이 보기에 일관된 하나의 순서대로 일이 처리된 것처럼만 보이면 된다
- 예시: A가 x = 1을 저장하고 B가 x = 2를 저장했을 때 전체 분산 시스템은 A→B, 또는 B→A 둘 중 하나의 순서로만 처리한다.
- 시간 순서와는 무관하며, 현실적인 성능과 일관성의 균형을 제공한다.
4. 인과적 일관성(Causal Consistency)
- 정의: 인과 관계가 있는 작업은 순서를 지켜야 하지만, 관련 없는 작업은 순서가 달라도 무방하다.
- 예시: A가 게시글을 쓰고 B가 그 글에 댓글을 달았을 때, 다른 사용자들은 반드시 글 → 댓글 순서로 봐야 함. 하지만 C의 별개 글과의 순서는 바뀌어도 문제가 없다.
- 느슨하지만 현실적인 일관성 모델로, 소셜 미디어 같은 시스템에 적합하다.
간단 비교 요약
모델 시간 순서 보장 프로세스 순서 보장 인과 관계 보장 현실성
| 엄격한 일관성 | 항상 보장 | 보장 | 보장 | 거의 불가능 |
| 선형화 가능성 | 반드시 보장 | 보장 | 보장 | 구현 복잡 |
| 순차 일관성 | 시간 순서 무관 | 보장 | 보장하지 않음 | 현실적 |
| 인과적 일관성 | 시간 순서 무관 | 인과 관계만 보장 | 보장 | 매우 현실적 |
세션 모델
세션 모델(Session Model)은 클라이언트 관점에서 본 분산 시스템 모델이다. 한 클라이언트의 일관성이라 할 수 있겠다. 일관성 모델과 세션 모델을 비교해보면 이해에 도움이 된다.
일관성 모델 vs 세션 모델
항목 일관성 모델 (Consistency Model) 세션 모델 (Session Model)
| 대상 | 전체 분산 시스템의 모든 사용자 | 한 사용자의 세션 (ex. 로그인한 사용자) |
| 목표 | 모든 사용자에게 일관된 데이터 보장 | 사용자에게 예측 가능한 경험 보장 |
| 중심 개념 | 모든 노드 간 전역적 순서 보장 | 한 사용자의 로컬한 순서 보장 |
| 예시 | A가 x=1 하면, B도 바로 x=1을 봐야 함 (ex. 선형화 가능성) | A가 x=1 하면, A는 다음에 반드시 x=1을 봐야 함 (다른 사람은 몰라도 됨) |
일관성 모델은 “모두에게 어떻게 보여줄까?“를 고민하고, 세션 모델은 “나한테만이라도 이상하게 안 보이게 해줘!“를 중심에 둔다 할 수 있다.
세션 모델의 네 종류
1. 자신이 쓴 값 읽기 (Read-Own-Writes)
- 정의: 사용자가 어떤 값을 썼다면, 이후에 그 값을 반드시 읽을 수 있어야 한다.
- 예시: 내가 방금 쓴 댓글이 다시 내 화면엔 바로 보여야 한다.
2. 단조 읽기 (Monotonic Read)
- 정의: 같은 데이터를 여러 번 읽을 때, 이전에 읽은 값보다 예전 값을 읽어선 안된다.
- 예시: 이전에 x = 3을 봤는데, 다시 읽을 때에 그 전의 값인 x = 1이 보이면 이상하다.
3. 단조 쓰기 (Monotonic Write)
- 정의: 한 사용자의 쓰기 작업은 서로 순서를 지켜서 반영되어야 한다.
- 예시: 내가 먼저 x = 1 하고 나중에 x = 2를 했다면, 서버도 그 순서대로 저장해야 한다.
4. 읽기 후 쓰기 (Writes-Follow-Reads)
- 정의: 사용자가 어떤 값을 읽은 뒤에 그것에 기반한 쓰기를 했다면, 그 쓰기는 그 읽기 이후의 시스템 상태에 적용돼야 한다.
- 예시: 문서의 최신 버전을 읽고 수정했는데, 시스템이 이전 버전에 덮어쓰면 안 된다.
결과적 일관성
일관성 모델, 세션 모델을 이야기했는데 결과적 일관성(eventual consistency)는 또 다른 개념으로, 모든 업데이트가 결국엔 모든 노드에 전파되고, 시간이 지나 결국엔 같은 값을 보게 된다는 약한 형태의 일관성이다. 실제로 많은 데이터베이스에서 사용된다.
예를 들어, 분산 시스템에서 A노드에 x=1을 썼을 때 당장은 B노드에서는 x=0처럼 예전 값이 보일 수 있다. 하지만 시간이 지나면 B노드를 포함한 모든 노드가 결국 x=1로 맞춰진다. 즉, “지금은 달라도 언젠가는 같아질 거야” 라는 모델이다.
일관성 모델 → 세션 모델 → 결과적 일관성 순서로 일관성 보장이 약해진다고 말할 수도 있겠다. 그래서 결과적 일관성에 세션 모델 보장을 함께 제공하기도 한다.
결과적 일관성 모델의 조정
결과적 일관성 모델은 CAP 모델에서 CA, CP를 조정하는 것(가용성과 일관성 사이의 균형을 조정하는 것)으로 볼 수 있으며, 복제 팩터, 쓰기 일관성, 읽기 일관성이라는 변수를 조정하게 된다.
- N(Replication Factor): 데이터를 복제해서 저장하는 노드의 수
- W(Write Consistency): 쓰기 작업이 몇 개의 노드에 성공해야 쓰기가 성공한 것으로 간주되는지 정의
- R(Read Consistency): 읽기 작업이 몇 개의 노드에서 읽어야 읽기가 성공한 것으로 간주되는지 정의
일관성을 보장하려면 R + W > N 를 만족해야 한다. 전략적으로 개수를 조정하는 예시는 다음과 같다.
전략 설정 예시 설명
| 쓰기 빠르게 | W = 1, R = 2 | 쓰기는 빠르지만, 읽기에서 더 많이 확인함 |
| 읽기 빠르게 | W = 2, R = 1 | 읽기는 빠르지만, 쓰기를 더 신중하게 처리 |
| 일관성 우선 | W + R > N | 항상 최신 값 보장 가능 |
| 성능 우선 | W + R ≤ N | 빠르지만 최신 보장이 안 될 수 있음 |
CRDTs
Conflict-free Replicated Data Types의 약자로, 분산 시스템에서 충돌 없이 병합이 가능한 데이터 구조이다. 모든 노드에서 독립적으로 데이터를 수정해도, 나중에 서로 병합하면 모두가 같은 최종 상태에 도달하게 된다.
분산 시스템에서는 여러 노드가 동시에 데이터를 수정할 수 있는데 이때 충돌을 피하려면 합의 알고리즘(Raft, Paxos 등)이 필요하다. 하지만, CRDT는 합의 없이도 일관성을 유지할 수 있어서 더 빠르고 유연한 시스템을 만들 수 있다.
주요 특징은 다음과 같다.
- 연산 결과가 순서와 무관하게 병합 가능하다.
- 네트워크 지연, 장애에 강하다.
- 결과적 일관성(eventual consistency)을 자연스럽게 제공한다.
실제 활용처는 다음과 같다.
- 협업 문서 편집 도구 (Google Docs 같은),
- 오프라인 동기화가 필요한 앱 (메모, 채팅 등),
- Redis CRDT, Riak, AntidoteDB, Yjs 등에서 사용 중
개인적 소회
역시 책은 한 번 읽어서는 힘들다. 실무에서 마주치게 되면 더욱 좋겠지만 재독을 하거나 이렇게 자신의 언어로 정리를 할 필요가 있다.
'book-movie' 카테고리의 다른 글
| 책: 모던 소프트웨어 엔지니어링 - 1부 (0) | 2025.05.01 |
|---|---|
| 데이터베이스 인터널스 - 12장 안티-엔트로피와 배포 (0) | 2025.04.25 |
| 책: 한비자, 권력의 기술 (0) | 2025.04.15 |
| 책: 에세 1권 (0) | 2025.04.12 |
| 책: 고기로 태어나서 (0) | 2025.03.24 |
- Total
- Today
- Yesterday
- Gin
- 영화
- clean agile
- solid
- 잡학툰
- 독서후기
- OpenAI
- strange
- 클린 애자일
- go
- 인텔리제이
- Echo
- github
- 티스토리챌린지
- bun
- notion
- agile
- API
- intellij
- 독서
- websocket
- ChatGPT
- 체호프
- 오블완
- MCP
- postgres
- golang
- backend
- gocore
- middleware
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |