RSS Trigger가 실패하면 워크플로 전체가 죽어야 하는가

RSS Trigger가 실패하면 워크플로 전체가 죽어야 하는가

Scope

핵심 질문

외부 RSS feed 장애가 전체 자동화 실패로 전파되지 않도록 어떤 실패격리 전략을 써야 하는가?

Research

핵심 근거

• 외부 feed는 일시적인 4xx, 5xx, timeout, invalid XML을 반환할 수 있다.
• 여러 feed를 하나의 batch로 처리할 때 한 feed의 실패가 전체 transaction을 취소하면 가용성이 낮아진다.
• source별 상태와 retry queue를 분리하면 partial success가 가능하다.

Draft

대부분의 뉴스·수집 파이프라인에서는 RSS 하나의 실패 때문에 전체 workflow를 실패시키는 것이 좋지 않다.

실패단위를 source로 줄인다

10개 feed를 읽는다면 각 feed fetch를 독립 작업으로 취급한다. 하나가 timeout 나도 나머지 9개 결과는 계속 처리할 수 있어야 한다.

오류를 데이터로 기록한다

예외를 무시하지는 않는다. source URL, 마지막 성공시각, 오류유형, retry 횟수를 저장해 장애가 지속되는 feed를 확인할 수 있게 한다.

언제 전체 실패가 맞는가

모든 source가 반드시 성공해야 결과의 의미가 성립하는 계산이라면 전체 실패가 맞을 수 있다. 하지만 뉴스 수집처럼 일부 source가 없어도 나머지 데이터를 사용할 수 있는 경우에는 partial success가 더 자연스럽다.

Retry

일시적인 HTTP 오류는 exponential backoff로 재시도하고 parsing 오류처럼 계속 반복될 가능성이 큰 문제는 별도 dead-letter 상태로 분리한다.

핵심

외부 source 장애를 workflow 전체 장애와 동일시하지 말고, 최소한의 독립적인 실패단위로 격리하는 것이 안정적이다.