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）: MQTT で接続・購読中のデバイスへ送る一時的な指示。保存されず、HTTP では受信できない
• JWT 認証: デバイスは登録した鍵で署名した JWT（JSON Web Token） をパスワードとして提示し接続する
• 互換性（互換 API）: ClearBlade IoT Core は Cloud IoT Core と同等の概念・API を提供し、既存クライアントの移行を容易にする位置づけ

仕様・制限・クォータ

• 接続は MQTT 3.1.1 または HTTP 1.1、暗号化は TLS 1.2 以上。MQTT は 8883 番または 443 番ポートを使い、QoS 2・任意トピック・永続セッションには対応しない
• デバイス認証は RS256 / ES256 で署名した JWT。JWT の有効期間は最大 24 時間で、秘密鍵はデバイス側に保持する
• 利用可能リージョンは us-central1 / europe-west1 / asia-east1。デバイス数はプロジェクト・リージョンごとに既定 10 万台、同時 MQTT 接続は既定 1 万件で、いずれも増枠を申請できる
• テレメトリは最大 256 KB、状態と config は最大 64 KB、資格情報は端末ごとに最大 3 個。MQTT は 1 接続あたり毎秒 100 メッセージ、上り・下りはそれぞれ毎秒 512 KB が上限
• command は MQTT のみで、接続・購読中の端末に限り送信する。保存されず、60 秒でタイムアウトする。QoS 1 の成功応答は少なくとも 1 回の受信を示すため重複処理に備える

内部の仕組み

横にスクロール

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

• 上り（デバイス→クラウド）: テレメトリと状態（state）を送る。テレメトリは Pub/Sub へ流れ、状態は最新版が保持される
• 下り（クラウド→デバイス）: 保存される config と、一時的な command を使い分ける。config は MQTT の再接続後または HTTP の取得要求で最新版を得られる。command は接続・購読中の MQTT デバイスだけに届く
• 認証と接続管理: 鍵のローテーションや有効期限切れの JWT を拒否し、許可されたデバイスだけを通す
• ブリッジ自体は マネージドで、ブローカやスケーリングの運用はサービス側が担う

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

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

運用・監視

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

コスト

ClearBlade IoT Core は月間データ量で課金され、250 MB までは無料、その後は段階単価です。各メッセージは最低 1,024 バイトとして計算され、MQTT の CONNECT・PINGREQ・PUBLISH なども対象です。Pub/Sub・保存・分析の料金は別途発生するため、接続維持だけの PINGREQ も含めて見積もります。

セキュリティ

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

関連サービス・比較

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

ハンズオン / CLI例

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

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