AX 시스템은 일반 웹 서비스보다 실패 제어가 더 중요하다. API와 달리 여러 단계를 거치기 때문에 여러가지 실패가 발생하게 된다.

• LLM 응답이 늦게 도착
• API 요청은 성공했지만 응답 유실
• 같은 작업이 두 번 실행
• 외부 서시브 장애가 장시간 지속됨
• 재시도가 몰려 장애가 더 심해짐
• 처리할 수 없는 메시지가 큐를 계속 막음

등등이 있다. 따라서 제어 장치가 매우 중요하다.

Timeout

• 타임아웃은 작업이 일정 시간 안에 끝나지 않으면 더 이상 기다리지 않고 실패로 판단하는 정책이다.

  • 만약 타임아웃 정책이 없다면 상대방이 응답할 때 까지 무한히 기다릴 수 있다.
  • 특히 AX 시스템에서는 특히 외부 호출이 긴 시간 멈출 수 있기 때문에 필수이다.

• 타임아웃의 종류

  • connection Timeout : 상대 서버와 연결을 맺기까지 기다리는 시간
    • DNS 조회 → TCP 연결 → TLS 연결 (예. connection timeout : 3초)
  • Read Timeout : 연결은 되었지만 응답 데이터를 받기까지 기다리는 시간
    • 서버 연결 성공 → 요청 전송 → 응답 대기 (예. Read timeout: 30초)
  • Write Timeout : 요청 데이터를 상대방에게 전송하는데 허용하는 시간
    • 대용량 파일 업로드나 이미지 전송에서 중요.
  • Request Timeout : 전체 요청 생명주기에 대한 제한.
    • 연결 + 전송 + 처리 + 응답 (예. 전체 API 호출 최대 45초)
  • Job Timeout : 비동기 작업 전체에 적용하는 제한.

• 타임아웃 값을 어떻게 정하는지

  • 너무 짧으면 정상 요청도 실패하게 되며, 반대로 너무 길면 장애를 늦게 감지한다.
  • 일반적으로는 응답 시간 분포를 기준으로 설정한다.

  p50 = 1초
  p95 = 4초
  p99 = 8초
  
  Timeout = 10~15초
  

• 타임아웃이 발생했다고 해서 실제 작업이 반드시 중단된 것이 아닐 수 있다. 클라이언트는 실패로 알고 있지만 서버에서는 성공했을 수 있다.

  • 특히 결제, 메일 전송, 캘린더 생성 같은 작업에서는 특히나 위험하다. 따라서 타임아웃은 반드시 멱등성과 함께 설계가 되어야한다.

Retry

• 실패한 작업을 다시 시도하는 것

Backoff

멱등성

중복 처리

Circuit Breaker

Dead Letter Queue