SaaS 결제

웹훅 재시도 정책이란 무엇인가요?

작성자: Oleksandra Butenko, 카피라이터

검토자: George Ploaie, 최고 운영 책임자 (COO)

웹훅 재시도 정책이란 무엇인가

웹훅 재시도 정책이란 무엇인가요?

웹훅 재시도 정책은 웹훅 시스템이 웹훅 전송 실패 시 재전송 여부를 결정하는 데 사용하는 일련의 규칙입니다. 이 구성은 시스템의 재시도 횟수 제한, 각 시도 사이의 일시 중지 시간, 실패 기준, 그리고 중단 조건을 명시합니다. 대부분의 정책에서 짧은 시간 내에 재시도가 발생하는 것을 방지하기 위해 지수 백오프(exponential backoff)가 사용되며, 영구적으로 실패하는 이벤트는 데드-레터 큐(dead-letter queue)로 전송됩니다.

유의 사항:

‘최소 한 번’ 전달 모델에서 재시도 작업은 동일한 이벤트가 여러 번 도착할 수 있도록 합니다. 수신자는 일반적으로 멱등성 키를 사용하여 중복을 안전하게 처리해야 합니다.

웹훅 재시도 정책이 왜 필요한가요?

네트워크 및 서비스의 신뢰성에 변동이 있을 수 있다는 점을 고려할 때, 재시도 정책은 중요한 고려 사항입니다. 전송 중 네트워크 또는 서비스 장애 시 데이터 전송의 완료는 활성 재시도 정책의 유무에 달려 있습니다. 재시도 정책은 수신 측이 2xx 응답을 반환하지 않을 경우 재시도를 보장함으로써 전송 실패로 인한 데이터 손실을 방지합니다.

재시도 가능 (일시적)

재시도 불가능 (영구적)

네트워크 이벤트

유효하지 않은 엔드포인트

시간 초과

잘못된 페이로드

일시적인 서버 중단

지속적인 4xx 오류

속도 제한

손상된 비즈니스 로직

 

웹훅 재시도 정책은 어떻게 작동하나요?

이벤트 전달 시도 중 문제가 발생하면 시스템 정책은 일반적으로 HTTP 상태 코드를 확인하여 이를 처리합니다. 이어서 재시도 일정에 따라 일시 중지가 적용된 후 이벤트 전송이 다시 시도됩니다. 구성 요소는 다음과 같습니다:

  •       트리거 조건: 재시도를 트리거하는 정확한 HTTP 상태.
  •       재시도 일정: 재시도 사이의 시간 간격으로, 일반적으로 지수 백오프 또는 Retry-After 헤더에서 추출된 값입니다.
  •       장애 발생 표면화: 즉각적인 해결 없이 문제 식별을 가능하게 하는 기능을 포함하며, 예를 들어 다음 재시도 시간 표시 등이 있습니다.
  •       관측 가능성 및 멱등성: 실패 분석을 위한 로그, 메트릭, 리플레이 도구와 중복 처리를 위한 멱등성 처리.

 

일반적인 재시도 전략은 무엇인가요?

대부분의 재시도 전략은 시도 간 간격에 지연을 포함합니다. 가장 자주 사용되는 전략은 지수 백오프(exponential backoff)로, 각 시도마다 대기 기간을 연장하여 문제를 겪는 수신자의 부담을 줄여줍니다.

이는 다음을 의미합니다:

  •       지수 백오프: 재시도 시도 간 간격을 점진적으로 늘려 분리하는 기법입니다.
  •       지터 추가: 대기 시간을 무작위 요소로 다양화하여 동시에 재시도 급증을 방지합니다. Twilio Event Streams는 “thundering herd” 현상을 방지하기 위해 지터(jitter) 개념을 구현합니다.
  •       계층형 재시도: 즉시, 단기, 장기, 데드 레터 큐.
전문가 팁:

공개된 재시도 일정은 통합자에게 타이밍 예상에 대한 정보를 제공합니다. 문서화되지 않은 타이밍은 디버깅의 어려움을 가중시킬 수 있습니다.

데드 레터 큐(DLQ)는 어떤 역할을 하나요?

이 큐는 구성된 재시도 프로세스를 활용했으나 완료 상태에 도달하지 못한 이벤트들을 위한 것입니다. 이 이벤트들은 지정된 위치에 보관되어 세부 사항 검토, 순서 관찰 또는 상황에 따른 처리가 가능합니다.

재시도 정책을 설계할 때 어떤 요소를 고려해야 할까요?

맹목적으로 공격적인 재시도 정책을 복사하기보다는, 좋은 재시도 설계는 시스템이 너무 많은 재시도로 인해 과부하될 수 있는 시점을 고려합니다. 즉, 재시도 제한 및 간격 타이밍을 신중하게 고려해야 합니다.

  •       지수 백오프와 지터를 함께 사용하는 것을 선호합니다.
  •       명확하게 정의된 재시도 제한 및 중단 기준을 설정하십시오.
  •       어떤 전송이 재시도되고 어떤 전송은 재시도되지 않을지에 대한 명확한 상태 코드 규칙을 설정하십시오.
  •       멱등성 키는 재처리의 일관된 관리와 관련이 있습니다.

웹훅 재시도를 어떻게 효과적으로 모니터링할 수 있을까요?

모니터링 방식은 파이프라인 전달의 불일치를 초기 단계에서 식별하는 것과 관련이 있습니다. 문제점을 나타내는 지표를 추적한 다음, 알림을 통해 자동으로 통지하고 운영에 사용되는 도구와 연결합니다.

  •       대시보드: 지난 기간 동안의 전달 상태에 대한 개요.
  •       수동 재실행: 근본 원인이 해결된 후 이벤트를 다시 보낼 수 있는 옵션.
  •       런북: 온콜 엔지니어를 위한 사전 정의된 조치를 제시하여 문제 해결 프로세스를 안내합니다.

피해야 할 일반적인 함정은 무엇인가요?

함정

영향

재시도 폭풍

즉각적이거나 무한한 재시도는 수신자의 처리 활동 증가와 경험적으로 연관되어 있습니다.

멱등성 누락

재시도 메커니즘은 때때로 여러 번의 실행을 포함할 수 있으며, 이는 후속 효과로 이어집니다.

모든 4xx 오류 재시도

이는 유효성 검사 및 스키마 문제를 식별하는 프로세스에 영향을 미칩니다.

잘못된 페이로드 은폐

재시도 작업은 로직 내 문제의 즉각적인 가시성에 영향을 미칠 수 있습니다.

문서화되지 않은 정책

동작 불일치 및 문제 해결의 집중적인 특성

비순차적 전달

엄격한 순서 요구 사항이 있는 프로세스에 영향을 줍니다.

 

웹훅 재시도 정책의 이점은 무엇인가요?

  •       실패한 전달을 체계적으로 재시도하는 프로세스는 이벤트가 처리되지 않을 수도 있는 상황을 해결하는 데 목적이 있습니다.
  •       이는 단기적인 중단 및 전달 지연 중에 이벤트 데이터 손실 가능성을 줄이는 데 기여합니다.
  •       통합은 대개 짧은 중단 기간에서 복구되며, 그에 따른 문제는 장기적인 서비스 중단으로 이어지기보다는 일시적인 경우가 많습니다.
  •       주문 및 결제와 같은 중요 데이터의 안정적인 전달은 통합에 대한 신뢰도 수준에 영향을 미치는 요인입니다.
유의 사항:

이러한 이점은 올바른 구성 설정에 따라 달라집니다. 정책의 특정 설정은 재시도 스톰(retry storms)의 발생률에 영향을 미칠 수 있습니다. 정책에 멱등성(idempotency)이 포함되지 않은 경우, 추가 이벤트 생성과 함께 관찰될 수 있으며, 이는 하나 이상의 결과로 이어질 수 있습니다.

결론

웹훅 재시도 정책은 지수 백오프(exponential backoff) 및 지터(jitter)와 같은 다양한 전략을 사용하여 실패한 전달을 재시도하고, 처리되지 않은 이벤트(dead events)를 DLQ(Dead Letter Queue)로 전달함으로써 이벤트 기반 통합을 견고하게 만드는 수단입니다. 웹훅 재시도 정책은 지수 백오프(exponential backoff) 및 지터(jitter)와 같은 다양한 전략을 사용하여 실패한 전달을 재시도하고, 처리되지 않은 이벤트(dead events)를 DLQ(Dead Letter Queue)로 전달함으로써 이벤트 기반 통합을 견고하게 만드는 수단입니다.

시작할 준비가 되셨나요?

저희가 도와드리겠습니다. 18년의 경험을 바탕으로 여러분의 글로벌 진출의 꿈을 현실로 만들어 드리겠습니다.
Mosaic Image
ko_KR한국어