Cloud Tasks를 사용하면 특정 큐 실행 동작 및 서비스 한도를 설계할 때 복원력이 우수한 비동기 시스템을 빌드할 수 있습니다. 최소 1회 전송, 시스템 제한, 대상 리소스 용량을 고려하여 처리 병목 현상과 예기치 않은 지연을 방지할 수 있습니다.
실행 순서
향후 실행하도록 예정된 태스크를 제외한 태스크 큐의 실행 순서는 플랫폼과 완전히 독립적입니다. 특정 순서로 태스크를 실행한다고 보장하거나 이를 위한 최선의 노력도 시도하지 않습니다. 특히 큐가 완전히 비어 있지 않으면 이전 태스크가 실행된다는 보장이 없습니다. 최신 태스크가 이전 태스크보다 먼저 실행된다는 일반적인 사례가 많이 있으며, 이와 관련한 패턴은 예고 없이 변경될 수 있습니다.
실행 지연
Cloud Tasks 실행은 내부 시스템 다시 시작으로 인해 약간의 지연이 발생할 수 있으며, 일반적으로 몇 분 정도 지속됩니다. 태스크가 지연되지만 손실되는 태스크는 없습니다. 이러한 이벤트는 해결 방법이 없는 시스템 수준 이벤트입니다. 이러한 이벤트는 로깅되지 않으며 발생 시점이 정해져 있지 않습니다.
중복 실행
Cloud Tasks는 '정확하게 한 번만 실행'이라는 의미 구현을 목적으로 합니다. 그러나 설계상 보장된 실행과 중복 실행 간에 균형을 맞춰야 하는 상황에서는 보장된 실행에 서비스 오류가 발생합니다. 마찬가지로 중복 실행이 1회 이상 발생합니다. 예기치 않은 오류가 발생하지 않도록 앱이 중복 실행을 적절하게 처리하는지 확인합니다. 프로덕션 단계에서는 99.999% 이상의 태스크가 한번만 실행됩니다.
리소스 제한사항
즉시 처리 큐에서 가장 일반적인 백로그 소스는 대상 인스턴스의 리소스를 소진하는 것입니다. 초당 10개의 요청만 처리할 수 있는 프런트엔드 인스턴스에서 초당 100개의 태스크를 실행하려고 하면 백로그가 생성됩니다. 이는 일반적으로 두 가지 방법 중 하나로 나타나며, 둘 중 하나는 일반적으로 요청을 처리하는 인스턴스 수를 늘려 해결할 수 있습니다.
백오프 오류 및 적용 비율
과부하되는 서버에서 HTTP 503(App Engine 대상)이나 HTTP 429 또는 5xx(외부 대상) 같은 백오프 오류를 반환하기 시작할 수 있습니다.
Cloud Tasks는 오류가 중단될 때까지 실행 속도를 늦춰서 이러한 오류에 대응합니다. 이 시스템 제한은 작업자의 과부하를 방지합니다. 설정은 변경되지 않습니다.
시스템 제한은 다음과 같은 상황에서 발생합니다.
Cloud Tasks가 모든 오류에서 백오프합니다. 일반적으로 Cloud Tasks는
retry_config에 지정된 백오프를 사용합니다. 하지만 작업자가 HTTP429 Too Many Requests,503 Service Unavailable또는5xx오류 응답을 반환하거나 오류율이 높은 경우 Cloud Tasks는 더 낮은 디스패치 속도를 적용하고Retry-AfterHTTP 응답 헤더에 지정된 재시도 지연을 고려합니다. 오류가 중지되고 대상 핸들러가 HTTP2xx응답을 반환하면 큐는 적용된 디스패치 속도를 점진적으로 다시 높입니다.트래픽 급증을 방지하고 부하의 급격한 증가를 완화하기 위해 Cloud Tasks는 큐가 새로 생성되거나, 일시중지 후 재개되거나, 활성 디스패치 없이 몇 분 동안 유휴 상태인 경우 디스패치를 점진적으로 늘립니다. 이러한 증가 현상은 작업 생성 급증 시 또는 여러 작업이 동시에 예약된 경우와 같이 많은 수의 작업을 갑자기 디스패치할 수 있는 경우에도 발생합니다. 콜드 또는 유휴 상태에서 Cloud Tasks는 낮은 기준 속도로 디스패치를 시작하고 주기적인 평가 간격에 따라 적용된 디스패치 속도를 점진적으로 높입니다. 큐 수요가 포화 상태로 유지되고 대상 핸들러가 HTTP
2xx응답을 반환하는 한, 구성된max_dispatches_per_second비율까지 비율이 계속 증가합니다. 콜드 또는 유휴 단계적 확대 및 재개된 큐 관리에 대한 자세한 내용은 초기 큐 단계적 확대 및 대상 오버로드를 참조하세요.
지연 시간 급증 및 최대 동시 작업 수
과부하된 서버도 크게 증가한 지연 시간으로 응답할 수 있습니다.
이 상황에서 요청은 장기간 미해결 상태로 유지됩니다. 큐는 최대 동시 태스크 수로 실행되므로 큐에서 태스크를 예상 비율로 실행하지 못할 수 있습니다. 값이 너무 낮게 설정되어 있어 인위적인 비율 제한이 발생하는 상황에서는 영향을 받는 큐의 max_concurrent_dispatches 값을 늘리면 이러한 문제가 해결될 수 있습니다. 그러나 max_concurrent_dispatches를 늘리는 것으로 기본적인 리소스 문제를 해결하기는 어렵습니다.
장기 실행 태스크의 증가 문제
Cloud Tasks 큐는 이전에 성공적으로 전달된 태스크 수를 기준으로 출력을 늘립니다. 태스크 핸들러가 태스크를 완료하고 성공 응답을 반환하기까지 상당한 시간(수 분 단위)이 소요되는 경우 큐 증가 속도가 느려질 수 있습니다.
태스크 5,000개 이상 보기
태스크가 5,000개를 초과하는 경우 일부 태스크가Google Cloud 콘솔에 표시되지 않습니다. 모든 태스크를 보려면 gcloud CLI를 사용하세요.
보고된 최대 큐 깊이 측정항목
Cloud Tasks에서 보고하는 최대 큐 깊이 측정항목은 태스크 1,000,000개로 제한됩니다. 이는 기본 태스크 작업자의 성능을 개선하기 위한 것으로, 큐로 전송되거나 큐에서 처리될 수 있는 태스크 수에는 영향을 미치지 않습니다. 큐 깊이 한도를 초과하여 큐로 전송된 태스크는 의도한 대로 계속 실행됩니다.
1,000,000개 이상의 태스크에 대해 현재 큐 깊이를 가져오려면 queues.tasks.list 메서드를 사용하면 됩니다.
이 메서드는 페이지로 나누기가 있는 모든 태스크를 반환하므로 데이터를 집계하고 개수 작업을 수행할 수 있습니다. 하지만 큐 깊이 크기에 따라 메서드에 할당량 제한이 적용될 수 있습니다.
동일한 이름으로 큐 다시 만들기
큐를 삭제하면 예약된 태스크와 실행 또는 재시도를 대기 중인 태스크를 포함하여 큐의 모든 태스크가 영구적으로 삭제되며 되돌릴 수 없습니다. 사용자나 Cloud Customer Care 모두 삭제된 큐나 태스크를 복구할 수 없습니다.
큐를 삭제한 후 이름이 같은 큐를 다시 만들려면 3일을 기다려야 합니다. 이 대기 기간은 삭제 시 실행 중인 태스크에서 예기치 않은 동작을 방지하고 삭제 및 재생성 주기 동안 내부 프로세스 오류를 방지합니다. 대기 기간은 Google Cloud 콘솔, gcloud CLI, REST 또는 RPC API, Terraform을 비롯한 모든 인터페이스를 통해 삭제된 큐에 적용됩니다.
최대 3일의 삭제 표시 기간 동안 큐 생성 요청은 큐를 다시 만들지 않고 성공한 것으로 표시될 수 있으며 삭제된 큐 이름이 포함된 queue.yaml 파일을 업로드하지 못할 수 있습니다. 같은 이름의 큐가 다시 생성되었는지 확인하려면 gcloud tasks queues describe 명령어 또는 projects.locations.queues.get 메서드를 사용하여 큐를 검색합니다. 성공(200 OK) 응답은 큐가 다시 생성되었음을 확인합니다.
큐를 삭제하거나 3일의 대기 기간을 트리거하지 않고 태스크를 삭제하거나 큐를 수정하려면 큐를 삭제하고 다시 만드는 대신 큐에서 모든 태스크를 삭제하거나, 큐를 제자리에서 업데이트하거나, 큐를 일시중지하세요. Terraform으로 큐를 관리하는 경우 실수로 큐가 삭제되지 않도록 lifecycle 블록에서 prevent_destroy = true를 설정합니다.
보안 경계를 사용할 때 지원되지 않는 타겟
VPC 서비스 제어를 사용하여 보안 경계를 설정한 경우 지원되지 않는 대상에 대한 Cloud Tasks 실행의 HTTP 요청이 차단되고 TARGET_TYPE_NOT_PERMITTED_FOR_VPC 오류 코드와 함께 실패합니다. 자세한 내용은 VPC 서비스 제어를 사용하여 서비스 경계 설정을 참조하세요.
리소스 위치 제약 조건
Cloud Tasks는 리소스 위치 제한을 지원하지만 다음 리전에는 제한사항이 적용됩니다.
us-central1us-central2(비공개 Google Cloud 리전)
조직 정책에 리전을 지정하는 경우 두 리전 모두에서 Cloud Tasks 리소스를 만들지 않더라도 us-central1 및 us-central2를 모두 포함해야 합니다. 조직에서 비공개 리전을 사용하지 않더라도 조직 정책에 us-central2 리전을 포함할 수 있습니다.