API 실패 확률
복수 API 호출과 재시도에 따른 실패 확률을 계산합니다.
API 실패 확률 계산기는 복수의 API를 호출하고 재시도(retry)를 수행할 때 전체 요청이 실패할 확률을 계산하는 도구입니다. 마이크로서비스 아키텍처에서 여러 API에 의존하는 시스템의 신뢰성을 분석하는 데 활용됩니다. 개별 API 실패율이 1%라도 10개를 직렬 호출하면 전체 실패율은 1-(0.99)^10 ≈ 9.6%로 급증합니다. 재시도를 3회 추가하면 개별 실패율이 (0.01)^3 = 0.0001%로 떨어져 전체 안정성이 크게 개선됩니다. 이 계산기를 통해 재시도 횟수, 서킷 브레이커, 폴백 전략 등 장애 대응 설계의 효과를 수치로 확인할 수 있습니다.
입력
연쇄적으로 호출하는 API의 수
실패 시 자동 재시도 횟수
1 in 40
재시도를 포함한 최종 실패 확률
모든 API가 성공할 확률
API 수별 체인 실패 확률
workflow
사용 방법
약 1분
API 정보 입력
각 API의 실패율과 호출 방식(직렬/병렬)을 입력합니다.
재시도 설정
재시도 횟수를 설정합니다.
결과 확인
전체 실패 확률과 재시도 효과를 확인합니다.
principle
계산 원리
## API 실패 확률의 수학적 배경
### 직렬 호출 실패 확률 각 API의 실패율을 p₁, p₂, ..., pₙ이라 하면, 전체 성공 확률은:
P(전체 성공) = ∏(1 - pᵢ) = (1-p₁)(1-p₂)...(1-pₙ)
전체 실패 확률 = 1 - P(전체 성공)
모든 API의 실패율이 동일(p)하면: P(실패) = 1 - (1-p)ⁿ
### 병렬 호출 실패 확률 모든 API가 동시에 실패해야 전체가 실패하므로:
P(전체 실패) = ∏pᵢ = p₁ × p₂ × ... × pₙ
동일 실패율 p인 경우: P(전체 실패) = pⁿ
### 재시도 효과 재시도 r회 시 개별 API의 유효 실패율:
p_effective = p^(r+1)
예시: 실패율 2%인 API에 재시도 2회 적용 시 p_effective = 0.02³ = 0.000008 (0.0008%)
### 서킷 브레이커와 폴백의 결합 효과 주 API 실패율 p, 폴백 실패율 p_f일 때:
P(최종 실패) = p × p_f
faq
자주 묻는 질문
cases
실생활 예시
결제 시스템 3개 API 직렬 호출
결제 게이트웨이(실패율 0.5%), 재고 확인(0.3%), 알림 전송(1%) 세 API를 직렬 호출합니다. 전체 실패율은 1-(0.995×0.997×0.99) ≈ 1.8%입니다.
1,000건 주문 중 약 18건이 실패합니다. 알림 전송을 비동기로 분리하면 실패율을 0.8%로 줄일 수 있습니다.
재시도 3회 추가 효과
실패율 2%인 API에 재시도 3회를 추가하면 개별 실패율이 (0.02)^3 = 0.0008%로 감소합니다.
재시도만으로 실패율을 2,500배 줄일 수 있어, 가장 비용 효율적인 안정성 개선 방법입니다.
Netflix Chaos Monkey와 장애 내성 설계
Netflix는 Chaos Monkey로 프로덕션 서버를 무작위로 종료하여 장애 내성을 테스트합니다. 개별 서비스 실패율을 1%로 가정하고 재시도 2회와 폴백을 적용하면 사용자 체감 실패율은 0.0001% 이하입니다.
의도적으로 장애를 주입하는 카오스 엔지니어링은 실제 장애 발생 시 시스템이 얼마나 견디는지 사전에 검증하는 핵심 방법론입니다.
AWS S3 의존성 장애 사례 (2017년)
2017년 AWS S3 장애로 수천 개 서비스가 동시에 다운되었습니다. S3에 직접 의존하는 서비스들의 가용성이 S3 가용성(그날 약 96%)과 동일하게 떨어졌습니다.
단일 서비스에 대한 과도한 의존은 전체 시스템의 단일 장애 지점(SPOF)이 됩니다. 다중 리전 구성과 캐싱으로 의존도를 줄여야 합니다.
마이크로서비스 10개 직렬 호출 시나리오
각 API 실패율이 0.5%인 마이크로서비스 10개를 직렬 호출하면 전체 실패율은 1-(0.995)^10 ≈ 4.9%입니다. 재시도 2회를 모든 서비스에 적용하면 개별 실패율이 0.0025%로 떨어져 전체 실패율은 약 0.025%가 됩니다.
서비스 수가 늘수록 직렬 의존의 위험이 급증합니다. 비동기 이벤트 기반 통신으로 직렬 의존성을 줄이는 것이 근본 해결책입니다.
glossary
용어 사전
- 서킷 브레이커(Circuit Breaker)
- 연속 실패가 임계치를 초과하면 자동으로 요청을 차단하여 장애 전파를 방지하는 디자인 패턴입니다.
- 폴백(Fallback)
- 주 요청이 실패했을 때 대체 응답을 제공하는 전략입니다. 캐시된 데이터 반환, 기본값 사용 등이 있습니다.
- 지수 백오프(Exponential Backoff)
- 재시도 간격을 1초, 2초, 4초, 8초처럼 지수적으로 늘려 서버 과부하를 방지하는 재시도 전략입니다.
- 멱등성(Idempotency)
- 같은 요청을 여러 번 보내도 결과가 동일한 성질입니다. 재시도를 안전하게 적용하기 위한 필수 조건입니다.
- 벌크헤드(Bulkhead)
- 시스템을 격리된 구획으로 나누어 한 부분의 장애가 다른 부분에 전파되지 않도록 하는 패턴입니다.
- 연쇄 장애(Cascading Failure)
- 하나의 서비스 장애가 의존 서비스들로 연쇄적으로 전파되어 전체 시스템이 마비되는 현상입니다.
- 재시도 폭풍(Retry Storm)
- 다수의 클라이언트가 동시에 재시도하여 서버에 폭발적인 부하가 가해지는 현상입니다. 지터(jitter)를 추가하여 방지합니다.
- API 게이트웨이(API Gateway)
- 모든 API 요청의 진입점 역할을 하며 인증, 속도 제한, 로드밸런싱 등을 중앙에서 관리하는 서버입니다.
next tools