Python 2.7은 지원이 종료되었으며 2026년 1월 31일에
지원 중단됩니다. 지원 중단 후에는 조직에서 이전에 조직 정책을 사용하여 레거시 런타임의 배포를 다시 사용 설정한 경우에도 Python 2.7 애플리케이션을 배포할 수 없습니다. 기존 Python 2.7 애플리케이션은
지원 중단 날짜 이후에도 계속 실행되고 트래픽을 수신합니다.
지원되는 최신 Python 버전으로 마이그레이션하는 것이 좋습니다.
태스크 큐 개요
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이 페이지에서는 태스크 큐의 정의, 사용 시기, 사용 방법을 설명합니다.
태스크 큐를 사용하면 애플리케이션이 사용자 요청 이외에도 비동기식으로 태스크라는 작업을 수행할 수 있습니다. 앱이 백그라운드에서 작업을 실행해야 하는 경우 태스크 큐에 태스크를 추가합니다. 태스크는 나중에 작업자 서비스에 의해 실행됩니다.
태스크 큐 서비스는 비동기 작업을 위해 설계되었습니다. 작업 전송 시점을 완벽하게 보장하지 않으므로, 사용자가 결과를 기다리는 대화형 애플리케이션에는 적합하지 않습니다.
push 큐와 pull 큐
태스크 큐에는 push와 pull이라는 2가지 유형이 있습니다. 태스크 큐 서비스가 작업 요청을 작업자 서비스로 전달하는 방식은 대기열마다 다릅니다.
push 큐는 App Engine 작업자 서비스에 HTTP 요청을 전달하여 작업을 실행합니다.
이러한 push 큐는 안정적이고 일정한 속도로 요청을 보내고 안정적으로 태스크를 실행합니다. 사용자는 태스크가 대기열에서 전송되는 속도를 제어할 수 있으므로 작업자의 확장 동작과 비용을 제어할 수 있습니다.
태스크는 App Engine 서비스를 대상으로 하는 요청으로 실행되므로 엄격한 기한이 적용됩니다. 자동 확장 서비스로 처리되는 태스크는 10분 안에 완료되어야 합니다. 기본 및 수동 확장 서비스로 처리되는 태스크는 최대 24시간 동안 실행될 수 있습니다.
pull 큐는 작업을 전혀 보내지 않습니다. 대신 다른 작업자 서비스를 사용하여 큐에서 태스크를 자체적으로 '임대'합니다. pull 큐를 사용하면 태스크가 처리되는 시기와 장소에 대해 더 많은 권한과 유연성을 얻는 대신 더 많은 프로세스를 관리해야 합니다. 태스크가 임대되면 임대 작업자가 기한을 선언합니다. 기한이 도래하면 작업자는 태스크를 완료하고 삭제해야 합니다. 그렇지 않으면 태스크 큐 서비스에서 다른 작업자가 태스크를 임대하도록 허용합니다.
모든 태스크 큐 작업은 비동기적인 방식으로 수행됩니다. 태스크를 만드는 애플리케이션이 태스크를 대기열로 전송합니다. 원본 애플리케이션에는 태스크의 완료 또는 성공 알림이 표시되지 않습니다.
작업자가 태스크를 처리하지 못하면 태스크 큐 서비스에서 재시도 메커니즘을 대기열에 제공하므로 제한된 횟수만큼 태스크를 다시 시도할 수 있습니다.
사용 사례
push 큐
push 큐의 일반적인 사용 사례는 '느린' 작업입니다. 소셜 네트워크 메시지 시스템을 예로 들어 보겠습니다. 사용자가 메시지를 보낼 때마다 네트워크는 보내는 사람의 팔로어를 업데이트해야 합니다. 이 작업에는 시간이 매우 오래 걸릴 수 있습니다. push 큐를 사용할 경우, 애플리케이션은 각 메시지 작업이 도착하면 이를 대기열에 추가하여 처리를 위해 작업자 서비스에 발송할 수 있습니다. 작업자가 태스크 요청을 받으면 보내는 사람의 팔로어 목록을 검색하여 각각의 DB를 업데이트할 수 있습니다. 각 데이터베이스 업데이트마다 다른 내보내기 태스크를 대기열에 추가하면 작업자의 효율성을 높일 수 있습니다.
push 큐의 또 다른 용도는 예약 작업입니다. 광고 캠페인을 구현하는 애플리케이션을 생각해 봅시다. 이메일 발송을 위해 작성된 태스크 그룹을 push 큐에 추가하고 향후 지정된 시간까지 태스크를 보류하라는 명령을 포함할 수 있습니다. 기한이 만료되면 태스크 큐 서비스가 태스크 실행 요청을 실행하기 시작합니다.
가져오기 대기열
pull 큐는 효율적인 실행을 위해 일괄 태스크를 수행해야 하는 경우 효과적입니다. 한 가지 방법은 가져오기 태스크에 태그 연결 기능을 활용하는 것입니다. 작업자는 동일한 태그가 있는 작업 그룹을 임대할 수 있습니다. 대표적인 예로는 여러 플레이어와 그룹이 지속적으로 플레이하는 다양한 게임의 리더보드를 관리하는 앱이 있습니다. 새로운 최고 점수가 나올 때마다 앱에서 점수와 플레이어가 포함된 가져오기 태스크를 큐에 추가하고 게임 ID를 태스크 태그로 사용할 수 있습니다. 작업자는 주기적으로 '깨어나' 동일한 게임 ID의 태스크 그룹을 임대하고 리더보드를 업데이트합니다. 지정된 태그 값을 사용하여 태스크를 명시적으로 임대하거나, 보낼 태스크 중에서 유사한 태그가 지정된 태스크 그룹을 서비스에서 결정하도록 할 수 있습니다.
태그를 사용한 일괄 처리는 성능이 매우 강력합니다. 앱이 실행되는 동안 태그를 동적으로 생성할 수 있으므로 작업자는 간편하게 새로운 게임 ID를 처리할 수 있습니다.
다음 단계
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-09-04(UTC)
[[["이해하기 쉬움","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 dispatch tasks via HTTP requests to App Engine worker services, and pull queues, which require worker services to lease tasks.\u003c/p\u003e\n"],["\u003cp\u003ePush queues are well-suited for slow operations and scheduled tasks, allowing control over worker scaling and costs, while pull queues are ideal for batching tasks with dynamic tagging for efficient execution.\u003c/p\u003e\n"],["\u003cp\u003eTask queue tasks are performed asynchronously, meaning the application that creates the task is not notified of its completion or success.\u003c/p\u003e\n"],["\u003cp\u003eThe Task Queue service provides a retry mechanism for failed tasks, allowing them to be retried a certain number of times.\u003c/p\u003e\n"]]],[],null,["# Task Queue Overview\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| python3\n|\n| /services/access). If you are updating to the App Engine Python 3 runtime, refer to the [migration guide](/appengine/migration-center/standard/migrate-to-second-gen/python-differences) 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\n### Pull queues\n\nPull queues work well when you need to batch tasks together for efficient\nexecution. One solution takes advantage of the ability to attach a *tag* to a\npull task. Workers can lease a group of tasks that have the same tag. A typical\nexample might be an app that maintains leaderboards for numerous different games, with\nmany players and groups constantly in play. Every time there is a new high\nscore, the app can enqueue a pull task with the score and the player, and use\nthe game ID as a task tag. A worker periodically \"wakes up\", leases a group of\ntasks with the same game ID, and updates the leaderboard. You can lease tasks\nexplicitly, using a specified tag value, or let the service decide which group\nof similarly tagged tasks to send.\n\nBatching with tags can be very powerful. Since tags can be dynamically\ngenerated while your app is running, a worker can handle new game IDs with no\nspecial effort.\n\n\nWhat's next\n-----------\n\n- Read about [push queues](/appengine/docs/legacy/standard/python/taskqueue/push)\n- Read about [pull queues](/appengine/docs/legacy/standard/python/taskqueue/pull)"]]
