신뢰성·장애 복구 패턴
Rate Limit·Retry·Circuit Breaker·DLQ 조합으로 과부하·의존성 실패·부분 실패를 제어하는 신뢰성 설계
한 문단 요약 — 장애는 네 가지로 분류해야 대응이 가능하다
결론: 장애는 원인이 아니라 전파 방식으로 나눠야 설계가 된다.
첫째, 과부하(Overload) — 처리 능력 초과로 정상 요청까지 밀려난다.
둘째, 의존성 실패(Dependency Failure) — 외부/하위 시스템 장애가 전파된다.
셋째, 부분 실패(Partial Failure) — 일부 인스턴스·호출만 실패한다.
넷째, 지연 증가(Latency Amplification) — 평균은 정상인데 꼬리 지연이 SLA를 깬다.
신뢰성 패턴은 이 네 가지 중 어떤 실패를 어디서 끊을지 결정하는 구조다.
공통 예시 시나리오
결론: 모든 패턴은 외부 결제 API 실패가 내부 주문 서비스로 번지는 것을 막기 위한 장치다.
주문 생성
→ 외부 결제 API 호출
→ 결제 성공/실패
→ 주문 상태 갱신
Rate Limiting
결론: Rate Limiting은 공격 방어가 아니라 시스템 자살을 막는 안전벨트다.
막는 실패 유형
- 과부하
- 지연 증가
정의
요청 수·속도를 제한해 시스템이 감당 가능한 범위로 트래픽을 자르는 패턴.
직관
엘리베이터 정원 초과 시 더 태우지 않는다.
작동 원리
Client
→ Rate Limiter
→ 허용된 요청만 주문 서비스 진입
트레이드오프
- 장점: 전체 시스템 보호
- 비용: 일부 정상 요청 거부
적용 체크리스트
- 제한 기준이 사용자/토큰/IP 단위로 명확한가?
- 초과 시 사용자에게 명확히 알리는가?
- 내부 서비스에도 동일하게 적용되는가?
- 임계치 조정 근거가 있는가?
- 제한 로그가 관측되는가?
Retry
결론: Retry는 실패 복구 장치가 아니라 실패 증폭 장치가 될 수 있다.
막는 실패 유형
- 일시적 의존성 실패
정의
실패한 요청을 다시 시도하는 패턴.
필수 조건
결론: Retry는 제약 없으면 재난이다.
지수 백오프 + 지터
- 재시도 간격을 점점 늘린다.
- 지터로 동시 재시도 폭주를 방지한다.
멱등성(Idempotency)
- 같은 요청을 여러 번 처리해도 결과가 동일해야 한다.
- 주문 생성에는 멱등 키 필수.
Retry Storm 방지 규칙
- 최대 재시도 횟수 제한
- 전체 요청 중 재시도 비율 상한
트레이드오프
- 장점: 일시적 실패 복구
- 비용: 지연 증가, 부하 증폭 위험
적용 체크리스트
- 어떤 실패에만 재시도하는가?
- 멱등 키가 있는가?
- 재시도 횟수/간격이 명시됐는가?
- 타임아웃과 결합돼 있는가?
- 모니터링 지표가 있는가?
Circuit Breaker
결론: Circuit Breaker는 실패한 의존성을 빠르게 포기하는 용기다.
막는 실패 유형
- 의존성 실패 전파
- 지연 증폭
정의
의존 호출 실패율이 임계치를 넘으면 호출을 차단하는 패턴.
상태 전이
- Closed: 정상 호출
- Open: 호출 차단
- Half-open: 제한적 테스트 호출
임계치 튜닝 기준
결론: 임계치는 감각이 아니라 지연·오류율 지표다.
- 오류율 %
- 응답 시간 p95/p99
- 연속 실패 횟수
트레이드오프
- 장점: 장애 전파 차단
- 비용: 빠른 실패로 사용자 경험 저하 가능
적용 체크리스트
- 어떤 의존성에 적용하는가?
- Open 상태 시 대체 경로가 있는가?
- Half-open 테스트 기준이 명확한가?
- 상태 전이가 관측되는가?
- 임계치 변경 이력이 관리되는가?
Dead Letter Queue (DLQ)
결론: DLQ는 버리는 곳이 아니라 격리·재처리 파이프라인이다.
막는 실패 유형
- 부분 실패
- 데이터 손실
정의
처리 실패 메시지를 별도 큐로 분리하는 패턴.
왜 필요한가
- 메시지 한 건의 실패가 전체 스트림을 막지 않게 한다.
- 재처리를 운영 작업으로 분리한다.
운영 체크리스트
- DLQ 적재량 모니터링
- 재처리 기준/절차 문서화
- 스키마 버전 관리
- 자동/수동 재처리 구분
트레이드오프
- 장점: 장애 격리
- 비용: 운영 부담 증가
패턴 조합: 함께 써야 의미가 생긴다
결론: 단일 패턴은 방패 하나, 조합은 방어 체계다.
| 순서 | 패턴 | 주의점 |
|---|---|---|
| 1 | Rate Limiting | 가장 바깥에서 과부하 차단 |
| 2 | Retry | 멱등성 없으면 금지 |
| 3 | Circuit Breaker | Retry와 반드시 결합 |
| 4 | DLQ | 최종 격리 지점 |
실무 체크리스트
- 실패 유형을 네 가지로 분류했는가?
- 과부하 차단 지점이 있는가?
- 재시도는 제한되어 있는가?
- 멱등 키가 설계에 포함됐는가?
- 의존성별 CB 설정이 있는가?
- 타임아웃 기준이 명확한가?
- 부분 실패를 허용하는가?
- DLQ가 운영 프로세스에 포함됐는가?
- 실패 지표가 관측되는가?
- 장애 시 사용자 메시지가 준비됐는가?
- 자동 복구와 수동 개입 경계가 명확한가?
- “왜 이 조합인가”를 설명할 수 있는가?