1. 장애 대처 방법
1.1 캐싱 (Caching)
설명
API 응답 데이터를 캐싱하여 일정 기간 동안 재사용합니다.
장점
- 반복적인 요청을 줄여 API 사용 비용 감소
- API 장애 시에도 기존 데이터를 사용 가능
단점
- 데이터 신선도가 낮아질 수 있음
- 복잡한 캐싱 정책이 필요할 수 있음
트레이드오프
캐싱은 데이터 신선도와 안정성 사이의 균형을 요구합니다. 실시간 데이터보다 안정성이 중요한 경우에 유용합니다.
1.2 폴백 처리 (Fallback Handling)
설명
API 호출 실패 시, 기본값이나 대체 로직을 제공하여 서비스가 계속 동작하도록 합니다.
장점
- 장애 시에도 서비스 중단 방지
- 유연한 사용자 경험 제공
단점
- 정확도가 낮을 수 있는 기본값 의존
- 복잡한 폴백 로직 구현 필요
트레이드오프
폴백 처리에서는 데이터 정확성과 연속적인 서비스 제공의 우선순위를 고려해야 합니다.
1.3 재시도 메커니즘 (Retry Mechanism)
설명
API 호출이 실패했을 때 일정 간격을 두고 재시도합니다.
장점
- 일시적인 네트워크 문제 해결 가능
- 장애가 일시적일 경우 효과적
단점
- 재시도 설정에 따라 서비스 지연 발생 가능
- 과도한 재시도는 API 제공자 서버에 부하 초래
트레이드오프
재시도는 요청 성공률과 서비스 지연 사이의 조정이 필요합니다. 과도한 재시도를 방지하기 위해 백오프(backoff) 전략을 함께 사용하는 것이 일반적입니다.
1.4 서킷 브레이커 (Circuit Breaker)
설명
API 장애가 일정 횟수를 초과하면 요청을 차단하여 시스템 과부하를 방지합니다.
장점
- 시스템 안정성 확보
- 불필요한 요청 감소
단점
- 장애 복구 후에도 차단 지속 가능성
- 초기 설정 및 모니터링 복잡
트레이드오프
서킷 브레이커는 시스템 안정성과 빠른 복구를 위한 선택이며, 정확한 설정이 중요합니다.
1.5 API 제공자 다중화 (API Redundancy)
설명
다수의 API 제공자를 설정하여 한 API가 장애가 나면 다른 API를 사용합니다.
장점
- 높은 가용성
- 장애 시에도 지속적인 서비스 제공
단점
- 다중 API 제공자 간의 데이터 불일치 가능성
- 높은 구현 및 유지보수 비용
트레이드오프
이 방법은 비용과 신뢰성 간의 균형이 필요하며, 미션 크리티컬한 서비스에 적합합니다.
2. 일반적으로 가장 권장되는 기술
장애 대처 전략은 사용 사례와 서비스 특성에 따라 다르지만, 일반적으로 서킷 브레이커와 캐싱을 결합하는 방식이 권장됩니다. 서킷 브레이커를 사용해 시스템 과부하를 방지하고, 캐싱을 통해 일관된 사용자 경험을 제공할 수 있습니다. 이를 통해 장애 시에도 서비스의 연속성을 최대한 보장할 수 있습니다.
Backend Developer