이 페이지에서는 태스크 큐의 정의, 사용 시기, 사용 방법을 설명합니다.
태스크 큐를 사용하면 애플리케이션이 사용자 요청 이외에도 비동기식으로 태스크라는 작업을 수행할 수 있습니다. 앱이 백그라운드에서 작업을 실행해야 하는 경우 태스크 큐에 태스크를 추가합니다. 태스크는 나중에 작업자 서비스에 의해 실행됩니다.
태스크 큐 서비스는 비동기 작업을 위해 설계되었습니다. 작업 전송 시점을 완벽하게 보장하지 않으므로, 사용자가 결과를 기다리는 대화형 애플리케이션에는 적합하지 않습니다.
push 큐와 pull 큐
태스크 큐에는 push와 pull이라는 2가지 유형이 있습니다. 태스크 큐 서비스가 작업 요청을 작업자 서비스로 전달하는 방식은 대기열마다 다릅니다.
push 큐는 App Engine 작업자 서비스에 HTTP 요청을 전달하여 작업을 실행합니다.
이러한 push 큐는 안정적이고 일정한 속도로 요청을 보내고 안정적으로 태스크를 실행합니다. 사용자는 태스크가 대기열에서 전송되는 속도를 제어할 수 있으므로 작업자의 확장 동작과 비용을 제어할 수 있습니다.
태스크는 App Engine 서비스를 대상으로 하는 요청으로 실행되므로 엄격한 기한이 적용됩니다. 자동 확장 서비스로 처리되는 태스크는 10분 안에 완료되어야 합니다. 기본 및 수동 확장 서비스로 처리되는 태스크는 최대 24시간 동안 실행될 수 있습니다.
pull 큐 태스크를 전혀 보내지 않습니다. 대신 다른 작업자 서비스를 사용하여 큐에서 태스크를 자체적으로 '임대'합니다. pull 큐를 사용하면 태스크가 처리되는 시기와 장소에 대해 더 많은 권한과 유연성을 얻는 대신 더 많은 프로세스를 관리해야 합니다. 태스크가 임대되면 임대 작업자가 기한을 선언합니다. 기한이 도래하면 작업자는 태스크를 완료하고 삭제해야 합니다. 그렇지 않으면 태스크 큐 서비스에서 다른 작업자가 태스크를 임대하도록 허용합니다.
모든 태스크 큐 작업은 비동기적인 방식으로 수행됩니다. 태스크를 만드는 애플리케이션이 태스크를 대기열로 전송합니다. 원본 애플리케이션에는 태스크의 완료 또는 성공 알림이 표시되지 않습니다.
작업자가 태스크를 처리하지 못하면 태스크 큐 서비스에서 재시도 메커니즘을 대기열에 제공하므로 제한된 횟수만큼 태스크를 다시 시도할 수 있습니다.
사용 사례
push 큐
push 큐의 일반적인 사용 사례는 '느린' 작업입니다. 소셜 네트워크 메시지 시스템을 예로 들어 보겠습니다. 사용자가 메시지를 보낼 때마다 네트워크는 보내는 사람의 팔로어를 업데이트해야 합니다. 이 작업에는 시간이 매우 오래 걸릴 수 있습니다. push 큐를 사용할 경우, 애플리케이션은 각 메시지 작업이 도착하면 이를 대기열에 추가하여 처리를 위해 작업자 서비스에 발송할 수 있습니다. 작업자가 태스크 요청을 받으면 보내는 사람의 팔로어 목록을 검색하여 각각의 DB를 업데이트할 수 있습니다. 각 데이터베이스 업데이트마다 다른 내보내기 태스크를 대기열에 추가하면 작업자의 효율성을 높일 수 있습니다.
push 큐의 또 다른 용도는 예약 작업입니다. 광고 캠페인을 구현하는 애플리케이션을 생각해 봅시다. 이메일 발송을 위해 작성된 태스크 그룹을 push 큐에 추가하고 향후 지정된 시간까지 태스크를 보류하라는 명령을 포함할 수 있습니다. 기한이 만료되면 태스크 큐 서비스가 태스크 실행 요청을 실행하기 시작합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eTask queues enable applications to perform tasks asynchronously outside of a user request, with worker services executing these tasks later.\u003c/p\u003e\n"],["\u003cp\u003eThere are two types of task queues: push queues, which deliver HTTP requests to worker services, and pull queues, which require worker services to lease tasks.\u003c/p\u003e\n"],["\u003cp\u003ePush queues are suitable for managing slow operations and scheduling tasks, allowing control over the rate of task execution and scaling behavior.\u003c/p\u003e\n"],["\u003cp\u003ePull queues offer greater flexibility in task processing but necessitate more process management by the user, with leased tasks needing to be completed or deleted before a specified deadline.\u003c/p\u003e\n"],["\u003cp\u003eAll task queue tasks are performed asynchronously, with a built-in retry mechanism for tasks that fail during the initial attempt.\u003c/p\u003e\n"]]],[],null,["# Task Queue Overview\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\nGo Java PHP Python\n\nThis page describes what task queues are, and when and how to use them.\nTask queues let applications perform work, called *tasks* ,\nasynchronously outside of a user request. If an app needs to execute work\nin the background, it adds tasks to *task queues*. The tasks are executed later,\nby worker services.\n\nThe Task Queue service is designed for asynchronous work. It does not\nprovide strong guarantees around the timing of task delivery and is therefore\nunsuitable for interactive applications where a user is waiting for the result.\n| This API is supported for first-generation runtimes and can be used when [upgrading to corresponding second-generation runtimes](/appengine/docs/standard/\n|\n| /services/access). If you are updating to the App Engine runtime, refer to the [Upgrade to second-generation runtimes]() page to learn about your migration options for legacy bundled services.\n\nPush queues and pull queues\n---------------------------\n\nTask queues come in two flavors, *push* and *pull*. The manner in which the\nTask Queue service dispatches task requests to worker services is different for\nthe different queues.\n\n**Push queues** run tasks by delivering HTTP requests to App Engine worker services.\nThey dispatch these requests at a reliable, steady rate and guarantee\nreliable task execution. Because you can control the rate at which tasks are\nsent from the queue, you can control the workers' scaling behavior and hence\nyour costs.\n\nBecause tasks are executed as requests targeted at App Engine\nservices, they are subject to stringent deadlines. Tasks handled by automatic\nscaling services must finish in ten minutes. Tasks handled by basic and manual\nscaling services can run for up to 24 hours.\n\n**Pull queues** do not dispatch tasks at all. They depend on other worker\nservices to \"lease\" tasks from the queue on their own initiative. Pull queues\ngive you more power and flexibility over when and where tasks are processed, but\nthey also require you to do more process management. When a task is leased the\nleasing worker declares a deadline. By the time the deadline arrives the worker\nmust either complete the task and delete it or the Task Queue service will\nallow another worker to lease it.\n\n| **Tip:** In some cases [Google Cloud Pub/Sub](/pubsub/overview) is a good alternative to pull queues.\n\nAll task queue tasks are performed **asynchronously**. The application that creates\nthe task hands it off to the queue. The originating application is not notified\nwhether or not the task completes, or if it was successful.\n\nIf a worker fails to process a task, the Task Queue service provides the queue\nwith a retry mechanism, so the task can be retried a finite number of times.\n\nUse cases\n---------\n\n### Push queues\n\nOne typical push queue use case is a \"slow\" operation. Consider a social\nnetwork messaging system. Every time a user sends a message, the network needs\nto update the followers of the sender. This can be a very time-consuming\noperation. Using a push queue, the application can enqueue a task for each\nmessage as it arrives to be dispatched to a worker service for processing. When\nthe worker receives the task request, it can retrieve the sender's list of\nfollowers and update the DB for each one. The worker can be made even more\nefficient by enqueuing another pushtask for each database update.\n\nAnother use for push queues is scheduled tasks. Imagine an application that\nimplements an ad campaign. A group of tasks written to send out emails can be\nadded to a push queue with instructions to withhold the tasks until a specified\ntime in the future. When the due date arrives, the Task Queue service will\nbegin to issue requests to execute the tasks.\n\nWhat's next\n-----------\n\n- Read about [push queues](/appengine/docs/standard/services/taskqueue/push)"]]
