ClearBlade IoT Core

解決する課題

多数の IoT デバイスを安全に接続し、認証・接続管理・テレメトリ取り込みをマネージドに任せられます。Google が提供していた Cloud IoT Core は終了しましたが、その互換後継として ClearBlade IoT Core が Google Cloud 上で同等の役割を担います。

• 大量デバイスからのテレメトリを MQTT / HTTP で安全に受けたい（個別のブローカ運用なしで）
• デバイスごとに 証明書ベースの認証 を行い、なりすましを防ぎたい
• クラウドからデバイスへ 設定（config）やコマンド を配信したい
• 受信データを Pub/Sub に流し、後段の分析・保存・処理へつなぎたい
• 終了した Cloud IoT Core からの移行 を、コードや API をできるだけ変えずに行いたい

主要概念と用語

• デバイスレジストリ（Registry）: デバイスをまとめる論理的なコンテナ。テレメトリ/状態の転送先 Pub/Sub トピックや、許可するプロトコルを設定する。AWS IoT Core の「モノ（Thing）」群の管理に近い
• デバイス（Device）: レジストリに登録される個々の機器。公開鍵（証明書）や設定（config）、状態（state）を持つ
• MQTT ブリッジ: デバイスが MQTT で接続するエンドポイント。テレメトリ発行・config 受信・コマンド受信などに予約トピックを使う
• HTTP ブリッジ: 常時接続が難しいデバイス向けに、リクエスト単位でテレメトリ送信や config 取得を行う経路
• テレメトリ（Telemetry）イベント: デバイスからの計測データ。レジストリに紐づく Pub/Sub トピックへ転送される
• デバイス状態（State）: デバイスが報告する現在の状態。最新版が保持される
• 設定（Configuration / config）: クラウドからデバイスへ配るバージョン付きの設定値
• コマンド（Command）: デバイスへ即時に届けたい指示。config が「望ましい状態の保持」なら、command は「その場限りの指示」
• JWT 認証: デバイスは登録した鍵で署名した JWT（JSON Web Token） をパスワードとして提示し接続する
• 互換性（互換 API）: ClearBlade IoT Core は Cloud IoT Core と同等の概念・API を提供し、既存クライアントの移行を容易にする位置づけ

仕様・制限・クォータ

• 接続プロトコルは MQTT と HTTP が中心。MQTT は常時接続のストリーミング、HTTP はリクエスト単位の送受信に向く
• デバイス認証は 公開鍵（RSA / 楕円曲線）による JWT が基本。秘密鍵はデバイス側で安全に保持する
• テレメトリ・状態・config・command には メッセージサイズや更新レートの上限 があり、過大・過密な送信は制限される（具体値は公式の最新値を参照）
• 1 つのレジストリに 多数のデバイス を収容でき、テレメトリは紐づく Pub/Sub トピック へ転送される
• リージョンやプロジェクト単位の クォータ が設定され得るため、大規模設計では事前に上限確認と緩和申請を検討する

内部の仕組み

デバイスは MQTT ブリッジ（または HTTP ブリッジ）へ接続し、JWT を提示して認証されます。認証後、デバイスは予約された MQTT トピックへテレメトリを発行し、ブリッジはそれをレジストリに設定された Pub/Sub トピックへ転送 します。以降の保存・分析・通知は Pub/Sub の購読側で行います。

• 上り（デバイス→クラウド）: テレメトリと状態（state）を送る。テレメトリは Pub/Sub へ流れ、状態は最新版が保持される
• 下り（クラウド→デバイス）: バージョン付きの config と、即時性の高い command を配る。config はデバイスが再接続時にも取得でき、command はオンラインのデバイスへ届ける
• 認証と接続管理: 鍵のローテーションや有効期限切れの JWT を拒否し、許可されたデバイスだけを通す
• ブリッジ自体は マネージドで、ブローカやスケーリングの運用はサービス側が担う

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

• 取り込みは ClearBlade IoT Core、後段は Pub/Sub 以降に分離: テレメトリを Pub/Sub に流し、保存は BigQuery、ストリーム処理は Dataflow へつなぐ疎結合構成にする
• config と command を使い分け: 「望ましい状態を保持したい」設定は config、「今すぐ実行させたい」指示は command にする
• デバイス鍵は個別発行: 共有鍵を避け、デバイスごとに鍵を持たせて被害範囲を局所化する。鍵には有効期限を設けローテーションする
• 再接続と冪等性: ネットワーク断での再送やまれな重複を前提に、後段の処理を 冪等 に作る
• 段階的なロールアウト: config の更新はデバイス群を分けて段階適用し、不具合時の影響を抑える
• 移行時は互換性を活用: 旧 Cloud IoT Core からの移行では、互換 API を活かしてクライアント変更を最小化する

運用・監視

• Cloud Monitoring / Cloud Logging で接続数・エラー・認証失敗などを監視する
• 認証失敗の増加は 鍵の期限切れ・時刻ずれ（JWT の有効期間判定）・証明書設定ミス を疑う
• テレメトリが後段に届かない場合は、レジストリの 転送先 Pub/Sub トピックと IAM 権限 を確認する
• デバイス側のクロックずれは JWT 検証を失敗させるため、時刻同期 を運用要件に含める
• 後段の滞留は Pub/Sub のメトリクス（未配信メッセージ数・最古メッセージ経過時間）で把握する

コスト

課金はおもに 取り込むデータ量や接続規模 に応じて発生し、後段の Pub/Sub・保存・分析サービスの料金が別途加わります。ClearBlade IoT Core は Google Cloud Marketplace 経由で提供されるため、料金体系はマーケットプレイス上の最新情報を確認します。

セキュリティ

• デバイスは 公開鍵による JWT 認証 で接続し、共有パスワードを使わない
• 通信は TLS で暗号化し、デバイス側で正規エンドポイントを検証する
• IAM でレジストリ管理や転送先 Pub/Sub への権限を最小化する（管理者と運用者の分離）
• 鍵は デバイス個別に発行し有効期限とローテーション を設定、漏えい時は当該デバイスのみ失効させる
• 後段の Pub/Sub・保存先には CMEK や VPC Service Controls を併用し、データの保護・持ち出し防止を強化する

関連サービス・比較

テレメトリの転送先となる Pub/Sub と組み合わせるのが基本構成です。役割を比較します。

ハンズオン / CLI例

# ClearBlade IoT Core は ClearBlade 提供の CLI / API で操作する想定だが、
# 旧 Cloud IoT Core 互換のため、概念対応の確認として gcloud の流れを示す。

# 1) テレメトリ転送先となる Pub/Sub トピックを用意
gcloud pubsub topics create device-telemetry

# 2) そのトピックを購読するサブスクリプションを作成
gcloud pubsub subscriptions create device-telemetry-sub \
  --topic=device-telemetry

# 3) レジストリ作成・デバイス登録・config 配信は IoT Core 側の
#    CLI / API（互換エンドポイント）で実施する。概念は次の通り:
#    - レジストリ: テレメトリ転送先 Pub/Sub トピックを指定
#    - デバイス: 公開鍵（RSA / EC）を登録し JWT 認証を有効化
#    - config: バージョン付き設定を配布、command: 即時指示を送信

# 4) 後段の動作確認: 届いたテレメトリを購読側で取得
gcloud pubsub subscriptions pull device-telemetry-sub --auto-ack --limit=10