활동 작업을 폴링할 때 지연 시간 방지

GetActivityTask API는 taskToken을 정확히 한 번만 제공하도록 설계되어 있습니다. 활동 작업자와 의사 소통 중 taskToken이 삭제되면GetActivityTask 시간이 초과될 때까지 응답을 기다리는 60초 동안 많은 GetActivityTask 요청이 차단될 수 있습니다.

응답을 기다리는 폴링 수가 적은 경우에만 모든 요청을 차단된 요청 뒤쪽의 대기열에 넣고 정지합니다. 그러나 활동 Amazon 리소스 이름(ARN)마다 미해결 폴링이 상당수 있고 요청 일부가 대기 상태에 머물러 있으면 계속 taskToken을 가져와 작업을 처리할 수 있는 경우가 많습니다.

프러덕션 시스템의 경우 각 시점에서 활동 ARN당 100개 이상의 공개 폴링을 추천합니다. 하나의 폴링이 차단되고 이 폴링의 일부를 뒤쪽의 대기열에 넣으면 taskToken를 받아 작업을 처리할 수 있는 요청이 여전히 많은 반면 GetActivityTask 요청은 차단됩니다.

작업에 대한 폴링 시 이러한 종류의 지연 시간 문제를 피하려면:

• 활동 작업자 구현 시 작업에서 별도의 스레드로 poller를 구현하십시오.

• 각 시점에서 활동 ARN당 100개 이상의 공개 폴링을 하십시오.

  참고

  ARN당 100개의 공개 폴링으로 확장하는 것은 비용이 많이 들 수 있습니다. 예를 들어 ARN당 Lambda 함수 폴링 100개 보유 비용이 폴링 스레드가 100개 있는 단일 Lambda 함수 보유에 비해 100배 이상 높습니다. 지연 시간 단축 및 비용 최적화를 모두 달성하려면 비동기 I/O가 있는 언어를 사용하고 작업자마다 여러 개의 폴링 스레드를 구현합니다. Poller 스레드가 작업 스레드와 분리되어 있는 경우 활동 작업자의 예제는 Ruby 활동 작업자 예제를 참조하십시오.

활동 및 활동 작업자에 대한 자세한 내용은 활동을 참조하십시오.