技術選定にだいぶ苦労した過去の私へ。
1. TL;DR
- Cloud Tasks はHTTP ターゲットへ明示的に配信するタスク実行に向く。細かな レート制御／リトライ／スケジュール、タスク単位の管理 が必要なら第一候補。Cloud Run との相性が非常に良い（最小インスタンス 0 でイベント駆動）。
- Pub/Sub Push サブスクリプション はイベント通知のファンアウト／疎結合に強い。Cloud Run/Functions に HTTP POST で即時配信されるため、間欠的ワークロードでもゼロスケールが可能。
- Pub/Sub Pull サブスクリプション は、ワーカーが自らメッセージを取りに行く。常時起動が前提になりがちで、バッチ処理や高スループット用途に適合。Cloud Run の「リクエスト駆動」モデルとは相性が悪いケースが多い。
- 迷ったら「明示的呼び出し（ジョブ実行制御） ＝Cloud Tasks」「暗黙的通知（イベント配信/多対多） ＝Pub/Sub」。
2. 用語と前提
- Cloud Run: リクエストやイベントに応じて自動スケール。トラフィックが無ければ 0 インスタンスに縮退可能。必要に応じて 最小インスタンス数を設定してウォーム保持もできる。
- Cloud Tasks: HTTP/HTTPS でターゲット（例: Cloud Run エンドポイント）へタスクを プッシュ配信。キュー単位で レート制限やリトライを構成できる。
- Cloud Pub/Sub: トピックに発行されたメッセージをサブスクリプション経由で配信。Push（Pub/Sub→HTTP POST）と Pull（クライアントが取得）をサポート。
3. アーキテクチャ別の使い分け
3.1 Cloud Tasks（Push）× Cloud Run
ユースケース
- ユーザーリクエストから切り離した非同期ジョブ実行（画像処理、メール送信、決済後処理など）。
- レート制限や明示的リトライポリシー、遅延実行（schedule_time） が必要。
動作ポイント
- Cloud TasksのSDKがタスクを登録。Tasks が スロットリングと リトライ制御のもと、HTTP リクエストとして Worker にプッシュする。
- Cloud Run はイベント到着時のみ起動できるため、最小インスタンス 0でコスト最適。必要なら最小インスタンスでコールドスタートを緩和。
長所/短所
- ✅ 強力な レート制御／リトライ／スケジューリング。タスク単位の可視性。
- ⚠️ Dead Letter Queue（DLQ）機能は限定的。監視/再処理設計で補う必要あり。
3.2 Pub/Sub Push × Cloud Run/Functions
ユースケース
- イベント通知、ファンアウト（複数消費者へ同一メッセージ配信）。依存を最小化した疎結合設計。
- 間欠的にイベントが来るワークロードでも ゼロスケールで費用効率良く処理。
動作ポイント
- Pub/Sub が push で HTTPS POST を送る。メッセージは Base64 データ（ラップ形式/アンラップ）を選択可。JWT による認証も設定可能。
長所/短所
- ✅ 多対多の配信、グローバルスケール、高スループット。
- ⚠️ 細かなレート制御は Cloud Tasksほどではない。順序保証は ordering keyでキー単位。
3.3 Pub/Sub Pull × 常時起動 Worker（VM/GKE 等）
ユースケース
- 大量メッセージの バッチ処理、独自の フロー制御 と ACK期限管理が必要。
動作ポイント
- ワーカーが StreamingPull/Pull API で能動取得し、処理後 ACK/NACK。
- 常時起動リソース（VM/GKE）と相性が良い。Cloud Run のゼロスケールとは設計思想が異なる。
4. Cloud Tasks と Pub/Sub の機能比較（要点）
| 観点 | Cloud Tasks | Pub/Sub |
|---|---|---|
| 配信モデル | 明示的HTTP ターゲットへ1対1プッシュ | 暗黙的イベント配信（Push/Pull, 1対多可） |
| レート制御 | キュー単位で明示的に制御 | Pushは自動調整／Pullはクライアント側フロー制御 |
| リトライ | 詳細に構成可 | 基本的なリトライ（DLQ/フィルタ等あり） |
| スケジュール | あり | なし（遅延は別途工夫） |
| 順序保証 | ベストエフォート | ordering key 単位で順序保持 |
| メッセージサイズ | 最大 1MB | 最大 10MB |
| 配信レート上限 | 500 QPS/キュー | 実質上限なし（サービス設計による） |
| 地理特性 | リージョン | グローバル |
※上記は公式比較ページの要約。詳細は原文を参照。
5. 設計の勘所・ベストプラクティス
5.1 Cloud Run と組み合わせるとき
- ゼロスケール前提なら Push（Cloud Tasks／Pub/Sub Push）を選ぶ。Pull は原則不適。
- コールドスタートを許容しない場合は 最小インスタンスでウォーム保持。課金への影響はドキュメントを要確認。
5.2 セキュリティ
- Cloud Tasks の HTTP ターゲットは IAM サービスアカウントを使った認証呼び出しが可能。
- Pub/Sub Push は JWT ベアラトークンによる認証を構成可能。受け側で検証を実装する。
5.3 信頼性/再処理
- 冪等性を担保しましょう。Cloud Tasks/ Pub/Sub は at-least-once 配信。
- Cloud Tasks の DLQは限定的。失敗タスクの処理を別途検討すべき。
6. 実装リファレンス（最小構成）
6.1 Cloud Tasks → Cloud Run（FastAPI）
- API サービス:
CloudTasksClient.create_task()で HTTP タスク作成。 - Worker: Cloud Run の FastAPI で POST を受け取り、2xx なら成功、非2xx はリトライ。
6.2 Pub/Sub Push → Cloud Run（FastAPI）
- Push 受信時のリクエストボディは Base64 エンコードされた
message.dataをデコードして処理。JWT 認証を有効化可。
6.3 Pub/Sub Pull → 常時起動 Worker
- 高レベルクライアントの StreamingPull＋非同期コールバックが推奨。ACK デッドラインの管理に留意。
7. 選定フローチャート
- Cloud Run ゼロスケールで動かしたい？ → はい → Push（Cloud Tasks / Pub/Sub Push）。
- 1対1の明示的タスク実行を制御したい？（レート/遅延/リトライの細かな設定） → はい → Cloud Tasks。
- イベントのファンアウト/多対多が必要？ → はい → Pub/Sub。Push or Pull を要件で選択。
- 高スループットのバッチ/常時起動ワーカーが前提？ → はい → Pub/Sub Pull。
8. コスト/運用の目安
- Cloud Run: 最小インスタンス > 0 ならアイドルでも課金。最小 0 ならアイドル課金なし（リクエストベース課金）。
- Cloud Tasks: タスク数/ディスパッチに応じた課金。キューでバッファして 過負荷回避が可能。
- Pub/Sub: メッセージ量・保持ストレージ・配信に応じて課金。グローバルで高スループット。
9. まとめ
- 「明示的タスク実行を厳密に制御」→ Cloud Tasks、「疎結合のイベント配信・ファンアウト」→ Pub/Sub。
- Cloud Run を活かした ゼロスケール運用は Push型が基本。Pull は常時起動基盤と組み合わせる。