IBM 의 마이크로서비스를 위한 재시도 메커니즘을 읽고

• 원본 게시물 링크

간략한 요약

이 글은, 제어할 수 없는 써드파티 시스템에 의존하는 로직에서 재시도를 어떻게 설계했는지에 대해 설명하는 글이다.

3계층을 설계해서, 초 단위 / 분 단위 / 일 단위로 복구가 진행될 수 있는 방식을 설명한다.
그리고, 왜 이런 재시도 메커니즘에서 Kafka 를 안 쓰는지? (안 좋아하는지?) 에 대해 설명한다.

3계층

MSA 에서 실패는 실패가 아니다. 관측되는 것이다.
네트워크 실패, 서버 다운, 레이턴시 급증등은 항상 발생할 수 있는 것이다.

레이턴시 급증 : 네트워크 혼잡, ISP 경로 문제 혹은 무선 신호 불안정 등 지연시간이 의도치않게 늘어나는 것

그래서, 이를 계속 대응할 수 있게 3계층을 구축했다고 한다.

1계층 - 지수 백오프

타임아웃, 커넥션 에러, 서버 에러 등 일시적 장애에 대응한다.

• 재시도 간격도 적절히 지수 백오프로 설정한다.
• 즉각적인 재시도를 원하기에 Kafka 같은 비동기 시스템이 부적합하다고 판단

2계층 - n분 주기 배치잡

서비스가 지속적으로 문제가 바로 해결 안되거나, 느린 경우에 대응한다.

실패를 기록할 큐 테이블 생성

• retryCount : 재시도 횟수

• nextRetryAt : 다음에 시작할 시간

• n 분마다 주기적으로 큐를 스캔해서 재시도

• 성공한 레코드는 제거 (바로 삭제 or 지연 시간 후 삭제도 가능 - Janitor 로직 )

Janitor : 청소부 역할, 성공 및 오랜 지난 데이터 주기적 삭제해서 무한히 커지는 것을 방지(house-keeping)

3계층 - 24 시간 배치잡

2계층으로도 복구 안되는 건들을 위한 최종 안정망에 해당한다.

이때부턴, 어떻게 구현 하냐에 따라 달라질거 같다.

• 하루 몇회 스캔할 지
• 최대 몇일 시도할 지
• 최대 시도 실패 후, 어떻게 처리할지

왜 Kafka + EDA 가 아닌가?

• 각 요소별 추적 불가능 : Kafka 는 개별 건 성공/실패를 실시간 + 직관적 추적 불가능
• 긴 처리 시간 : 건당 1~2분을 넘어가므로, 컨슈머에 부적합 판단
• 재시도 가시성 부족 : 토픽 간 리다이렉션 (@RetryableTopic) 은 성공 여부 투명성이 낮음
• 인프라 오버헤드 : 소규모 재시도에도 Kafka 클러스터를 쓰기에는 과잉
• DLQ : DLQ 는 실패를 저장할 뿐, 능동적으로 재시도하지 않는다.

---

25년 10월 8일로 따끈따끈한 글이다.
여전히, 카프카만이 정답은 아니라는걸 알려주는거 같다?