Pub/Sub Lite

解決する課題

• 流量がおおむね読めるワークロードで、メッセージングのコストを予測・最適化したい
• 通常の Pub/Sub の従量課金ではなく、事前に確保したキャパシティに対して支払う形にしたい
• 高スループットのストリーム取り込みを、パーティション設計を自分で握りながら安く回したい
• Kafka 的なパーティション + オフセットのモデルに慣れたチームで、運用負荷の小さい代替を探している

主要概念と用語

• トピック / サブスクリプション: メッセージの宛先がトピック、そこから読み出す口がサブスクリプション。通常の Pub/Sub と用語は共通だが、内部モデルとキャパシティの考え方が異なる
• パーティション: トピックを構成する並列単位。スループットはパーティション数に比例し、1 パーティション内では順序が保たれる。Kafka のパーティションに相当する
• キャパシティ（スループット予約）: パーティションごとにパブリッシュ / サブスクライブのスループット上限とストレージを事前に確保する。従量ではなく確保したキャパシティに対して課金される
• オフセット: パーティション内でのメッセージ位置。サブスクライバーは確認応答に加えてコミット済みオフセットで読み取り位置を管理する。Kafka 的な再読み込みがしやすい
• ゾーン / リージョン Lite: 配置単位として単一ゾーン型とリージョン型がある。リージョン型は複数ゾーンに複製され可用性が高い。通常の Pub/Sub のグローバル配信とはここが大きく異なる
• 予約 (Reservation): 複数トピックでスループットキャパシティを共有・管理するための単位。トピック個別に持たせる代わりに予約へ束ねて運用できる
• 保持期間 / バックログ: メッセージを保持する期間とストレージ。サブスクライバーが遅れても保持期間内は読み直せる

仕様・制限・クォータ

• スループットはパーティション数 × 1 パーティションあたりの確保キャパシティで決まる。流量に応じて自動拡張する通常の Pub/Sub と違い、容量はユーザーが設計する
• メッセージ順序はパーティション内で保証される。順序が必要なら同じキーを同じパーティションへ振り分ける
• 配信は**At-least-once（最低 1 回）**が基本で、受信側は重複に耐える設計が前提
• 配置はゾーンまたはリージョン単位で、通常の Pub/Sub のようなグローバル配信ではない。プロデューサ / コンシューマと同一ロケーションに置くのが基本
• パーティション数やキャパシティ、メッセージサイズ、保持期間には上限がある。具体的な数値や上限は変動するため、最新の公式ドキュメントで確認すること

内部の仕組み

Pub/Sub Lite は、トピックを複数のパーティションに分割して保持します。各パーティションは追記ログとして動作し、パブリッシュされたメッセージは末尾に追記され、サブスクライバーはオフセットで位置を進めながら読み出します。この構造は Apache Kafka に近く、同一パーティション内では順序が維持されます。

スループットとストレージは事前に確保したキャパシティの範囲で提供され、確保量を超えるパブリッシュやサブスクライブはスロットリングされます。通常の Pub/Sub が流量に応じて内部で自動スケールするのに対し、Lite は設計したキャパシティが上限になる点が本質的な違いです。

配置はゾーンまたはリージョンに固定され、リージョン型では複数ゾーンへ複製して単一ゾーン障害に耐えます。プロデューサ・コンシューマと同じロケーションに配置することで、ロケーション跨ぎのデータ転送と遅延を抑えます。

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

• 流量が読めるワークロードに絞って採用する。スパイクが激しく予測しにくい場合は、自動スケールする通常の Pub/Sub の方が運用が楽になりやすい
• パーティション数はピーク時スループットから逆算して決め、順序が必要なメッセージは順序キーで同一パーティションへ寄せる
• 複数トピックを運用するなら予約 (Reservation) でキャパシティを束ね、トピックごとの過不足をならして無駄な確保を減らす
• ストリーム処理は Dataflow（Apache Beam の Pub/Sub Lite コネクタ） と組み合わせ、変換・集計・BigQuery 等への書き込みを担わせる
• 受信側は冪等に設計し、At-least-once 由来の重複に耐える。再処理はオフセットを巻き戻して行う
• プロデューサ・コンシューマ・Lite トピックを同一ロケーションに揃え、ロケーション跨ぎの遅延と転送を避ける

運用・監視

• Cloud Monitoring でパブリッシュ / サブスクライブのスループットとキャパシティ使用率を監視し、確保量に対して頭打ちになっていないかを確認する
• バックログ（未処理メッセージ量）と最古メッセージの経過時間を追い、コンシューマが追いつけているかを把握する。増え続ける場合はパーティション数かキャパシティの不足を疑う
• キャパシティはトピック / 予約の設定変更で見直す。常時頭打ちならキャパシティ増、慢性的に余るなら縮小してコストを最適化する
• 操作ログは Cloud Logging に記録され、設定変更や障害の監査に使える
• 単一ゾーン型はゾーン障害の影響を直接受けるため、可用性要件が高ければリージョン型を選ぶ

コスト

セキュリティ

• サービスアカウントでパブリッシュ / サブスクライブ権限を付与し、認証情報のハードコードを避ける（AWS の IAM ロール相当の考え方）
• IAM でパブリッシャーとサブスクライバーの権限を分離し、最小権限で付与する
• 保存データは Google 管理鍵で既定暗号化され、要件に応じて CMEK（顧客管理鍵, Cloud KMS） を適用できる
• データ流出対策として VPC Service Controls を組み合わせ、境界外への持ち出しを制限する

関連サービス・比較

ハンズオン / CLI例

# 1) Lite の予約（スループットキャパシティの管理単位）を作成
gcloud pubsub lite-reservations create my-reservation \
  --location=asia-northeast1 \
  --throughput-capacity=4

# 2) 予約に紐づく Lite トピックを作成（パーティション数を指定）
gcloud pubsub lite-topics create my-lite-topic \
  --location=asia-northeast1 \
  --partitions=2 \
  --per-partition-bytes=30GiB \
  --throughput-reservation=my-reservation

# 3) Lite サブスクリプションを作成
gcloud pubsub lite-subscriptions create my-lite-sub \
  --location=asia-northeast1 \
  --topic=my-lite-topic

# 4) 作成したトピック/サブスクリプションを確認
gcloud pubsub lite-topics list --location=asia-northeast1
gcloud pubsub lite-subscriptions list --location=asia-northeast1