Java 8 はサポートが終了しており、2026 年 1 月 31 日に
非推奨になります。非推奨になると、過去に組織のポリシーを使用して以前のランタイムのデプロイを再度有効にしていた場合でも、Java 8 アプリケーションをデプロイできなくなります。既存の Java 8 アプリケーションは、
非推奨になる日付以降も引き続き実行され、トラフィックを受信します。
サポートされている最新バージョンの Java に移行することをおすすめします。
タスクキューの概要
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
このページでは、タスクキューの概要とその使い方を説明します。タスクキューを使用すると、アプリケーションはユーザー リクエストの外部でタスクと呼ばれる処理を非同期的に実行できます。アプリがバックグラウンドで処理を行う必要がある場合、タスクがタスクキューに追加されます。そのタスクはワーカー サービスによって後で実行されます。
タスクキュー サービスは、非同期処理用に設計されています。タスクの配信タイミングに関する確実な保証はないため、ユーザーが結果を待機する対話型のアプリケーションには適していません。
push キューと pull キュー
タスクキューには push と pull の 2 種類があります。タスクキュー サービスがタスク リクエストをワーカー サービスにディスパッチする方法は、キューの種類ごとに異なります。
push キューは、HTTP リクエストを App Engine ワーカー サービスに送信して、タスクを実行します。これらのリクエストは確実かつ一定の頻度でディスパッチされ、信頼性の高いタスク実行が保証されます。タスクがキューから送信される頻度を制御できるため、ワーカーのスケーリング動作、つまりコストを制御できます。
タスクは、App Engine サービスをターゲットとするリクエストとして実行されるため、厳格な期限が適用されます。自動スケーリング サービスで処理されるタスクは 10 分以内に終了する必要があります。基本および手動スケーリング サービスで処理されるタスクは、最大 24 時間実行できます。
pull キューはタスクをディスパッチしません。このキューは、他のワーカー サービスの必要に応じて自発的にキューからタスクを「リース」します。pull キューは強力で、タスクを処理するタイミングや場所を柔軟に選べますが、プロセス管理の負担が増えます。タスクがリースされると、リースワーカーによって期限が宣言されます。期限までに、ワーカーはそのタスクを完了して削除するか、またはタスクキュー サービスによって別のワーカーがそのタスクをリースできるようにする必要があります。
タスクキューのすべてのタスクは非同期的に実行されます。タスクを作成したアプリケーションは、タスクをキューに渡します。タスクが完了したかどうか、または成功したかどうかは元のアプリケーションには通知されません。
ワーカーがタスクの処理に失敗した場合、タスクキュー サービスはキューに再試行メカニズムを適用するため、タスクは限られた回数だけ再試行されます。
使用例
push キュー
push キューの典型的な使用例は「スロー」処理です。ソーシャル ネットワークのメッセージング システムでは、ユーザーがメッセージを送信するたびに、送信者のフォロワーを更新する必要があります。この処理には相当の時間がかかる場合があります。push キューを使用すると、アプリケーションは、メッセージが届くたびにそれに対応するタスクをキューに追加し、処理のためにワーカー サービスにディスパッチされるようにできます。ワーカーはタスク リクエストを受信すると、送信者のフォロワーのリストを取得し、フォロワーごとにデータベースを更新できます。データベース更新のたびに別の push タスクをキューに入れると、ワーカーの効率が向上します。
push キューの別の使用例として、スケジュールされたタスクがあります。たとえば、広告キャンペーンを実装するアプリを考えてみましょう。メールを送信するために作成した一連のタスクを、指定した時間になるまで保留するよう指示した上で push キューに追加できます。指定した時間になると、タスクキュー サービスがリスクエストの発行を開始し、タスクを実行します。
pull キュー
タスクを一括して効率的に実行する必要があるときは、pull キューが有効です。1 つの方法として、pull タスクにタグを付ける機能を活用できます。ワーカーは同じタグの付いている一連のタスクをリースできます。典型的な例として、多くのプレーヤーやグループが次々と参加する多数のゲームのリーダーボードを管理するアプリがあります。ハイスコアが更新されるたびに、スコアとプレーヤーを指定した pull タスクをキューに追加し、ゲーム ID をタスクタグとして使用できます。ワーカーは定期的に「復帰」して、ゲーム ID が同じ一連のタスクをリースし、リーダーボードを更新します。指定されたタグ値を使用してタスクを明示的にリースすることも、類似のタグが付いているどの一連のタスクを送信するかの判断をサービスに任せることもできます。
タグを使用した一括処理はとても強力です。アプリの実行中にタグを動的に生成できるため、ワーカーは簡単に新しいゲーム ID を処理できます。
次のステップ
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は 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 worker services, and pull queues, which require worker services to lease tasks.\u003c/p\u003e\n"],["\u003cp\u003ePush queues are ideal for operations like slow processes or scheduled tasks, while pull queues are well-suited for batching tasks together for efficient execution, such as updating leaderboards in games.\u003c/p\u003e\n"],["\u003cp\u003ePush queues offer control over worker scaling and cost, but are subject to deadlines, whereas pull queues provide more flexibility but require more process management.\u003c/p\u003e\n"],["\u003cp\u003eAll task queue tasks are asynchronous, and the originating application is not notified about task completion; the task queue service provides a retry mechanism if a worker fails to process a task.\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| java-gen2\n|\n| /services/access). If you are updating to the App Engine Java 11/17 runtime, refer to the [migration guide](/appengine/migration-center/standard/migrate-to-second-gen/java-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/java/taskqueue/push)\n- Read about [pull queues](/appengine/docs/legacy/standard/java/taskqueue/pull)"]]
