이 페이지에서는 Cloud Tasks를 사용할 때 발생할 수 있는 몇 가지 문제와 제한사항을 설명합니다.
실행 순서
향후 실행하도록 예정된 태스크를 제외한 태스크 큐의 실행 순서는 플랫폼과 완전히 독립적입니다. 특정 순서로 태스크를 실행한다고 보장하거나 이를 위한 최선의 노력도 시도하지 않습니다.
특히 큐가 완전히 비어 있지 않으면 이전 태스크가 실행된다는 보장이 없습니다. 최신 태스크가 이전 태스크보다 먼저 실행된다는 일반적인 사례가 많이 있으며, 이와 관련한 패턴은 예고 없이 변경될 수 있습니다.
중복 실행
Cloud Tasks는 '정확하게 한 번만 실행'이라는 의미 구현을 목적으로 합니다.
그러나 설계상 보장된 실행과 중복 실행 간에 균형을 맞춰야 하는 상황에서는 보장된 실행에 서비스 오류가 발생합니다. 마찬가지로 중복 실행이 1회 이상 발생합니다.
개발자는 중복 실행이 치명적인 결과를 초래하지 않도록 조치를 취해야 합니다. 프로덕션 단계에서는 99.999% 이상의 태스크가 한번만 실행됩니다.
리소스 제한사항
즉시 처리 큐에서 가장 일반적인 백로그 소스는 대상 인스턴스의 리소스를 소진하는 것입니다. 사용자가 초당 10개의 요청만 처리할 수 있는 프런트엔드 인스턴스에서 초당 100개의 작업을 실행하려고 하면 백로그가 만들어집니다. 이는 대개 두 가지 방식 중 하나로 나타나는 데, 이중 하나는 일반적으로 요청을 처리하는 인스턴스 수를 늘려서 해결할 수 있습니다.
백오프 오류 및 적용 비율
과부하되는 서버에서 HTTP 503(App Engine 대상)이나 HTTP 429 또는 5xx(외부 대상) 같은 백오프 오류를 반환하기 시작할 수 있습니다.
Cloud Tasks는 오류가 중단될 때까지 실행 속도를 늦춰서 이러한 오류에 대응합니다. 이 시스템 제한은 작업자 과부하를 방지합니다. 사용자가 지정한 설정은 변경되지 않습니다.
시스템 제한은 다음과 같은 경우에 발생합니다.
Cloud Tasks가 모든 오류에서 백오프합니다. 일반적으로 rate limits에 지정된 백오프가 사용됩니다. 하지만 작업자가 HTTP 429 Too Many Requests, 503 Service Unavailable을 반환하거나 오류 비율이 높은 경우 Cloud Tasks는 더 높은 백오프 비율을 사용합니다. Retry-After HTTP 응답 헤더에 지정된 재시도가 고려됩니다.
트래픽 급증을 방지하고 트래픽 급증을 원활하게 처리하기 위해 큐가 새로 생성되거나 유휴 상태일 때와 (생성 태스크 비율 급증, 일시중지가 해제된 큐, 동시에 예약된 여러 태스크 등으로 인해) 갑자기 많은 수의 태스크를 전달할 수 있게 된 경우에 전달이 천천히 늘어납니다.
지연 시간 급증 및 최대 동시 작업 수
과부하된 서버도 크게 증가한 지연 시간으로 응답할 수 있습니다.
이 상황에서 요청은 장기간 미해결 상태로 유지됩니다. 큐는 최대 동시 태스크 수로 실행되므로 큐에서 태스크를 예상 비율로 실행하지 못할 수 있습니다. 값이 너무 낮게 설정되어 있어 인위적인 비율 제한이 발생하는 상황에서는 영향을 받는 큐의 max_concurrent_tasks를 늘리면 이러한 문제가 해결될 수 있습니다. 그러나 max_concurrent_tasks를 늘리는 것으로 기본적인 리소스 문제를 해결하기는 어렵습니다.
장기 실행 태스크의 증가 문제
Cloud Tasks 큐는 이전에 전달된 태스크 수에 따라 부분적으로 출력을 늘립니다. 태스크 핸들러가 태스크를 완료하고 성공 응답을 반환하기까지 상당한 시간(수 분 단위)이 소요되는 경우 큐 증가 속도가 느려질 수 있습니다.
태스크 5,000개 이상 보기
태스크가 5,000개를 초과하는 경우 일부 태스크가 Google Cloud 콘솔에 표시되지 않습니다. 모든 태스크를 보려면 gcloud CLI를 사용하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-12-21(UTC)"],[],[],null,["# Issues and limitations\n\nThis page describes some of the issues and limitations that you might encounter\nwhen using Cloud Tasks.\n\nExecution order\n---------------\n\nWith the exception of tasks scheduled to run in the future, task queues are\ncompletely platform-independent about execution order. There are no guarantees\nor best effort attempts made to execute tasks in any particular order.\nSpecifically: there are no guarantees that old tasks will execute unless a queue\nis completely emptied. A number of common cases exist where newer tasks are\nexecuted sooner than older tasks, and the patterns surrounding this can change\nwithout notice.\n\nDuplicate execution\n-------------------\n\nCloud Tasks aims for a strict \"execute exactly once\" semantic.\nHowever, in situations where a design trade-off must be made between guaranteed\nexecution and duplicate execution, the service errs on the side of guaranteed\nexecution. As such, a non-zero number of duplicate executions do occur.\nDevelopers should take steps to ensure that duplicate execution is not a\ncatastrophic event. In production, more than 99.999% of tasks are executed only\nonce.\n\nResource limitations\n--------------------\n\nThe most common source of backlogs in immediate processing queues is exhausting\nresources on the target instances. If a user is attempting to execute 100 tasks\nper second on frontend instances that can only process 10 requests per second,\na backlog will build. This typically manifests in one of two ways, either of\nwhich can generally be resolved by increasing the number of instances processing\nrequests.\n\n### Backoff errors and enforced rates\n\nServers that are being overloaded can start to return backoff errors: HTTP `503`\n(for App Engine targets), or HTTP `429` or `5xx` (for external targets).\nCloud Tasks reacts to these errors by slowing down execution until\nerrors stop. This system throttling prevents the worker from overloading. Note\nthat user-specified settings are not changed.\n\nSystem throttling happens in the following circumstances:\n\n- Cloud Tasks backs off on all errors. Normally the backoff\n specified in\n [`rate limits`](/tasks/docs/reference/rpc/google.cloud.tasks.v2#google.cloud.tasks.v2.Queue.FIELDS.google.cloud.tasks.v2.RateLimits.google.cloud.tasks.v2.Queue.rate_limits)\n is used. But if the worker returns HTTP `429 Too Many Requests`,\n `503 Service Unavailable`, or the rate of errors is high, Cloud Tasks\n uses a higher backoff rate. The retry specified in the `Retry-After` HTTP\n response header is considered.\n\n- To prevent traffic spikes and to smooth sudden increases in traffic,\n dispatches ramp up slowly when the queue is newly created or idle, and if large\n numbers of tasks suddenly become available to dispatch (due to spikes in create\n task rates, the queue being unpaused, or many tasks that are scheduled at the\n same time).\n\n### Latency spikes and max concurrent\n\nOverloaded servers can also respond with large increases in latency.\nIn this situation, requests remain open for longer. Because queues run with a\nmaximum concurrent number of tasks, this can result in queues being unable to\nexecute tasks at the expected rate. Increasing the\n[`max_concurrent_dispatches`](/tasks/docs/reference/rpc/google.cloud.tasks.v2#ratelimits)\nfor the affected queues can help in situations where the value has been set too\nlow, introducing an artificial rate limit. But increasing\n`max_concurrent_dispatches` is unlikely to relieve any underlying resource\npressure.\n\n### Ramp-up issues with long running tasks\n\nCloud Tasks queues ramp up their output in part based on the number of\nsuccessful previously dispatched tasks. If the task handler takes a considerable\nperiod of time---on the order of minutes---to complete a task and return a success\nresponse, there can be a lag in the queue ramp-up rate.\n\nViewing more than 5,000 tasks\n-----------------------------\n\nIf you have more than 5,000 tasks, some tasks are not visible in the\nGoogle Cloud console. Use [gcloud CLI](/sdk/gcloud/reference/tasks/list)\nto view all tasks.\n\nRecreating a queue with the same name\n-------------------------------------\n\nIf you [delete a queue](/tasks/docs/deleting-appengine-queues-and-tasks#delete-queues)\nfrom the Google Cloud console, you must wait 3 days before recreating it with\nthe same name. This waiting period prevents unexpected behaviour in tasks that\nare executing at the time of deletion or waiting to be executed. It also avoids\ninternal process failures in the delete or recreate cycle."]]
