Cloud Tasks を使用すると、メインのアプリケーション フローの外部で独立して実行できる作業を分離し、作成したハンドラを使用した非同期での処理に回します。 このような独立した作業は、タスクと呼ばれます。 たとえば、ユーザー リクエストの処理の一環としてデータベースを更新する必要がありますが、更新には時間がかかることがあります。 この処理をタスクとしてオフロードすると、リクエストからより迅速に処理を返せるようになります。
オフロードされるタスクはキューに追加され、正常に実行されるか、 再試行回数が上限に達するまでタスクは保持されます。その後、タスクは 削除されます。初期構成に基づいて、キューはディスパッチ フロー制御の役割を果たすこともできます。Cloud Tasks サービスによって管理されるキューを作成して構成します。タスクが追加されると、キューはそのタスクをディスパッチし、ワーカーによって確実に処理されるようにします。 ユーザー側のレイテンシ コスト、サーバーのクラッシュ、リソース消費の上限、再試行の管理など、プロセスに関連する複雑な作業は、サービスに任せることができます。
Cloud Tasks は「少なくとも 1 回」処理を行うように設計されています。つまり、タスクが正常に追加された場合、キューはそれを少なくとも 1 回配信します。まれに複数のタスクが実行されることもあるので、反復的な実行で有害な副作用が生じないようにする必要があります。ハンドラは べき等である必要があります。
タスク自体は一意の名前と構成情報からなります。リクエストの処理に必要であれば、最初のリクエストのデータ（ペイロード）も含まれます。ペイロードはリクエストの本文で送信されるため、ペイロードを含むタスクは HTTP メソッドとして POST または PUT を使用する必要があります。
Cloud Tasks API を使用して Cloud Tasks サービスにアクセスするには、 プロジェクト Google Cloud が必要です。
機能
Cloud Tasks を使用すると、次のコントロールを使用して非同期作業アイテムをディスパッチできます。
- 具体的な配信時間のスケジュール
- 配信レートの管理
- 再試行動作の構成
- キュー内の個々のタスクへのアクセスと管理
- タスクの重複排除の有効化
全般的なワークフロー
一般的なワークフローは次のとおりです。
- タスクを処理するためのワーカーを作成します。
- キューを作成します。
- プログラムでタスクを作成し、キューに追加します。
- Cloud Tasks サービスが元のアプリケーションに OK を返します。これは、タスクが Cloud Task ストレージに正常に書き込まれて、タスク作成リクエストの高可用性と耐久性が確保されたことを意味します。
- タスクがワーカーに渡されます。
- ワーカーがタスクを処理します。
- シーケンスを完了するために、ワーカーが 2xx の成功ステータス コードを Cloud Tasks サービスに返します。
タスクがキューに渡された後は、最初のリクエストでデータが使用できなくなります。
ユースケース
主な用途としては、次のようなものがあります。
- データベースの更新など、処理速度に影響を及ぼすバックグラウンド オペレーションをワーカーに委任し、ユーザーのレスポンス時間を短縮する。
- 本番環境で予期しないインシデントが発生した場合にリクエストを保存する。
- ユーザーに直接関係のないタスクをメインユーザーのフローから削除し、トラフィックの急増を抑える。
- サードパーティ API 呼び出しレートの管理
HTTP ターゲットを使用した Cloud Tasks キュー
汎用 HTTP ターゲットの場合、Cloud Tasks サービスは、どのようにタスクが構成されているか基づいて、汎用 HTTP エンドポイントにあるワーカーにタスク リクエストを転送します。このエンドポイントは、どのようにタスクが構成されているかに基づいて Cloud Run 関数、Cloud Run、 GKE、 Compute Engine、またはオンプレミスのウェブサーバー上にあります。これらのキューは確実なレートでリクエストをディスパッチします（このレートは構成可能です）。これらのキューにより、信頼性の高いタスク実行が保証されます。タスクが正常に実行されると、すべてのワーカーはデフォルトのタイムアウト期限の 10 分、最大 30 分以内に HTTP レスポンス コード（200 ～ 299）を Cloud Tasks サービスに送信する必要があります。別のレスポンスが送信された場合、あるいはレスポンスがない場合、タスクが再試行されます。
ターゲットはワーカーのスケーリングを管理し、タスクが完了したらタスクをクリーンアップする必要があります。
ターゲットで認証が必要な場合は、2 つのサービス アカウントを設定する必要があります。1 つはアプリケーションとクライアント用であり、もう 1 つはキュー用です。これらのアカウントには、必要な権限を付与する必要があります。また、タスク リクエストには、クライアント サービス アカウントの識別子を含める必要があります。詳細については、 HTTP Target タスクを作成するをご覧ください。
App Engine ターゲットを使用した Cloud Tasks キュー
Cloud Tasks は、次の App Engine 環境と互換性があります。
- App Engine スタンダード環境、第 2 世代ランタイム
- App Engine フレキシブル環境
Task Queue API を使用する App Engine 第 1 世代ランタイムのユーザーは、 Cloud Tasks に移行できます。方法については、 以前のバンドル サービスからの移行をご覧ください。 バンドルされたタスク サービスを使用しない App Engine 第 1 世代ランタイムのユーザーは、第 2 世代ランタイムにアップグレードして Cloud Tasks を使用できます。
App Engine ターゲットの場合、Cloud Tasks サービスはタスク リクエストをハンドラに転送しますが、このワーカーは App Engine 内にあります。したがって、App Engine ハンドラを対象とするすべてのキューには、 App Engine アプリが必要です。 このハンドラは、App Engine アプリが動作しているリージョンで動作する必要があります。このリージョンは、Cloud Tasks リクエストの LOCATION_ID パラメータとしても機能します。
タスクは、タスク（または、あまり一般的ではありませんがキュー自体）の構成方法に基づいて転送されます。これらのキューは確実なレートでリクエストをディスパッチします（このレートは構成可能です）。 これらのキューにより、信頼性の高いタスク実行が保証されます。タスクが正常に実行されると、サービスの インスタンス スケーリング のタイプに応じた期限までに、この インスタンス内で、すべてのワーカーが HTTP レスポンス コード（200 ～ 299）を Cloud Tasks サービスに送信する必要があります。コードを返す期限は、自動スケーリングで 10 分以内、手動スケーリングで 24 時間以内です。別のレスポンスが送信された場合、あるいはレスポンスがない場合、タスクが再試行されます。
ハンドラは App Engine の一部であるため、タスクのプロセス管理の大半は Cloud Tasks サービスが処理できます。これには、トラフィック量に応じたワーカーのスケールアップとスケールダウン、完了したタスクの削除も含まれます。
ターゲットでサポートされているリージョン
ターゲットが HTTP/S エンドポイント の場合、Cloud Tasks は Cloud Tasks がサポートされているすべてのリージョン Google Cloud で使用できます。
ターゲットが現在のプロジェクト内にある App Engine アプリケーション の場合:
App Engine をターゲットとするタスクは、プロジェクトの App Engine リージョンでのみ作成できます。
プロジェクトには 1 つの App Engine アプリのみを含めることができます。App Engine アプリの作成後には、アプリが配置されているリージョンは変更できません。 Google Cloud
App Engine はリージョンの影響を受けます。つまり、アプリを実行するインフラストラクチャは特定のリージョンに配置されています。 コンピューティングとキューを複数のリージョンに分散する場合は、代わりに HTTP/S エンドポイントをターゲットにする必要があります。
App Engine をターゲットとして使用していない場合、App Engine アプリをデプロイする必要はなく、既存の App Engine アプリを無効にできます。
タスクの重複排除
タスクの重複排除は、タスクに一意の名前を割り当てることで実現されます。キューにすでに存在する名前のタスクを作成しようとすると、作成リクエストは失敗します。これにより、同じタスクが複数回追加されるのを防ぐことができます。
Cloud Tasks は、キューからタスクが削除されてから最大 24 時間、タスク名を記憶します。この期間中に同じ名前でタスクを再作成しようとすると、リクエストも失敗します。
タスクの作成時に名前を指定しない場合、Cloud Tasks は一意の名前を生成するため、重複排除は不要です。
主な用語
次の用語は、Cloud Tasks の主な機能を説明しています。
| 用語 | 定義 |
|---|---|
| 試行 | タスクを実行しようとすること。 |
| ディスパッチの試行 | Cloud Tasks がタスクをそのターゲットに送信すること。 |
| 試行のレスポンス | 正常に完了したか失敗したタスクに関連付けられた 作業を示すワーカーからのレスポンス。 |
| handler | タスクの処理を担当するアプリケーション コード（ワーカーとも呼ばれます）。 Cloud Tasks がキューからタスクをディスパッチすると、ターゲット サービスにリクエストを送信します。そのエンドポイントでタスクを受信して実行するコードがハンドラです。 |
| キュー | 単一の構成で管理される、同じターゲット タイプのタスクのセット。 |
| レート制限 | キューがタスクをディスパッチできるレートを 、ディスパッチが 最初のタスク試行か再試行かに関係なく決定します。 |
| 再試行 | タスクの実行を複数回試行します。再試行回数は、 再試行パラメータを使用して設定されます。 |
| ターゲット タイプ | タスクの処理方法を定義します。HTTP エンドポイントまたは App Engine アプリケーションをターゲットにできます。 |
| タスク | 非同期で実行する基本的な作業単位。これは、Cloud Tasks によってメインのアプリケーション フローの外部で処理されるように、キューに追加する単一の独立した作業を表します。 |
| Worker | タスクを処理するサービス。ハンドラをご覧ください。 |
オブザーバビリティ
Google Cloud Observability が提供するモニタリング、ロギング、診断ツールを使用して、Cloud Tasks のアクティビティと増加をモニタリングして分析できます。詳細については、Cloud Tasks のオブザーバビリティをご覧ください。