분산 시스템의 도전 과제
들어가며
한 대의 머신으로 부족해질 때, 진짜 문제가 시작된다. 분산 시스템은 현대 인터넷의 초석입니다. WeChat 메시지부터 Taobao 주문까지, 그 이면에는 수백 대의 머신이 협력하고 있습니다. 하지만 '분산'은 공짜 점심이 아닙니다. 단일 시스템에서는 결코 겪지 못했던 일련의 도전 과제를 가져옵니다.
이 글에서 무엇을 배우게 되나요?
이 장을 마치면 다음을 얻게 됩니다:
- 핵심 정리: CAP 정리와 시스템 설계에 미치는 영향 이해
- 일관성 모델: 강 일관성, 최종 일관성, 인과적 일관성 구분
- 8대 도전 과제: 분산 시스템이 직면한 핵심 난제 파악
- 합의 알고리즘: Paxos, Raft 등 분산 합의의 기본 원리 이해
- 실전 패턴: 2PC, Saga, CRDT 등 자주 쓰이는 해결方案 숙지
| 장 | 내용 | 핵심 개념 |
|---|---|---|
| 1장 | 분산이 필요한 이유 | 확장성, 가용성, 지리적 분산 |
| 2장 | CAP 정리 | 일관성, 가용성, 파티션 허용 |
| 3장 | 일관성 모델 | 강 일관, 최종 일관, 인과 일관 |
| 4장 | 8대 도전 과제 | 네트워크, 시계, 파티션, 스플릿 브레인 등 |
| 5장 | 합의 알고리즘 | Paxos, Raft, ZAB |
| 6장 | 분산 트랜잭션 | 2PC, Saga, TCC |
0. 전경: 분산 시스템이 필요한 이유
단일 시스템은 단순하고 신뢰할 수 있지만, 넘을 수 없는 세 가지 병목이 있습니다:
| 병목 | 설명 | 분산의 해결책 |
|---|---|---|
| 성능 한계 | 단일 머신의 CPU, 메모리, 디스크에는 물리적 한계가 있음 | 수평 확장: 더 많은 머신을 추가해 부하 분산 |
| 단일 장애점 | 한 머신이 죽으면 서비스 전체가 중단됨 | 중복 복제: 여러 머신이 서로 백업 |
| 지리적 지연 | 사용자가 전 세계에 있지만, 단일 머신은 한 곳에만 있음 | 다중 지역 배포: 사용자와 가까운 곳에서 서비스 |
분산의 대가
분산 시스템은 위의 문제를 해결하지만, 새로운 복잡성을 도입합니다: 네트워크 불안정성, 시계 비동기, 부분 장애, 데이터 일관성... 이것이 바로 이 글에서 다룰 '도전 과제'입니다.
Peter Deutsch의 분산 컴퓨팅 8대 오류는 다음과 같은 가정이 분산 환경에서는 모두 틀리다고 말합니다:
- 네트워크는 신뢰할 수 있다
- 지연 시간은 0이다
- 대역폭은 무한하다
- 네트워크는 안전하다
- 토폴로지는 변하지 않는다
- 관리자는 한 명뿐이다
- 전송 비용은 0이다
- 네트워크는 동종이다
1. CAP 정리: 분산 시스템의 '불가능한 삼각형'
2000년, Eric Brewer는 CAP 추측(이후 정리로 증명됨)을 제시했습니다: 분산 시스템은 다음 세 가지 속성 중 최대 두 가지만 동시에 만족할 수 있습니다.
| 속성 | 의미 | 직관적 이해 |
|---|---|---|
| Consistency(일관성) | 모든 노드가 같은 시각에 동일한 데이터를 봄 | 어떤 ATM에서 잔액을 조회해도 결과가 동일함 |
| Availability(가용성) | 모든 요청이 오류가 아닌 응답을 받음 | 시스템이 항상 응답하며, "서비스 불가"라고 말하지 않음 |
| Partition tolerance(파티션 허용) | 네트워크 파티션 발생 시에도 시스템이 계속 작동함 | 일부 네트워크 케이블이 끊어져도 시스템이 동작함 |
왜 두 가지만 선택할 수 있나요?
분산 환경에서 네트워크 파티션(P)은 불가피합니다. 광케이블이 잘리고, 스위치가 고장 나고, 데이터센터가 네트워크 단절됩니다. 따라서 P는 필수 선택이며, 실제 선택은 C와 A 사이의 트레이드오프입니다:
- CP 선택: 파티션 시 불확실한 요청을 거부하여 데이터 정확성 보장 → 금융, 재고 관리에 적합
- AP 선택: 파티션 시에도 서비스를 계속하지만, 데이터가 일시적으로 불일치할 수 있음 → 소셜, 콘텐츠에 적합
CAP은 흑백이 아닙니다
현실의 시스템은 단순한 "CP 또는 AP"가 아닙니다. 많은 시스템이 다른 연산에서 다른 선택을 합니다. 예를 들어, 같은 데이터베이스에서 읽기 연산은 AP(이전 데이터 읽기 허용), 쓰기 연산은 CP(다수 확인 요구)일 수 있습니다.
2. 일관성 모델: 데이터 동기화의 '엄격함 정도'
일관성은 스위치(있거나 없거나)가 아니라 스펙트럼입니다. 각각의 일관성 모델은 '정확성'과 '성능' 사이에서 다른 트레이드오프를 합니다.
일관성 모델 비교
| 모델 | 보장 | 지연 | 적용 시나리오 |
|---|---|---|---|
| 강 일관성 | 반드시 최근에 기록된 값을 읽음 | 높음(동기 대기 필요) | 은행 이체, 재고 차감 |
| 최종 일관성 | 결국 모든 복제본이 일치하지만, 중간에 이전 값을 읽을 수 있음 | 낮음(기록 즉시 반환) | 소셜 피드, DNS |
| 인과적 일관성 | 인과 관계가 있는 연산의 순서는 보장함 | 중간 | 댓글 답글, 협업 편집 |
| 선형화 가능성 | 모든 연산이 단일 머신에서 순서대로 실행되는 것처럼 보임 | 가장 높음 | 분산 락, 리더 선출 |
| 세션 일관성 | 같은 세션 내에서는 자신이 쓴 데이터를 읽을 수 있음 보장 | 낮음~중간 | 사용자 개인 데이터 |
'자신의 쓰기 읽기' 일관성
가장 흔한 실제 요구 사항은: 사용자가 자신의 데이터를 수정한 후, 즉시 업데이트된 내용을 볼 수 있는 것입니다(다른 사용자는 나중에 볼 수 있음). 이를 "Read Your Own Writes" 일관성이라고 하며, 최종 일관성의 실용적인 강화 버전입니다.
3. 8대 도전 과제: 분산 시스템의 '지뢰밭'
분산 시스템의 복잡성은 하나의 문제에서 오는 것이 아니라, 여러 문제가 얽혀 있습니다. 다음은 가장 핵심적인 8가지 도전 과제입니다.
- Timeouts and retries with idempotency
- Heartbeat checks to detect connection health
- Circuit breakers to pause calls after repeated failures
도전 과제 간의 연관성
이 8가지 도전 과제는 독립적이지 않고 서로 연관되어 있습니다:
- 네트워크 불안정 → 네트워크 파티션 유발 → CAP 트레이드오프 촉발
- 시계 비동기 → 이벤트 정렬 어려움 유발 → 데이터 일관성에 영향
- 부분 장애 → 스플릿 브레인 유발 가능 → 합의 알고리즘으로 해결 필요
- 데이터 일관성 → 분산 트랜잭션 필요 → 트랜잭션은 네트워크 불안정의 영향을 받음
은탄환은 없습니다
분산 시스템에는 '완벽한' 해결책이 없고, '적절한' 트레이드오프만 있습니다. 이러한 도전 과제의 본질을 이해해야 시스템을 설계할 때 올바른 선택을 할 수 있습니다.
4. 합의 알고리즘: 여러 머신이 '합의에 도달'하는 방법
합의 알고리즘은 분산 시스템의 핵심입니다. 해결하는 문제는: 여러 노드가 어떻게 특정 값에 대해 합의에 도달하는가? 일부 노드가 장애가 나거나 네트워크 지연이 발생하더라도.
4.1 Paxos
Leslie Lamport가 1990년에 제안했으며, 엄격하게 증명된 최초의 합의 알고리즘입니다.
| 역할 | 책임 |
|---|---|
| Proposer | 제안(값)을 제출 |
| Acceptor | 제안에 대해 투표하여 수락 또는 거부 |
| Learner | 최종적으로 선택된 값을 학습 |
2단계 프로세스:
- Prepare 단계: Proposer가 제안 번호를 보내고, Acceptor는 더 작은 번호의 제안을 수락하지 않겠다고 약속
- Accept 단계: Proposer가 구체적인 값을 보내고, 다수의 Acceptor가 수락하면 제안이 통과
Paxos의 문제점
Paxos는 정확하지만, 이해하고 구현하기가 유명하게 어렵습니다. Lamport 자신의 논문이 그리스 의회라는 비유를 사용했는데, 오히려 더 많은 사람들을 혼란스럽게 만들었습니다.
4.2 Raft: 이해 가능성을 위해 탄생
2014년 Diego Ongaro가 Raft를 제안했으며, "이해하기 쉬운 Paxos"를 목표로 삼았습니다. 합의 문제를 세 가지 하위 문제로 분해합니다:
| 하위 문제 | 설명 |
|---|---|
| 리더 선출 | 클러스터에서 리더를 선출하고, 모든 쓰기는 리더를 거침 |
| 로그 복제 | 리더가 연산 로그를 모든 팔로워에게 복제 |
| 안전성 | 이미 커밋된 로그가 덮어쓰이지 않음을 보장 |
Raft의 핵심 프로세스:
- 클러스터 시작 시, 모든 노드는 팔로워 상태
- 팔로워가 리더의 하트비트를 시간 내에 받지 못하면, 후보자가 되어 선거 시작
- 다수표를 얻은 후보자가 새로운 리더가 됨
- 리더가 클라이언트 요청을 받아, 다수 노드에 로그를 복제한 후 커밋
4.3 합의 알고리즘 비교
| 알고리즘 | 제안 시기 | 이해 난이도 | 사용 시스템 |
|---|---|---|---|
| Paxos | 1990 | 어려움 | Google Chubby |
| Raft | 2014 | 쉬움 | etcd, Consul, TiKV |
| ZAB | 2011 | 중간 | ZooKeeper |
| EPaxos | 2013 | 어려움 | 주로 학술 연구 |
5. 분산 트랜잭션: 노드 간의 '전부 아니면 전무'
단일 데이터베이스의 트랜잭션은 로컬 락과 로그만으로 ACID를 구현할 수 있습니다. 하지만 하나의 비즈니스 연산이 여러 서비스/데이터베이스에 걸쳐 있을 때, 원자성을 어떻게 보장할까요?
5.1 2단계 커밋(2PC)
가장 고전적인 분산 트랜잭션 프로토콜로, 두 단계로 나뉩니다:
| 단계 | 조정자 동작 | 참여자 동작 |
|---|---|---|
| Prepare | 모든 참여자에게 "커밋할 수 있나요?"라고 묻기 | 연산을 수행하지만 커밋하지 않고, Yes/No 응답 |
| Commit | 전부 Yes이면 Commit 전송 | 공식 커밋; No가 있으면 전부 롤백 |
2PC의 문제점:
- 차단: Prepare 후 조정자가 다운되면, 참여자는 무한 대기
- 단일 장애점: 조정자가 단일 장애점이며, 다운되면 전체 트랜잭션이 멈춤
- 성능 저하: 여러 번의 네트워크 왕복이 필요하고, 락 유지 시간이 긺
5.2 Saga 패턴
Saga는 하나의 큰 트랜잭션을 여러 로컬 트랜잭션으로 나누며, 각 로컬 트랜잭션에는 해당하는 보상 연산이 있습니다. 어느 단계에서 실패하면 역순으로 보상을 실행합니다.
전자상거래 주문의 Saga 예시:
| 단계 | 정방향 연산 | 보상 연산 |
|---|---|---|
| T1 | 주문 생성(결제 대기) | 주문 취소 |
| T2 | 재고 차감 | 재고 복구 |
| T3 | 잔액 차감 | 잔액 환불 |
| T4 | 주문 확인(결제 완료) | — |
T3(잔액 차감)이 실패하면: C2(재고 복구) → C1(주문 취소)를 실행합니다.
두 가지 편성 방식:
- 코레오그래피(Choreography): 각 서비스가 이벤트를 수신하고 스스로 다음 단계를 결정. 단순하지만 전역 상태 추적이 어려움
- 오케스트레이션(Orchestration): 중앙 조정자가 프로세스를 제어. 명확하지만 조정자가 단일 장애점
5.3 TCC(Try-Confirm-Cancel)
TCC는 2PC의 비즈니스 계층 구현으로, 각 연산을 세 단계로 나눕니다:
| 단계 | 설명 | 예시(재고 차감) |
|---|---|---|
| Try | 자원을 예약하지만 실제로 실행하지 않음 | 10개 재고 동결(가용 재고 -10, 동결 재고 +10) |
| Confirm | 실행을 확정하고, 예약 자원을 소비 | 동결 재고 -10(실제 차감) |
| Cancel | 예약을 취소하고 자원을 해제 | 동결 재고 -10, 가용 재고 +10(복구) |
5.4 세 가지方案 비교
| 方案 | 일관성 | 성능 | 복잡도 | 적용 시나리오 |
|---|---|---|---|---|
| 2PC | 강 일관성 | 낮음 | 중간 | 데이터베이스 수준의 크로스 DB 트랜잭션 |
| Saga | 최종 일관성 | 높음 | 높음 | 장기 실행 비즈니스 프로세스(주문, 물류) |
| TCC | 최종 일관성 | 중간 | 가장 높음 | 자금류 고신뢰 시나리오 |
실제 선택 조언
- 단일 DB 트랜잭션으로 해결할 수 있다면 분산 트랜잭션을 사용하지 마세요
- 대부분의 비즈니스 시나리오에서는 Saga + 메시지 큐면 충분합니다
- TCC는 일관성 요구가 매우 높은 금융 시나리오에 적합하지만, 개발 비용이 높습니다
- 2PC는 데이터베이스 미들웨어(예: ShardingSphere)가 자동으로 처리하는 데 적합합니다
요약
분산 시스템은 현대 인터넷의 인프라지만, 그 복잡성은 단일 시스템을 훨씬 뛰어넘습니다. 이러한 도전 과제를 이해하는 것은 그것들을 '해결'하기 위함이 아니라(많은 것이 근본적인 것입니다), 시스템을 설계할 때 올바른 트레이드오프를 하기 위함입니다.
이 장의 핵심要点을 되돌아보겠습니다:
- CAP 정리: 네트워크 파티션은 불가피하며, 실제 선택은 일관성과 가용성 사이의 트레이드오프입니다
- 일관성 모델: 강 일관성에서 최종 일관성까지 스펙트럼이며, 비즈니스 요구에 따라 선택합니다
- 8대 도전 과제: 네트워크 불안정, 시계 비동기, 네트워크 파티션, 스플릿 브레인 등이 서로 연관되어 있습니다
- 합의 알고리즘: Raft가 현재 가장 실용적인 합의 알고리즘이며, etcd/Consul이 모두 이를 기반으로 합니다
- 분산 트랜잭션: Saga가 대부분의 시나리오에 적합하고, TCC는 금융 시나리오에 적합하며, 2PC는 데이터베이스 계층에 적합합니다
더 읽어보기
- Designing Data-Intensive Applications - Martin Kleppmann의 분산 시스템 고전
- The Raft Consensus Algorithm - Raft 공식 시각화 데모
- CAP Twelve Years Later - Brewer의 CAP 재검토
- Jepsen - 분산 시스템 정확성 테스트 프레임워크
- 분산 시스템 패턴 - Martin Fowler의 분산 패턴 모음