# 분산 시스템 장애 확률이 겹쳐 “40% 실패”를 만든다 – 리소스 지터와 확률 스택링 완전 정복

*(SEO 키워드: **분산 시스템**, **장애 확률**, **리소스 지터**)*

---

# # 📌 서론 – “왜 우리 서비스는 갑자기 느려지나요?”

여러분이 운영하는 웹 서비스가 **수십 개**의 서버(노드)로 구성된 **분산 시스템**이라고 가정해봅시다.

각 노드는 정상적인 요청을 처리하지만, **1 %** 정도의 **리소스 지터**(일시적인 성능 저하)가 발생할 수 있습니다.

> **문제 제기**

> *“모든 노드가 정상이어야만 하나의 호출이 성공한다면, 전체 시스템의 성공 확률은 얼마나 될까?”*

이 질문에 답을 찾다 보면 **확률이 겹쳐서(Probability Stacking)** 의외로 **40 %**에 달하는 **장애 확률**을 마주하게 됩니다.

초보자도 이해하기 쉬운 예시와 수학적 원리를 통해, 왜 이런 현상이 발생하고 어떻게 대비해야 하는지 단계별로 살펴보겠습니다.

---

# # 1️⃣ 확률 기본 개념 – 독립 사건과 곱셈 법칙

## # 1-1. 독립 사건이란?

두 사건 A와 B가 서로에게 영향을 주지 않을 때, **독립**이라고 합니다.

예를 들어, **노드 1**이 지터에 빠지는 사건과 **노드 2**가 지터에 빠지는 사건은 서로 다른 하드웨어·소프트웨어를 사용한다면 대부분 **독립**합니다.

## # 1-2. 성공·실패 확률 계산법

- **한 노드가 정상일 확률** = 1 – 0.01 = **0.99**

- **50개의 노드가 모두 정상일 확률** = 0.99⁵⁰

> **계산**

> 0.99⁵⁰ ≈ 0.605 → 약 **60.5 %**

즉, **전체 호출이 성공**하려면 **40 %** 정도는 **실패**(하나라도 지터가 발생)하게 됩니다.

> **핵심 포인트**

> *“모든 노드가 정상이어야 하는 경우, 개별 실패 확률이 작아도 전체 실패 확률은 급격히 상승한다.”*

---

# # 2️⃣ 리소스 지터가 시스템에 미치는 실제 영향

## # 2-1. 지터란 무엇인가?

**리소스 지터**는 CPU, 메모리, 네트워크 대역폭 등 자원의 일시적인 변동을 의미합니다.

- **CPU 스파이크** → 응답 지연

- **네트워크 패킷 손실** → 재전송 증가

- **디스크 I/O 지연** → 데이터베이스 타임아웃

## # 2-2. 지터가 누적되는 메커니즘

분산 시스템에서는 **서비스 호출 체인**이 길어질수록 지터가 **누적**됩니다.

예) API Gateway → 인증 서비스 → 사용자 프로파일 서비스 → 결제 서비스

각 단계마다 **1 %**의 지터가 발생한다면, 전체 체인의 성공 확률은

\[

(0.99)^{\text{단계 수}}

\]

단계가 5개라면 0.99⁵ ≈ 0.951 → **4.9 %**의 실패 확률.

## # 2-3. 실제 사례 – Reddit 토론 스레드

Reddit의 *r/programming*에 올라온 **“Probability stacking in distributed systems”** 스레드에서는

> “50개의 노드가 각각 1 %의 장애율을 가지고, 모든 노드가 필요할 때 전체 호출 성공 확률은 40 %에 불과하다.”

이와 같은 **실제 현장 사례**는 **장애 확률**이 작아 보이더라도 **시스템 설계** 단계에서 반드시 고려해야 함을 강조합니다.

---

# # 3️⃣ 확률 스택링을 방지하는 설계 전략

## # 3-1. **다중화(Redundancy)와 복제**

| 전략 | 설명 | 기대 효과 |

|------|------|-----------|

| **Active‑Active** | 여러 인스턴스가 동시에 트래픽을 처리 | 하나가 지터가 나도 다른 인스턴스가 바로 대체 |

| **Active‑Passive** | 주 인스턴스와 대기 인스턴스 구분 | 장애 시 자동 페일오버 |

| **데이터 복제** | 여러 데이터 센터에 동일 데이터 저장 | 지역 장애·지연 최소화 |

> **팁**: 복제 수를 **2배** 이상으로 늘리면 전체 실패 확률을 **거듭 제곱**으로 감소시킬 수 있습니다. 예) 3개의 복제 → (0.99)³ ≈ 0.970 → 3 % 실패율.

## # 3-2. **서킷 브레이커(Circuit Breaker)와 타임아웃**

- **서킷 브레이커**는 일정 횟수 이상 실패가 감지되면 해당 노드에 대한 호출을 차단하고, **백오프(back‑off)** 후 재시도합니다.

- **타임아웃**을 짧게 설정하면 지터가 심한 노드가 전체 체인을 지연시키는 것을 방지합니다.

## # 3-3. **리트라이와 백오프 전략**

| 단계 | 리트라이 횟수 | 백오프 간격 |

|------|--------------|-------------|

| 1차 | 1~2회 | 100 ms |

| 2차 | 3~4회 | 500 ms |

| 3차 | 5회 이상 | 1 s 이상 |

리트라이를 **지수 백오프**(exponential back‑off)와 ** jitter**(무작위 지연)와 결합하면 **동시 재시도**로 인한 **쓰루풋 폭주**를 방지할 수 있습니다.

## # 3-4. **관측 및 알림(Observability)**

- **메트릭**: `request_latency`, `error_rate`, `jitter_rate` 등을 실시간 대시보드에 표시

- **로그**: 지터 발생 시점과 원인(CPU, 네트워크 등) 기록

- **알림**: 실패 확률이 일정 임계값(예: 5 %)을 초과하면 자동 슬랙·메일 알림

관측 체계가 튼튼해야 **문제 조기 탐지**와 **신속한 복구**가 가능합니다.

---

# # 4️⃣ 확률 스택링을 수치로 이해하기 – 간단한 계산 예시

## # 4-1. 파이썬으로 직접 계산해 보기

```
python

# 노드 수와 개별 장애 확률

n = 50          # 노드 수

p_fail = 0.01   # 개별 노드 장애 확률

# 전체 성공 확률

p_success = (1 - p_fail) ** n

p_failure = 1 - p_success

print(f'전체 호출 성공 확률: {p_success:.2%}')

print(f'전체 호출 실패 확률: {p_failure:.2%}')

```

> **출력**

> 
```

> 전체 호출 성공 확률: 60.5%

> 전체 호출 실패 확률: 39.5%

> 
```

## # 4-2. 시각화 – 그래프로 보는 확률 변화

| 노드 수 | 개별 장애 1 % | 전체 성공 확률 |

|--------|--------------|----------------|

| 10     | 0.99¹⁰ ≈ 0.904 | 90.4 % |

| 20     | 0.99²⁰ ≈ 0.819 | 81.9 % |

| 30     | 0.99³⁰ ≈ 0.739 | 73.9 % |

| 40     | 0.99⁴⁰ ≈ 0.667 | 66.7 % |

| 50     | 0.99⁵⁰ ≈ 0.605 | 60.5 % |

노드가 늘어날수록 **성공 확률**이 급격히 떨어지는 것을 한눈에 확인할 수 있습니다.

---

# # 5️⃣ 실전 적용 체크리스트

| 체크 항목 | 적용 여부 | 비고 |

|----------|----------|------|

| **노드 독립성 보장** | ☐ | 동일 하드웨어·네트워크 사용 최소화 |

| **다중화 설계** | ☐ | Active‑Active 혹은 Active‑Passive 선택 |

| **서킷 브레이커 도입** | ☐ | 실패 임계값과 복구 정책 정의 |

| **지수 백오프 + jitter** | ☐ | 재시도 폭주 방지 |

| **관측 메트릭 구축** | ☐ | `error_rate`, `latency`, `jitter` 실시간 수집 |

| **정기적인 장애 시뮬레이션** | ☐ | Chaos Engineering 활용 |

위 체크리스트를 **주기적으로 검증**하면, “40 % 실패”라는 충격적인 확률을 **10 % 이하**로 낮출 수 있습니다.

---

# # 🏁 결론 – 확률 스택링을 이겨내는 첫걸음

분산 시스템에서 **작은 지터**가 **전체 서비스**의 성공률을 크게 좌우한다는 사실, 이제는 명확히 이해하셨을 겁니다.

1. **확률을 수치화**하고 **시각화**해 보면, 설계상의 위험이 눈에 보이게 됩니다.

2. **다중화·서킷 브레이커·백오프**와 같은 **내결함성 패턴**을 적용하면, 개별 노드의 1 % 장애가 전체 시스템에 미치는 영향을 크게 줄일 수 있습니다.

3. **관측·알림 체계**를 갖추어 **실시간 대응**이 가능하도록 하면, 장애가 발생하더라도 서비스 가용성을 유지할 수 있습니다.

> **행동 유도**

> *지금 바로 여러분의 서비스에 적용 가능한 **장애 확률 계산 스크립트**를 실행해 보세요. 그리고 위 체크리스트를 바탕으로 **한 가지라도 개선점**을 찾아 적용한다면, 다음 배포에서는 **40 % 실패**를 **10 % 이하**로 낮출 수 있습니다.*

---

## # 📣 더 알고 싶다면?

- **구독**: 최신 분산 시스템 설계와 장애 대응 팁을 매주 받아보세요.

- **댓글**: 여러분이 겪은 “리소스 지터” 사례를 공유하고, 함께 해결책을 논의해요!

- **다운로드**: “분산 시스템 장애 확률 계산기” 엑셀 템플릿을 무료로 받아보세요.

함께라면 복잡한 **분산 시스템**도 **안정적인 서비스**로 만들 수 있습니다. 🚀