Pub/Sub for IoT Ingestion

解決する課題

Pub/Subへ直接つなぐ構成は、工場や拠点内の多数のセンサーを 数十〜数百台程度の集約ゲートウェイへまとめられる場合に向きます。各ゲートウェイが REST または gRPC でテレメトリを発行し、後段の分析・保存・通知へ疎結合に渡します。端末ごとのMQTT接続や台帳管理が必要な大規模フリートには、別途ブローカまたはIoTプラットフォームが必要です。

• デバイス台数や送信頻度が読めず、バックエンドが詰まる → サブスクリプションがバッファして処理側のペースで捌く
• 一斉に起動した端末からの バースト送信 を取りこぼさず受け止めたい
• 1 件のテレメトリを リアルタイム分析・長期保存・アラート など複数系統へ同報したい
• デバイスは MQTT や HTTP しか話せない → プロトコルブリッジで Pub/Sub に橋渡しする
• リージョンをまたぐ広域デバイス群でも 同一エンドポイント で受けたい（グローバルサービス）

主要概念と用語

• テレメトリ（Telemetry）: デバイスが定期送信するセンサー値や状態などの計測データ
• 取り込み（Ingestion）: デバイスからのデータをクラウド側の入口で受け止める工程。ここを Pub/Sub が担う
• トピック（Topic）: テレメトリの発行先。デバイス種別や用途ごとに分けることが多い
• サブスクリプション（Subscription）: トピックに紐づく受け取り口。1 トピックに複数付けるとファンアウトになり、分析・保存・通知へ同報できる
• プロトコルブリッジ（Protocol bridge）: MQTT や HTTP で送るデバイスと Pub/Sub の間を仲介する層。パートナー製 IoT プラットフォームや自前のゲートウェイで構成する
• デバイス認証: 端末ごとの資格情報（証明書やトークン）で送信元を識別する仕組み。Pub/Sub 手前のブリッジ層で行うのが一般的
• 確認応答（ack）と ackDeadline: 取得したメッセージを処理し終えたら ack。期限内に ack しないと 再配信 される
• デッドレタートピック（Dead-letter topic）: 規定回数失敗したメッセージの退避先
• Pub/Sub サブスクリプション直送: サブスクライバーのコードを書かずに、BigQuery / Cloud Storage へメッセージを直接取り込む形式

仕様・制限・クォータ

• 少なくとも 1 回（at-least-once）配信 が基本。まれに重複 するため処理は 冪等 に作る
• 1 メッセージのデータは最大 10 MB、属性は最大 100 個。小さなメッセージでもスループットは 1 kB 単位で計測されるため、必要に応じてバッチ化する
• 未確認メッセージの保持は既定 7 日、設定範囲は 10 分〜31 日。31 日間利用されないサブスクリプションは既定で期限切れになる
• ackDeadline は既定 10 秒、設定範囲は 10〜600 秒。期限内に処理できなければ再配信されるため、クライアントライブラリで期限を延長する
• 正確に 1 回は Pull / StreamingPull で明示的に有効化し、購読処理を単一リージョンへ固定した場合に限る。Push・BigQuery・Cloud Storage の各サブスクリプションは少なくとも 1 回配信
• グローバルサービス: トピック/サブスクリプションは単一エンドポイントを持ち、配信はメッセージストレージポリシーに従う
• 1 トピックに 多数のサブスクリプション を付けてファンアウトできる
• 属性（attribute） にデバイス ID やリージョンなどのメタデータを載せ、後段のルーティングに使える

内部の仕組み

横にスクロール

現場のセンサーはローカルプロトコルで集約ゲートウェイへ送り、ゲートウェイが REST または gRPC で Pub/Sub トピックへ発行します。外部IdPが使える場合はWorkload Identity連携で短期資格情報を取得し、使えない場合だけサービスアカウント鍵を安全に保管します。受理されたメッセージは各サブスクリプションへ分岐し、後段が Pull、Push、BigQuery直送、Cloud Storage直送で処理します。

• 処理に成功して ack すると、そのサブスクリプションからメッセージが削除される
• ackDeadline 内に ack できなければ 再配信（少なくとも 1 回配信。冪等処理が前提）
• 規定回数失敗すると デッドレタートピック へ退避される。ただし試行回数は概算で、5〜100 回の範囲を設定しても転送はベストエフォート
• BigQuery / Cloud Storage サブスクリプションを使うと、サブスクライバーのコードなしで取り込み先へ直送される

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

• ブリッジ → Pub/Sub → 分岐: ブリッジで受けたテレメトリを 1 トピックに集約し、複数サブスクリプションで分析・保存・通知へファンアウト
• ストリーミング処理: リアルタイム集計や異常検知は Dataflow（Apache Beam） を Pub/Sub の後段に置く
• 長期保存: 生データは Cloud Storage サブスクリプション、構造化分析は BigQuery サブスクリプション で直送し、中継 ETL を省く
• コマンド送信（下り）: デバイスへの制御指示は、別トピック経由でゲートウェイへ配り、ブリッジから端末へ届ける
• 属性でルーティング: デバイス種別やリージョンを属性に載せ、後段で振り分ける
• デッドレタートピックで取り込み失敗を退避し、形式不正や権限エラーを調査・再投入

運用・監視

• Cloud Monitoring のメトリクスで滞留を監視:
  • 未配信メッセージ数（バックログの増加はサブスクライバー不足やダウンストリーム障害の兆候）
  • 最古の未 ack メッセージの経過時間（処理遅延の指標）
• バックログ急増 → サブスクライバー不足や ダウンストリーム障害、ack 失敗を疑う
• デッドレタートピックに溜まる → メッセージ形式 / 権限（IAM）/ 処理ロジック を確認
• デバイス側の 送信成功率やブリッジの可用性 も併せて監視し、入口での取りこぼしを防ぐ
• シーク（Seek） はスナップショットまたは保持範囲内の時刻を指定して巻き戻す。確認済みメッセージを時刻指定で再処理する場合は保持設定も有効にする

コスト

課金はおもに メッセージのスループット量（取り込み・配信・保持のデータ量） に対して発生します。IoT では小さなメッセージが高頻度で届くため、最小課金メッセージサイズの考え方と総件数が効いてきます。

セキュリティ

• デバイス認証はブリッジ層で: 端末ごとの証明書やトークンで送信元を識別し、Pub/Sub には認証済みの経路だけ発行させる
• IAM でトピック/サブスクリプション単位の権限を最小化（発行はブリッジ、購読は後段サービスに限定）
• ブリッジや後段サービスには サービスアカウント を使い、鍵のハードコードを避ける
• 転送中は TLS、保存時は Google 管理鍵で既定暗号化。要件次第で CMEK（Cloud KMS の顧客管理鍵） を指定
• VPC Service Controls で境界を作り、データの持ち出しを防止

関連サービス・比較

Pub/Sub Lite は廃止予定で、新規利用はできません。既存利用者も 2027 年 1 月 31 日までに通常の Pub/Sub または Google Cloud Managed Service for Apache Kafka へ移行します。新しい IoT 取り込みで事前確保型の Lite を選ばないでください。

ハンズオン / CLI例

# テレメトリ用トピックを作成
gcloud pubsub topics create device-telemetry

# デッドレター転送先も先に作成
gcloud pubsub topics create telemetry-dlq

# 分析用サブスクリプション（Pull、ack 期限とデッドレターを設定）
# 実運用ではPub/Subサービスエージェントへ必要な転送権限も付与する
gcloud pubsub subscriptions create telemetry-analytics \
  --topic=device-telemetry \
  --ack-deadline=30 \
  --dead-letter-topic=telemetry-dlq \
  --max-delivery-attempts=5

# 長期保存はもう 1 本サブスクリプションを生やしてファンアウト
gcloud pubsub subscriptions create telemetry-archive --topic=device-telemetry

# デバイスからの 1 件を擬似的に発行（属性にデバイス ID を付与）
gcloud pubsub topics publish device-telemetry \
  --message='{"temp":24.5}' \
  --attribute=device_id=sensor-001,region=asia

# 取り込んだメッセージを取得して即 ack（確認）
gcloud pubsub subscriptions pull telemetry-analytics --auto-ack --limit=10