Pub/Sub 上のデバイスから Google Cloud への接続

Last reviewed 2024-08-09 UTC

一部の組織では、デバイスを分析アプリケーションに接続するためのアーキテクチャを実装するのではなく、エッジデバイスから Pub/Sub に直接接続するとメリットが得られる場合があります。ローカル ネットワークまたはオンプレミス ネットワーク内の多数のデバイスやセンサーからデータを集約する、少数の接続済みデバイスがある組織には、この方法をおすすめします。この方法は、工場などのより安全な環境でデバイスが接続されている場合にもおすすめします。このドキュメントでは、このアプローチを使用してデバイスを Google Cloud プロダクトに接続する際に考慮すべきアーキテクチャ上の考慮事項の概要について説明します。

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

アーキテクチャ

次の図は、Pub/Sub に直接接続されている集約デバイスまたはゲートウェイを示しています。

Pub/Sub に接続された集約デバイスまたはゲートウェイ アーキテクチャ（次のテキストで説明するイベントの流れ）。

上の図のイベントの流れは次のとおりです。

  • Identity and Access Management API を使用して、サービス アカウントの新しい鍵ペアを作成します。公開鍵は IAM に保存されます。ただし、認証に使用できるように、秘密鍵を安全にダウンロードし、ゲートウェイ デバイスに保存する必要があります。
  • 集約デバイスは、安全なローカル ネットワーク内に配置された他の複数のリモート デバイスとセンサーからデータを収集します。リモート デバイスは、MODBUS、BACNET、OPC-UA などのローカル エッジ プロトコル、または別のローカル プロトコルを使用してゲートウェイと通信します。
  • 集約デバイスは、HTTPS または gRPC を介して Pub/Sub にデータを送信します。これらの API 呼び出しは、集約デバイスで保持されているサービス アカウントの秘密鍵を使用して署名されます。

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

Pub/Sub はサーバーレスのデータ ストリーミング サービスであるため、イベント プロデューサーとコンシューマー（パブリッシャーとサブスクライバー）で構成される双方向システムを作成できます。一部のコネクテッド デバイスのシナリオでは、効果的なデータ アーキテクチャを作成するために、スケーラブルなパブリッシュ / サブスクライブ サービスが必要になります。以降のセクションでは、Google Cloud の Pub/Sub アーキテクチャにデバイスを実装する際の考慮事項と選択について説明します。

取り込みエンドポイント

Pub/Sub は、REST API と gRPC API を実装し、複数の言語で事前にビルドされたクライアント ライブラリを提供します。メッセージの取り込みには、REST（HTTP）と gRPC の 2 つのプロトコルがサポートされています。接続デバイスが Pub/Sub を介してデータを送受信するには、デバイスがこれらのエンドポイントのいずれかとやり取りできる必要があります。

多くのソフトウェア アプリケーションには REST API のサポートが組み込まれているため、最も簡単なソリューションは Pub/Sub REST API です。ただし、いくつかのユースケースでは、gRPC のほうが効率的で高速な場合があります。メッセージ ペイロードには、JSON、XML などのテキストベースの形式ではなくシリアル化されたプロトコル バッファが使用されるため、gRPC は、コネクテッド デバイスで使用される一般的な低帯域幅アプリケーションに適しています。gRPC API 接続はまた、データ転送に関して REST より高速であり、gRPC は同時双方向通信をサポートしています。ある調査によると、gRPC は REST よりも 7 倍高速です。そのため、多くのコネクテッド デバイス シナリオでは、gRPC コネクタが使用可能な場合や、コネクテッド デバイス アプリケーションに実装できる場合は、gRPC のほうが適しています。

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

Pub/Sub は、Google Cloud の外部からのアクセス用にいくつかの認証方法をサポートしています。

アーキテクチャに Active Directory やローカルの Kubernetes クラスタなどの外部 ID プロバイダが含まれている場合は、Workload Identity 連携を使用して Pub/Sub へのアクセスを管理します。この方法により、接続デバイスに有効期間の短いアクセス トークンを作成できます。また、サービス アカウント キーの使用に伴う管理とセキュリティのオーバーヘッドなしに、接続デバイスに IAM のロールを付与することもできます。

外部 ID プロバイダを使用できない場合は、サービス アカウント キーが唯一の認証オプションになります。サービス アカウント キーを正しく管理しないと、セキュリティ リスクになる可能性があるため、接続デバイスにサービス アカウント キーをデプロイする際は、セキュリティのベスト プラクティスに従うことをおすすめします。詳細については、サービス アカウント キーを管理するためのベスト プラクティスをご覧ください。また、サービス アカウントは制限されたリソースであり、クラウド プロジェクトでは、ユーザー管理のサービス アカウントの割り当てが限られています。したがって、このアプローチは、接続する必要があるデバイスの数が少ないデプロイにのみ使用できます。

バックエンド アプリケーション

Pub/Sub トピックに取り込まれたデータは、Google Cloud で実行され、適切な認証情報とアクセス権限のあるすべてのアプリケーションで使用できるようになります。アプリケーションの Pub/Sub API 以外に追加のコネクタは必要ありません。バックエンド インフラストラクチャ全体の複数のアプリケーションで、並列処理やアラート、アーカイブ ストレージなどの分析のためのメッセージを使用できます。

ユースケース

次のセクションでは、デバイスから Pub/Sub への直接接続が、コネクテッド デバイスのユースケースに適しているシナリオの例について説明します。

オンプレミスのデータ ヒストリアンからのデータの一括取り込み

デバイスから Pub/Sub への接続は、大量のデータを送信するエンドポイントの数が少ないアプリケーションに最適です。運用データ履歴は、Google Cloud に送信する必要がある大量のデータを格納するオンプレミス システムの例です。このユースケースでは、少数のエンドポイント（通常は 1～数台の接続デバイス）を認証する必要があります。また、これらのエンドポイントはサービス アカウント認証の一般的なパラメータの範囲内に収まります。これらのシステムはモジュラー アーキテクチャも備えており、Google Cloud との通信に必要な Pub/Sub API 接続を実装できます。

工場のローカル ゲートウェイ データの集約

ローカル ゲートウェイで工場のセンサーデータを集約する場合も Pub/Sub への直接接続が適しています。この場合、ローカルのデータ マネジメントと集約システムが、工場のゲートウェイ デバイスにデプロイされます。このシステムは通常、ローカルのさまざまなセンサーやマシンに接続するソフトウェア プロダクトです。このプロダクトはデータを収集し、標準化された表現に変換してからクラウド アプリケーションに渡します。

このシナリオでは、多くのデバイスを接続できます。ただし、これらのデバイスは通常、ローカル ゲートウェイにのみ接続され、そのデバイス上のソフトウェアによって管理されるため、クラウドベースの管理アプリケーションは必要ありません。MQTT ブローカー アーキテクチャとは異なり、このユースケースでは、ゲートウェイがデータの集約と変換でアクティブな役割を果たします。

ゲートウェイは Google Cloud に接続するときに、サービス アカウント キーを使用して Pub/Sub で認証を行います。このキーにより、集約および変換されたデータがクラウド アプリケーションに送信され、処理されます。接続されているゲートウェイの数も通常数十から数百台の範囲で、これはサービス アカウント認証の一般的な範囲内です。

次のステップ