홈블로그Tracking API 확장성: 성수기 트래픽, 속도 제한 및 대량 등록을 처리하는 방법

Tracking API 확장성: 성수기 트래픽, 속도 제한 및 대량 등록을 처리하는 방법

17TRACK

성수기에 추적 API를 확장하려면 내구성 있는 큐 뒤에 배송 등록을 배치하고, 모든 워커에 걸쳐 제공업체 제한을 적용하며, 문서화된 제한 내에서만 배치 처리하고, 추적 업데이트를 비동기적으로 처리해야 합니다. 등록 처리량, 재시도 트래픽 및 웹훅 처리를 서로 별개의 용량 문제로 취급하십시오. 아웃바운드 요청을 제어하지 않고 워커만 추가하면 백로그가 해소되기는커녕 스로틀링이 증가할 수 있습니다.

Tracking API Scalability How to Handle Peak Season Volume Rate

주문 관리 시스템, 창고 플랫폼 또는 이커머스 백엔드를 추적 서비스에 연결하는 엔지니어링 팀의 목표는 단순히 더 많은 요청을 보내는 것이 아닙니다. 정해진 시간 내에 배송을 등록하고, 트래픽 급증 중에도 업데이트를 보존하며, 중복 작업을 만들지 않고 장애에서 복구하는 것이 목표입니다.

배송, 요청 및 업데이트를 기준으로 작업량 산정

일일 배송량만으로는 통합 규모를 산정하기에 충분하지 않습니다. 창고는 짧은 출고 시간대에 대부분의 운송장 번호를 발행할 수 있지만, 상태 업데이트는 하루 종일 도착할 수 있습니다. 이러한 작업량을 별도로 모델링하십시오.

  • 등록 유입: 가져오기 및 창고 출고 급증을 포함하여 초 또는 분당 시스템에 유입되는 신규 배송 레코드 수입니다.
  • 아웃바운드 API 트래픽: 등록 요청, 조회, 수정, 대사 호출 및 재시도입니다.
  • 인바운드 업데이트 트래픽: 제공업체가 지원하는 경우 웹훅 전달 및 재전달입니다.
  • 다운스트림 작업: 각 업데이트로 인해 발생하는 데이터베이스 쓰기, 고객 알림, 분석 이벤트 및 주문 상태 변경입니다.

예를 들어 운송장 번호를 받은 후 등록이 확인될 때까지 허용되는 최대 시간을 내부 등록 목표로 설정하십시오. 이를 추적 최신성과 분리하십시오. 등록이 성공했다고 해서 운송업체 스캔 정보가 이미 제공된다는 의미는 아닙니다.

실효 등록 용량 계산

요청 제한이 적용되는 등록 엔드포인트의 경우 다음과 같은 계획 수식을 활용할 수 있습니다.

등록 용량 = 초당 허용 요청 수 × 요청당 평균 레코드 수 × 성공 레코드 비율

이는 제공업체의 보장이 아니라 계획을 위한 추정치입니다. 요청 제한이 핵심 제약 조건이라고 가정합니다. 레코드 기반 할당량, 페이로드 크기, 지연 시간 및 공유 계정 제한으로 인해 더 낮은 상한이 적용될 수 있습니다.

예시로, 한 통합이 초당 2회의 등록 요청을 허용받고 각 요청에 평균 30개의 레코드를 전송한다고 가정해 보겠습니다. 실패 및 기타 제약 조건을 고려하기 전 명목상 용량은 초당 60개 레코드입니다. 지속적인 급증 상황에서 유입 등록량이 초당 평균 80개라면 큐는 초당 약 20개 레코드씩 증가합니다. 이 수치는 가상의 예시이며 17TRACK의 제한을 의미하지 않습니다.

복구 용량도 계산하십시오. 신규 유입이 λ의 속도로 계속되고 실효 처리 용량이 μ이며 기존 백로그가 B개 레코드라면, μ > λ일 때 백로그를 비우는 데 약 B / (μ − λ)초가 걸립니다. 처리 용량이 유입량을 초과하지 못하면 해당 조건에서는 백로그가 해소되지 않습니다.

제공업체가 실제로 제한하는 항목 확인

속도 제한과 사용 허용량은 서로 다른 문제를 해결합니다. 속도 제한은 요청 또는 레코드를 얼마나 빠르게 제출할 수 있는지를 제어합니다. 사용 허용량은 청구 또는 권한 부여 기간 동안 계정이 사용할 수 있는 추적 활동의 양을 제한할 수 있습니다. 한 항목을 제한 이하로 유지한다고 해서 다른 항목도 준수한다고 볼 수는 없습니다.

워커 수를 설정하기 전에 제공업체 문서와 계정 약관을 기준으로 다음 사항을 확인하십시오.

  • 제한이 계정, API 키, 엔드포인트, IP 주소 또는 다른 범위별로 적용되는지 여부.
  • 계산 단위가 요청, 추적 레코드 또는 다른 작업인지 여부.
  • 엔드포인트가 제한을 공유하는지 또는 독립적인 허용량을 가지는지 여부.
  • 한 요청에서 허용되는 최대 레코드 수와 페이로드 크기.
  • 중복 제출, 잘못된 레코드 및 재시도가 사용량에 미치는 영향.
  • 응답에 스로틀링 정보 또는 재시도 지침이 포함되는지 여부.
  • 할당량 소진과 일시적인 스로틀링의 차이.

17TRACK 통합의 경우 공식 Tracking API 페이지와 API 문서를 이 구성의 출발점으로 사용하십시오. 배포 전에 적용되는 엔드포인트 동작과 계정 제한을 확인하십시오. 이 가이드의 예시 용량은 아키텍처 설명을 위한 것이며 17TRACK의 권한, 배치 크기 또는 서비스 보장을 나타내지 않습니다.

주문 처리와 등록 사이에 내구성 있는 큐 배치

체크아웃 또는 창고 완료 처리가 추적 제공업체의 등록 수락을 기다리게 하지 마십시오. 배송 정보를 로컬에 저장하고 등록 작업을 내구성 있게 기록한 뒤 백그라운드 워커가 제출을 처리하도록 하십시오.

실용적인 흐름은 다음과 같습니다.

  1. 배송 정보와 등록 의도를 저장합니다. 주문은 저장되었지만 백그라운드 작업이 유실되는 상황을 방지하기 위해 트랜잭션 아웃박스 또는 이에 준하는 설계를 사용하십시오.
  2. 입력을 검증하고 정규화합니다. 앞부분의 0을 포함하여 운송장 번호를 문자열로 보존하십시오. 정당한 경우에만 운송업체별 정규화를 적용하십시오.
  3. 기존 등록 여부를 확인합니다. 제공업체와 데이터 모델에 적합한 안정적인 식별자를 사용하십시오.
  4. 처리 가능한 레코드를 큐에 넣습니다. 시도 횟수, 다음 재시도 가능 시간 및 진단에 필요한 충분한 컨텍스트를 저장하십시오.
  5. 공유 제한기를 통해 제출합니다. 아웃바운드 요청 직전에 용량을 확보하십시오.
  6. 레코드 수준의 결과를 저장합니다. 확인된 성공, 재시도 가능한 실패, 영구 거부 및 결과가 불분명한 경우를 구분하십시오.

큐는 급증을 흡수하지만 제공업체 용량을 만들어내지는 않습니다. 처리 가능한 가장 오래된 레코드의 대기 시간이 계속 늘어난다면 워커 수만 늘리지 말고 유입 속도와 처리 용량의 차이를 조사하십시오.

워커 간 제한 조정

독립적인 워커가 각각 전체 계정 허용량을 사용할 수 있다고 가정해서는 안 됩니다. 조정된 속도 제한기 또는 공유 요청 예산을 배분하는 디스패처를 사용하십시오. 예약된 가져오기, 운영 스크립트 및 대사 작업도 해당 예산에 포함하십시오.

속도와 동시성은 서로 다른 제어 수단입니다. 제한기는 요청이 시작되는 빈도를 제어하고, 동시성 상한은 처리 중인 요청의 수를 제어합니다. 제공업체 지연 시간이 증가할 때 두 가지 모두 유용합니다. 동시성을 높이면 지연 시간에 의해 제한되는 작업량에는 도움이 될 수 있지만 아웃바운드 속도 제한을 무시할 수는 없습니다.

레코드 수준 제어를 유지하면서 일괄 등록 사용

엔드포인트가 요청당 여러 레코드를 지원하는 경우 배치 처리를 통해 요청 오버헤드를 줄일 수 있습니다. 하지만 레코드 기반 사용량이 반드시 줄어드는 것은 아니며, 허용되는 최대 배치가 항상 운영상 최선의 선택인 것도 아닙니다.

최대 레코드 수와 최대 대기 시간이라는 두 가지 조건을 사용하여 배치를 구성하십시오. 둘 중 하나에 도달하면 제출합니다. 이렇게 하면 트래픽이 많은 기간에는 배치를 효율적으로 채우고, 트래픽이 적을 때는 무기한 기다리지 않게 할 수 있습니다.

  • 레코드 수뿐만 아니라 페이로드 제한도 준수하십시오. 선택적 메타데이터로 인해 레코드 수가 같은 배치라도 바이트 크기가 크게 달라질 수 있습니다.
  • 내부 배치 매니페스트를 유지하십시오. 제출된 로컬 배송 식별자를 기록하고 반환된 각 결과를 올바르게 연결하십시오.
  • 애플리케이션 수준의 결과를 확인하십시오. HTTP 성공 응답만으로 모든 레코드가 수락되었다고 판단해서는 안 됩니다.
  • 재시도가 필요한 레코드만 재시도하십시오. 성공한 레코드를 다시 전송하면 불필요한 트래픽이 발생하고 사용량에 영향을 줄 수 있습니다.
  • 영구적인 검증 실패를 수정 작업으로 전달하십시오. 변경되지 않은 잘못된 페이로드를 재시도 큐에서 반복해서 처리해서는 안 됩니다.

타임아웃 처리는 특히 중요합니다. 클라이언트가 응답을 받지 못했더라도 제공업체가 요청을 수락했을 수 있습니다. 이러한 결과를 불명확한 상태로 표시하십시오. 지원되는 멱등성 메커니즘, 문서화된 중복 등록 규칙 또는 가능한 경우 대사 조회를 통해 해결하십시오. 타임아웃된 쓰기 작업이 실패했다고 가정하지 마십시오.

실시간 트래픽과 과거 데이터 가져오기를 분리

백필 작업이 새로 출고된 배송에 필요한 모든 용량을 사용해서는 안 됩니다. 가중치 기반 스케줄링 또는 명시적인 용량 예약을 사용하여 별도의 큐를 운영하십시오. 실시간 등록을 위한 최소 할당량을 유지하면서 가져오기에 여유 용량을 사용하도록 허용하십시오. 낮은 우선순위 레코드도 결국 처리되도록 에이징 또는 다른 공정성 규칙을 적용하십시오.

재시도를 제어되고 지연되며 제한된 방식으로 처리

HTTP 429는 “Too Many Requests”를 의미합니다. RFC 6585에 따르면 429 응답에는 Retry-After 헤더가 포함될 수 있습니다. RFC 9110은 해당 헤더의 값을 HTTP 날짜 또는 초 단위 지연 시간으로 정의합니다. 클라이언트는 항상 정수가 반환된다고 가정하지 말고 두 형식을 모두 파싱해야 합니다.

유효한 재시도 지연 시간이 제공되면 해당 시간이 만료되기 전에 재시도하지 마십시오. 재시도 지침이 없으면 지터가 포함된 제한형 지수 백오프를 사용하십시오. 시도 사이의 지연 시간을 점진적으로 늘리고 무작위성을 추가하여 모든 워커가 동시에 재시도하지 않도록 합니다. 재시도도 최초 시도와 동일한 아웃바운드 제한기를 통과해야 합니다.

재시도하기 전에 실패를 분류하십시오.

  • 스로틀링: 영향을 받은 작업을 지연시키고 관련 제한 범위 내에서 디스패치 압력을 줄입니다.
  • 일시적인 네트워크 또는 서버 실패: 결과가 불명확한 쓰기 작업을 고려하여 제한된 정책에 따라 재시도합니다.
  • 인증 또는 권한 부여 실패: 자격 증명 또는 권한이 수정될 때까지 알림을 보내고 영향을 받은 작업을 일시 중지합니다.
  • 검증 실패: 레코드를 변경하거나 격리하고 변경되지 않은 상태로 다시 전송하지 않습니다.
  • 허용량 소진: 짧은 트래픽 급증으로 취급하지 말고 문서화된 계정 해결 절차를 따릅니다.

시도 횟수 제한과 최대 재시도 기간을 모두 설정하십시오. 소진된 항목은 사유, 담당자 및 재처리 절차와 함께 데드 레터 큐로 이동하십시오. 그렇지 않으면 오래된 실패 항목이 새 배송에 할당된 용량을 조용히 소모할 수 있습니다.

웹훅 수집을 독립적으로 확장

제공업체가 적절한 웹훅을 제공하는 경우 반복적인 상태 폴링을 줄일 수 있습니다. 그러나 업데이트 급증 중에도 가용성을 유지해야 하는 별도의 인바운드 작업량이 발생합니다.

수신 엔드포인트의 역할을 단순하게 유지하십시오. 제공업체가 문서화한 메커니즘으로 요청을 검증하고, 이벤트를 내구성 있게 저장한 후 필요한 확인 응답을 반환합니다. 주문 변경, 분석 및 고객 메시지는 비동기적으로 처리하십시오. 이벤트가 유실될 위험이 있다면 내구성 있게 수락하기 전에 수신을 확인해서는 안 됩니다.

제공업체 계약에 명시적으로 달리 규정되어 있지 않다면 소비자가 중복 전달을 허용하도록 설계하십시오. 중복 제거에는 문서화된 안정적인 이벤트 식별자를 우선 사용하십시오. 그러한 식별자가 없다면 복합 식별자를 신중하게 설계하고 테스트하십시오. 상태 레이블만 사용하면 서로 다른 이벤트가 하나로 합쳐질 수 있습니다.

순서가 뒤바뀐 업데이트도 방어하십시오. 이벤트 기록을 파생된 현재 배송 상태와 별도로 저장하십시오. 가능한 경우 문서화된 이벤트 타임스탬프와 전이 규칙을 적용하십시오. 도착 순서가 이벤트 순서라거나 배송 상태가 항상 증가하는 순서라고 가정하지 마십시오.

대사 작업은 대상과 속도를 제한하여 수행하십시오. 대사 작업은 의심되는 전달 누락 또는 불명확한 등록을 조사할 수 있지만, 모든 배송을 공격적으로 폴링하면 웹훅으로 피하려던 아웃바운드 부하가 다시 발생할 수 있습니다.

최대 처리량뿐 아니라 복구도 테스트

제공업체 시뮬레이터를 사용하여 자체 구성 요소에 대한 부하 테스트를 실행하십시오. 실제 제공업체에 상당한 트래픽을 보내는 테스트는 조정하고 승인된 제한 내에서 수행하십시오. 성공적인 테스트는 시스템이 대규모 급증을 수용한다는 것뿐만 아니라 장애 후 정상 상태로 돌아온다는 것도 입증해야 합니다.

  • 창고와 같은 급증 후 정상 트래픽이 계속되는 상황을 재현합니다.
  • 스로틀링 응답, 증가한 지연 시간 및 일시적인 서버 실패를 주입합니다.
  • 배치 일부 거부와 서버 측 수락 후 발생하는 타임아웃을 시뮬레이션합니다.
  • 중복 및 순서가 뒤바뀐 웹훅 이벤트를 전달합니다.
  • 데이터베이스 액세스를 중단하고 수락되지 않은 이벤트가 잘못 확인되지 않는지 검증합니다.
  • 실시간 등록과 함께 백필을 실행하고 공정성을 확인합니다.
  • 속도 제어를 우회하지 않고 데드 레터 항목을 재처리합니다.

처리 가능한 가장 오래된 등록의 경과 시간, 수락 지연 시간, 레코드 수준 성공률, 스로틀링 빈도, 재시도량, 웹훅 처리 지연 및 데드 레터 증가량을 모니터링하십시오. 큐 깊이만으로는 충분하지 않습니다. 큰 큐가 빠르게 비워질 수도 있고, 작은 큐에 반복적으로 실패하는 비즈니스 핵심 배송 몇 건이 포함되어 있을 수도 있습니다.

성수기 전에 운영 책임을 배정하십시오. 엔지니어링 팀은 디스패치 제어와 복구 도구를 담당하고, 통합 담당자는 제공업체 권한을 확인하며, 운영팀은 어떤 배송에 우선순위를 부여할지 정의해야 합니다. 가져오기를 일시 중지하거나, 추가 용량을 요청하거나, 누락된 업데이트를 조사해야 하는 시점을 문서화하십시오. 가장 강력한 설계는 트래픽이 즉시 처리 용량을 초과할 때도 예측 가능성을 유지하는 설계입니다.

FAQ

API 키를 추가하면 처리량이 증가하나요?

반드시 그렇지는 않습니다. 여러 키가 계정 수준의 허용량을 공유할 수 있습니다. 제공업체에 제한 범위와 허용되는 확장 방법을 확인하십시오. 제한을 우회하기 위해 키를 교체하지 마십시오.

모든 등록에 가능한 가장 큰 배치를 사용해야 하나요?

아니요. 큰 배치는 요청 효율성을 높일 수 있지만, 트래픽이 적을 때 배치를 채우기 위해 기다리면 지연 시간이 증가합니다. 문서화된 크기 상한과 플러시 타이머를 사용한 다음 측정된 수락 지연 시간과 실패 동작을 바탕으로 조정하십시오.

타임아웃 후 중복 등록을 어떻게 방지할 수 있나요?

내구성 있는 로컬 배송 식별자와 제공업체가 문서화한 멱등성 또는 중복 처리 동작을 사용하십시오. 결과가 여전히 불확실하다면 재처리하기 전에 지원되는 경우 대사하십시오. 로컬 중복 제거만으로는 원격 요청이 성공했는지 입증할 수 없습니다.

등록이 성공하면 추적 정보가 최신 상태라는 의미인가요?

아니요. 등록 수락, 운송업체 이벤트 제공, 제공업체 처리 및 자체 업데이트 처리는 서로 다른 단계입니다. 지연된 운송업체 스캔을 등록 백로그로 오인하지 않도록 각각 별도로 측정하십시오.

팀은 언제 제공업체에 더 많은 용량을 요청해야 하나요?

예측된 유입량과 필요한 복구 시간이 불필요한 재시도, 중복 제출 및 비효율적인 배치 처리를 제거한 후 검증된 사용 가능 용량을 초과할 때 요청하십시오. 더 큰 허용량으로 차단된 소비자나 데이터베이스 병목이 해결되지는 않으므로 먼저 핵심 제약 조건을 파악하십시오.

출처

Loading