コネクテッド デバイスから得られるデータの価値を最大化するには、組織がデータ分析を実行できるようにする必要があります。組織がデバイスを分析アプリケーションに接続する方法は数多くあり、特定の接続済みデバイス アーキテクチャのメリットは、組織のユースケースによって異なる可能性があります。このドキュメントでは、 Google Cloud上の一連のコネクテッド デバイス アーキテクチャについて説明します。これらのアーキテクチャは、接続済みのデバイスの幅広いユースケースと要件に対応しています。
このドキュメントは、 Google Cloudの IoT アーキテクチャに関する情報を提供する一連のドキュメントの一部です。このシリーズには、このほかに次のドキュメントが含まれています。
- Google Cloud のコネクテッド デバイス アーキテクチャの概要(このドキュメント)。
- スタンドアロン MQTT ブローカー: MQTT ブローカーは、コネクテッド デバイスとGoogle Cloud プロジェクトの間、およびデバイス間の双方向通信を実現します。
- Google Cloudの IoT プラットフォーム アーキテクチャ: IoT プラットフォームは、データ接続とともに追加のデバイス管理機能を提供します。これは、コネクテッド デバイスの大規模なフリートをデプロイする場合に重要です。
- Pub/Sub への直接接続: データを取り込むには、デバイスから Pub/Sub に直接接続することをおすすめします。
- Google Cloudで IoT バックエンドを実行するためのベスト プラクティス。
- エッジとベアメタルのシステムとサーバーを自動的にプロビジョニングして構成するためのベスト プラクティス
コネクテッド デバイス アーキテクチャの概要
本ドキュメントでは、接続済みのデバイスのアーキテクチャを計画する際に考慮する必要がある次の項目に基づいて、接続されたデバイスのユースケースを 3 つのカテゴリに分類しています。
デバイスの数: アプリケーションに直接接続されるデバイスの数を考慮することが重要です。アプリケーションに多数のエンドデバイス(マシン、センサー、カメラなど)があり、これらのデバイスが中間ゲートウェイまたは他のデバイス(スマートフォンなど)に接続されている場合、エンドデバイスをアプリケーションで表現し、管理をする必要があるかどうかを判断することが重要です。場合によっては、個々のデバイスを表現する必要があり、中間デバイスのみを表現する必要がある場合もあります。
フリート管理: デバイスのステータス モニタリング、ソフトウェアとファームウェアの更新、構成管理、その他のフリート管理機能などの機能が必要かどうかを検討します。これらの要件は、アプリケーション アーキテクチャの選択を決定する際に役立ちます。
デバイス間メッセージング: アプリケーション アーキテクチャを介したデバイス間の通信は重要な要素です。たとえば、アプリケーション アーキテクチャを介した接続済みのデバイス間の通信に依存するアプリケーションもあります。また、各デバイスとアプリケーションの間でのみデータフローが発生し、デバイス間でメッセージングが発生しないアプリケーションもあります。
サマリー テーブル
アプリケーションの特性を理解すると、ユースケースに最適なアーキテクチャを選択できます。次の表は、このシリーズで説明する各接続型アーキテクチャが提供するサポートをまとめたもので、選択の指針になります。
デバイスのサポートの上限 | デバイス間メッセージング | フリート管理サポート | |
---|---|---|---|
MQTT ブローカー | 数百万 | 推奨 | 非対応 |
IoT プラットフォーム | 数百万 | サポートあり | 推奨 |
デバイスから Pub/Sub | 数百 | サポートあり | 非対応 |
次のステップ
- ユースケースに最適な接続済みのデバイス アーキテクチャを確認する。
- Intelligent Products Essentials を使用して、 Google Cloud でデバイスを接続し、IoT アプリケーションを構築する方法について学びます。
- エッジとベアメタルのシステムを自動的にプロビジョニングして構成するためのベスト プラクティスについて学習する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。