Pub/Sub for IoT Ingestion

解決する課題

数万から数百万のデバイスが送るテレメトリを、ブローカの構築やスケール調整を待たずに取り込み、後段の分析・保存・通知へつなげられます。GCP の旧 IoT Core 終了後は、Pub/Sub をデバイスの入口に据えるのが標準的な取り込みパターンです。

• デバイス台数や送信頻度が読めず、バックエンドが詰まる → サブスクリプションがバッファして処理側のペースで捌く
• 一斉に起動した端末からの バースト送信 を取りこぼさず受け止めたい
• 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）配信 が基本。まれに重複 するため処理は 冪等 に作る
• メッセージ本文は大きめ（数 MB 規模）まで扱えるが、テレメトリは小さく頻度の高いものが中心
• ack 前メッセージには保持期間があり、サブスクライバー停止中も一定期間バッファされる
• ackDeadline の範囲内で ack できなければ再配信される（リース延長も可能）
• グローバルサービス: トピック/サブスクリプションは単一エンドポイントを持ち、配信はメッセージストレージポリシーに従う
• 1 トピックに 多数のサブスクリプション を付けてファンアウトできる
• 属性（attribute） にデバイス ID やリージョンなどのメタデータを載せ、後段のルーティングに使える

内部の仕組み

デバイスはまず MQTT/HTTP ブリッジ層で認証され、テレメトリがブリッジ経由で Pub/Sub トピックへ発行されます。発行されたメッセージは 分散ストレージへ複数コピーで永続化 され、その時点で各サブスクリプションのキューへ振り分けられます。後段のサブスクライバーは Pull で取得するか、Push で受信します。

• 処理に成功して ack すると、そのサブスクリプションからメッセージが削除される
• ackDeadline 内に ack できなければ 再配信（少なくとも 1 回配信。冪等処理が前提）
• 規定回数失敗すると デッドレタートピック へ退避される
• 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 で境界を作り、データの持ち出しを防止

関連サービス・比較

IoT 取り込みでは、流量が読めるなら事前確保型の Pub/Sub Lite が候補になります。自動スケールやグローバル配信が要るなら通常の Pub/Sub を選びます。

ハンズオン / CLI例

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

# 分析用サブスクリプション（Pull、ack 期限とデッドレターを設定）
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