학습 목표
분산 시스템이 단일 머신 OS와 어떻게 다른지 설명할 수 있다.
클러스터 구조(공유 없음, HA)와 로드 밸런싱 흐름을 설명할 수 있다.
CAP 정리에서 Consistency·Availability·Partition tolerance 트레이드오프를 설명할 수 있다.
강한 일관성과 최종 일관성의 차이를 직관적으로 설명할 수 있다.
문제 상황
- 웹 서비스 트래픽이 커져 한 서버로는 한계 — 수평 확장이 필요하다
- DB 서버 장애 시 전체 서비스가 멈춘다 — 이중화·페일오버를 검토한다
- 로드 밸런서 뒤에 서버 3대인데 한 대만 과부하 — 배분 알고리즘?
- 캐시·CDN을 쓰면 빠른데 다른 지역에서 값이 다르게 보인다
- 일관성을 포기한 건가?
- 마이크로서비스는 네트워크로 통신 — 프로세스 IPC와 뭐가 다르지?
NUMA·멀티코어는 한 머신 안 이야기였다. 이번엔 여러 노드가 네트워크로 협력하는 분산 시스템 개요다.
1. 분산 시스템이란
분산 시스템(distributed system) — 독립된 컴퓨터(노드) 가 네트워크로 연결되어 하나의 시스템처럼 동작한다.
| 특징 | 설명 |
|---|---|
| 투명성 | 사용자는 노드 수·위치를 몰라도 서비스 이용 (위치·복제·동시성 투명성) |
| 확장성 | 노드 추가로 처리량·용량 확장 — scale-out |
| 장애 격리 | 한 노드 다운이 전체를 죽이지 않게 설계 (이상적 목표) |
| 동시성 | 여러 노드에서 동시 실행 — 일관성 문제 발생 |
단일 OS: 프로세스 ──shared memory / IPC── 프로세스 (같은 커널)
분산: 노드 A ──network message / RPC── 노드 B (별도 OS, 지연·실패)- 네트워크는 믿을 수 없다 — 지연, 패킷 손실, 파티션(구간 단절)
- OS가 보장하던 원자성·순서를 애플리케이션·중간 계층이 다시 설계
- 클라우드·K8s·마이크로서비스는 분산 시스템의 실무 형태
2. 클러스터
클러스터(cluster) — 여러 머신을 묶어 하나의 자원 풀처럼 쓴다.
| 유형 | 구조 | 용도 |
|---|---|---|
| Compute cluster | 동질 노드 + 스케줄러가 작업 분배 | HPC, 배치, K8s worker |
| HA cluster | Active + Standby, 페일오버 | DB, 스토리지 컨트롤러 |
| Load-balanced cluster | 동일 서비스 복제 + LB 앞단 | 웹·API tier |
Shared nothing vs shared disk
| 모델 | 설명 |
|---|---|
| Shared nothing | 각 노드가 자기 CPU·메모리·디스크 — 네트워크로만 협력. 확장에 유리 |
| Shared disk | 스토리지는 공유, 노드가 페일오버 — HA DB에서 흔함 |
| Shared memory | NUMA·SMP에 가깝 — 단일 시스템 이미지 |
- Quorum — 과반 노드가 살아야 리더 선출·쓰기 허용 (split-brain 방지)
- Heartbeat — 노드 생존 확인 — 타임아웃 시 standby 승격
- OS 관점: 각 노드는 자기 커널·프로세스 — 클러스터 소프트웨어가 조율
3. 로드 밸런싱
로드 밸런싱(load balancing) — 들어오는 요청을 여러 백엔드에 나눠 부하·지연을 고른다.
| 계층 | 대상 | 예 |
|---|---|---|
| L4 | IP·포트·TCP 연결 | AWS NLB, HAProxy TCP mode |
| L7 | HTTP URL·헤더·쿠키 | nginx, ALB, Ingress |
알고리즘 (개요)
| 방식 | 설명 |
|---|---|
| Round Robin | 순서대로 돌려 배정 — 단순, 세션 없을 때 |
| Least Connections | 연결 수 적은 서버 우선 |
| Consistent Hash | 키 해시로 서버 고정 — 캐시 locality |
| Weighted | 서버 성능 비율 반영 |
- Health check — 응답 없는 서버는 풀에서 제외 (drain)
- Sticky session — 같은 클라이언트를 같은 서버로 — 상태ful 앱
- OS·런타임: 각 백엔드 노드에서 accept → 프로세스/스레드 처리 — LB는 연결 분배만
4. CAP 정리
CAP theorem (Brewer) — 분산 데이터 저장소는 네트워크 파티션(P) 이 발생하면 C 와 A 를 동시에 완벽히 만족할 수 없다. 둘 중 하나를 택한다 (실무는 강도 조절).
| 기호 | 의미 |
|---|---|
| C (Consistency) | 모든 노드가 같은 시점에 같은 데이터를 본다 (선형화에 가까운 강한 일관성) |
| A (Availability) | 모든 요청이 (성공/실패 응답 없이) 응답을 받는다 — 노드 일부 다운도 서비스 |
| P (Partition tolerance) | 노드 간 통신 단절이 있어도 시스템이 동작한다 |
파티션 없을 때 — C와 A 모두 가능. 파티션 중 — CP 또는 AP 쪽으로 기울인다.
| 성향 | 파티션 시 선택 | 예 |
|---|---|---|
| CP | 일관성 우선 — minority 쪽 쓰기 거부 | ZooKeeper, etcd, HBase |
| AP | 가용성 우선 — 쓰기 허용, 나중에 합의 | Cassandra, Dynamo 계열 |
| CA | 단일 노드·파티션 없는 가정 | 전통 단일 RDBMS (분산 아님) |
- CAP은 설계 가이드이지 모든 트레이드오프를 담지 않는다
- PACELC 확장: 평상시에도 Latency vs Consistency
5. 일관성 모델 직관
CAP과 연결되는 읽기·쓰기 보장 수준.
| 모델 | 설명 | 사용 맥락 |
|---|---|---|
| Strong | 쓰기 후 읽기가 즉시 최신값 | 계좌 잔액, 재고 |
| Eventual | 충분 시간 후 모든 복제본이 수렴 | SNS 좋아요 수, CDN |
| Read-your-writes | 내가 쓴 값은 내가 바로 읽을 때 보임 | 세션·프로필 |
| Causal | 인과 관계 있는 연산 순서 보장 | 댓글·대화 스레드 |
Primary DB (strong) ──async replicate──▶ Read replica (lag 가능)- 캐시·CDN은 AP에 가깝게 동작하는 경우가 많다 — TTL·무효화로 완화
- 분산 트랜잭션(2PC)은 C를 지향하지만 가용성·지연 비용 큼
- OS 단일 머신의 mutex가 네트워크 전체에서는 합의 알고리즘(Raft, Paxos)으로 대체된다
6. 정리
- 분산 시스템은 네트워크·장애·지연을 전제로 설계한다
- 클러스터는 compute·HA·LB 패턴으로 확장·복원력을 확보
- 로드 밸런서는 L4/L7에서 요청을 분배하고 health check로 장애 노드 제외
- CAP: 파티션 시 C vs A 트레이드오프 — CP vs AP 제품 선택의 기준
- 다음: OS 종류와 활용 — Linux, Windows, macOS, embedded
다음에 다룰 것
- OS 종류와 활용
- Linux, Windows, macOS, embedded 비교
해당 내용은 Operating System Concepts, 10/E (Avraham Silberschatz, Peter Baer Galvin, Greg Gagne) 의 내용을 기반으로 합니다.