써드파티 API 장애 대응: DevOps 엔지니어 가이드

 

서비스 장애의 원인은 크게 애플리케이션 로직 문제, 리소스 과점유, 그리고 외부 의존 서비스 장애로 나눌 수 있다. 이 글에서는 이 중에서도 의존성 있는 서비스(써드파티 API) 장애에 한정하여 다룬다.

특히 외부 API 장애가 내부 시스템으로 전파되는 구조를 살펴보고, 이를 막기 위해 DevOps 엔지니어가 고려해야 할 설계 포인트와 운영 대응 방안을 중심으로 정리한다.

1) 장애가 서버까지 번지는 구조

써드파티 API가 느려지거나 에러를 반환하면, 우리 시스템의 호출 큐/스레드풀이 고갈되고, 전체 서비스 지연·500 에러로 이어질 수 있다.
이 문제를 해결하려면 “외부 장애가 내부로 전파되지 않도록 보호막을 설계”하는 것이 핵심이다.

---

2) 장애 전파 방지 핵심 설계

개념 1: 타임아웃과 일관된 요청 제한

정의
API 호출마다 한도가 없으면 호출 지연이 우리 서비스의 리소스를 점유한다. 이 때문에 반드시 일관된 타임아웃을 설정해야 한다.

적용 예시

• 상위 요청 SLA가 1초라면, 외부 API 호출은 그보다 작은 값(예: 300–500ms)으로 설정.
• 호출 체인은 전체 타임라인을 고려해 설계.

참고: AWS Builders Library – Timeouts, Retries, and Backoff with Jitter (공식 가이드)
https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/

---

3) 재시도와 서킷 브레이커

재시도 전략

• 조건부 재시도: 5xx/네트워크 오류에 한정(4xx는 즉시 오류 처리).
• 지수 백오프 + 지터: 과도한 재시도로 장애를 악화시키지 않도록 무작위 지연 추가.

참고: AWS Builders Library – Timeouts, Retries, and Backoff with Jitter
https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/

서킷 브레이커

정의
성공률이 떨어지면 연결을 차단해 내부 리소스를 보호하고, 회복 가능 시 자동으로 다시 연결을 시도하는 패턴이다.

적용 예시

• 실패율이 10% 넘으면 30초간 차단 → 캐싱 응답으로 fallback 제공.

참고: Martin Fowler – Circuit Breaker Pattern
https://martinfowler.com/bliki/CircuitBreaker.html

---

4) Bulkhead(격리) + 스레드풀 제한

정의
외부 API 호출 전용 스레드풀/커넥션풀을 분리해, 장애 시 나머지 경로가 영향을 덜 받게 한다.

예시

• 각 호스트별 동시 요청 상한 설정
• 호출 큐 길이 제한 + 큐 오버플로 처리

이렇게 하면 특정 외부 장애가 전체 서비스의 CPU/메모리/커넥션을 잠식하지 않게 된다.

---

5) 캐시/디그레이드 전략

캐시 전략

• TTL 캐시를 기본으로 두고, 장애 시 stale-while-revalidate(오래된 캐시라도 제공) 전략 사용.
• 데이터 유효성의 위험도는 비즈니스 규칙에 따라 조정.

참고: RFC 5861 – stale-while-revalidate Cache Control
https://datatracker.ietf.org/doc/html/rfc5861

디그레이드 (부분 기능 제공)

• 주요 호출이 실패하면 “기능 제한 응답”으로 서비스 유지.
  예) 실시간 가격 조회 실패 시 “최근 저장 가격 + ‘갱신 지연’ 플래그” 반환.

---

6) 운영 대응 플랜

순서

1. 킬 스위치/피처 플래그로 외부 호출 중지
2. 레이트 리밋 강화 및 동시성 상한 축소
3. Fallback/디그레이드 모드 활성화
4. 큐 기반 비동기 처리로 전환 가능 여부 확인
5. 장애 사후 분석 & PRR 체크리스트 작성

위 순서는 “빠른 보호 → 안정화 → 복구 → 평가”의 흐름으로 설계하면 효과적이다.

---

7) 모니터링 & 관측

메트릭

• 외부 호출 성공률, 응답 시간 p95/p99, 재시도 횟수, 서킷 상태(Open/Closed)
• SLI/SLO 개념으로 API별 SLA 목표 설정

참고: SLO 개념 정리
https://chaaany.tistory.com/468 (차니)

트레이싱

• 호출 흐름 전체 트레이싱으로 병목 위치 식별

---

References

• AWS Builders Library: Timeouts, Retries, and Backoff with Jitter
  https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/
• Martin Fowler – Circuit Breaker Pattern
  https://martinfowler.com/bliki/CircuitBreaker.html
• RFC 5861 – stale-while-revalidate Cache Control
  https://datatracker.ietf.org/doc/html/rfc5861
• 본인 블로그의 SLO/RTO 장애 대응 정리 글
  https://chaaany.tistory.com/468 (차니)

 

다음 글에서는, 이번 글에서 다룬 내용을 바탕으로 아래 주제들을 조금 더 구체적으로 정리해볼 예정이다.

1. 외부 API 장애가 시스템 장애로 번지는 가장 큰 원인은 무엇인지, 그리고 이를 어떤 지표로 사전에 감지할 수 있는지
2. 서킷 브레이커 · 재시도 · 타임아웃을 함께 사용할 때, 우선순위와 기본 설정 값(타임아웃 길이, 재시도 횟수, 백오프 상한)을 어떻게 잡는 것이 현실적인지
3. 디그레이드(fallback) 응답을 설계할 때, 사용자 경험을 크게 해치지 않으면서 시스템 안정성을 확보하는 구조는 어떻게 정리할 수 있는지