Cloud Tasks について理解する

このページでは、Cloud Tasks のタスクとキューの概要と、それぞれの使い方を説明します。Cloud Tasks を使用すると、メインのアプリケーションフローの外部で独立して実行できる作業を分離し、作成したハンドラを使用した非同期での処理に回します。このような独立した作業は、タスクと呼ばれます。たとえば、ユーザーリクエストの処理の一環としてデータベースを更新する必要がありますが、更新には時間がかかることがあります。この詳細をタスクとしてオフロードすると、リクエストからさらに迅速に戻ることができます。

オフロードされるタスクはキューに追加され、正常に実行されるまでタスクは保持されます。初期構成に基づいて、キューはディスパッチフロー制御の役割を果たすこともできます。Cloud Tasks サービスによって管理されるキューを作成して構成します。タスクが追加されると、キューはそのタスクをディスパッチし、ワーカーによって確実に処理されるようにします。ユーザー側のレイテンシコスト、サーバーのクラッシュ、リソース消費の上限、再試行の管理など、プロセスに関連する複雑な作業は、サービスに任せることができます。

Cloud Tasks は「少なくとも 1 回」処理を行うように設計されています。つまり、タスクが正常に追加された場合、キューはそれを少なくとも 1 回配信します。まれに複数のタスクが実行されることもあるので、反復的な実行で有害な副作用が生じないようにする必要があります。ハンドラはべき等である必要があります。

タスク自体は一意の名前と構成情報からなります。リクエストの処理に必要であれば、最初のリクエストのデータ（ペイロード）も含まれます。ペイロードはリクエストの本文で送信されるため、ペイロードを含むタスクは HTTP メソッドとして POST または PUT を使用する必要があります。

Cloud Tasks API を使用して Cloud Tasks サービスにアクセスするには、Google Cloud プロジェクトが必要です。

ユースケース

主な用途としては、次のようなものがあります。

データベースの更新など、処理速度に影響を及ぼすバックグラウンドオペレーションをワーカーに委任し、ユーザーのレスポンス時間を短縮する。
本番環境で予期しないインシデントが発生した場合にリクエストを保存する。
ユーザーに直接関係のないタスクをメインユーザーのフローから削除し、トラフィックの急増を抑える。
サードパーティ API 呼び出しレートの管理

HTTP ターゲットを使用した Cloud Tasks キュー

汎用 HTTP ターゲットの場合、Cloud Tasks サービスは、どのようにタスクが構成されているか基づいて、汎用 HTTP エンドポイントにあるワーカーにタスクリクエストを転送します。このエンドポイントは、どのようにタスクが構成されているかに基づいて Cloud Functions、Cloud Run、GKE、Compute Engine、またはオンプレミスのウェブサーバー上にあります。これらのキューは確実なレートでリクエストをディスパッチします（このレートは構成可能です）。これらのキューにより、信頼性の高いタスク実行が保証されます。タスクが正常に実行されると、すべてのワーカーはデフォルトのタイムアウト期限の 10 分、最大 30 分以内に HTTP レスポンスコード（200～299）を Cloud Tasks サービスに送信する必要があります。別のレスポンスが送信された場合、あるいはレスポンスがない場合、タスクが再試行されます。

HTTP ベースのキュー

ターゲットはワーカーのスケーリングを管理し、タスクが完了したらタスクをクリーンアップする必要があります。

ターゲットで認証が必要な場合は、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 ベースのキュー

ハンドラは App Engine の一部であるため、タスクのプロセス管理の大半は Cloud Tasks サービスが処理できます。これには、トラフィック量に応じたワーカーのスケールアップとスケールダウン、完了したタスクの削除も含まれます。

ターゲットでサポートされているリージョン

ターゲットが HTTP/S エンドポイントの場合、Cloud Tasks は、Cloud Tasks がサポートされているすべての Google Cloud リージョンで使用できます。

ターゲットが現在のプロジェクト内にある App Engine アプリケーションの場合:

App Engine をターゲットとするタスクは、プロジェクトの App Engine リージョンにのみ作成できます。
Google Cloud プロジェクトには 1 つの App Engine アプリのみを配置できます。App Engine アプリの作成後には、アプリが配置されているリージョンは変更できません。
App Engine はリージョンの影響を受けます。つまり、アプリを実行するインフラストラクチャは特定のリージョンに配置されています。コンピューティングとキューを複数のリージョンに分散する場合は、代わりに HTTP/S エンドポイントをターゲットにする必要があります。
App Engine をターゲットとして使用していない場合、App Engine アプリをデプロイする必要はなく、既存の App Engine アプリを無効にできます。

ワークフロー

一般的なワークフローは次のとおりです。

タスクを処理するためのワーカーを作成します。
キューを作成します。
プログラムでタスクを作成し、キューに追加します。
Cloud Tasks サービスが元のアプリケーションに OK を返します。これは、タスクが Cloud Task ストレージに正常に書き込まれて、タスク作成リクエストの高可用性と耐久性が確保されたことを意味します。
タスクがワーカーに渡されます。
ワーカーがタスクを処理します。
シーケンスを完了するために、ワーカーが 2xx の成功ステータスコードを Cloud Tasks サービスに返します。

タスクがキューに渡された後は、最初のリクエストでデータが使用できなくなります。

特徴

Cloud Tasks を使用すると、次のコントロールを使用して非同期作業アイテムをディスパッチできます。

具体的な配信時間のスケジュール
配信レートの管理
再試行動作の構成
キュー内の個々のタスクへのアクセスと管理
タスクの重複排除の有効化

利用規約

次の表に、Cloud Tasks の動作の側面を説明する主要な用語を記載します。

用語	定義
キュー	単一の構成で管理される、同じターゲットタイプのタスクのセット。
ターゲットタイプ	タスクの処理方法を定義します。
ワーカー	タスクを処理するサービス。
試行	タスクを実行しようとすること。
ディスパッチの試行	Cloud Tasks がタスクをそのターゲットに送信すること。
試行のレスポンス	正常に完了したか失敗したタスクに関連付けられた作業を示すワーカーからのレスポンス。
再試行	タスクの実行を複数回試行します。再試行回数は、RetryConfig によって設定されます。
レート制限	キューのレート制限。

指標

Cloud Monitoring を使用すると、次の定義済みの Google ToDo リストの指標を使用できます。

指標タイプ表示名種類、タイプ、単位	説明ラベル
`api/request_count` API リクエスト `DELTA`, `INT64`, `1`	Cloud Tasks API の呼び出し数。 `api_method`: 呼び出された API メソッド（例: CreateTask） `response_code`: 文字列での正規のレスポンスコード（例: OK）。
`queue/depth` ベータ版キューの深さ `GAUGE`、 `INT64`、 `1`	キュー内のタスクの数。60 秒ごとにサンプリングされます。サンプリング後、データは最長 120 秒間表示されません。
`queue/task_attempt_count` タスク試行回数 `DELTA`, `INT64`, `1`	キューがディスパッチしようとしたタスクの数。タスクレスポンスコードごとに分類されます。 `response_code`: 文字列での正規のレスポンスコード（例: OK）。
`queue/task_attempt_delays` タスク試行の遅延 `DELTA`, `DISTRIBUTION`, `ms`	予定された試行時間と実際の試行時間の間の遅延。