IoT Core から環境を移行する

Last reviewed 2023-02-01 UTC

Google は IoT Core の非推奨を発表しました。このドキュメントは、以下に関して、IoT Core ベースの環境から IoT Core に依存しない新しい環境への移行計画を設計して実装する際に役立ちます。

  • エッジデバイスの認証
  • エッジデバイスの管理
  • エッジデバイスと Google Cloud 間の通信

このドキュメントでは、IoT Core のサポート終了後に移行の可能性を評価し、移行の概要を検討する際のガイダンスも提供しています。

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

移行するワークロード

このドキュメントは、IoT Core から移行するワークロードに次の部分があることを前提としています。

  • エッジデバイス(環境のエッジで、処理するデータの次にデプロイする部分)で実行される部分。
  • Google Cloud で実行されるバックエンド

次の図は、IoT Core を使用する一般的なワークロードのアーキテクチャを示しています。このアーキテクチャでは、Cloud IoT は Google Cloud 上で動作するバックエンドを持つエッジデバイスを統合します。

エッジデバイスから Cloud IoT へのイベントのフロー(以下のテキストに要約)。

上の図を要約すると次のようになります。

移行を効果的に計画するには、評価を行い、移行元の環境のアーキテクチャを十分に理解することをおすすめします。ここで、移行元の環境は、現在の IoT Core ベースの環境を指します。

このドキュメントは、移行のためにエッジデバイスで実行されている構成とソフトウェア コンポーネントを更新できることを前提としています。場合によっては、このアプローチが不可能なこともあります。たとえば、エッジデバイスやデプロイ プロセスが、このユースケースをサポートしていない場合があります。この場合は、更新をサポートしていないエッジデバイスの廃止を計画することをおすすめします。エッジデバイスの自動プロビジョニングと構成プロセスの設計と実装の詳細については、エッジとベアメタル システムおよびサーバーの自動プロビジョニングと構成のベスト プラクティスをご覧ください。

移行を設計する

IoT Core ベースの環境を移行する場合は、Google Cloud への移行で説明する移行フレームワークに従うことをおすすめします。

次の図は、移行の過程を示しています。

4 フェーズの移行パス

上の図に示すように、この過程には 4 つのフェーズがあります。

  1. 評価: このフェーズでは、移行元の環境を評価し、Cloud IoT Core から移行するワークロードとエッジデバイスを評価します。
  2. 計画: このフェーズでは、リソース階層のプロビジョニングやネットワーク アクセスの設定など、Google Cloud で基本的なインフラストラクチャを作成します。
  3. デプロイ: このフェーズでは、IoT Core の代わりに使用する新しいソリューションをデプロイし、エッジデバイスを新しいソリューションに移行します。
  4. 最適化: このフェーズでは、移行先の環境を最適化します。ここで、移行先の環境とは、IoT Core をベースとしない移行先の環境を指します。

移行元の環境とワークロードを評価する

評価フェーズでは、移行元の環境、エッジデバイス、組織での IoT Core の使用に関する情報を収集します。この情報は、移行計画を作成し、移行と移行先の環境に必要なリソースを確保するのに役立ちます。

評価フェーズでは、次のことを行います。

  1. Cloud IoT Core に登録したエッジデバイスのインベントリを構築する。
  2. Cloud IoT Core と統合するバックエンド ワークロードのインベントリを構築する。
  3. エッジデバイスとバックエンド ワークロードを分類する
  4. 概念実証を設計し、テストする。
  5. 総所有コストを計算する。
  6. 移行先の環境のアーキテクチャを設計する。
  7. 最初に移行するエッジデバイスとバックエンド ワークロードを選択する。

評価フェーズが終了すると、エッジデバイスのインベントリとバックエンド ワークロードのインベントリの 2 つのインベントリが作成されます。

不整合を回避するため、これらのインベントリを構築する前に、新しいエッジデバイスとバックエンド ワークロードのデプロイを一時停止することをおすすめします。また、インベントリを作成した後は、新しいエッジデバイスとバックグラウンド ワークロードをデプロイしないことをおすすめします。

エッジデバイスのインベントリを構築する

移行のスコープを設定して移行計画を設計するには、移行元の環境にあるエッジデバイスの数を把握する必要があります。また、デバイスと IoT Core の連携について理解し、一般的な特性、動作、目的、依存関係別にデバイスを分類できるかどうかも確認する必要があります。

IoT Core に登録する各エッジデバイスは、IoT Core レジストリに属します。エッジデバイスのインベントリを作成する最初のステップは、作成した IoT Core レジストリの一覧を作成することです。その後で、各レジストリに登録されているエッジデバイスに関する情報を収集します。

エッジデバイスのインベントリを構築するには、各エッジデバイスについて以下の情報と、そのデバイスが IoT Core とどのように統合されているのかを検討します。

  • 識別子: エッジデバイスの IoT Core 識別子に関する次の情報を収集します。

    • ユーザー定義の識別子
    • サーバー定義の編集可能な ID(エッジデバイスを IoT Core に登録したときに IoT Core が自動的に生成します)
    • エッジデバイスを登録した IoT Core レジストリの識別子を使用してエッジデバイスを一意に識別するリソース名
  • デプロイ状態: エッジデバイスの現在のデプロイ状態を評価します。たとえば、エッジデバイスは次のいずれかの状態になります。

    • まだ製造されていない、または現在製造中
    • デプロイの準備は整っているが、IoT Core に未登録
    • すでに移行先のサイトにデプロイされ、IoT Core に登録されている
  • IoT Core デバイスタイプ: IoT Core のデバイスタイプを評価します。IoT Core に登録するエッジデバイスは、次のいずれかの方法で動作します。IoT Core に直接接続するクライアント。または、IoT Core に直接接続できないクライアント ゲートウェイや、接続したくないクライアントのゲートウェイ。

  • 通信プロトコル: IoT Core は、エッジデバイスと通信するために HTTP と MQTT の 2 つのプロトコルをサポートしています。エッジデバイスが IoT Core との通信に使用するプロトコルを評価します。MQTT プロトコルについては、エッジデバイスとバックエンド ワークロードが依存するサービス品質も決める必要があります。

  • 認証情報: IoT Core は、鍵ペアと、その鍵ペアを使用して生成された有効期間の短いトークンを使用して、エッジデバイスの認証を行います。必要に応じて、証明書ベースの検証方法を使用して、鍵ペアの公開部分の署名を検証します。エッジデバイスの認証がどのように構成されているかを評価します。デバイスが属する IoT Core レジストリに証明書ベースの検証メカニズムを使用しているかどうかを確認します。

  • デバイス メタデータ: IoT Core では、各エッジデバイスのメタデータを Key-Value ペアの形式で定義できます。たとえば、ハードウェアのサムネイル、シリアル番号、メーカーの情報、エッジデバイスに関連するその他の属性を定義できます。エッジデバイスを IoT Core レジストリに追加するとき、またはレジストリにすでに存在するエッジデバイスを編集するときに、メタデータを定義できます。メタデータが IoT Core を介してエッジデバイスに送受信されることはありません。エッジデバイス用に定義したメタデータに関する情報を収集します。

  • デバイスの状態: IoT Core では、各エッジデバイスがその状態に関する情報を任意の構造化データまたは非構造化データとしてレポートできます。たとえば、エッジデバイスから実行中のファームウェアのバージョンが報告される場合があります。また、特定の指標に従って、健全性に関する情報を報告する場合もあります。IoT Core は、構成した Pub/Sub トピックに、デバイスの状態に関して受信した情報をメッセージとしてパブリッシュします。エッジデバイスが状態に関する情報を報告する方法と、IoT Core がそれらのメッセージをパブリッシュする Pub/Sub トピックを評価します。アーキテクチャのどのコンポーネントがエッジデバイスの状態に関する情報に依存しているかを判断します。

  • テレメトリー イベント: IoT Core レジストリに追加するエッジデバイスは、テレメトリー イベントを任意の構造化デ