Cloud Tasks

解決する課題

ユーザーのリクエストを待たせずに重い処理を後回しにしたい、外部 API への呼び出しを安定したペースで送りたい、失敗しても自動で再試行したい、といった要件をワーカーの実装なしで満たせます。

• 重い処理（メール送信・画像変換・集計）を リクエスト経路から切り離し て応答を速くしたい
• 呼び出し先（自前のサービスや外部 API）へ送る 流量を一定に保ち、過負荷を防ぎたい
• 一時的なエラーで失敗したタスクを 自動で再試行 したい（指数バックオフ）
• 「30 分後に通知する」のように 指定時刻まで遅延 させて 1 回だけ実行したい
• 個々のタスクの 生成元と実行先を疎結合 にし、独立してスケールさせたい

主要概念と用語

• キュー（Queue）: タスクを溜める入れ物。ディスパッチレートや同時実行数などの流量制御はキュー単位で設定する。AWS SQS のキューに相当
• タスク（Task）: 実行したい 1 件の作業。ターゲット（送信先 URL）・HTTP メソッド・ペイロード・スケジュール時刻などを含む
• ディスパッチ（Dispatch）: Cloud Tasks がタスクを取り出し、ターゲットへ HTTP リクエストとして送ること。プッシュ型（Cloud Tasks 側がワーカーを呼ぶ）が基本
• HTTP ターゲット: 任意の公開 HTTPS エンドポイントへ配信する方式。OIDC または OAuth トークンを付与できる
• App Engine ターゲット: 同一プロジェクトの App Engine サービスへ配信する専用方式
• ディスパッチレート（maxDispatchesPerSecond）: 1 秒あたりに送るタスク数の上限。流量の天井
• 最大同時実行数（maxConcurrentDispatches）: 同時に処理中にできるタスク数の上限
• 再試行設定（Retry config）: 失敗時の最大試行回数・最小／最大バックオフ・最大経過時間などを定義
• scheduleTime: タスクを実行してよい最短時刻。未来時刻を指定すると 遅延実行 になる
• タスク名による重複排除（dedupe）: 同名タスクを作ろうとすると拒否され、短時間の重複生成を防げる

仕様・制限・クォータ

• 配信はプッシュ型で、Cloud Tasks 側がターゲット URL を呼び出す（SQS の Pull とは逆向き）。ワーカーは 2xx を返せば成功、それ以外は失敗として再試行対象になる
• 少なくとも 1 回（at-least-once） の実行が基本。まれに重複実行されうるため、処理は 冪等 に作る
• タスクのペイロードや実行時間には上限があり、長時間バッチではなく短い HTTP 処理に向く（数十分単位の長尺ジョブには不向き）
• scheduleTime には未来へのスケジュール上限があり、無制限に遠い未来を指定することはできない
• 重複排除はタスク名で行うが、削除直後の同名再作成には一定の待ち時間があるなど制約がある
• 流量制御（ディスパッチレート・同時実行数）と再試行は キュー単位 の設定。タスクごとに上書きはできない
• HTTP ターゲットは HTTPS が前提で、認証トークン（OIDC/OAuth）を付けて呼び出せる

具体的な上限値は変動しうるため、設計時は公式ドキュメントのクォータと上限を確認してください。

内部の仕組み

タスクを作成すると、Cloud Tasks はそれを キューに永続化 し、キューの流量設定に従って取り出してターゲットへ HTTP リクエストを送ります。ワーカーが 2xx を返すと成功として削除、それ以外（4xx の一部・5xx・タイムアウト）は 失敗として再試行キューに戻します。

• ディスパッチは maxDispatchesPerSecond と maxConcurrentDispatches の両方を満たす範囲で行われ、ワーカーへ押し寄せる量を平滑化する
• 失敗時は 指数バックオフ で待ってから再試行し、最大試行回数または最大経過時間に達すると打ち切られる
• scheduleTime を未来にしたタスクは、その時刻になるまでディスパッチされない（遅延実行・予約実行）
• キューを 一時停止（pause） するとディスパッチが止まり、再開すると溜まったタスクから流れ出す

設計パターン / ベストプラクティス

• Web リクエストの裏で非同期化: API はタスクを作成して即応答し、実処理は Cloud Run / Cloud Functions のワーカーに任せる
• 外部 API のレート制御: 送信先の制限に合わせてキューの ディスパッチレート を下げ、429 を避ける（タスクキュー全体が緩衝材になる）
• 遅延・予約実行: scheduleTime で「N 分後」「指定時刻」に 1 回だけ実行。定期実行（cron）は Cloud Scheduler の役割で、用途が異なる
• 過負荷時の絞り込み: 障害時は 同時実行数を絞る か キューを一時停止 して、復旧後にまとめて流す
• 冪等キー: タスクのペイロードに一意キーを持たせ、ワーカー側で処理済みを判定して重複実行を吸収する
• ファンアウトが欲しいときは Pub/Sub: 1 イベントを多数の購読者へ同報したい場合は Cloud Tasks ではなく Pub/Sub が適任

運用・監視

• Cloud Monitoring でキューの状態を監視する:
  • 試行回数や成功／失敗レスポンス数 → ワーカーのエラー率を把握
  • キューの タスク滞留（深さ） → ディスパッチが追いついていないサイン
• 滞留が増える → 同時実行数・ディスパッチレートの上限やワーカー側のレイテンシ／エラーを疑う
• 失敗が続く → ターゲット URL・認証（トークン）・ペイロード形式・ワーカーの 5xx を確認
• 緊急時は キューの一時停止／パージ（全削除） で流れを止めたり溜まったタスクを破棄できる
• 再試行の打ち切り（最大試行回数・最大経過時間到達）はログで追えるようにし、取りこぼしを検知する

コスト

課金はおもに 処理したタスク操作の件数 に対して発生し、一定の無料枠が用意されています。リクエスト数ベースのため、不要なタスク生成や過剰な再試行が積み重なるとコスト要因になります。

セキュリティ

• IAM でキュー単位の権限を制御する（タスクの作成権限・キュー管理権限などを分離）。最小権限を徹底
• HTTP ターゲットへの配信には サービスアカウントを使った OIDC / OAuth トークンを付与し、ワーカー側で発行元を検証する
• ワーカーのエンドポイントは 認証必須にし、誰でも叩ける公開 URL にしない
• 転送中は TLS（HTTPS） が前提。ペイロードに秘密情報を平文で入れない
• VPC Service Controls で境界を作り、データ持ち出しを防ぐ

Well-Architected の観点

• 信頼性（Reliability）: 自動再試行・指数バックオフ・キューによる緩衝で、一時障害やスパイクに強い非同期処理を組める。ワーカーを冪等にすることで「少なくとも 1 回」実行の重複も安全に吸収できる
• 流量制御（ディスパッチレート・同時実行数）で ダウンストリームを過負荷から守る ことができ、システム全体の安定性に寄与する
• 失敗タスクの再試行を任せられるため、呼び出し側に複雑なリトライ実装を持ち込まずに済む

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# キューを作成（ディスパッチレートと同時実行数で流量を制御）
gcloud tasks queues create jobs-queue \
  --max-dispatches-per-second=5 \
  --max-concurrent-dispatches=10 \
  --max-attempts=5

# HTTP ターゲットへタスクを作成（OIDC 認証付き）
gcloud tasks create-http-task \
  --queue=jobs-queue \
  --url=https://worker-xxxx.a.run.app/process \
  --method=POST \
  --body-content='{"id":"job-1"}' \
  --oidc-service-account-email=tasks-invoker@PROJECT_ID.iam.gserviceaccount.com

# 60 秒後に実行する遅延タスク（指定時刻まで配信されない）
gcloud tasks create-http-task \
  --queue=jobs-queue \
  --url=https://worker-xxxx.a.run.app/notify \
  --schedule-time="2026-06-14T12:00:00Z"

# 過負荷時はキューを一時停止し、復旧後に再開
gcloud tasks queues pause jobs-queue
gcloud tasks queues resume jobs-queue

# キューの状態と設定を確認
gcloud tasks queues describe jobs-queue