블랙프라이데이 폭주에도 끄떡없는 distributed system reliability 비결 7가지

블랙프라이데이도 거뜬히 버텨내는 분산 시스템 7가지 생존 전략

 

---

 

왜 이 이야기가 중요한가 – 한밤중 블랙프라이데이의 숨 막히는 순간

새벽 0시 1분, 한정 수량 콘솔을 장바구니에 담자마자 결제 완료 메시지가 즉시 뜹니다. 같은 시각, 수백만 명이 동시에 클릭하고 있지만 Amazon은 고요합니다. 반면, 대륙을 잇는 광케이블이 끊겨도 금융 시스템은 여전히 트랜잭션을 잃지 않습니다.

이 기적 같은 안정성은 어디서 나올까요? 사실 마법이 아니라, 수없이 검증된 7가지 reliability 개념 덕분입니다. 지금부터 이 원칙들을 한국어로, 그러나 SW 용어는 영어 그대로 살려서, 친근하게 풀어봅니다.

💡 Tip: 처음부터 모든 패턴을 적용할 필요는 없습니다. 언제 어떤 보호막을 추가할지 판단하는 눈이 더 중요합니다.

 

---

 

1. CAP theorem – Partition 속에서도 무엇을 지킬 것인가?

 

1. CAP theorem – Partition 속에서도 무엇을 지킬 것인가?

Long‑tail keyword: CAP theorem consistency vs availability during network partitions

세 가지 약속, 그중 둘만 선택

• Consistency : 모든 node가 같은 시점에 동일한 데이터를 본다.
• Availability : 살아 있는 node라면 반드시 응답한다.
• Partition tolerance : network가 갈라져도 시스템은 동작한다.

Partition은 언젠가 반드시 발생합니다. 결국 Consistency와 Availability 중 하나를 희생해야 하는 순간이 옵니다.

 

현실 세계의 선택

시스템	선택	전략	단점
Google Spanner	Consistency	원자 시계 + GPS clock으로 global linearizable transaction 유지	소수 파티션은 write 불가
Amazon DynamoDB	Availability	eventual consistency, timestamp 기반 last‑write‑wins	잠시 동안 stale data 노출

은행처럼 이중 인출이 치명적인 곳은 Consistency를, 소셜 피드처럼 약간 늦어도 되는 서비스는 Availability를 선택합니다.

🧭 Action step: "Partition이 나면 우리는 **{Consistency | Availability}**를 지킨다"라는 한 줄 정책을 팀 위키에 적어두세요.

 

---

 

2. Eventual consistency – 느슨해 보여도 강력한 비밀 병기

Long‑tail keyword: eventual consistency example Amazon shopping cart

한동안 업데이트가 멈추면 모든 replica가 결국 같은 상태로 수렴한다는 약속이 바로 eventual consistency입니다.

 

왜 사랑받을까?

• 지연 최소화 : 모든 replica에게 왕복할 때까지 기다리지 않아도 write 완료.
• 가용성 극대화 : 반쪽 지구가 끊겨도 사용자는 계속 기록 가능.

Amazon의 shopping cart가 대표 사례입니다. 서버 하나가 잠시 고립돼도 "Noise‑Cancelling Headphones"를 담을 수 있고, 나중에 데이터가 자동으로 합쳐집니다.

 

Conflict 해결 3종 세트

Strategy	설명	Trade‑off
Last‑write‑wins	가장 최근 timestamp 선택	데이터 유실 위험
CRDT	수학적 merge, 순서 상관없이 수렴	특수 자료형 필요
Custom merge	비즈니스 로직으로 해결	개발 비용 상승

🌱 Pro Tip: MVP 단계에서는 last‑write‑wins로 시작하고, 중요성이 커지면 CRDT나 custom merge를 도입하세요.

 

---

 

3. 똑똑한 load balancer – 단순 라운드로빈을 넘어

 

3. 똑똑한 load balancer – 단순 라운드로빈을 넘어

Long‑tail keyword: layer 7 load balancing vs layer 4 performance

 

Layer 4, 순수 속도의 세계

IP와 TCP/UDP 포트만 보고 라우팅합니다. 초고속이지만, 컨텍스트는 모릅니다.

 

Layer 7, 스마트 컨시어지

HTTP header, URL, cookie까지 들여다봅니다.

• /checkout 은 PCI‑준수 서버로
• 이미지 업로드는 여유 디스크 노드로

 

현대적 기술

1. Least connections : 연결 수가 적은 서버로 분배
2. Latency‑aware routing : 응답이 느려진 서버는 자동 회피
3. Consistent hashing sticky session : 같은 사용자를 같은 node에 고정
4. 이중화된 balancer : heartbeat로 1차 장애 시 ms 단위 failover

 

⚡ Quick win: /healthz 엔드포인트를 만들고, 종속 서비스까지 OK일 때만 200을 반환하도록 하세요.

 

---

 

4. Consistent hashing – 서버를 늘려도 야근하지 않는 비결

Long‑tail keyword: consistent hashing explained simple terms

 

key % n 방식은 node를 하나만 추가해도 거의 모든 key mapping이 바뀝니다. consistent hashing은 ring으로 해결합니다.

1. node와 key를 모두 0~2³² hash ring에 배치
2. key를 시계방향으로 이동해 처음 만난 node에 저장
3. replica 수만큼 그다음 node에도 복제
4. 새로운 node가 생기면 이웃에게서 일부 key만 가져옴 (약 k/n)

 

DynamoDB, Cassandra, CDN 캐시는 이 원리 덕분에 주말 없이 scale‑up 합니다.

🛠️ Try it: Docker로 cache 세 대를 띄우고 네 번째를 추가하며 key 이동량을 직접 확인해보세요.

 

---

 

5. Circuit breaker – 느린 죽음보다 빠른 실패가 낫다

 

5. Circuit breaker – 느린 죽음보다 빠른 실패가 낫다

Long‑tail keyword: circuit breaker pattern microservices Netflix Hystrix

외부 결제 서비스가 다운되면 checkout이 무한 retry로 thread를 다 써버릴 수 있습니다. circuit breaker가 고리를 끊습니다.

• Closed : error rate가 임계치 미만이면 정상 통과
• Open : 즉시 실패를 반환해 자원 보호
• Half‑open : 잠시 후 소량의 테스트 요청 허용

 

Netflix Hystrix로 유명해진 이 패턴은 Spring Cloud, Istio에도 기본 탑재됐습니다.

🚨 현장 후기: 한 fintech는 맹목적 retry를 circuit breaker로 바꾼 뒤 p95 latency를 35 % 절감했습니다.

 

---

 

6. Rate limiting – 과부하와 악의적 트래픽을 막는 전위

Long‑tail keyword: token bucket vs leaky bucket algorithm API rate limiting

공평성과 안전을 동시에 지키려면 rate limiting이 필수입니다.

Algorithm	원리	적합한 경우
Token bucket	일정 속도로 token 충전, 요청은 token 소모	일시적 burst 허용 API
Leaky bucket	고정 속도로 queue에서 흘려보냄	스트리밍처럼 일정 속도 필요
Fixed window	고정 시간칸에 카운트	프로토타입 단계
Sliding window	롤링 집계로 경계 효과 해소	프로덕션 API

 

분산 환경에서는 Redis + Lua로 atomic counter와 TTL을 관리해 cluster 전체 일관성을 얻습니다.

🛡️ Defense‑in‑depth: 인증 사용자 1,000 req/min, 익명 60 req/min처럼 계층형 정책을 두세요.

 

---

 

7. Observability – 트윗 난리 나기 전에 내부를 들여다보라

Long‑tail keyword: metrics logs traces four pillars of observability

보이지 않으면 고칠 수 없습니다. metrics, logs, traces, events 네 가지 신호를 엮어야 합니다.

• Metrics: RPS, error rate, CPU 등 시계열 숫자
• Logs: 구조화된 이벤트 레코드
• Traces: 분산 request의 end‑to‑end 흐름
• Events: deploy, feature flag처럼 맥락을 주는 사건

 

알림, 소음 대신 가치를

• Static threshold : 안정적 지표엔 좋지만, 트래픽 변화엔 취약
• Anomaly detection : 정상 패턴을 학습해 이탈 시 경보
• Composite rule : CPU↑, error↑, latency↑ 모두 충족 시만 알림

 

서비스 수준을 SLO로 정의하세요. 예) “checkout 99.9 %가 300 ms 내 성공”.

🎯 습관: 매달 알림 리뷰로 ‘안 터진’ 경보를 과감히 삭제하세요.

 

---

 

이제 당신의 시스템에 적용하는 순서

1. Start simple : 한 AZ 배포로 충분하면 거기서 시작.
2. Measure relentlessly : launch day부터 latency·throughput·error 수집.
3. Add guards when data speaks : 진짜 장애 원인을 발견하면 그다음 sprint에 보호막 추가.
4. Iterate forever : Reliability는 끝없는 개선 여정.