2장 분산 시스템의 속성
대규모 비즈니스 애플리케이션에서는 필수 요구 사항
CAP
일관성 (Consistency)
정의: 모든 노드가 동시에 같은 데이터를 보여주어야 합니다. (Linearizability)
Trade-off: 일관성을 지키려면 데이터를 복제하는 동안 다른 요청을 차단(Lock)해야 하므로, **지연 시간(Latency)**이 증가하고 **가용성(Availability)**이 떨어질 수 있습니다.
가용성 (Availability)
정의: 모든 요청은 성공/실패 여부와 관계없이 반드시 응답을 받아야 합니다. "시스템이 죽지 않고 살아있는가?"를 묻습니다.
Trade-off: 가용성을 높이려면 노드 하나가 죽어도 다른 노드가 답해야 합니다. 이때 동기화가 덜 된 '오래된 데이터'를 줄 수도 있어 **일관성(Consistency)**이 희생될 수 있습니다.
파티션 허용성 (Partition Tolerance)
정의: 네트워크가 단절(Partition)되어 노드 간 통신이 실패하더라도 시스템이 계속 동작해야 한다는 속성입니다.
Senior Insight: 분산 시스템에서 이것은 선택 사항이 아닙니다. 물리적 네트워크는 반드시 실패합니다. 따라서 우리는 P를 전제로 하고, 일관성(C)과 가용성(A) 중 하나를 선택해야만 합니다. (CP 시스템 vs AP 시스템)
시스템 안정성 관련
내구성
성공적으로 커밋된 트랜잭션은 영구적으로 보존되어야 합니다
신뢰성
확률적 개념입니다. 보통 MTBF(평균 고장 간격)로 측정합니다. 소프트웨어 버그가 없고, 로직이 정확하게 수행되는 상태를 의미합니다.
장애 허용성
신뢰성이 '고장이 안 나는 것'이라면, 장애 허용성은 **'고장이 나도 버티는 능력(Graceful Degradation)'**입니다.
성능및 확장
지연 시간
요청 후 응답을 받을 때까지 걸리는 물리적 시간입니다.
확장성
부하(Load)가 증가했을 때, 리소스를 추가하면 성능이 선형적으로 증가하는 능력
2.1 분산 시스템 데이터 읽기 쓰기 예시
쓰기 두 가지 방법
- 앱 서버가 모든 레플리카에 직접 쓰기
- DB 자체 복제 기능 사용
데이터 쓰기 옵션
- 직렬 동기 쓰기
가장 안전해 보이지만, 가장 위험한 결합
논리적으로 분산 시스템이 아님 - 직렬 비동기 쓰기
최초 요청 처리, 동기화 단계 순서를 보장 - 병렬 비동기 쓰기
동시에 뿌리고 나중에 거둔다 - 메시징 서비스
보내고 잊어라, 하지만 잃어버리지 않는다
| 특성 | 1. 직렬 동기 | 2. 직렬 비동기 | 3. 병렬 비동기 | 4. 메시징 서비스 |
| 응답성 (Latency) | 🔴 매우 느림 (Sum) | 🟡 보통 | 🟢 빠름 (Max) |
⚡ 매우 빠름 (Fire & Forget)
|
| 결합도 (Coupling) | 🔴 매우 높음 | 🟡 높음 (논리적) | 🟡 중간 |
🔵 매우 낮음 (Decoupled)
|
| 일관성 (Consistency) | 🔵 강한 일관성 (즉시) | 🟡 상황에 따름 | 🟡 복잡함 (부분실패) |
🟠 최종적 일관성 (지연)
|
| 구현 난이도 | 🟢 쉬움 | 🟡 보통 | 🟠 어려움 |
🔴 매우 어려움 (인프라 필요)
|
| 장애 격리 | ❌ 불가 (도미노 현상) | ⚠️ 제한적 | ⚠️ 제한적 |
✅ 우수 (브로커가 완충)
|
| 주요 패턴 | REST/gRPC Call | CompletableFuture | Fork-Join Pool |
Pub/Sub, Queue
|
데이터 읽기 옵션
- 하나 레플리카 읽기
빠르지만, 과거를 볼 수도 있다 - 일부 레플리카 읽기
다수결의 원칙 - 모든 레플리카 읽기
완벽하지만 가장 느리고 취약
논리적으로 분산 시스템이 아님
| 특성 | 1. 하나의 레플리카 (ONE) | 2. 일부 레플리카 (QUORUM) |
3. 모든 레플리카 (ALL)
|
| 일관성 (Consistency) | 🔴 낮음 (최종적 일관성) | 🟢 높음 (강한 일관성 가능) | 🔵 매우 높음 |
| 응답 속도 (Latency) | ⚡ 매우 빠름 | 🟡 보통 (느린 노드에 맞춰짐) |
🔴 매우 느림 (가장 느린 노드 기준)
|
| 가용성 (Availability) | ✅ 매우 높음 (하나만 살아도 됨) | ⚠️ 보통 (과반수 생존 필수) |
❌ 매우 낮음 (하나만 죽어도 실패)
|
| 추천 시나리오 | SNS 피드, 상품 목록, 로그 조회 | 결제, 재고 확인, 로그인 세션 |
데이터 마이그레이션 검증, 관리자 툴
|
| 데이터 신선도 | ⚠️ 복제 지연 발생 가능 | ✅ 최신 데이터 보장 (R+W>N) |
✅ 최신 데이터 보장
|
2.2 일관성
항상 동일한 상태나 데이터를 참조하는 것
- 강한 일관성
- 최종 일관성
2.2.1 강한 일관성(CP)
시스템 내 모든 노드가 공유하고 있는 데이터 업데이트를 동일한 순서로 처리하도록 보장하는 특성
처리 속도가 느리거나 시스템 가용성이 떨어지는 대가
2.2.2 최종 일관성(AP)
일시적 데이터 불일치 허용, 결국은 동기화. 단, 데이터 업데이트에 충돌은 있으면 안됨
메커니즘
- 충돌 해결
- 데이터 복제
- 가십 프로토콜
| 특성 | 강한 일관성 (Strong) |
최종 일관성 (Eventual)
|
| CAP 분류 | CP (Consistency + Partition Tolerance) |
AP (Availability + Partition Tolerance)
|
| 사용자 경험 | "항상 최신 정보만 본다. 가끔 시스템이 멈춘다." |
"시스템은 항상 빠르다. 가끔 옛날 정보를 본다."
|
| 대표 기술 | RDBMS (ACID), HBase, Redis (Single), Zookeeper, Etcd |
Cassandra, DynamoDB, MongoDB (Default), DNS, CDN
|
| 적합한 도메인 | 금융 거래, 재고 관리, 티켓 예매, ID 생성 |
SNS 타임라인, 댓글, 상품 리뷰, 조회수 카운터
|
| 핵심 알고리즘 | Paxos, Raft, 2PC (Two-Phase Commit) |
Gossip Protocol, Merkle Tree, Vector Clocks
|
강한 일관성은 즉각적이고 엄격한 동기화 필요한 경우 적합
최종 일관성은 일시적인 데이터 불일치를 감수하는 대신 가용성과 확장성을 높이는 선택
최종 일관성에서 일시적인 데이터 불일치 문제로 후속 보정 작업이 필요한 경우도 있다.
| 시나리오 | 공식 조건 | 일관성 (Consistency) | 가용성 (Availability) | 응답 속도 (Latency) | 추천 예시 |
| 강한 일관성 | R+W>N | ✅ 보장됨 | ⚠️ 보통 (과반 생존 필수) | 🟡 보통 |
금융 거래, 재고 차감
|
| 읽기 최적화 | W=N,R=1 | ✅ 보장됨 | ❌ 낮음 (쓰기 취약) | ⚡ 읽기 매우 빠름 |
우편번호 검색, 공지사항
|
| 쓰기 최적화 | W=1,R=1 | ❌ 보장 안 됨 (Eventual) | ✅ 매우 높음 | ⚡ 쓰기 매우 빠름 | 로그, 클릭 스트림 |
| 밸런스형 | W=Q,R=Q | ✅ 보장됨 | ✅ 좋음 (일부 장애 허용) | 🟢 좋음 |
일반적인 웹 서비스 DB
|
2.3 가용성
시스템에 장애나 오류가 발생하더라도 사용자에게 서비스를 지속적으로 제공할 수 있는 능력
가용성을 보장하는 여러 방식
- 다중화(중복성)
- 복제
데이터 기준 복제 방식
구분 Active-Passive (Hot Standby) Active-Active (Multi-Master)작동 방식 평소엔 Active만 일함. Passive는 대기하며 데이터만 받음. 두 노드 모두 읽기/쓰기 처리를 동시에 수행.장점 구현이 단순함. 데이터 충돌 없음. 비용 저렴. Zero Downtime. 자원 활용률 100%.단점 장애 발생 시 전환(Failover) 시간 동안 서비스 중단. 데이터 충돌(Conflict) 해결 복잡. 구현 난이도 최상.추천 대상 일반적인 RDBMS (MySQL, PostgreSQL) 글로벌 서비스, 카산드라(Cassandra), 다이나모DB - 로드 밸런싱
- 장애 감지 및 복구
- 장애 전환 및 복귀
2.4 파티션 허용성
2.4.1 네트워크 파티션
네트워크 장애나 문제로 일부 노드나 컴포넌트가 시스템의 다른 부분과 연결이 끊겨 서로 접근하거나 데이터를 주고받지 못하는 상태
2.4.2 파티션 허용성
네트워크 장애나 파티션이 발생하더라도 시스템이 계속 정상적으로 작동할 수 있는 능력
가용성이 중요한 상황에서 매우 중요한 역할
- 고립되더라도 운영 지속
- 성능이 급격히 떨어지지 않고 점진적으로 저하
2.5 지연 시간
요청에 대한 응답이 돌아오기까지 걸리는 시간
시스템 성능과 사용자 경험에 영향
지연 시간 줄이는 기술
- 네트워크 최적화
- 캐싱
- 데이터 지역화
- 비동기 통신
- 성능 튜닝
지연 시간을 극도로 줄이려면 일관성과 장애 허용성에 영향
2.6 내구성
장애나 오류가 발생하더라도 시스템에 저장된 데이터가 손실되지 않도록 보장하는 능력
일관성과 가용성과 밀접한 관계
내구성을 높이면 일관성 소요시간 증가
2.7 신뢰성
하드웨어 고장, 네트워크 문제, 애플리케이션 버그, 휴먼 에러 등 다양한 오류와 장애가 발생하더라도 시스템이 원래 기능을 꾸준히 제공할 수 있는 능력
2.8 장애 허용성
장애 허용이란 일부 요소가 고장 서 제대로 돌아가지 않거나 네트워크 문제가 발생해도 시스템이 정상적으로 작동을 계속할 수 있음을 의미
분산 시스템이 장애나 오류가 발생해도 서비스를 지속적으로 제공할 수 있도록 하여 신뢰성과 가용성을 높여 주는 것을 의미
2.9 확장성
사용자 수나 데이터 양이 증가해도 성능이나 신뢰성을 유지하면서 시스템이 더 많은 작업을 처리할 수 있는 능력
- 수직 확장성
기존 서버 강화 - 수평 확장성
신규 서버 추가
2.9.1 수직 확장성
장점
- 단순함
- 소규모 시스템일 경우 비용 효율적
단점
- 하드웨어 증설 한계
- 단일 장애점
2.9.2 수평 확장성
장점
- 장애 허용성
단점
- 분산 시스템 복잡성
- 데이터 일관성
느낀 점
강한 일관성은 사실상 직렬화를 요구하고 이는 분산 시스템 장점을 전부 갉아먹어 분산된 모놀로그 시스템이 되어 단점만 남는다. 다만, 모든 부분을 강한 직렬화로 구현하는 것이 아니기 때문에 전체 시스템에서는 목적에 맞게 일관성을 선택할지 가용성을 집중할지 판단해 전체 시스템 완성도를 높이는 것이 분산 설계인 것 같다.
'개발' 카테고리의 다른 글
| 요즘 개발자를 위한 시스템 설계 수업 - 3장 분산 시스템의 이론과 데이터 구조 2 (0) | 2026.03.02 |
|---|---|
| 요즘 개발자를 위한 시스템 설계 수업 - 3장 분산 시스템의 이론과 데이터 구조 1 (1) | 2026.02.27 |
| 요즘 개발자를 위한 시스템 설계 수업 - 1장 시스템 설계의 기본 (0) | 2026.02.20 |
| 레디스 - 쓰기 전략 (0) | 2026.02.15 |
| 레디스 - 읽기 전략 (0) | 2026.02.08 |