Google Cloud の IoT プラットフォーム プロダクト アーキテクチャ

Last reviewed 2024-08-09 UTC

IoT プラットフォーム プロダクトは通常、基本的な MQTT および HTTPS データ接続を提供します。また、デバイスのプロビジョニング、認証と管理、テレメトリーの保存と可視化、データ処理、アラート機能も提供します。スタンドアロンの MQTT ブローカーではユースケースに不十分で、企業にとってより完全な IoT プラットフォーム プロダクトが必要な場合によく利用されます。IoT プラットフォームは、デバイスの異種コレクションを管理するための統合インターフェースを提供します。このインターフェースは、多くのコネクテッド デバイス アプリケーションにとって重要であり、IoT プラットフォームとスタンドアロンの MQTT ブローカーとの主な違いでもあります。このドキュメントでは、IoT プラットフォーム プロダクト アーキテクチャを Google Cloud にデプロイする前に行う必要のある、基本的なアーキテクチャ上の考慮事項と推奨事項について説明します。

このドキュメントは、Google Cloud の IoT アーキテクチャに関する情報を提供する一連のドキュメントの一部です。このシリーズには、このほかに次のドキュメントが含まれています。

次の図は、Google Cloud で稼働する一般的な IoT プラットフォーム プロダクトを使用したアーキテクチャの例を示しています。

一般的な IoT プラットフォーム アーキテクチャ（以降の本文で説明するイベントのフロー）。

上の図に示すように、IoT プラットフォームはデバイス接続用の MQTT ブローカーまたはエンドポイントをデプロイします。IoT プラットフォームは、外部プロキシ ネットワーク ロードバランサに接続され、エッジデバイスからのトラフィックを分散します。追加の IoT アプリケーションは、Pub/Sub または Dataflow MQTT コネクタを使用して IoT プラットフォームに接続できます。

IoT プラットフォームは、一連のデバイス管理サービスを提供します。図に示すように、これらのサービスには次のようなものがあります。

  • デバイスの認証情報ストア
  • ルールエンジン
  • デバイスの認証と認可
  • デバイスの構成管理
  • デバイス レジストリ
  • デバイス更新管理

また、IoT プラットフォーム プロダクトには通常、デジタルツイン機能、ローコード開発インターフェース、アラート機能と通知機能、その他の分析機能などのサービスも含まれます。

アーキテクチャに関する比較検討と選択

以降のセクションでは、IoT プラットフォーム プロダクト アーキテクチャとして選択できるアーキテクチャの選択肢と、それらの選択肢の影響について説明します。

取り込みエンドポイント

ほとんどの商用 IoT プラットフォーム アプリケーションには、MQTT エンドポイントが含まれています。また、通常はコネクテッド デバイスからのデータ取り込み用の HTTPS エンドポイントも含まれています。

MQTT

IoT プラットフォームは、次のいずれかの方法で MQTT エンドポイントを実装します。

  • MQTT と別のメッセージ サービス間のコネクタ
  • 完全な MQTT 仕様を実装するした MQTT ブローカー

商用 IoT プラットフォームを評価する際は、ベンダーがプロダクトに対して前述のどのアプローチ選択したかを把握し、ユースケースへの影響を判断することが重要です。

場合によっては、MQTT エンドポイントは MQTT クライアントを Kafka や Pub/Sub などのバックエンド メッセージング サービスに接続するだけであることがあります。このタイプのエンドポイントは通常、完全な MQTT プロトコル仕様を実装しておらず、多くの場合、QoS レベル 1 や 2、共有サブスクリプションなどの機能が含まれていません。このアプローチの利点は、個別の MQTT ブローカー アプリケーションがないため、IoT プラットフォームの複雑さが軽減されることです。個別の MQTT ブローカーをプラットフォームで使用するよりも、運用コストを削減でき、メンテナンスも簡単です。ただし、より高度な MQTT プロトコル機能のサポートが縮小されているため、このアプローチでは、完全な MQTT 仕様を実装するスタンドアロン MQTT ブローカーよりも、MQTT メッセージ転送の柔軟性と機能性が低くなります。

他の IoT プラットフォームは、このドキュメントのアーキテクチャの例に示すように、プラットフォームの一部として完全な MQTT ブローカーを提供します。このブローカーは、既存のオープンソース ブローカーの一つである場合もあれば、独自のブローカーの実装である場合もあります。完全な MQTT ブローカーは、前述の完全な双方向 MQTT 機能を提供しますが、完全なブローカーを使用すると、IoT プラットフォームの管理が複雑化し、運用コストが増加する可能性があります。

HTTPS とその他の補助プロトコル

多くの IoT プラットフォームでは、MQTT に加えて、このドキュメントで説明するメイン アーキテクチャよりも多くのデータ取り込みエンドポイントが提供されています。

HTTPS は、コネクテッド デバイスのユースケースにおいて MQTT に代わる一般的な代替プロトコルです。MQTT よりもオーバーヘッドが高くなりますが、スマートフォンなどのモバイル デバイスや、ウェブブラウザやその他のアプリケーションで幅広くサポートされています。特定のコネクテッド デバイス アプリケーションで頻繁に使用され、Eclipse Hono などのオープンソース プラットフォームや多くの商用プロダクトでサポートされています。

多くの制約のあるデバイス アプリケーションは、MQTT の代わりとして RFC 7252 で定義されている制約付きアプリケーション プロトコル（CoAP）を使用します。CoAP は、組み込みデバイスとセンサー向けのオーバーヘッドとフットプリントが小さなクライアントを対象としています。商用 IoT プラットフォーム アプリケーションの多くは、CoAP エンドポイントも提供しています。

ロード バランシング

アーキテクチャに最適なロードバランサの選択について詳しくは、Google Cloud 上のスタンドアロン MQTT ブローカー アーキテクチャのロード バランシングのセクションをご覧ください。この考慮事項もこのケースに当てはまります。

デバイスの認証と認証情報の管理

デバイスの認証情報と認証の管理は、IoT プラットフォームの運用の重要な部分です。コネクテッド デバイスでサポートされる認証方法は、アプリケーションやデバイスのフォーム ファクタによって大きく異なります。対象となるユースケースに適した認証方法を選択し、選択した認証スキームを正しく実装することが重要です。

スタンドアロンの MQTT ブローカーとは異なり、IoT プラットフォームは、デバイスの ID と認証情報を管理するための統合サービスが提供されます。ほとんどの IoT プラットフォームでは、認証用の X.509 クライアント証明書認証、JWT トークンベースの認証（多くの場合、OAuth 2.0 との組み合わせ）、ユーザー名とパスワードの認証を使用します。一部のプラットフォームでは、外部 LDAP 認証プロバイダとの統合もサポートしています。

一部の制限されたデバイスでは、JWT またはユーザー名とパスワードによる認証のほうが適切な場合があります。これは、これらのスキームではコネクテッド デバイス上のリソースが少なくて済むためです。JWT 認証またはユーザー名とパスワードによる認証を使用する場合、いずれの認証方法でも暗号化された接続は要求されないため、mTLS 認証とは別にネットワーク接続を暗号化することが重要です。一方、X.509 証明書認証は、コネクテッド デバイスでより多くのリソースを消費しますが、通常は mTLS 暗号化接続で使用されるため、高レベルのセキュリティが提供されます。

製造時にエッジデバイスで認証情報をプロビジョニングすることも、コネクテッド デバイス認証スキームの重要な部分ですが、このドキュメントでは扱いません。

認証と認証情報の管理の詳細については、Google Cloud で IoT バックエンドを実行するためのベスト プラクティスをご覧ください。

コネクテッド デバイスの管理

通常、コネクテッド デバイスは、MQTT などの取り込みエンドポイントの 1 つを介してテレメトリー イベントと状態情報をプラットフォームに公開します。マルチプロトコル IoT プラットフォームを使用している場合、デバイスはサポートされているいずれかのプロトコルを使用して通信できます。

組織では、次の機能を備えた IoT プラットフォームを使用することをおすすめします。

  • ソフトウェアとシステムの更新: コネクテッド デバイスへのファームウェア、ソフトウェア、アプリケーションの更新の配信およびロールバック。これらの更新には通常、更新自体の保存と管理も含まれます。
  • 構成の更新: コネクテッド デバイスにデプロイされたアプリケーションの構成に対する更新の配信、保存、ロールバック。
  • 認証情報の作成と管理: 新しいデバイス認証情報の作成、コネクテッド デバイスへの認証情報の配信、デバイス アクセスの試行とアクティビティの監査、適切なタイミングでの不正使用された認証情報や期限切れの認証情報の取り消し。
  • ルールエンジンとデータ処理: データドリブンのルールとその他のデータ処理ステップの定義および実行。多くの場合、この機能には、ルールとデータ処理パイプラインを定義するためのなんらかのローコード インターフェースが組み込まれています。

バックエンド ワークロード

ほとんどの IoT プラットフォームは、バックエンドのワークロードとアプリケーションに接続できる独自の内部データ ストレージと転送機能を備えています。AMQP、RabbitMQ、Kafka は、内部データ転送の提供用に広く使用されています。これらはすべて、Pub/Sub SDK を使用して Pub/Sub に接続できます。PostgreSQL などの統合データベース システムを使用して、プラットフォームにデータを保存することもできます。多くの場合、Cloud SQL、Firebase、BigQuery などの Cloud Storage プロダクトのいずれかを直接使用するように IoT プラットフォームを構成できます。

IoT プラットフォームに完全な MQTT ブローカーがある場合、バックエンド アプリケーションはプラットフォームの MQTT 機能を使用してデバイスと通信することもできます。アプリケーションが MQTT をサポートしている場合、アプリケーションはブローカーにサブスクライバーとして接続できます。MQTT がサポートされていない場合、Apache Beam は MQTT ドライバを提供します。これにより、Dataflow や他の Beam デプロイメントとの双方向インテグレーションが可能になります。

ユースケース

以降のセクションでは、IoT プラットフォームがスタンドアロンの MQTT ブローカーや Pub/Sub への直接接続よりも優れたアーキテクチャの選択肢となるシナリオの例について説明します。

スマート アプライアンス管理

複数のスマート アプライアンスを管理するアプリケーションは、IoT プラットフォームに適しています。そのようなアプリケーションの例は、食器洗い機やコーヒー メーカーなどのキッチン家電を管理するためのプラットフォームです。これらのデバイスは、通常、Wi-Fi 経由で直接、または Bluetooth Low Energy（BLE）やその他のローカル プロトコルを使用するローカル ゲートウェイを介して、クラウドベースのアプリケーションに接続します。ここでは、IoT プラットフォームの管理機能が重要になります。各デバイスの状態のモニタリング、ソフトウェア アップデートとセキュリティ パッチの管理、デバイス アクティビティの取得において、メーカーとお客様に重要なインテリジェンスを提供します。これらの機能は、基本的な MQTT ブローカーの範囲外です。スマート アプライアンス プラットフォームを構築するには、少なくとも、デバイス情報リポジトリ、デバイス状態データベース、テレメトリー データストア、分析インターフェースが不可欠です。

ロジスティクスとアセット トラッキング

ロジスティクスとアセット トラッキングのアプリケーションの場合、IoT プラットフォーム プロダクトは基本的な MQTT ブローカーよりも完全な機能を提供するため、このユースケースには適しています。大量のアセット群の現在および過去の状態と場所をモニタリングするには、堅牢なデバイス状態データベースと ID 管理システムが必要です。新しいアセットがデプロイされると、可能な限りスムーズにプラットフォームと接続し、アセットのライフサイクル全体でモニタリングする必要があります。多くの場合、予想外の動きや落下を検出するために、アプリケーションはアセットに関する他のセンサー情報（地域の温度、湿度、大気圧、3D の位置データ、加速度データなど）も収集します。これらのデータはすべて、バックエンド アプリケーションで分析するために取り込んで正しいアセットに関連付ける必要があります。そのため、IoT プラットフォームが提供するフル機能のデバイス管理が重要な役割を果たします。

次のステップ