설명서Experience Cloud KCS

Dynamic Media OpenAPI 및 Asset Gateway: API 요금 제한 이해 및 해결

마지막 업데이트: 2026년 6월 21일

대량 API 활동은 요청 패턴이 동적 비율 제한을 초과할 때 HTTP 429 오류를 반환할 수 있습니다. 이 문제는 일반적으로 버스트 트래픽, 반복된 폴링 또는 각 호출이 별도로 계산되는 다단계 워크플로우로 인해 발생하며, 캐싱은 업데이트가 표시될 때 지연될 수 있습니다. 해결은 로그에서 전송률 조절을 확인하고 불필요한 요청을 줄이며 캐시 동작을 준수하며 지수 백오프를 적용하는 데 중점을 둡니다. 요청 패턴과 재시도 동작이 조정된 후 안정적인 응답이 반환됩니다.

설명 description

환경:

  • API 기반 에셋 수집 워크플로
  • 메타데이터 검색 워크플로
  • 에셋 전달 또는 게이트웨이 통합
  • 반복적 또는 대량 API 요청을 수행하는 클라이언트

문제/증상

  • API 종단점은 간헐적인 HTTP 429 너무 많은 요청 응답을 반환하며, 이 응답은 애플리케이션 로그 또는 모니터링 데이터에서 확인하고 영향을 받는 종단점에 다시 연결할 수 있습니다.
  • 이 문제는 버스트 트래픽이나 기타 대량 요청 기간 동안 더 잘 나타나며, 이는 과도한 요청 로드 시 조절됨을 나타냅니다.
  • 한 번의 작업으로 검색, 메타데이터 조회, 업로드 시작 및 업로드 제출과 같은 여러 개의 카운트된 API 요청이 생성될 수 있으므로 여러 단계 워크플로는 불균형적으로 영향을 받을 수 있습니다.
  • 폴링, 다시 시도 또는 캐시된 응답 재사용 실패를 포함한 클라이언트 작업을 반복하면 요청 볼륨이 증가하고 조절에 기여할 수 있습니다.
  • 캐시된 응답이 최대 10분 동안 지속될 수 있으므로 에셋 또는 콘텐츠 업데이트가 지연될 수 있습니다. 이 동작은 Cache-Control: max-age=600과(와) 같은 응답 헤더를 통해 확인할 수 있습니다.
  • 이러한 경우 업데이트된 콘텐츠는 1~10분 후에만 표시될 수 있으며, 이는 별도의 API 오류가 아닌 캐시 계층 지연을 가리킵니다.

근본 원인:

API는 고정된 초당 요청 수 임계값이 아닌 동적 로드 기반 속도 제한을 사용합니다. 트래픽 스파이크, 최적화되지 않은 폴링, 다단계 업로드 또는 쿼리 흐름은 요청 볼륨을 정상적인 제한을 초과하여 푸시하고 제한을 트리거할 수 있습니다. 또한 응답이 Cache-Control: max-age=600(으)로 캐시될 수 있으므로 다운스트림 캐시는 원본이 업데이트된 후 이전 데이터를 계속 제공할 수 있습니다.

해결 방법 resolution

아래 단계를 사용하여 제한을 줄이고 복구를 확인하십시오.

  1. 응용 프로그램 로그 또는 API 모니터링을 검토하여 HTTP 429 요청이 너무 많음 응답을 식별하십시오. 예상되는 결과는 영향을 받는 API 엔드포인트에 연결된 조절의 명백한 증거입니다. 응답이 동일한 워크플로우에서 반복 가능하고 관련 없는 요청으로 분리되지 않는지 확인합니다.
  2. 업로드 또는 쿼리 워크플로우에서 여러 단계 요청 패턴을 검사합니다. 예상되는 결과는 각 호출이 전체 요청 볼륨에 별도로 기여하는 흐름을 파악하는 것입니다. 검색, 메타데이터 조회, 업로드 시작 및 업로드 제출과 같은 요청 시퀀스가 모두 계산되는지 확인합니다.
  3. Cache-Control: max-age=600을(를) 포함한 다시 시도 동작 및 응답 캐싱을 검토하십시오. 예상되는 결과는 제거, 지연 또는 캐시할 수 있는 반복된 호출을 찾는 것입니다. 클라이언트가 캐시 지속 시간을 준수하고 동일한 데이터를 즉시 다시 요청하지 않는지 확인합니다.
  4. 가능한 경우 응답을 캐시하고 반복되는 메타데이터 가져오기 또는 중복 호출을 방지하여 요청 볼륨을 줄입니다. 예상되는 결과는 더 낮은 API 처리량과 더 적은 제한된 요청입니다. 로그를 검토하거나 모니터링을 통해 변경 사항을 확인하여 요청 볼륨이 감소하고 429개의 응답이 덜 자주 발생하는지 확인합니다.
  5. 업데이트를 확인할 때 캐시 동작을 확인합니다. 예상되는 결과는 새로 고침된 콘텐츠가 즉시 보다는 정상적인 캐시 전파 후에 나타날 수 있다는 것을 인지하는 것입니다. 브라우저 캐시를 지우고, 요청을 다시 시도하고, 새로 고친 콘텐츠가 예상 1~10분 캐시 창 내에 표시되는지 확인하여 이를 확인합니다.
  6. 클라이언트가 429 응답 후 다시 시도하기 전에 점진적으로 더 오래 대기하도록 지수 백오프를 적용합니다. 예상되는 결과는 제한 이벤트의 빈도가 더 낮습니다. 재시도 변경 사항이 배포된 후 로그를 모니터링하고 429회 반복된 응답이 감소하는지 확인하여 개선 사항을 확인합니다.
  7. 트래픽이 서비스 제한에 일관되게 근접한 경우 요청 일괄 처리 또는 워크플로우 디자인 변경을 통해 항목별 호출을 줄일 수 있는지 여부를 검토하십시오. 예상되는 결과는 일반 트래픽에서 보다 안정적인 응답 동작입니다. 일반적인 사용 중에 요청 패턴이 일정하게 유지되며 더 이상 반복적인 제한을 트리거하지 않는지 확인하십시오.
  8. 요청 최적화 후에도 제한이 계속되면 지원팀에 문의하기 전에 타임스탬프, 영향을 받는 끝점, 요청 및 응답 헤더, 예상 요청 비율 및 캐시 전략 세부 정보를 수집합니다. 예상되는 결과는 보다 신속한 조사를 지원하는 완전한 기술 기록입니다. 수집된 정보가 제한된 요청 및 이러한 요청이 발생하는 조건을 반영하는지 확인합니다.

요청 볼륨이 줄어든 후에도 HTTP 429 너무 많은 요청 응답이 계속되면 캐싱이 예상대로 작동하고, 다시 시도 동작이 업데이트되었으며, 동일한 API 워크플로에 대해 제한이 계속 반복될 수 있는 경우 Adobe 지원에 티켓을 제출하고, 문제 해결 중에 수집된 타임스탬프, 영향을 받는 끝점, 요청 및 응답 헤더, 예상 요청 비율 및 캐시 전략 세부 정보를 포함하십시오.

관련 읽기

recommendation-more-help
experience-cloud-kcs-help-kbarticles