결제 시스템 3개 API 직렬 호출
결제 게이트웨이(실패율 0.5%), 재고 확인(0.3%), 알림 전송(1%) 세 API를 직렬 호출합니다. 전체 실패율은 1-(0.995×0.997×0.99) ≈ 1.8%입니다.
1,000건 주문 중 약 18건이 실패합니다. 알림 전송을 비동기로 분리하면 실패율을 0.8%로 줄일 수 있습니다.
API 실패 확률
복수 API 호출과 재시도에 따른 실패 확률을 계산합니다.
입력
개
연쇄적으로 호출하는 API의 수
%
회
실패 시 자동 재시도 횟수
체인 실패 확률 (재시도 없음)
체인 실패 확률 (재시도 없음) 2.475125%
1 in 40
체인 성공97.5%
체인 실패2.5%
- 체인 실패 확률 (재시도 2회)0.00006250%재시도를 포함한 최종 실패 확률
- 체인 성공 확률97.524875%모든 API가 성공할 확률
1 in 40: 2.475125%
API 수별 체인 실패 확률
차트 그리는 중…
풀이 보기
결과 공유하기
API 실패 확률 계산기는 복수의 API를 호출하고 재시도(retry)를 수행할 때 전체 요청이 실패할 확률을 계산하는 도구입니다. 마이크로서비스 아키텍처에서 여러 API에 의존하는 시스템의 신뢰성을 분석하는 데 활용됩니다. 개별 API 실패율이 1%라도 10개를 직렬 호출하면 전체 실패율은 1-(0.99)^10 ≈ 9.6%로 급증합니다. 재시도를 2회 추가하면 개별 실패율이 (0.01)^3 = 0.0001%로 떨어져 전체 안정성이 크게 개선됩니다. 이 계산기를 통해 재시도 횟수, 서킷 브레이커, 폴백 전략 등 장애 대응 설계의 효과를 수치로 확인할 수 있습니다.
실생활 예시
이럴 때 이렇게 계산해요.
재시도 2회 추가 효과
실패율 2%인 API에 재시도 2회를 추가하면 개별 실패율이 (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.0000125%로 떨어져 전체 실패율은 약 0.000125%가 됩니다.
서비스 수가 늘수록 직렬 의존의 위험이 급증합니다. 비동기 이벤트 기반 통신으로 직렬 의존성을 줄이는 것이 근본 해결책입니다.
관련 계산기
같이 쓰면 좋아요. 옆으로 넘겨 보세요.
자주 묻는 질문
궁금한 거 모아 봤어요. 눌러서 펼쳐 보세요.
직렬 호출과 병렬 호출은 실패 확률이 어떻게 다른가요?
직렬 호출은 모든 API가 성공해야 하므로 실패율이 누적됩니다(1-(1-p)^n). 병렬 호출은 하나만 성공하면 되므로 실패율이 p^n으로 급격히 감소합니다. 실패율 1%인 API 3개 병렬 호출 시 전체 실패율은 0.0001%입니다.
재시도를 무한히 늘리면 실패율이 0이 되나요?
이론적으로는 접근하지만, 재시도마다 지연시간이 추가되고 서버에 부하가 가중됩니다. 보통 3~5회 재시도가 적정선이며, 그 이상은 지수 백오프(exponential backoff)와 서킷 브레이커로 보완합니다.
서킷 브레이커 패턴은 무엇인가요?
연속 실패가 임계치를 초과하면 자동으로 요청을 차단(open)하여 장애 전파를 막는 패턴입니다. 일정 시간 후 반열림(half-open) 상태에서 복구를 확인한 뒤 정상(closed)으로 돌아갑니다.
폴백(fallback) 전략은 실패율에 어떤 영향을 주나요?
폴백은 주 API가 실패했을 때 대체 응답을 제공합니다. 예를 들어 실시간 추천 API가 실패하면 캐시된 인기 상품 목록을 반환하는 방식입니다. 주 API 실패율이 2%이고 폴백 실패율이 0.1%라면 최종 실패율은 0.02×0.001 = 0.002%로 크게 줄어듭니다.
멱등성(idempotency)이 재시도에 왜 중요한가요?
멱등성이 보장되지 않으면 재시도 시 같은 요청이 중복 처리됩니다. 예를 들어 결제 API가 멱등성 없이 재시도되면 이중 결제가 발생합니다. 재시도를 안전하게 적용하려면 모든 API에 멱등성 키(idempotency key)를 포함해야 합니다.
연쇄 장애(cascading failure)는 어떻게 발생하나요?
하나의 API가 느려지면 호출 측에서 대기 스레드가 쌓이고, 이것이 상위 서비스의 타임아웃과 실패를 유발합니다. 마이크로서비스 10개가 직렬 연결된 환경에서 하나의 장애가 전체 시스템을 마비시킬 수 있습니다. 서킷 브레이커와 벌크헤드 패턴으로 차단합니다.
API 실패율은 어떻게 측정하나요?
HTTP 5xx 응답 비율, 타임아웃 비율, 에러 로그 수를 모니터링 도구(Datadog, Prometheus 등)로 추적합니다. 보통 5분 또는 1시간 단위의 롤링 윈도우로 측정하며, SLA에서는 월 단위 평균 실패율을 기준으로 합니다.
계산 원리
## 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
사용 방법
API 정보 입력
각 API의 실패율과 호출 방식(직렬/병렬)을 입력합니다.
재시도 설정
재시도 횟수를 설정합니다.
결과 확인
전체 실패 확률과 재시도 효과를 확인합니다.
용어 사전
- 서킷 브레이커(Circuit Breaker)
- 연속 실패가 임계치를 초과하면 자동으로 요청을 차단하여 장애 전파를 방지하는 디자인 패턴입니다.
- 폴백(Fallback)
- 주 요청이 실패했을 때 대체 응답을 제공하는 전략입니다. 캐시된 데이터 반환, 기본값 사용 등이 있습니다.
- 지수 백오프(Exponential Backoff)
- 재시도 간격을 1초, 2초, 4초, 8초처럼 지수적으로 늘려 서버 과부하를 방지하는 재시도 전략입니다.
- 멱등성(Idempotency)
- 같은 요청을 여러 번 보내도 결과가 동일한 성질입니다. 재시도를 안전하게 적용하기 위한 필수 조건입니다.
- 벌크헤드(Bulkhead)
- 시스템을 격리된 구획으로 나누어 한 부분의 장애가 다른 부분에 전파되지 않도록 하는 패턴입니다.
- 연쇄 장애(Cascading Failure)
- 하나의 서비스 장애가 의존 서비스들로 연쇄적으로 전파되어 전체 시스템이 마비되는 현상입니다.
- 재시도 폭풍(Retry Storm)
- 다수의 클라이언트가 동시에 재시도하여 서버에 폭발적인 부하가 가해지는 현상입니다. 지터(jitter)를 추가하여 방지합니다.
- API 게이트웨이(API Gateway)
- 모든 API 요청의 진입점 역할을 하며 인증, 속도 제한, 로드밸런싱 등을 중앙에서 관리하는 서버입니다.