백그라운드 워커에 제한된 예산 부여

유용한 작업의 한 단위를 정의하십시오

내부 CSV 내보내기의 경우 요청이 내보내기 레코드를 생성하고; 워커가 제한된 데이터 세트를 읽고, 출력 객체를 작성하며, 레코드를 완료로 표시합니다. 최대 유용 범위, 시간 제한 및 취소 동작을 정의하십시오. 실제 고객에게 알릴 수 없는 격리된 큐, 테스트 데이터베이스 및 대상을 사용하십시오.

컴퓨팅 시간을 데이터베이스 및 스토리지 대기와 분리하십시오. 하나의 작업 기간 숫자는 이러한 구분을 숨깁니다. 전체 파일을 메모리에 구축하는 것은 제한된 배치를 스트리밍하는 것과 다르게 확장됩니다. 큐 메시지를 고객 데이터나 자격 증명을 포함하지 않고 작업을 설명할 수 있을 만큼 작게 유지하십시오.

설계에 의해 반복 전달을 안전하게 만드십시오

영구 내보내기 식별자를 사용하여 시도를 하나의 논리적 결과와 연관시키십시오. 영구 상태에서 고유성과 원자적 소유권/완료 전환을 적용하십시오. 내보내기가 존재하는지 확인한 다음 별도의 보호되지 않은 단계에서 삽입하면 동시 시도가 경합할 수 있습니다. 객체를 게시하고 큐 메시지를 승인하는 것도 실패 경계를 형성합니다.

# Illustrative contract, not queue implementation
job_type: export-account-report
logical_result: EXPORT_RECORD_ID
input_scope: AUTHORIZED_ACCOUNT_AND_DATE_RANGE
attempt_limit: REVIEWED_FINITE_LIMIT
completion: ONE_PUBLISHED_RESULT_FOR_THIS_EXPORT
retry: CLASSIFIED_TRANSIENT_FAILURES_ONLY
failed_result: INSPECTABLE_WITHOUT_CUSTOMER_SECRETS

Celery는 지연 승인을 멱등 작업과 연결하고 자식 프로세스 종료 후에도 승인이 발생하는 경우를 문서화합니다. 큐 옵션이 정확히 한 번 실행을 생성하지는 않습니다. 시스템의 재전달 의미를 검토하고 재시도를 견디도록 애플리케이션 결과를 설계하십시오.

기술 참조: Celery 작업 동작.

프로세스를 늘리기 전에 예산을 설정하십시오

활성 내보내기당 300 MiB를 사용하는 가상 워커의 경우, 네 개의 동시 내보내기는 런타임 오버헤드 전에 이미 약 1,200 MiB를 의미합니다. 이는 벤치마크가 아닌 계획 입력입니다. 데이터베이스 연결, 쿼리 메모리, 임시 디스크 및 출력 대역폭을 추가하십시오; 프로세스 수는 하나의 제한일 뿐입니다.

하나의 활성 내보내기와 현실적인 백로그로 리허설하십시오. 동일한 API 트래픽을 반복하면서 두 개로 늘리십시오. 완료된 유용한 내보내기, 가장 오래된 작업 수명, 지연 시간, 실패 및 호스트 압력을 비교하십시오. 데이터베이스 대기가 증가하면서 처리량이 거의 개선되지 않으면 동시성 증가를 중단하십시오. 추가 CPU가 그 병목을 제거하지 못할 수 있습니다.

실패가 더 많은 부하를 생성하지 않도록 하십시오

재시도 전에 오류를 분류하십시오. 일시적인 스토리지 중단은 일시적일 수 있습니다; 권한이 없는 계정이나 지원되지 않는 내보내기 형식은 종료 오류 또는 개입이 필요합니다. 지원되는 경우 백오프와 지터를 사용한 유한 시도 예산 및 지연 재시도를 사용하십시오. 민감한 필드를 제거한 실패한 작업을 검사 가능하게 유지하십시오.

외부 호출에 타임아웃을 적용하고 전체 작업 예산을 설정하세요. 시도를 중단한다고 해서 원격 부작용이 발생하지 않았다는 것이 증명되지는 않습니다. 타임아웃된 게시는 이미 출력을 기록했을 수 있습니다. 다른 결과를 무작정 게시하지 말고 내보내기 ID로 조정하세요.

배포 및 복구에 워커를 포함하십시오

문서화된 종료 동작을 사용하여 이전 작업자에서 새 작업을 중지하세요. 진행 중인 작업을 완료하도록 두거나 알려진 기한 내에서 안전하게 중단하세요. 출력이 기록된 후 완료가 기록되기 전에 충돌을 테스트하세요. 대체 시도는 결과를 복제하지 않고 일관된 결과를 찾아야 합니다.

겹치는 릴리스 간에 메시지 형식을 호환되게 유지하세요. 새 API는 이전 작업자가 읽을 수 없는 페이로드를 대기열에 넣을 수 있습니다. 계약에 버전을 지정하거나 새 메시지가 나타나기 전에 지원되는 소비자가 존재하도록 롤아웃 순서를 정하세요. 다음을 포함하세요 스키마 호환성 검토.

변경할 다음 제약을 선택하십시오

동시성 설정, 재시도 정책, 작업 계약 및 측정된 중지 규칙을 남겨 두세요. 비용이 많이 드는 내보내기가 작은 작업을 지연시키는 경우 전역 한도를 높이기 전에 독립적인 예산을 가진 별도 큐를 고려하세요. 현실적인 내보내기 부하에서 API 지연 시간이 저하되는 경우 공유 호스트 하나를 확장하는 것보다 작업자를 분리하는 것이 더 유용할 수 있습니다.

변경 후 동일한 워크로드를 반복하고 비교를 유지하세요. API 및 워커 시나리오 는 App 2과 추가 메모리가 선택에 어떻게 들어가는지 설명합니다. 이 절차는 관리형 큐, 무제한 작업 또는 자동 확장을 의미하지 않습니다.