Google Cloud 非同期処理サービスの比較

はじめに#

Google Cloud を利用して非同期処理を設計する際の主要なサービスの特徴・用途・ベストプラクティスなどを調べてまとめる。

対象サービス一覧#

1. 各サービスの詳細#

Cloud Pub/Sub#

概要

グローバルスケールの非同期メッセージングサービス。パブリッシャーはサブスクライバーを知る必要がなく、複数のサブスクライバーが同じメッセージを受信できる 「暗黙的呼び出し」 モデル。

特徴

• 配信保証: At-least-once（少なくとも1回）
• メッセージ保持: 最大31日
• スループット: 上限なし（グローバル）
• メッセージサイズ: 最大10MB
• 順序付き配信: Ordering Keyで対応可能
• Push / Pull 両方対応
• バッチインサート対応
• 複数サブスクライバー（1トピックに複数サブスクリプション）に対応

主な用途

• リアルタイムイベント処理・ストリーミング
• マイクロサービス間の疎結合な通信
• ログ集約・分析パイプライン
• データ変換・ETL
• IoTデータ収集

制限・注意点

• サブスクライバーを指定できない（送信先を制御したい場合は不向き）
• 個別タスクの管理・キャンセルは不可
• デデュープ（重複排除）は非対応

公式ドキュメント: https://docs.cloud.google.com/pubsub/docs/overview ↗

Pub/Sub バッチメッセージング・大規模スパイク対応#

Pub/Subには、高スループットと大規模スパイクに対応するための複数の機構が用意されている。Sansanが公開している事例（後述）でも、直列バッチ処理をPub/Subで並列化することで大幅な時間短縮を実現している。

① Publisher-side バッチング（送信側まとめ送り）

クライアントライブラリはデフォルトで複数メッセージを1バッチにまとめて送信する。スループット向上とコスト削減が目的。

公式: https://docs.cloud.google.com/pubsub/docs/publish-best-practices ↗

② Publisher-side フロー制御（送信側過負荷防止）

パブリッシャー自身がスパイク時にメモリ・CPU・ネットワークを圧迫しないよう、送信中リクエスト数を制限する。

公式: https://docs.cloud.google.com/pubsub/docs/flow-control-messages ↗

③ Subscriber-side フロー制御（受信側過負荷防止・スパイク吸収）

サブスクライバーが処理しきれないスパイクが来た際に、受信レートを自動的に絞ってバックプレッシャーをかける機構。コストを増やさずにスパイクを平滑化できる。

公式: https://docs.cloud.google.com/pubsub/docs/flow-control ↗
公式: https://docs.cloud.google.com/pubsub/docs/handle-spikes ↗

④ 並列度制御（Concurrency Control）

Pull サブスクライバーのストリーム数・スレッド数を設定して処理並列度を上げる。

公式: https://docs.cloud.google.com/pubsub/docs/concurrency-control ↗

⑤ Pub/Subによるバッチ直列処理の並列化パターン（Sansanの事例）

直列で実行していた重いバッチ処理を、1件1メッセージとしてPub/Subにパブリッシュし、複数のサブスクライバーが並列処理するパターン。処理件数が多いほど効果が大きい。

sequenceDiagram
    participant B as バッチトリガー<br/>（Scheduler等）
    participant P as Publisher
    participant T as Pub/Sub Topic
    participant W1 as Worker 1<br/>（Subscriber）
    participant W2 as Worker 2<br/>（Subscriber）
    participant WN as Worker N<br/>（Subscriber）
    participant DB as DB / Storage

    B->>P: バッチ起動
    loop 処理対象レコード分
        P->>T: publish(record_id)
    end
    Note over T: メッセージがキューとして機能
    par 並列処理（スパイク時もフロー制御で吸収）
        T-->>W1: メッセージ配信
        T-->>W2: メッセージ配信
        T-->>WN: メッセージ配信
    end
    W1->>DB: 処理・書き込み
    W2->>DB: 処理・書き込み
    WN->>DB: 処理・書き込み
    W1-->>T: ack
    W2-->>T: ack
    WN-->>T: ack

参考: 時間のかかっているバッチ処理をCloud Pub/Subで改善する話（Sansan Tech） ↗

⑥ スパイク時の推奨対応フロー

flowchart TD
    A[大規模スパイク発生] --> B{一時的なスパイク？}
    B -->|Yes| C[Subscriber-side フロー制御で吸収\nMaxOutstandingMessages / Bytes を調整]
    B -->|No / 継続的増大| D[フロー制御 + Subscriber オートスケール未ack メッセージ数をメトリクスにスケール]
    C --> E[処理バックログを保持期間内（最大31日）で消化]
    D --> F[インスタンス数増加でスループット向上]
    A --> G{Publisher 側が詰まる？}
    G -->|Yes| H[Publisher-side フロー制御\nMaxOutstandingMessages / Block設定]
    H --> I[DEADLINE_EXCEEDEDエラー抑制]

Cloud Tasks#

概要

タスクキューを管理し、特定エンドポイントに非同期でHTTPリクエストを配信する 「明示的呼び出し」 モデル。送信側がいつ・どこに・どのように配信するかを完全にコントロールできる。

特徴

• 配信保証: At-least-once
• タスク保持: 最大30日
• 最大配信レート: 500 qps/キュー（キュー単位で設定可能）
• タスクサイズ: 最大1MB
• 配信時刻の指定（スケジュール配信）可能
• レート制限（流量制御・スロットリング）
• 個別タスクの管理・キャンセル・再試行設定
• タスク作成時のデデュープ（重複排除）対応
• Pull配信は非対応（HTTPエンドポイントまたはApp Engineへの Push のみ）
• 複数ハンドラー配信は非対応（ 1タスク1エンドポイント ）

主な用途

• バックグラウンドジョブ（画像処理、メール送信など）
• 特定時刻に実行したい処理（24時間後にリマインダー送信など）
• 外部APIへのレート制限付きコール
• 大量タスクの流量制御（バースト防止）
• 冪等性を持つ再試行が必要な処理

制限・注意点

• 1プロジェクトあたり最大1,000キューまで（クォータ増加申請可能）
• Pull配信不可（HTTPエンドポイントまたはApp Engineへの Push のみ）
• 順序付き配信はベストエフォート（保証されない）（Pub/SubのOrdering Keyのような機能はない）
• 最大処理時間: HTTPターゲット30分（デフォルト10分）、App Engine 自動スケーリング10分・手動スケーリング最大24時間

公式ドキュメント: https://docs.cloud.google.com/tasks/docs/dual-overview ↗

Cloud Scheduler#

概要

完全マネージドなcronジョブサービス。定期的・固定スケジュールでHTTPエンドポイント、Pub/Subトピック、またはCloud Functionsを呼び出す。

特徴

• cron式でスケジュール定義 （最小粒度: 1分）
• 対象: HTTP/S エンドポイント・Pub/Subトピック・App Engine
• 失敗時のリトライ設定可能（ただし次回実行まで再実行しないのがデフォルト）
• 各ジョブ実行は同一内容（パラメータの個別制御なし）

主な用途

• 定期バッチ処理（日次・週次レポートなど）
• キャッシュ更新・データ同期
• 定期的なデータベースクリーンアップ
• ヘルスチェック・監視

制限・注意点

• 最小粒度が1分のため、秒単位のスケジューリングは不可
• 個別タスクの管理は不可（Cloud Schedulerはジョブ単位）
• 動的なスケジューリング（ユーザーアクションに応じた実行タイミング変更）は不向き

公式ドキュメント: https://docs.cloud.google.com/scheduler/docs ↗

Eventarc Standard#

概要

GCPサービスのイベントをトリガーとして、Cloud Run・Cloud Functions・Workflowsなどの宛先にルーティングするサービス。CloudEvents仕様に準拠。Pub/Subをトランスポート層として利用 。

特徴

• 130以上のGCPサービスからイベントソースとして利用可能
• イベントフィルタリングとルーティング
• CloudEvents仕様準拠
• 配信・リトライ・セキュリティ・認可を自動管理
• 宛先: Cloud Run、Cloud Functions、Workflows、GKE
• Pub/Subをトランスポート層として使用（Eventarc料金 + Pub/Sub料金）

主な用途

• GCSバケットへのファイルアップロードをトリガーとした処理
• Cloud Audit Logsに基づくリアクティブ処理
• Firebase/Firestoreのデータ変更に応じた処理
• マイクロサービス間のイベント駆動通信（GCPサービス中心）

制限・注意点

• 順序保証なし（高速な変更は予期しない順序でイベントが届く可能性）
• ハンドラーは冪等性を持つこと（At-least-once配信のため）
• リージョナルサービス（マルチリージョン対応は一部制限）
• 料金はEventarc + トランスポート層（Pub/Sub）の合算

公式ドキュメント: https://docs.cloud.google.com/eventarc/standard/docs/overview ↗

Eventarc Advanced#

概要

Eventarc Standardの上位版。複雑なイベント基盤向けの中央バス（Event Bus）型アーキテクチャ。複数ソース・複数宛先・イベント変換・フィルタリングを一元管理できる。Pub/SubトピックやKafkaキューなど多数を管理している組織向け。

特徴

• 中央バス（Event Bus）によるイベントの集中管理
• 複数プロジェクト・複数チームを跨いだイベント管理
• Enrollment（サブスクリプション）によるフィルタリング
• パイプラインによるイベント変換（Transform）
• 複数ソースから複数宛先へのファンアウト
• ハイブリッド・マルチクラウドにも対応
• 完全リージョナル（全トラフィック・データが同一リージョン内）

主な用途

• 複数チーム・複数プロジェクトを跨ぐイベント基盤構築
• IoTデータや大規模AIワークロードのイベントストリーミング
• Pub/SubトピックやKafkaキューの統合・一元管理
• マルチクラウド・オンプレミス連携

公式ドキュメント: https://docs.cloud.google.com/eventarc/advanced/docs/overview ↗

Cloud Workflows#

概要

完全マネージドなオーケストレーションプラットフォーム。Cloud Run、Cloud Functions、Google Cloud API、外部HTTP APIなど複数のサービスを定義した順序で実行・組み合わせる。状態・リトライ・エラーハンドリングを一元管理でき、最大1年間の実行継続が可能。

特徴

• サーバーレス（使用時のみ課金・アイドル時は無料）
• YAML/JSON形式で定義
• 最大実行継続期間: 1年
• ステート保持・ポーリング・コールバック対応
• 並列ステップ実行対応
• エラーハンドリング・リトライロジックをワークフロー内に記述
• 最大同時実行数: 10,000
• Eventarcトリガーで起動可能（イベント駆動対応）
• 100以上のGCPサービスに対してコネクタ提供

主な用途

• 複数GCPサービスを組み合わせたビジネスロジック実行（例: OCR→BigQuery→通知）
• 人間の承認ステップを含むワークフロー（コールバック利用）
• ETLパイプライン
• 複数APIのオーケストレーション
• 長時間実行が必要な処理（最大1年）
• マイクロサービスの依存関係を明示的に管理

制限・注意点

• 独自のYAML/JSON構文の習得が必要
• 最大同時実行数10,000（それ以上はCloud Composerを検討）
• コードや依存ライブラリを持たないためセキュリティパッチ不要だが、複雑なロジックは可読性に注意

公式ドキュメント: https://docs.cloud.google.com/workflows/docs/overview ↗

Cloud Run Jobs#

概要

処理を実行して終了する「run-to-completion」型のコンテナジョブ。Cloud Run Serviceがリクエストを待ち続けるのに対し、Jobsは処理が完了したら終了する。任意のコンテナを最大24時間実行でき、最大10,000タスクの並列実行（Array Job）にも対応。スケジュール実行・ワークフロー起動・手動実行のいずれも可能。

特徴

• 処理完了で終了（HTTPリクエスト待機なし）
• 最大タスク数: 10,000タスク（並列実行 / Array Job）
• 最大実行時間: 24時間/タスク
• タスクごとにリトライ回数を設定可能
• 各タスクは CLOUD_RUN_TASK_INDEX で自身のインデックスを把握可能
• コンテナ単位のため言語・フレームワーク非依存
• スケジュール実行: Cloud Schedulerと連携
• ワークフロー起動: WorkflowsのCloud Run Admin APIコネクタで実行可能
• Eventarcトリガーによるイベント駆動実行も可能

主な用途

• データ変換・ETLのバッチ処理
• 大量ファイルの並列処理（例: GCSの1,000画像を並列リサイズ）
• DBマイグレーション・定期クリーンアップなどの運用タスク
• バッチML推論・モデルファインチューニング
• レポート生成・定期的なデータエクスポート
• スクリプトや CLIツールのコンテナ化

Dataflowとの違い

制限・注意点

• Cloudのカナリアデプロイは非対応（Cloud Run Serviceには対応）
• ジョブ名は作成後に変更不可
• タスク間での共有状態管理は自前で実装（Cloud Storageなどを利用）
• 7日より古い実行詳細はコンソールから削除（ログはCloud Loggingに残る）

公式ドキュメント: https://docs.cloud.google.com/run/docs/create-jobs ↗

Cloud Dataflow#

概要

Apache Beam をベースとした、フルマネージドのバッチ・ストリーミングデータパイプラインサービス。単一のプログラミングモデルでバッチとストリーミングの両方を記述できる。最大4,000ワーカーVMへの自動スケール、動的ワーク再分配、Exactly-once処理保証が特徴。大規模ETL・リアルタイム分析・ML推論パイプラインに適する。

特徴

• バッチとストリーミングを統一モデル（Apache Beam）で記述
• 配信保証: Exactly-once（他サービスはAt-least-once）
• 最大4,000ワーカーVMへの自動スケール
• 動的ワーク再分配（Autoscaling・動的リバランス）
• 対応言語SDK: Java / Python / Go
• ノーコードオプション: Job Builder UI（GCPコンソール）、事前構築テンプレート
• Dataflow ML: ストリーム・バッチパイプラインへのML推論組み込み
• 豊富なI/Oコネクタ（Pub/Sub、BigQuery、GCS、Kafka、Bigtable、Spanner等）
• Apache FlinkやApache Sparkへの移行も可能（Beamパイプラインはランナー非依存）
• VPC Service Controls・CMEK対応

主な用途

• 大規模ETL（ペタバイト級のデータ変換・集計）
• Pub/Sub → BigQuery のリアルタイムストリーミングパイプライン
• ストリーミングMLパイプライン（リアルタイム推論・特徴量抽出）
• ログ・センサーデータのリアルタイム分析
• データウェアハウス（BigQuery）へのデータ投入
• CDC（Change Data Capture）イベントの処理

Cloud Run Jobsとの違い

→ 上記「Cloud Run Jobs」セクションの比較表を参照。

制限・注意点

• Apache Beam SDKの習得が必要（学習コストが高め）
• ワーカーVM起動に5〜7分かかる場合がある（テンプレート使用時）
• 小規模・単純なバッチであればCloud Run Jobsの方がコスト効率が高い
• ストリーミングジョブは継続課金（アイドルでも費用発生）

公式ドキュメント: https://docs.cloud.google.com/dataflow/docs/overview ↗

2. 比較表#

基本特性#

配信・スループット#

料金（参考）#

3. Cloud Tasks vs Pub/Sub 詳細比較（公式ドキュメントより）#

公式: https://docs.cloud.google.com/tasks/docs/comp-pub-sub ↗

4. Cloud Tasks vs Cloud Scheduler 詳細比較（公式ドキュメントより）#

公式: https://docs.cloud.google.com/tasks/docs/comp-tasks-sched ↗

5. シーケンス図#

Pub/Sub（Fan-out型）#

パブリッシャーはコンシューマーを知らない。1メッセージを複数サービスが同時に受信する。

sequenceDiagram
    participant P as Publisher
    participant T as Topic
    participant A as Consumer A
    participant B as Consumer B
    participant C as Consumer C

    P->>T: publish(message)
    T-->>A: push (Subscription A)
    T-->>B: push (Subscription B)
    T-->>C: push (Subscription C)
    A-->>T: ack
    B-->>T: ack
    C-->>T: ack

Cloud Tasks（Point-to-Point型）#

送信者が宛先・タイミング・レートを完全に制御する。1タスク1エンドポイント。

sequenceDiagram
    participant C as Caller
    participant Q as Task Queue
    participant E as Endpoint

    C->>Q: create task<br/>(url, payload, scheduleTime)
    Note over Q: レート制御・遅延・デデュープ
    Q->>E: HTTP request
    alt 成功
        E-->>Q: 200 OK (ack)
    else 失敗
        E-->>Q: 5xx / timeout
        Note over Q: 設定に従いリトライ<br/>（バックオフ・上限回数）
    end

Cloud Scheduler（定期実行型）#

Cron式で定義したスケジュールで固定的に実行する。

sequenceDiagram
    participant S as Cloud Scheduler
    participant T as Target<br/>(HTTP / Pub/Sub)

    loop 定期実行（例: 毎日0時）
        S->>T: invoke
        alt 成功
            T-->>S: 200 OK
        else 失敗
            T-->>S: error
            Note over S: ログ記録<br/>（次回スケジュールまで待機）
        end
    end

Eventarc Standard（イベント駆動型）#

GCPサービスのイベントをトリガーとして、フィルタリングして宛先にルーティングする。

sequenceDiagram
    participant G as GCS / Audit Logs / etc.
    participant P as Pub/Sub<br/>(トランスポート層)
    participant E as Eventarc<br/>(フィルタ・ルーティング)
    participant R as Cloud Run /<br/>Cloud Functions /<br/>Workflows

    G->>P: イベント発生
    P->>E: メッセージ配信
    Note over E: トリガー条件でフィルタリング
    E->>R: CloudEvents形式でルーティング
    R-->>E: ack

Eventarc Advanced（イベントバス型）#

複数ソースからのイベントを中央バスで集約し、変換・フィルタリングして複数宛先に配信する。

sequenceDiagram
    participant PA as Publisher A
    participant PB as Publisher B
    participant PC as Publisher C
    participant BUS as Event Bus
    participant PIPE as Pipeline<br/>(変換・フィルタ)
    participant D1 as 宛先 A
    participant D2 as 宛先 B

    PA->>BUS: publish event
    PB->>BUS: publish event
    PC->>BUS: publish event
    Note over BUS: Enrollment（サブスクリプション）で照合
    BUS->>PIPE: マッチしたイベント
    Note over PIPE: フィルタ・スキーマ変換
    PIPE->>D1: ルーティング
    PIPE->>D2: ルーティング

Cloud Workflows（オーケストレーション型）#

複数のサービスをステップとして定義し、状態・エラーハンドリング・リトライを一元管理する。

sequenceDiagram
    participant TR as Trigger<br/>(Scheduler / Eventarc / HTTP)
    participant WF as Workflows
    participant CR as Cloud Run
    participant BQ as BigQuery
    participant CB as Callback<br/>(人間承認)
    participant NT as 通知サービス

    TR->>WF: 実行開始
    WF->>CR: Step1: API呼び出し
    CR-->>WF: レスポンス
    WF->>BQ: Step2: INSERT
    BQ-->>WF: 完了
    WF->>CB: Step3: 承認待ち（コールバック）
    Note over WF,CB: 最大1年間待機可能
    CB-->>WF: 承認イベント受信
    par Step4: 並列実行
        WF->>CR: 並列タスク A
        WF->>BQ: 並列タスク B
    end
    WF->>NT: Step5: 完了通知
    alt エラー発生時
        WF->>NT: エラー通知・ロールバック処理
    end

Cloud Run Jobs（run-to-completion型）#

処理を実行して終了するコンテナジョブ。Array Jobで複数タスクを並列実行できる。

sequenceDiagram
    participant TR as Trigger<br/>(Scheduler / Workflows / 手動)
    participant CR as Cloud Run Jobs
    participant T0 as Task 0
    participant T1 as Task 1
    participant TN as Task N
    participant GCS as Cloud Storage

    TR->>CR: 実行開始（タスク数・パラメータ指定）
    Note over CR: Array Job: N タスクを並列起動
    par 並列実行
        CR->>T0: CLOUD_RUN_TASK_INDEX=0
        CR->>T1: CLOUD_RUN_TASK_INDEX=1
        CR->>TN: CLOUD_RUN_TASK_INDEX=N
    end
    T0->>GCS: 処理結果を書き込み
    T1->>GCS: 処理結果を書き込み
    TN->>GCS: 処理結果を書き込み
    T0-->>CR: 完了（exit 0）
    T1-->>CR: 完了（exit 0）
    TN-->>CR: 完了（exit 0）
    Note over CR: 全タスク完了でジョブ成功
    alt タスク失敗時
        CR->>T0: リトライ（設定回数まで）
    end

Cloud Dataflow（パイプライン型）#

Apache Beamパイプラインを分散実行。バッチとストリーミングを同一モデルで処理。

sequenceDiagram
    participant SRC as Source<br/>(Pub/Sub / GCS / BigQuery)
    participant DF as Dataflow<br/>（ワーカーVM群）
    participant W1 as Worker 1
    participant W2 as Worker 2
    participant WN as Worker N
    participant SNK as Sink<br/>(BigQuery / GCS / Bigtable)

    SRC->>DF: データ投入
    Note over DF: パイプライン定義に従い<br/>ワークを自動シャーディング
    par 並列処理（自動リバランス）
        DF->>W1: PTransform（変換・集計）
        DF->>W2: PTransform（変換・集計）
        DF->>WN: PTransform（変換・集計）
    end
    W1-->>DF: 処理済みデータ
    W2-->>DF: 処理済みデータ
    WN-->>DF: 処理済みデータ
    Note over DF: Shuffle / GroupByKey / Windowing
    DF->>SNK: 書き込み（Exactly-once）
    Note over DF: ストリーミングの場合は継続実行<br/>バッチの場合はジョブ完了で終了

6. 運用のしやすさ#

7. 非機能要件#

可用性・信頼性#

スケーラビリティ#

8. ユースケース別の選択ガイド#

「どれを使うか」の判断フロー#

処理を非同期化したい
│
├── 定期的・固定スケジュールで実行したい
│   └── Cloud Scheduler
│
├── GCPサービスのイベント（GCS更新・DBの変更など）に反応したい
│   ├── シンプルなルーティング → Eventarc Standard
│   └── 複数ソース・複数宛先・イベント変換が必要 → Eventarc Advanced
│
├── 複数のサービスを順番に組み合わせて実行したい（状態・リトライ管理も）
│   └── Cloud Workflows
│
├── 1つのメッセージを複数のサービスに並行配信したい
│   └── Cloud Pub/Sub（Fan-out）
│
├── 特定エンドポイントへの配信でレート制御・スケジュール・リトライを細かく管理したい
│   └── Cloud Tasks
│
├── 大規模なデータパイプライン・ETL・ストリーミング処理
│   ├── Pub/Sub → BigQuery などシンプルなデータ移動 → Dataflow テンプレート
│   └── 複雑な変換・集計・ストリーム分析 → Dataflow (Apache Beam)
│
└── コンテナで任意の処理を実行して終了させたい（バッチ・スクリプト）
    ├── 小〜中規模・汎用バッチ → Cloud Run Jobs
    └── PB級・高スループット・Exactly-once必須 → Dataflow

よくある構成パターン#

Cloud Run Jobs vs Dataflow の選択基準#

9. 組み合わせ利用#

これらのサービスは排他的ではなく、組み合わせて使用できる。

• Cloud Scheduler + Pub/Sub: 定期的にPub/Subにメッセージをパブリッシュし、複数のコンシューマーに配信
• Cloud Scheduler + Cloud Run Jobs: cron起動で任意のコンテナバッチを定期実行
• Cloud Scheduler + Workflows: 定期的にWorkflowsを起動してオーケストレーション実行
• Cloud Tasks + Workflows: Cloud TasksでWorkflowsの実行をバッファリング・レート制御（公式チュートリアル ↗）
• Eventarc + Workflows: イベント（例: GCS更新）をトリガーにWorkflowsを起動
• Eventarc + Cloud Run Jobs: GCSファイル追加などのイベントでCloud Run Jobsを起動
• Workflows + Cloud Run Jobs: Workflowsのステップとして Cloud Run Jobsを実行（公式チュートリアル ↗）
• Pub/Sub + Dataflow: Pub/Subをソースとしてリアルタイムストリーミングパイプラインを構築
• Pub/Sub + Eventarc: Pub/Subをイベントソースとして、Eventarcでルーティング

参考リンク#

公式ドキュメント#

• Cloud Tasks vs Pub/Sub の選択 ↗
• Cloud Tasks vs Cloud Scheduler の比較 ↗
• Pub/Sub バッチ・フロー制御 ベストプラクティス（Publisher） ↗
• Pub/Sub フロー制御 ベストプラクティス（Subscriber） ↗
• Pub/Sub — スパイクのフロー制御 ↗
• Pub/Sub — 同時実行制御 ↗
• Pub/Sub — 信頼性入門 ↗
• Cloud Scheduler ドキュメント ↗
• Eventarc ドキュメント ↗
• Eventarc Standard vs Advanced の選択 ↗
• Cloud Workflows ドキュメント ↗
• Workflows vs Cloud Composer の選択 ↗
• Cloud Run Jobs — ジョブの作成 ↗
• Cloud Run Jobs — ジョブの実行 ↗
• Dataflow テンプレート ↗
• Workflows × Cloud Run Jobs チュートリアル ↗
• Eventarc 料金 ↗

参考記事#

• GCP Event-Driven Architectures: Pub/Sub, Eventarc, or Cloud Tasks ↗
• GCP Application Integration: Pub/Sub, Eventarc, or Workflows? ↗
• Google Cloud Pub/Sub vs Eventarc: Understanding the Differences (RisingWave) ↗
• How to Choose Between Pub/Sub and Cloud Tasks for Async Processing on GCP (OneUptime) ↗
• Triggering Workflows with Eventarc (Google Codelabs) ↗
• 時間のかかっているバッチ処理をCloud Pub/Subで改善する話（Sansan Tech） ↗
• Testing Cloud Pub/Sub clients to maximize streaming performance（Google Cloud Blog） ↗