분산 시스템 기초

학습 목표

분산 시스템이 네트워크·다중 노드 위에서 동작할 때 생기는 아키텍처 관점 질문을 설명할 수 있다.

Scale up vs scale out 선택 기준을 설명할 수 있다.

로드 밸런싱의 역할과 L4/L7 차이를 설명할 수 있다.

Stateless vs Stateful 설계와 세션·스티키 트레이드오프를 설명할 수 있다.

문제 상황

• 트래픽 3배 — DB 서버 CPU 95%, 앱 서버는 40%
  • 앱만 10대 늘려도 DB가 병목
• 로드 밸런서 뒤 인스턴스 5개인데 한 대만 CPU 90%
  • 세션 sticky + in-memory cart
• Scale up — 64코어·512GB 단일 DB
  • 비용·장애 blast radius · 한계 도달
• 인스턴스 재시작마다 로그인 풀림 — 세션이 로컬 Tomcat
• 헬스체크 /health 200인데 실제 DB 연결 끊김 — 가짜 healthy

MSA·EDA는 여러 프로세스 전제다. Part 4는 그 전제에서 공통으로 쓰는 스케일·트래픽·상태 패턴이다.

1. 분산 시스템이란

분산 시스템 — 독립 노드가 네트워크로 협력해 하나의 서비스처럼 보이는 시스템.

단일 JVM	분산
메서드 호출	네트워크 RPC·HTTP
공유 메모리	메시지·API
한 프로세스 장애	부분 장애·지연
트랜잭션 ACID (한 DB)	분산 트랜잭션 복잡 (이후 편)

분산 컴퓨팅의 함정(Fallacies) — 항상 기억:

• 네트워크는 신뢰되지 않는다
• 지연은 0이 아니다
• 대역폭은 무한하지 않다
• 보안 경계는 어디에나 있다
• Network 시리즈의 HTTP·TCP·DNS — 여기서는 아키텍처가 그 위에 무엇을 두는지

2. Scale up vs Scale out

	Scale up (vertical)	Scale out (horizontal)
방법	더 큰 머신	더 많은 노드
적합	DB·단일 강한 TX	stateless 앱 tier
한계	hardware 천장	조율·데이터 일관성
장애	한 대 = 전체	일부 노드만

계층	흔한 선택
앱	scale out + LB
DB	scale up → read replica → sharding (데이터 편)
캐시	scale out (Redis cluster)
메시지	partition scale out (Kafka)

• Elasticity — 수요에 맞게 out 노드 증감 (K8s HPA, auto scaling group)
• 병목 측정 후 스케일 — 앱만 늘리고 DB가 100%면 효과 없음

3. 로드 밸런싱

로드 밸런서(LB) — 트래픽을 여러 인스턴스에 나눠 가용성·처리량을 올린다.

계층	예	특징
L4	TCP/UDP, NLB	빠름, IP·port 기준
L7	HTTP, ALB, nginx	경로·헤더·TLS 종료

알고리즘	설명
Round robin	순환 — 인스턴스 동질·stateless
Least connections	연결 적은 쪽
Weighted	capacity 다를 때
Hash	client IP — sticky에 가깝 (주의)

upstream api_backend {
    least_conn;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
    server 10.0.1.13:8080;
}

server {
    location / {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
    }
}

• Health check — /health가 의존성(DB)까지 검사하는지
• Graceful shutdown — drain 후 deregister
• MSA — 서비스마다 LB 또는 mesh·Gateway 뒤 배치

4. Stateless vs Stateful

	Stateless	Stateful
인스턴스	어느 대도 동일 처리	특정 대에 상태
스케일	LB 자유	sticky·shard 필요
장애	교체 쉬움	상태 복구·마이그레이션
상태 저장	외부 (DB, Redis)	메모리·로컬 디스크

Stateless 권장 패턴

Client → LB → any App instance
                  ↓
              Redis / DB (session, cart)

• JWT + 짧은 TTL — 서버 세션 없음 (단, revoke·블록리스트는 별도)
• 12-factor — 프로세스 disposable

Stateful이 필요할 때

케이스	대응
WebSocket 연결	sticky 또는 connection broker
로컬 cache warm	재시작 시 cache miss 허용 vs pre-warm
순서 보장 consumer	partition key (Kafka)

• Sticky session — LB가 같은 인스턴스로 고정
  • 배포·장애 시 세션 유실 — 외부 session store가 낫다
• StatefulSet(K8s) — 고정 ID·볼륨 (DB, ZooKeeper)

5. 품질 속성·MSA 연결

QA	분산 패턴
Scalability	scale out + stateless
Availability	LB + N instance + health check
Performance	L7 routing·캐시·지역 배치
Maintainability	state 외부화 — 인스턴스 교체 용이

• MSA 서비스마다 독립 scale — catalog 10대, billing 2대
• 동기 체인 scale out — fan-out 지연·장애 (15편)

6. 실무 체크리스트

질문	좋은 답
앱 tier stateless한가	yes — session in Redis
LB health가 DB를 보나	critical path 포함
scale out 전 병목 측정했나	DB·외부 API
sticky 왜 쓰나	WebSocket 등 이유 문서화
배포 시 connection drain	preStop·weight 0

7. 정리

• 분산 = 네트워크·부분 장애 전제 — 함정 기억
• Scale out + LB — stateless 앱 tier 기본
• Scale up — DB·특수 강 일관 워크로드
• State는 외부 store — sticky는 최후
• 다음 — CAP·일관성 (강 vs eventual)

다음에 다룰 것

• CAP과 일관성 모델
• CAP, PACELC, strong/eventual consistency

---

해당 내용은 Fundamentals of Software Architecture (Mark Richards, Neal Ford) 및 Designing Data-Intensive Applications (Martin Kleppmann) 의 내용을 기반으로 합니다.