GCP で非同期処理やイベント駆動の設計を考えると、Pub/Sub 以外にも Cloud Tasks、Eventarc、Cloud Scheduler、Dataflow、BigQuery、Cloud Storage などが登場します。
これらは似た文脈で登場しますが、Pub/Sub との関係は2種類に分かれます。Cloud Tasks のように「Pub/Sub とどちらを使うか」を比較して選ぶサービスと、Dataflow のように Pub/Sub の上流や下流に組み合わせて使うサービスです。
この記事では、周辺サービスをこの2つに分類したうえで、GCP Pub/Sub との役割分担を整理します。
Pub/Sub そのものの基本は『Pub/Subとは何か』で扱っています。
Pub/Subの役割
Pub/Sub は、イベントやメッセージを受け渡すためのメッセージング基盤です。
Publisher
↓
Topic
↓
Subscription
↓
Subscriber主な役割は以下です。
- Publisher と Subscriber を疎結合にする
- メッセージを一時的に保持する
- 下流処理の障害や遅延を上流から切り離す
- 1つのイベントを複数の処理に配る
- ストリーミング処理の入口になる
Pub/Sub は、保存先でも、変換処理基盤でも、ワークフローエンジンでもありません。
周辺サービスは「比較する」か「組み合わせる」かで分ける
周辺サービスを検討するときは、まずそのサービスが Pub/Sub の代替候補なのか、Pub/Sub と役割分担する部品なのかを分けます。
| Pub/Subとの関係 | サービス | 考え方 |
|---|---|---|
| どちらを使うか比較する | Cloud Tasks、Eventarc、Workflows | Pub/Sub か そのサービス か を選ぶ |
| 組み合わせて使う | Cloud Scheduler、Dataflow、BigQuery、Cloud Storage | Pub/Sub と そのサービスで役割分担する |
以降、この分類に沿って1つずつ見ていきます。
Pub/Subとどちらを使うか比較するサービス
このグループのサービスは、Pub/Sub と用途が重なる 代替候補 です。「Pub/Sub か、そのサービスか」を比較して、どちらか一方を選びます。
Pub/SubかCloud Tasksか
Cloud Tasks は、Pub/Sub とどちらを使うかを比較して選ぶ関係にあります。どちらも非同期処理で使われますが、設計思想が違います。
| 観点 | Pub/Sub | Cloud Tasks |
|---|---|---|
| 主な用途 | イベント配信、ファンアウト、メッセージング | 特定エンドポイントへのタスク実行 |
| 呼び出し | Publisher は Subscriber を知らない | タスク作成側が実行先を指定する |
| 配信先 | 複数 Subscription に配れる | 基本的に指定した1つのターゲット |
| 向いている処理 | 1つのイベントを複数用途に使う処理 | 1つのジョブを確実に実行する処理 |
| 制御 | Subscriber 側に寄る | キュー側でレートやスケジュールを制御しやすい |
Pub/Sub は、Publisher が Subscriber を知らない 暗黙的な呼び出し に向いています。
Cloud Tasks は、どのエンドポイントにいつ実行させるかを明示する 明示的な呼び出し に向いています。
判断軸は以下です。
- Pub/Sub を選びやすい場合
- 同じイベントを複数の処理に配りたい
- Publisher と Subscriber を強く疎結合にしたい
- ストリーミングやイベント配信が主目的である
- Cloud Tasks を選びやすい場合
- 特定のHTTPエンドポイントにタスクを実行させたい
- レート制御や実行タイミングを細かく制御したい
- 1対1のジョブ実行に近い
注文作成イベントをメール送信、分析保存、在庫更新に配るなら Pub/Sub が自然です。
特定の決済確認APIを後で1回叩くタスクを積むなら Cloud Tasks が自然です。
Pub/SubかEventarcか
Eventarc は、GCP サービスやアプリケーションから発生するイベントを、Cloud Run などの宛先にルーティングするサービスです。
Pub/Sub とは、イベントの発生源がどこかで使い分ける関係にあります。アプリケーションが自分で発行するイベントなら Pub/Sub、GCP サービスが発生させるイベントなら Eventarc です。
| 観点 | Pub/Sub | Eventarc |
|---|---|---|
| 役割 | 汎用メッセージング | イベントのルーティングとトリガー |
| 主な入力 | アプリ、サービス、デバイスなど任意のPublisher | GCPサービスイベント、カスタムイベントなど |
| 主な出力 | Subscription を通じたSubscriber | Cloud Run などのイベント宛先 |
| 設計の中心 | Topic と Subscription | Trigger と Event provider |
判断軸は以下です。
- Pub/Sub を選びやすい場合
- アプリケーションが明示的にイベントを publish する
- Topic と Subscription を中心に設計したい
- 1つのイベントを複数用途へ配りたい
- Eventarc を選びやすい場合
- Cloud Storage や Audit Logs などのGCPイベントをトリガーにしたい
- Cloud Run へイベント駆動でつなぎたい
- イベントプロバイダと宛先をトリガーとして管理したい
Cloud Storage へのファイルアップロードを合図に、Cloud Run のサムネイル生成を起動するなら Eventarc が自然です。
アプリケーションが発行する注文作成イベントを、メール送信や分析保存に配るなら Pub/Sub が自然です。
Pub/SubかWorkflowsか
Workflows は、複数ステップの処理を順番や条件分岐つきで実行するためのサービスです。
Pub/Sub と機能が重なるわけではありませんが、「非同期の処理フローをどう組むか」という同じ問いに対する別の設計方針になるため、比較して選ぶ関係にあります。Pub/Sub は状態管理を持ったワークフローエンジンではありません。
判断軸は以下です。
- Pub/Sub を選びやすい場合
- メッセージ単位で独立した処理を動かしたい
- 処理同士を疎結合にしたい
- ファンアウトが重要
- Workflows を選びやすい場合
- 複数ステップの順序を管理したい
- 条件分岐やエラー時の補償処理が必要
- 1つの業務フローとして状態を追いたい
「与信確認 → 請求 → 発送指示」のように順序があり、途中で失敗したら巻き戻し（補償処理）が必要な業務フローなら Workflows が自然です。
注文作成イベントを受けて、メール送信・分析保存・在庫更新がそれぞれ独立して動けばよいなら Pub/Sub が自然です。
Pub/Sub で複雑な状態遷移を自前実装し始めたら、Workflows のようなオーケストレーション基盤を検討します。
Pub/Subと組み合わせて使うサービス
このグループのサービスは、Pub/Sub の代替候補ではありません。Pub/Sub の上流・下流・隣に置いて役割分担する関係にあり、「どちらを使うか」ではなく「どうつなぐか」を考えます。
Cloud Scheduler + Pub/Sub（上流に置いて定期起動する）
Cloud Scheduler は、定期実行のためのサービスです。Pub/Sub は定期実行そのものを管理するサービスではないため、両者は競合しません。
Cloud Scheduler の実行先として Pub/Sub を上流に組み合わせる構成がよく使われます。
Cloud Scheduler
↓ publish
Pub/Sub
↓
Workerこの構成では、Cloud Scheduler が時刻管理を担当し、Pub/Sub が後続処理への受け渡しを担当します。
役割分担は以下です。
- Cloud Scheduler が担うこと
- 毎日、毎時、毎分などの定期起動
- cron のような時刻指定
- Pub/Sub が担うこと
- 定期起動後の処理を複数に配る
- Worker 障害時にメッセージを保持する
- 定期実行の起点と処理側を疎結合にする
たとえば、毎朝6時に日次集計を起動し、その結果を複数の Worker に処理させたい場合、Cloud Scheduler が毎朝6時に Pub/Sub へ publish し、Pub/Sub が複数の Subscription へ配ります。
Cloud Scheduler は時計です。Pub/Sub はメッセージの受け渡しです。
Pub/Sub + Dataflow（下流に置いてストリーム処理する）
Dataflow は、Pub/Sub とどちらかを選ぶ関係ではありません。Pub/Sub の下流に組み合わせて、ストリーム処理を担当させるサービスです。
Pub/Sub
↓
Dataflow
↓
BigQueryこの構成では、Pub/Sub はメッセージの入口です。Dataflow はストリーム処理の実行基盤です。
| 観点 | Pub/Sub | Dataflow |
|---|---|---|
| 役割 | メッセージを受け渡す | データを変換・集計・処理する |
| 得意なこと | バッファ、疎結合、ファンアウト | ウィンドウ集計、変換、重複排除、ETL |
| 単独利用 | メッセージングとして使える | 入力元と出力先が必要 |
| 典型構成 | Topic と Subscription | Pub/Sub から読み、BigQuery などへ書く |
Pub/Sub はデータを運ぶ層です。Dataflow はデータを処理する層です。
Dataflow は、Pub/Sub のように「メッセージを受け渡す場所」として単体で使うサービスではありません。Dataflow のパイプラインは、Pub/Sub、Cloud Storage、BigQuery などの入力元からデータを読み、変換・集計して、BigQuery や Cloud Storage などの出力先へ書き込みます。
ここで考えるのは「Pub/Sub か Dataflow か」ではなく、Pub/Sub の下流に Dataflow を置くかどうかです。
- Pub/Sub から直接 Worker に渡せば足りる場合
- メッセージをそのまま Worker に渡せばよい
- 1件ずつ軽い処理をすればよい
- 下流に Dataflow を置く場合
- ストリームの変換が必要
- ウィンドウ集計が必要
- BigQuery や Cloud Storage へ継続的に整形して保存したい
クリックストリームを1分単位のウィンドウで集計して BigQuery に書き込むなら、Pub/Sub の下流に Dataflow を置きます。
注文作成イベントを受けてメールを1通送るだけなら、Dataflow を挟まず Worker が直接処理すれば十分です。
Pub/Sub + BigQuery（下流に置いて保存・分析する）
BigQuery は分析用のDWHです。Pub/Sub は分析クエリを実行する場所ではないため、両者は競合しません。
Pub/Sub の下流に BigQuery を組み合わせて、イベントの保存・分析を担当させます。
Pub/Sub
↓
BigQueryこの構成では、Pub/Sub はイベントを流す入口で、BigQuery は保存・分析する場所です。
役割分担は以下です。
- Pub/Sub が担うこと
- イベントやログをリアルタイムに受ける
- 下流の保存処理とProducerを切り離す
- BigQuery が担うこと
- 保存したデータをSQLで分析する
- ダッシュボードやレポートの元データにする
たとえば、アプリの行動ログを Pub/Sub で受けて BigQuery に流し込み、翌朝のダッシュボードで前日分を集計する構成です。
Pub/Sub はクエリできる保存先ではありません。
分析したいなら、最終的には BigQuery などの保存先に流します。
Cloud Storage + Pub/Sub（本体の保存と参照の通知で分担する）
Cloud Storage はオブジェクト保存先です。Pub/Sub はファイル本体を長期保存する場所ではないため、両者は競合しません。
巨大なファイルを扱う場合は、ファイル本体を Cloud Storage に置き、Pub/Sub にはファイルの参照情報を流す、という役割分担で併用する構成が自然です。
Cloud Storage
↓ object path
Pub/Sub
↓
WorkerPub/Sub メッセージには、たとえば以下のような情報を入れます。
{
"event_type": "file.uploaded",
"bucket": "example-bucket",
"object": "uploads/order-123.csv"
}役割分担は以下です。
- Cloud Storage が担うこと
- ファイル本体を保存する
- 後から再処理できるように生データを残す
- Pub/Sub が担うこと
- ファイルが置かれたことを下流へ知らせる
- ファイル処理を非同期で起動する
Storage は置き場所です。Pub/Sub は通知と受け渡しです。
まとめ
GCP で Pub/Sub 周辺のサービスを選ぶときは、まず「どちらを使うか比較するサービス」と「組み合わせて使うサービス」を分けます。
| サービス | Pub/Subとの関係 | 主な役割 |
|---|---|---|
| Cloud Tasks | 比較して選ぶ | 特定エンドポイントへのタスク実行 |
| Eventarc | 比較して選ぶ（イベントの発生源で使い分け） | GCPサービスイベントのルーティング |
| Workflows | 比較して選ぶ（設計方針の違い） | 複数ステップの状態を管理する |
| Cloud Scheduler | 組み合わせる（Pub/Subの上流） | 定期時刻に起動する |
| Dataflow | 組み合わせる（Pub/Subの下流） | Pub/Sub から読み、ストリームを変換・集計する |
| BigQuery | 組み合わせる（Pub/Sub・Dataflowの下流） | 分析用に保存する |
| Cloud Storage | 組み合わせる（本体保存と参照通知の分担） | ファイル本体や生データを保存する |
Pub/Sub は、非同期処理の中心になりやすいサービスです。
ただし、何でも Pub/Sub に寄せるのではなく、メッセージング、タスク実行、イベントルーティング、ストリーム処理、保存、ワークフロー管理を分けて考えると設計しやすくなります。