Google は IoT Core の非推奨を発表しました。このドキュメントは、以下に関して、IoT Core ベースの環境から IoT Core に依存しない新しい環境への移行計画を設計して実装する際に役立ちます。
- エッジデバイスの認証
- エッジデバイスの管理
- エッジデバイスと Google Cloud 間の通信
このドキュメントでは、IoT Core のサポート終了後に移行の可能性を評価し、移行の概要を検討する際のガイダンスも提供しています。
このドキュメントは、Google Cloud の IoT アーキテクチャと IoT Core からの移行についての情報を提供する一連のドキュメントの一部です。このシリーズには、この他に次のドキュメントが含まれています。
- Google Cloud のコネクテッド デバイス アーキテクチャの概要
- Google Cloud のスタンドアロン MQTT ブローカー アーキテクチャ
- Google Cloud の IoT プラットフォーム プロダクト アーキテクチャ
- Google Cloud で IoT バックエンドを実行するためのベスト プラクティス
- Pub/Sub アーキテクチャ上のデバイスから Google Cloud への接続
- エッジとベアメタルのシステムとサーバーを自動的にプロビジョニングして構成するためのベスト プラクティス
- IoT Core から環境を移行する（このドキュメント）
移行するワークロード
このドキュメントは、IoT Core から移行するワークロードに次の部分があることを前提としています。
- エッジデバイス（環境のエッジにデプロイされている、処理するデータの隣にある部分）で実行される部分。
- Google Cloud で実行されるバックエンド
次の図は、IoT Core を使用する一般的なワークロードのアーキテクチャを示しています。このアーキテクチャでは、Cloud IoT は Google Cloud 上で動作するバックエンドを持つエッジデバイスを統合します。
上の図を要約すると次のようになります。
- エッジデバイスは、ローカルでデータを収集して処理します。
- エッジデバイスは、MQTT または HTTP プロトコルを介して IoT Core を利用し、Google Cloud で実行されているバックエンドに処理済みのデータを送信します。このデータにはテレメトリーとデバイスの状態が含まれます。
- IoT Core は、エッジデバイスから受信したデータを特定の Pub/Sub トピック内の Pub/Sub メッセージとしてパブリッシュします。
- バックエンド ワークロードは、Pub/Sub トピックにサブスクライブして、テレメトリーとデバイスの状態に関する情報を受け取ります。
- バックエンドは、デバイス構成とコマンドをエッジデバイスに送信する場合があります。
移行を効果的に計画するには、評価を行い、移行元の環境のアーキテクチャを十分に理解することをおすすめします。ここで、移行元の環境は、現在の IoT Core ベースの環境を指します。
このドキュメントは、移行のためにエッジデバイスで実行されているソフトウェア コンポーネントとその構成を更新できることを前提としています。場合によっては、このアプローチが不可能なこともあります。たとえば、エッジデバイスやデプロイ プロセスが、このユースケースをサポートしていない場合があります。この場合は、更新をサポートしていないエッジデバイスの廃止を計画することをおすすめします。エッジデバイスのプロビジョニングと構成を自動で行うプロセスの設計と実装の詳細については、エッジとベアメタルのシステムとサーバーを自動的にプロビジョニングして構成するためのベスト プラクティスをご覧ください。
移行を設計する
IoT Core ベースの環境を移行する場合は、Google Cloud への移行で説明する移行フレームワークに従うことをおすすめします。
次の図は、移行の過程を示しています。
上の図に示すように、この過程には 4 つのフェーズがあります。
- 評価: このフェーズでは、移行元の環境を評価し、Cloud IoT Core から移行するワークロードとエッジデバイスを評価します。
- 計画: このフェーズでは、リソース階層のプロビジョニングやネットワーク アクセスの設定など、Google Cloud で基本的なインフラストラクチャを作成します。
- デプロイ: このフェーズでは、IoT Core の代わりに使用する新しいソリューションをデプロイし、エッジデバイスを新しいソリューションに移行します。
- 最適化: このフェーズでは、移行先の環境を最適化します。ここで、移行先の環境とは、IoT Core をベースとしない移行先の環境を指します。
移行元の環境とワークロードを評価する
評価フェーズでは、移行元の環境、エッジデバイス、組織での IoT Core の使用に関する情報を収集します。この情報は、移行計画を作成し、移行と移行先の環境に必要なリソースを確保するのに役立ちます。
評価フェーズでは、次のことを行います。
- Cloud IoT Core に登録したエッジデバイスのインベントリを構築する。
- Cloud IoT Core と統合するバックエンド ワークロードのインベントリを構築する。
- エッジデバイスとバックエンド ワークロードを分類する
- 概念実証を設計し、テストする。
- 総所有コストを計算する。
- 移行先の環境のアーキテクチャを設計する。
- 最初に移行するエッジデバイスとバックエンド ワークロードを選択する。
評価フェーズが終了すると、エッジデバイスのインベントリとバックエンド ワークロードのインベントリの 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 プロトコルについては、エッジデバイスとバックエンド ワークロードが使用する QoS レベルも確認する必要があります。
認証情報: IoT Core は、鍵ペアと、その鍵ペアを使用して生成された有効期間の短いトークンを使用して、エッジデバイスの認証を行います。必要に応じて、証明書ベースの検証方法を使用して、鍵ペアの公開部分の署名を検証します。エッジデバイスの認証がどのように構成されているかを評価します。デバイスが属する IoT Core レジストリに証明書ベースの検証メカニズムを使用しているかどうかを確認します。
デバイス メタデータ: IoT Core では、各エッジデバイスのメタデータを Key-Value ペアの形式で定義できます。たとえば、ハードウェアのサムネイル、シリアル番号、メーカーの情報、エッジデバイスに関連するその他の属性を定義できます。エッジデバイスを IoT Core レジストリに追加するとき、またはレジストリにすでに存在するエッジデバイスを編集するときに、メタデータを定義できます。メタデータが IoT Core を介してエッジデバイスに送受信されることはありません。エッジデバイス用に定義したメタデータに関する情報を収集します。
デバイスの状態: IoT Core では、各エッジデバイスがその状態に関する情報を任意の構造化データまたは非構造化データとしてレポートできます。たとえば、エッジデバイスから実行中のファームウェアのバージョンが報告される場合があります。また、特定の指標に従って、健全性に関する情報を報告する場合もあります。IoT Core は、構成した Pub/Sub トピックに、デバイスの状態に関して受信した情報をメッセージとしてパブリッシュします。エッジデバイスが状態に関する情報を報告する方法と、IoT Core がそれらのメッセージをパブリッシュする Pub/Sub トピックを評価します。アーキテクチャのどのコンポーネントがエッジデバイスの状態に関する情報に依存しているかを判断します。
テレメトリー イベント: IoT Core レジストリに追加するエッジデバイスは、テレメトリー イベントを任意の構造化データまたは非構造化データとして IoT Core に送信できます。IoT Core は、受信したテレメトリー イベントを、構成した Pub/Sub トピックのメッセージとしてパブリッシュします。エッジデバイスがテレメトリー イベントをレポートする方法と、IoT Core がそれらのメッセージをパブリッシュする Pub/Sub トピックを評価します。エッジデバイスから報告されたテレメトリー イベントに依存しているアーキテクチャのコンポーネントを特定します。
デバイス構成: IoT Core では、エッジデバイスの構成を任意の構造化データまたは非構造化データとして定義できます。IoT Core では、デバイス構成の更新を新しいバージョンとして定義し、その後、エッジデバイスに push することもできます。エッジデバイスが Cloud IoT Core から構成を受信しているかどうかを評価し、定義したすべての構成バージョンに関する情報を収集します。
コマンド: IoT Core では、エッジデバイスは IoT Core からコマンドを受け取り、そのコマンドに従って応答できます。エッジデバイスが IoT Core からのコマンドへの対応をサポートしているかどうかを評価します。
ソフトウェアと構成の更新: 移行中に、エッジデバイスで実行されているソフトウェア コンポーネントまたはそれらのコンポーネントの構成の更新が必要になる場合があります。エッジデバイスがサポートする更新メカニズムを評価します。また、更新中に問題や問題が発生した場合に、デバイスを既知の動作状態に戻すためのロールバック メカニズムもサポートしているかどうかを確認します。
ダウンタイム: 移行中、バックエンド ワークロードまたは移行元の環境の他の部分が使用できない場合があります。エッジデバイスがダウンタイムをサポートしているかどうか、フォールバック メカニズム、ダウンタイム後の復旧方法を評価します。
IoT Core と統合するバックエンド ワークロードのインベントリを構築する
エッジデバイスのインベントリを作成した後、Cloud IoT Core と統合されている移行元環境のバックエンド ワークロードに関する情報を収集します。バックエンド ワークロードは、次の方法で IoT Core と統合できます。
- エッジデバイスにコマンドを送信し、IoT Core を使用してエッジデバイスの構成を更新する。
- エッジデバイスのテレメトリー イベントとデバイスの状態に関するメッセージを IoT Core がパブリッシュする Pub/Sub トピックにサブスクライブする。
- 直接的に、またはインフラストラクチャ プロビジョニング ツールを使用して、IoT Core API と統合する。たとえば、Terraform を使用して IoT Core のレジストリとデバイスをプロビジョニングできます。
Cloud IoT Core と統合されるバックエンド ワークロードのインベントリを作成するには、バックエンド ワークロードごとに次の点を考慮してください。
- コマンドとデバイス構成: バックエンド ワークロードがエッジデバイスにコマンドを送信するかどうか、およびデバイス構成を更新するかどうかを評価します。どちらの操作も IoT Core API との統合が必要です。
- テレメトリー イベントとデバイスの状態: バックエンド ワークロードが、テレメトリー イベントとデバイスの状態に関するメッセージを、IoT Core がパブリッシュする Pub/Sub トピックに登録するかどうかを評価します。
他の IoT Core API との統合: バックエンド ワークロードが、コマンドの送信やデバイス構成の更新を行う以外に、他の IoT Core API とやり取りするかどうかを評価します。たとえば、バックエンドのワークロードは、IoT Core API を使用して次の処理を行う場合があります。
- IoT Core レジストリを作成し、その構成を更新する。
- IoT Core デバイスを作成し、その構成を更新する。
- IoT Core レジストリとデバイスに関する情報を収集する。
- IoT Core のロギング指標とデバイス アクティビティ ログを使用する。
エッジデバイスとバックエンド ワークロードを分類する
エッジデバイスとバックエンド ワークロードのインベントリを作成したら、その特性に基づいて各インベントリの項目を分類します。この分類により、移行計画の下書きを作成し、最初に移行するエッジデバイスとバックエンド ワークロードを選択できます。
エッジデバイスを分類する場合は、エッジデバイスとバックエンド ワークロードの間で発生する可能性のあるインタラクションの種類に基づいて分類することをおすすめします。次の種類のインタラクションを検討してください。
- エッジデバイスが、テレメトリー イベントまたはデバイスの状態に関する情報を使用して、バックエンド ワークロードにデータを送信する。
- コマンドまたはデバイス構成の更新を使用して、バックエンド ワークロードがエッジデバイスにディレクティブを送信する。
このようなインタラクションでは、インタラクション中に交換されるメッセージ タイプが異なります。ただし、メッセージの目的は類似しています。一部のデバイスでは、エッジデバイスからバックエンド ワークロードにデータ（テレメトリー イベントやデバイスの状態に関する情報など）を送信します。一部のデバイスは、コマンドやデバイス構成の更新などのディレクティブをバックエンド ワークロードからエッジデバイスに送信します。
提案されたインタラクションの種類に基づいて、エッジデバイスに次のカテゴリを使用することをおすすめします。
- 送信専用: テレメトリー イベントまたはデバイスの状態に関する情報を送信するが、バックエンド ワークロードからコマンドやデバイス構成の更新を受信しないエッジデバイス。
- 受信専用: テレメトリー イベントまたはデバイスの状態に関する情報を送信しないが、バックエンド ワークロードからコマンドまたはデバイス構成の更新を受信するエッジデバイス。
- 受信と送信: テレメトリー イベントまたはデバイスの状態に関する情報を送信し、バックエンド ワークロードからコマンドまたはデバイス構成の更新を受信するエッジデバイス。
バックエンド ワークロードを分類する場合、エッジデバイスの分類と同様の方法を使用できます。提案されたインタラクションの種類に基づいて、バックエンド ワークロードに次のカテゴリを使用することをおすすめします。
- 受信専用: エッジデバイスからテレメトリー イベントまたはデバイスの状態に関する情報を受信するが、コマンドまたはデバイス構成の更新を送信しないバックエンド ワークロード。
- 送信専用: テレメトリー イベントまたはデバイスの状態に関する情報を受信しないが、コマンドまたはデバイス構成の更新を送信するバックエンド ワークロード。
- 送信と受信: エッジデバイスからテレメトリー イベントまたはデバイスの状態に関する情報を受信し、コマンドまたはデバイス構成の更新を送信するバックエンド ワークロード。
評価を完了する
インベントリを構築したら、評価フェーズの次の部分を完了する必要があります。
これらのアクティビティを完了してから、以下の説明に進んでください。
移行先の環境のアーキテクチャを設計する
前の評価作業が完了したら、移行先の環境のアーキテクチャを設計します。
このドキュメントでは、移行元の環境を移行先の環境に移行する方法について説明しています。ただし、IoT Core から環境を移行する場合も、新機能とアップデートを計画する機会となります。移行先の環境のアーキテクチャを設計する際は、移行元の環境で発生する可能性のある制限を考慮してください。こうした制限を回避するため、移行先の環境をどのように構成するかを検討してください。また、移行先の環境で必要になる可能性のある新機能も検討できます。
エッジデバイスとバックエンド ワークロードの分類方法に基づいて、移行元環境の評価から追加された補完的な IoT Core ユースケースが見られる場合があります。
- エッジデバイスから Google Cloud で実行されているバックエンドへのデータの取り込み。
- Google Cloud でのエッジデバイス管理バックエンド ワークロードの実行。
移行の複雑さを軽減するために、移行元の環境の評価で明らかになったユースケースに焦点を当てることをおすすめします。たとえば、エッジデバイスからデータを取り込むが、IoT Core デバイス管理機能を使用しない場合は、移行先の環境の設計に集中することをおすすめします。このアプローチでは、データ取り込みのユースケースのみをサポートでき、デバイス管理のユースケースを考慮する必要はありません。
移行先の環境の設計は、移行元の環境に実装した Cloud IoT Core のユースケースと移行先の環境での実装方法によって異なります。次の要素を考慮する必要があります。
- 移行元の環境で両方のユースケースを実装している場合は、1 つのソリューションで両方のユースケースを実装するように移行先の環境を設計できます。また、個別のソリューションを使用して 2 つのユースケースを個別に実装することもできます。
- 移行元の環境で 2 つのユースケースのいずれか 1 つを実装している場合は、そのユースケースを 1 つのソリューションで実装するように移行先の環境を設計できます。
次の図は、移行先の環境のアーキテクチャを設計する方法を検討する際の質問事項を示しています。
上の図を要約すると次のようになります。
エッジデバイスからのデータの取り込みと、エッジデバイスの管理の両方が必要か
- 該当する場合は次の質問に進みます。
- 該当しない場合は、エッジデバイス管理のユースケースの質問に進みます。
データの取り込みとエッジデバイス管理の両方のユースケースの実装に、単一のソリューションが必要か？
- 該当する場合、データの取り込みとエッジデバイス管理の両方に対応するソリューションを Google Cloud にデプロイします。
- 該当しない場合、Google Cloud にエッジデバイス管理ソリューションをデプロイし、データ取り込みのユースケースの評価の質問に進みます。
エッジデバイスを管理する必要があるか？
- 該当する場合、Google Cloud にエッジデバイス管理ソリューションをデプロイし、データ取り込みのユースケースの評価の質問に進みます。
- 該当しない場合、データ取り込みのユースケースの評価の質問に進みます。
エッジデバイスからデータを取り込む必要があるか？
- 該当する場合、次の質問に進みます。
- 該当しない場合、移行を完了しているか、移行元の環境を移行する必要はありません。いずれの場合も、移行元の環境を廃止できます。
優先される通信プロトコルは何か？
- MQTT の場合は、MQTT ブローカーを Google Cloud にデプロイします。
- HTTP または gRPC の場合、Pub/Sub を使用してエッジデバイスからデータを取り込みます。
- それ以外の場合は、任意の通信プロトコルと互換性のあるデータ取り込みソリューションを評価してください。
移行先の環境のアーキテクチャを設計する際は、次の点を考慮してください。
- アーキテクチャのコンポーネントを管理するには知識と労力が必要です。移行先の環境を考慮するために必要な追加リソースの数を評価することをおすすめします。
- 多数のエッジデバイスのプロビジョニングには、セキュリティ、スケーラビリティ、運用上の課題があります。エッジデバイスのプロビジョニングの詳細については、エッジシステム、ベアメタル システム、サーバーの自動プロビジョニングと構成に関するベスト プラクティスをご覧ください。
- Pub/Sub を使用してエッジデバイスからデータを取り込むと、分散メッセージング プラットフォームの管理とスケーリングから解放されます。Pub/Sub を使用してエッジデバイスからデータを取り込む場合、特に、多数のデバイスからデータを取り込む必要がある場合は、Pub/Sub 割り当てと上限の両方を考慮してください。
移行先の環境に対してエッジデバイスを認証し、その ID を管理するため、移行先の環境でサポートされている認証方法と認証情報を評価することをおすすめします。移行元の環境の IoT Core で使用しているものとの比較してください。
この情報を収集したら、IoT バックエンド セキュリティ ガイドのガイダンスに従って、エッジデバイスの認証と ID の管理メカニズムを設計し、実装することをおすすめします。
最初に移行するエッジデバイスとバックエンド ワークロードを選択する
移行先の環境のアーキテクチャを設計したら、次のものを定義します。
- 最初に移行するエッジデバイスとバックエンド ワークロードのカテゴリ。
- 移行バッチ（移行元の環境から移行先の環境に移行する項目のグループ）。
最初に移行するエッジデバイスのカテゴリを定義する
エッジデバイスとバックエンド ワークロードのカテゴリでは、移行するためのさまざまな課題や困難が発生する場合があります。一例として、送信専用エッジデバイスの移行があります。これは、受信エッジと送信エッジデバイスの移行よりも簡単な場合があります。
最初に移行するエッジデバイスとバックエンド ワークロードのカテゴリの選択方法をより深く理解するには、最初に移行するアプリの選択をご覧ください。
このセクションでは、最初に移行するデバイスを決定する際に、各エッジデバイス カテゴリで考慮すべき事項について説明します。
送信専用のエッジデバイス
これらのエッジデバイスは、MQTT または HTTP のいずれかを使用して、テレメトリー イベントとデバイスの状態に関する情報を送信します。
デバイスで MQTT を使用している場合は、移行先の環境で MQTT ブローカーに接続して認証を行うため、構成の更新のみを行えばよい場合があります。移行先の環境の MQTT ブローカーを使用して、テレメトリー イベントとデバイスの状態に関する情報をパブリッシュできます。場合によっては、移行先の環境に MQTT ブローカーがなく、サードパーティ ソリューションなど、別の種類の移行先環境に移行しなければならないことがあります。この場合は、ソリューションが提供する機能と統合インターフェースを評価する必要があります。その後、適切な移行計画を設計して実装できます。
デバイスで HTTP を使用する場合は、移行先の環境に接続して認証するように構成の更新が必要になることがあります。IoT Core API を使用した場合と比較して、移行先の環境でデバイスがどのように通信するかのセマンティクスのリファクタリングが必要になる場合もあります。たとえば、移行先の環境で Pub/Sub を使用している場合、Pub/Sub トピックへメッセージをパブリッシュするための IoT Core API の使用から、同じ目的のための Pub/Sub API の使用に移行する場合があります。場合によっては、移行先の環境で Pub/Sub を使用しないため、サードパーティ ソリューションなど、別の種類の移行先環境に移行しなければならないことがあります。この場合、適切な移行計画を設計して実装するために、サードパーティ ソリューションが提供する機能と統合インターフェースを評価する必要があります。
受信専用のエッジデバイス
これらのエッジデバイスは、MQTT を使用してコマンドを受け取り、MQTT または HTTP を使用して構成の更新を受信します。IoT Core では、HTTP を使用してコマンドを送信することはできません。
デバイスで MQTT を使用してコマンドと構成の更新を受信する場合は、前述のエッジデバイス カテゴリと同様の考慮事項が適用されます。このカテゴリのエッジデバイスを移行するには、移行先の環境で MQTT ブローカーに接続して認証するようにエッジデバイスの構成を更新します。IoT Core がコマンドとデバイス構成の更新をパブリッシュする MQTT トピックのサブスクライブを継続します。場合によっては、移行先の環境に MQTT ブローカーがなく、サードパーティ ソリューションなど、別の種類の移行先環境に移行しなければならないことがあります。この場合、適切な移行計画を設計して実装するために、ソリューションが提供する機能と統合インターフェースを評価する必要があります。
デバイスが HTTP を使用して構成の更新を受信する場合は、以前のエッジデバイス カテゴリと同様の考慮事項が適用されます。このカテゴリのエッジデバイスを移行するには、移行先の環境に接続して認証するように構成の更新が必要になることがあります。構成の更新を受信するには、IoT Core API を使用した場合と比較して、移行先の環境の違いを考慮するために、通信のセマンティクスのリファクタリングが必要になることもあります。たとえば、サードパーティのソリューションなど、別の種類の移行先環境に移行する場合は、適切な移行計画を設計して実装するために、ソリューションが提供する機能と統合インターフェースを評価する必要があります。
受信と送信のエッジデバイス
これらのエッジデバイスは、バックエンド ワークロードからのデータ コンシューマであり、エッジデバイスが受信するデータのプロデューサーでもあるため、移行が最も難しくなる可能性があります。この場合、前述のエッジデバイスのカテゴリを移行するための考慮事項が適用されるため、このバックエンド ワークロードのカテゴリの移行は特別な注意が必要です。
最初に移行するエッジデバイスのカテゴリを選択した後、最初に移行するバックエンド ワークロードのカテゴリを選択します。
受信専用のバックエンド ワークロード
これらのバックエンド ワークロードは、テレメトリー イベントまたはデバイスの状態に関する情報を生成するエッジデバイスから分離されているため、比較的簡単に移行できます。その理由は次のとおりです。
- バックエンド ワークロードは Pub/Sub トピックにサブスクライブします。この理由から、デバイスは、これらの情報のプロデューサーについて知る必要がありません。エッジデバイスの構成やエッジデバイスで実行するソフトウェアを更新する必要がない場合があります。
- バックエンド ワークロードは、エッジデバイスにコマンドやデバイス構成の更新を送信しません。したがって、これらのバックエンド ワークロードの移行時に、このユースケースを考慮する必要はありません。
- メッセージをパブリッシュまたは使用するために、既存の Pub/Sub トピックを保持する場合があります。このような場合、移行先の環境がテレメトリー イベントとデバイスの状態に関する情報をこれらの Pub/Sub トピックに転送し続けると、バックエンド ワークロードが既存の Pub/Sub トピックにサブスクライブしたままになります。
送信専用のバックエンド ワークロード
これらのバックエンド ワークロードには、コマンドとデバイス構成の更新を送信するときにエッジデバイスがどのように動作するか、および移行先の環境に移行する方法を理解するために、包括的な評価が必要です。たとえば、MQTT ブローカーを使用して移行先の環境に移行する場合、こうしたバックエンド ワークロードは、IoT Core API を使用したコマンドやデバイス構成の更新を送信して、MQTT を介してメッセージをパブリッシュする場合があります。場合によっては、エッジデバイスでソフトウェアや構成の更新を実行する必要はありません。たとえば、バックエンド ワークロードがコマンドと構成の更新を同じ形式で、同じ MQTT トピックにパブリッシュし、IoT Core が移行元の環境でコマンドとデバイス構成の更新に関するメッセージをパブリッシュする場合などです。サードパーティのソリューションなど、別の種類の移行先環境に移行する場合は、適切な移行計画を設計して実装するために、ソリューションが提供する機能と統合インターフェースを評価する必要があります。
送信と受信のバックエンド ワークロード
これらのバックエンド ワークロードはエッジデバイスからのデータ コンシューマであり、エッジデバイスから受信するデータのプロデューサーでもあるため、移行が最も難しくなる可能性があります。この場合、前述のバックエンド ワークロードのカテゴリを移行する際の考慮事項が両方とも適用されるため、このバックエンド ワークロードのカテゴリの移行を処理する場合は特別な注意が必要です。
移行バッチを定義する
1 つのバッチで多数の項目を移行する際のリスクと複雑さを軽減するには、移行のバッチで移行する項目を各カテゴリで分割します。移行のバッチを計画するには、次のことを行います。
同種の項目をグループ化して移行のバッチを設計する: 移行する項目をバッチでグループ化するには、移行のバッチ項目が共通になるように、一連の条件を選択することをおすすめします。たとえば、エッジデバイスは、次のようにバッチでグループ化できます。
- デプロイ リージョン
- デバイスが登録されている IoT Core レジストリ
- 意味のある IoT Core デバイスのメタデータが設定されているかどうか
- デバイスのデプロイ状態
各移行バッチのサイズを決定する: 移行する項目のカテゴリごとに、そのカテゴリの最初の移行バッチを比較的小さく計画することをおすすめします。移行中に経験を積み、慣れてきたら、バッチのサイズを大きくします。
移行バッチでアドホック戦略が必要かどうかを評価する: 移行バッチで移行する項目をグループ化する方法に応じて、特定の移行バッチに適用する移行戦略は、このバッチの項目の特性に依存する場合があります。たとえば、デプロイ状態ごとにグループ化されたエッジデバイスを移行するには、次の点を考慮する必要があります。
- デバイスが製造されていない場合は、メーカーに依頼して、移行先の環境に移行するための構成とソフトウェアを更新するよう依頼します。
- デバイスをデプロイする準備ができているが、まだ IoT Core に登録されていない場合は、デプロイ担当者にこれらのエッジデバイスをリコールするように指示できます。その後、構成とソフトウェアを更新して、移行先の環境に移行できます。
- デバイスがすでに移行先のサイトにデプロイされ、IoT Core に登録されている場合は、構成とソフトウェアを更新して、リモートまたはオンサイトの移行先環境に移行できます。
基盤の計画と構築
計画と構築フェーズでは、次のように Google Cloud 上のワークロードをサポートするクラウド インフラストラクチャとサービスをプロビジョニングして構成します。
- リソース階層を構築する。
- Identity and Access Management を構成する。
- お支払い情報を設定する。
- ネットワーク接続を設定する。
- セキュリティを強化する。
- モニタリングとアラートを設定する。
ワークロードとその依存関係をサポートするクラウド インフラストラクチャとサービスの構築方法については、Google Cloud への移行: 基盤の構築をご覧ください。これらのガイドラインに従って環境の基盤を構築します。その後、このドキュメントの次のセクションで説明するアクティビティを行います。
エッジデバイスとバックエンド ワークロードを移行する
移行先の環境の基盤を構築した後、エッジデバイスとバックエンド ワークロードを移行先の環境に移行するために、次のことを行う必要があります。
- 移行先の環境のアーキテクチャを実装するためのリソースをプロビジョニングして構成する: 移行プロセスの最初のステップとして、新しいプラットフォームのインフラストラクチャを作成して設定します。
- エッジデバイスとバックエンド ワークロードを移行先の環境に移行する: 移行先の環境の準備が整ったことを確認したら、バックエンド ワークロードとエッジデバイスを移行先の環境に移行します。移行先の環境のアーキテクチャとユースケースによっては、移行方法が異なる場合があります。このドキュメントでは、移行元と移行先の環境を一定期間共存させる 2 段階の移行戦略について説明します。このアプローチでは、移行中にエラーが発生した場合、移行元の環境にロールバックできます。
- 移行元の環境を廃止する: 移行先の環境が完全に稼働していることを確認したら、移行元の環境を廃止します。
移行先の環境のアーキテクチャのリソースをプロビジョニングして構成する
このフェーズでは、移行先の環境をプロビジョニングして構成します。移行先の環境のアーキテクチャを設計するで説明しているように、移行先の環境のアーキテクチャは次のように要約できます。
- Google Cloud 上で動作する MQTT ブローカー: Google Cloud で MQTT ブローカーを実行し、テレメトリー イベントとデバイスの状態に関する情報を MQTT ブローカーからバックエンド ワークロードに転送します。バックエンド ワークロードは、コマンドとコントロールを MQTT トピックにパブリッシュします。
- Pub/Sub: エッジデバイスがテレメトリー イベントとデバイスの状態に関する情報を Pub/Sub にパブリッシュし、Pub/Sub からコマンドを受信します。
- サードパーティのデータ取り込みおよびデバイス管理プラットフォーム: テレメトリー イベント、デバイス状態の取り込みとデバイス管理に関する情報用にサードパーティ ソリューションを設定します。
各アーキテクチャの詳細については、Google Cloud 上のコネクテッド デバイス アーキテクチャをご覧ください。
エッジデバイスとバックエンド ワークロードを移行先の環境に移行する
移行先の環境にリソースをプロビジョニングして構成した後、エッジデバイスとバックエンド ワークロードを移行先の環境に移行します。このセクションでは、エッジデバイスとバックエンド ワークロードを移行元の環境から移行先の環境に移行します。移行元と移行先の環境は、移行元の環境を廃止するまで共存させます。
ダウンタイムを削減するため、移行プロセスは次のフェーズで行います。
- 移行元の環境と移行先の環境をモニタリングする。
- エッジのデバイス メタデータ情報を移行元の環境から移行先の環境に移行する。これには、デバイスの認証情報、デバイス構成、デバイスの状態が含まれます。
- 移行元の環境と移行先の環境の両方に接続するようにエッジデバイスを更新する。
- 移行元の環境から移行先の環境にバックエンド ワークロードを移行する。
- 移行元の環境のみに接続するようにエッジデバイスを更新する。
各移行フェーズで移行元と移行先の両方の環境をモニタリングし、各フェーズの結果を確認してから次のフェーズに進むことをおすすめします。
環境のモニタリングに加えて、ブラックボックス テストを導入し、環境が想定どおりに動作するかどうかを確認することをおすすめします。このようなテストの例として、バックエンド ワークロードが特定のイベント（摂氏 50 度を超える温度など）を検出したときに通知メールをオペレーターに送信するユースケースがあります。摂氏 50 度を超える気温を示すテレメトリー データを含むテストケースを作成し、バックエンド ワークロードがオペレーターにメールを送信するかどうかをテストできます。
移行元の環境と移行先の環境をモニタリングする
移行元と移行先の環境をモニタリングするには、次の指標を検討することをおすすめします。
- アクティブなデバイス数: IoT Core に最近データを送信したデバイスの数。
- デバイス通信エラー数: エラータイプ別にグループ化された、特定の期間にバックエンド ワークロードがエッジデバイスとの通信中に発生したエラーの数。この指標は、バックエンド ワークロードでエッジデバイスとの通信に問題があるかどうかを確認するのに役立ちます。
- デバイスのオペレーション数: 特定の期間内にエッジデバイスで実行されたオペレーションの数（接続や切断のリクエスト、メッセージのパブリッシュなど）。オペレーションのタイプ別にグループ化します。この指標は、エッジデバイスが期待どおりに動作しているかどうかを確認するのに役立ちます。たとえば、デバイスのエラー数とデバイスのオペレーション数の両方が増加している場合、環境には、エッジデバイスへのメッセージ送信に問題がある場合があります。
- 受信バイト数: 特定の期間にエッジデバイスから受信したバイト数。この指標は、上り（内向き）ネットワーク トラフィックの統計情報の推論に役立ちます。
- 送信バイト数: エッジデバイスに送信されたバイト数のデルタカウント。この指標は、下り（外向き）ネットワーク トラフィックの統計情報の推論に役立ちます。
- メッセージ スループット: 特定の期間にバックエンド ワークロードによって処理されたメッセージ数。この指標は、エッジデバイスとバックエンド ワークロード間のトラフィック量に応じて環境がスケーリングされるかどうかを確認するのに役立ちます。たとえば、アクティブなデバイス数とデバイス オペレーション数の両方が増えても、メッセージ スループットが過度に変化していない場合は、増加するメッセージを処理するのに十分なリソースがバックエンド ワークロードにあるかどうか確認する必要があります。
- メッセージ配信レイテンシ: エッジデバイスがメッセージをパブリッシュしてから、バックエンド ワークロードがメッセージを受信するまでに経過した時間。たとえば、レイテンシの値が増加した場合は、メッセージ配信を遅らせる問題がないかどうか確認します。
- 配信不能メッセージ数: エッジデバイスとバックエンド ワークロードに配信できないメッセージの数。コンシューマにメッセージを配信できない場合、エッジデバイスまたはバックエンド ワークロードが応答していない可能性があります。
- クラウド リソース割り当て使用量: クラウド リソース割り当ての使用状況をモニタリングして、環境にスケーリングするのに十分なリソースがあることを確認します。
移行元の環境をモニタリングする
Cloud Monitoring は、IoT Core と Pub/Sub から指標を自動的に収集します。たとえば、IoT Core では device/active_devices、device/error_count、device/operation_count 指標を公開します。このデータは、移行元の環境に接続されているエッジデバイスの数や、IoT Core との通信でエラーが発生しているエッジデバイスの数を把握するのに役立ちます。device/received_bytes_count 指標と device/sent_bytes_count 指標は、ネットワーク帯域幅の使用量のモニタリングに役立ちます。
メッセージ配信のステータスと正常性をモニタリングするには、Monitoring Query Language を使用して、サブスクリプションの配信レイテンシの健全性スコア、メッセージ スループット、配信不能メッセージを測定します。
移行先の環境をモニタリングする
移行先の環境をモニタリングして、移行が成功したかどうかを調べます。移行先の環境のアーキテクチャに応じて、MQTT ブローカーまたはサードパーティ IoT プラットフォームが次の指標を提供する場合があります。
MQTT ブローカー: 移行先の環境が MQTT ブローカーに基づいている場合、ブローカーはエッジデバイスとメッセージ配信に関する指標を提供する場合があります。送受信されたバイト数をモニタリングするには、Cloud Load Balancing が提供する指標をご覧ください。MQTT ブローカーが GKE クラスタで実行されている場合は、Cloud Monitoring を構成して、Monitoring に送信する指標を定義できます。MQTT ブローカーが Compute Engine インスタンスで実行されている場合は、デフォルトのダッシュボードを使用するか、Ops エージェントをインストールして Cloud Monitoring インスタンスから詳細なテレメトリーを収集できます。
Pub/Sub: 移行先の環境が Pub/Sub に基づく場合は、Pub/Sub トピックとサブスクリプションを使用します。たとえば、Monitoring Query Language を使用して、クエリを実行し、サブスクリプションの配信レイテンシの健全性スコア、メッセージのスループット、配信不能メッセージを取得できます。
IoT プラットフォーム: 移行先の環境が IoT プラットフォームに基づいている場合、プラットフォームがエッジデバイスとメッセージ配信に関する情報を提供する場合があります。サードパーティの IoT プラットフォームが GKE クラスタで実行されている場合は、Logging と Monitoring を構成して、Cloud Monitoring に送信する指標を構成できます。サードパーティの IoT プラットフォームが Cloud Monitoring インスタンスで実行されている場合は、デフォルトのダッシュボードを使用するか、Ops エージェントをインストールして Cloud Monitoring インスタンスから詳細なテレメトリーを収集できます。
エッジデバイスのメタデータ情報を移行元の環境から移行先の環境に移行する
新しい IoT プラットフォームに移行するには、エッジデバイスのメタデータ情報を移行先の環境に移行します。エッジデバイスのメタデータを移行する場合は、次のメタデータ カテゴリを検討してください。
デバイス認証情報: IoT Core は、鍵ペアと有効期間の短いトークンを使用してエッジデバイスを認証します。移行先の環境で必要な手順に沿って、移行先の環境にデバイスを登録し、認証メカニズムに従って移行先の環境でデバイスの認証情報を作成します。
デバイス構成: 移行先の環境がデバイス構成サービスを提供するサードパーティの IoT プラットフォームであり、ユースケースで、最新の望ましい状態でエッジデバイスを構成しなければならない場合があります。この場合は、デバイス構成を移行先の環境に移行する必要があります。移行中に、デバイス構成が移行元の環境と移行先の環境の間で同期していることを確認します。移行先の環境が MQTT ブローカーまたは Pub/Sub に基づいており、デバイス構成を管理する手段がない場合は、Cloud Storage バケットにデバイス構成を長期間保存する場合があります。
デバイスの状態に関する情報: 移行先の環境に初めて接続する際に、エッジデバイスがデバイスの状態を更新して、デバイスの状態に関する最新の情報が移行先の環境に含まれるようにします。
この手順が完了したら、必要なデバイス情報と認証情報が正しく構成され、エッジデバイスが移行先の環境に接続して認証できることを確認します。
移行元の環境と移行先の環境の両方に接続するようにエッジデバイスを更新する
この段階に達すると、移行先の環境はエッジデバイスからの接続を受け入れる準備が整います。レメトリー イベントとデバイスの状態に関する情報を送信するために、移行元と移行先の両方の環境に接続するようにエッジデバイスを更新できます。エッジデバイスを更新する場合のアプローチはエッジデバイスのカテゴリによって異なります。
テレメトリー イベントまたはデバイスの状態に関する情報を送信するが、バックエンド ワークロードからコマンドやデバイス構成の更新を受信しないエッジデバイスの場合は、次の操作を行います。
- エッジデバイスを更新して、テレメトリー イベントとデバイスの状態に関する情報を移行元と移行先の両方の環境に送信するようにします。
- 移行先の環境でテレメトリー イベントとデバイスの状態に関する情報が正しく受信されることを確認します。
逆に、テレメトリー イベントやデバイス状態に関する情報を送信しないが、バックエンド ワークロードからコマンドや構成の更新を受信するエッジデバイスの場合は、次の操作を行います。
- エッジバイスを更新して、移行先の環境からコマンドと構成の更新を受信します。
- エッジデバイスがコマンド実行または構成更新の結果を移行先の環境に報告していることを確認します。
- 移行先の環境からエッジデバイスにコマンドと構成の更新を送信します。
- コマンドと構成の更新が正常に実行されたことを確認します。
テレメトリー イベントとデバイスの状態に関する情報の両方を送信し、さらに、バックエンド ワークロードからコマンドまたは構成の更新を受信するエッジデバイスの場合は、次の操作を行います。
- エッジデバイスを更新して、テレメトリー イベントとデバイスの状態に関する情報を移行元と移行先の両方の環境に送信するようにします。
- 移行先の環境でテレメトリー イベントとデバイスの状態に関する情報が正しく受信されることを確認します。
- エッジバイスのコードを更新して、移行先の環境からコマンドと構成の更新を受信します。
- エッジデバイスがコマンド実行または構成更新の結果を移行先の環境に報告していることを確認します。
- 移行先の環境からエッジデバイスにコマンドと構成の更新を送信します。
- コマンドと構成の更新が正常に実行されたことを確認します。
これらの手順をユースケースに対して実行した後、エッジデバイスのすべてのカテゴリで次の処理を行います。
- 移行元と移行先の環境の両方に接続します。
- テレメトリー イベントとデバイスの状態に関する情報を移行元と移行先の両方の環境に送信します。
- バックエンド ワークロードをまだ移行していない場合にのみ、移行元の環境からコマンドと構成の更新を受信します。
バックエンド ワークロードが、移行元と移行先の両方の環境に送信する同じメッセージを処理するシナリオは避けることをおすすめします。移行先の環境のメッセージ保持期間は、できるだけ最小の値に構成することをおすすめします。このアプローチにより、移行先の環境が期待どおりに機能していることを確認できます。また、バックエンド ワークロードを移行する前に、移行先の環境のメッセージが期限切れになっていることも確認できます。移行先の環境では、次の移行ステップの後にメッセージ保持の構成を調整できます。
技術的または規制上の理由により、エッジデバイスが移行元と移行先の両方の環境に同時に接続できない場合は、最初に移行元の環境から切断するようにエッジデバイスを構成します。その後、移行先の環境にのみ接続できます。この場合、移行元の環境にまだ接続されているバックエンド ワークロードは、エッジデバイスからのテレメトリー イベントとデバイスの状態に関する情報の受信を停止します。デバイスからエッジデバイスにコマンドや構成の更新を送信できなくなります。
また、バッファ ストレージ メカニズムをプロビジョニングして構成することをおすすめします。このアプローチにより、バックエンド ワークロードが移行元の環境に接続されているときに、デバイスがテレメトリー イベントやデバイス状態に関する情報を移行先の環境に送信するときにデータが失われるのを防ぐことができます。バックエンド ワークロードは、移行先の環境に接続するときにこの情報を利用できます。たとえば、MQTT ブローカー、Pub/Sub、IoT プラットフォームに基づいて、移行先の環境のメッセージ保持を構成できます。このアプローチでは、次のセクションで説明するように、移行の次の段階を完了するために必要な時間内に、確認応答していないメッセージを保持できます。
バックエンド ワークロードを移行元の環境から移行先の環境に移行する
バックエンド ワークロードを移行先の環境に移行します。移行先の環境のアーキテクチャに応じて、ワークロードの移行アプローチが異なります。
Google Cloud での MQTT ブローカー: 移行先の環境が MQTT ブローカーをベースとしている場合は、次の要因に基づいて移行方法が決まります。
- エッジデバイスからテレメトリー イベントやデバイス状態に関する情報を受信するが、コマンドやデバイス構成の更新を送信しないバックエンド ワークロードの場合: エッジデバイスから送信されるテレメトリー イベントとデバイスの状態に関する情報を受信するために MQTT トピックにサブスクライブするようにバックエンド ワークロードを構成します。
- 逆に、テレメトリー イベントやデバイス状態に関する情報を受信しないが、コマンドやデバイス構成の更新を送信するバックエンド ワークロードの場合: 移行先の環境でコマンドと構成の更新のためにコマンドと構成の更新を MQTT トピックに送信するために、メッセージをパブリッシュするようにバックエンド ワークロードを構成します。
- エッジデバイスからテレメトリー イベントまたはデバイスの状態に関する情報を受信し、さらに、コマンドまたはデバイス構成の更新を送信するバックエンド ワークロードの場合: テレメトリーを受信するために MQTT トピックにサブスクライブするようにバックエンド ワークロードを構成してから、コマンドと構成の更新を MQTT トピックに送信するためにメッセージをパブリッシュするようにバックエンド ワークロードを構成します。
Pub/Sub: 移行先の環境が Pub/Sub をベースとしている場合、次の要因に基づいて移行方法が決まります。
- エッジデバイスからテレメトリー イベントまたはデバイスの状態に関する情報を受信するが、コマンドまたはデバイス構成の更新を送信しないバックエンド ワークロードの場合: 移行先の環境で Pub/Sub サブスクリプションを作成し、新しく作成したサブスクリプションを使用するようにバックエンド ワークロードを更新します。
- 逆に、テレメトリー イベントまたはデバイスの状態に関する情報を受信しないが、コマンドまたはデバイス構成の更新を送信するバックエンド ワークロードの場合: Pub/Sub トピックを作成し、コマンドと構成の更新を Pub/Sub トピックに送信するためにメッセージをパブリッシュするようにバックエンド ワークロードを構成します。
- エッジデバイスからテレメトリー イベントまたはデバイスの状態に関する情報を受信し、さらに、コマンドまたはデバイス構成の更新を送信するバックエンド ワークロードの場合: テレメトリー イベントとデバイスの状態に関する情報を受信するために Pub/Sub トピックにサブスクライブするようにバックエンド ワークロードを構成します。次に、コマンドと構成の更新を Pub/Sub トピックに送信するためにメッセージをパブリッシュするようにバックエンド ワークロードを構成します。
サードパーティの IoT プラットフォーム: 移行先の環境がサードパーティの IoT プラットフォームに基づいている場合は、サードパーティの IoT プラットフォームの手順に沿って、バックエンド ワークロードと IoT プラットフォーム間の統合を設定する必要があります。次に、バックエンド ワークロードが、エッジデバイスから送信されるテレメトリー イベントとデバイスの状態に関する情報を受信できることを確認します。また、バックエンド ワークロードがメッセージをパブリッシュして、コマンドまたはデバイス構成の更新をエッジデバイスに送信できることも確認します。
エッジデバイスとバックエンド ワークロードが期待どおりに動作していることを確認するには、次のことを行うことをおすすめします。
- バックエンド ワークロードが、テレメトリー イベントとデバイスの状態に関する情報を受信し、正しく対応していることを確認します。たとえば、バックエンド ワークロードで、特定のテレメトリー データをモニタリングするためにほぼリアルタイムのダッシュボードが生成される場合、ダッシュボードが最新のデータ期間で更新されていることを確認します。
- バックエンド ワークロードがコマンドと構成の更新をエッジデバイスに正常に送信していることを確認します。エッジデバイスも想定どおりに対応していることを確認します。
- エッジデバイスがテレメトリー イベントとデバイスの状態に関する情報を移行先の環境に報告するかどうかを確認します。
この時点で、バックエンド ワークロードは次の処理を行います。
- 移行先の環境に接続します。
- 移行先の環境から、エッジデバイスからのテレメトリー イベントとデバイスの状態に関する情報を受信します。
- 移行先の環境からエッジデバイスにコマンドと構成の更新を送信します。
これで、エッジデバイスを移行元と移行先の両方の環境に接続するときに、最小値に設定した移行先の環境のメッセージ保持の構成を更新し、必要に応じて設定できるようになりました。
移行先の環境からテレメトリー イベントとデバイスの状態に関する情報を受信するようにバックエンド ワークロードを更新した場合、この更新された構成を適用するのに時間を要する場合があります。移行フェーズでは、バックエンド ワークロードは、エッジデバイスが送信したテレメトリー イベントとデバイスの状態に関する情報を使用できません。ユースケースで完全なデータの整合性が求められる場合は、バックエンド ワークロードの構成を更新する前に、移行先の環境のメッセージ保持期間の構成が必要になることがあります。このアプローチにより、バックエンド ワークロードが新しい構成を適用してメッセージを使用する前に、メッセージが期限切れになることがなくなります。
移行先の環境のみに接続するようにエッジデバイスを更新する
この時点で、エッジデバイスは移行先の環境に正常に移行されていますが、まだ移行元の環境を使用しています。移行手順を完了するには、IoT Core への接続と統合を削除することにより、移行先の環境にのみ接続するようにエッジデバイスを更新します。この更新が完了すると、エッジデバイスは移行先の環境にのみ接続します。
移行元の環境を廃止する
エッジデバイスとバックエンド ワークロードを移行先の環境に移行し、移行先の環境を検証したら、移行元の環境を廃止します。
移行元の環境を廃止するには、次のことを行います。
- IoT Core トピックにサブスクライブする Pub/Sub サブスクリプションを削除します。
- 未使用の Pub/Sub トピックを削除します。Pub/Sub トピックを再利用する場合は、IoT Core によって作成されたトピックを削除しないでください。IoT Core で使用されている Pub/Sub トピックは、IoT Core コンソールで確認できます。
- IoT Core デバイスとレジストリを削除します。
移行後の環境を最適化する
最適化が移行の最終フェーズになります。このフェーズでは、環境を以前よりも効率的なものにします。そのために、反復可能な手順を環境が最適化の要件を満たすまで複数回繰り返し実施します。この反復可能な手順は、次のとおりです。
- 現在の環境、チーム、最適化ループを評価する。
- 最適化の要件と目標を設定する。
- 環境とチームを最適化する。
- 最適化ループを調整する。
以降のセクションは、Google Cloud への移行: 環境の最適化に基づいています。
移行先の環境、チーム、最適化ループを評価する
最初の評価では移行元の環境に焦点を当てますが、この評価フェーズは最適化フェーズを対象としています。移行先の環境、チーム、最適化ループを評価する方法については、環境、チーム、最適化ループを評価するをご覧ください。
最適化の要件を確立する
移行先の環境で行う必要がある最適化要件を確認します。
- 自動スケーリングを設定する: マネージド インスタンス グループ、Google Kubernetes Engine などの Google Cloud サービスを使用して、負荷が増加したときに IoT ソリューションとバックエンド ワークロードを自動的に水平方向または垂直方向にスケーリングします。この方法により、デバイスの登録とテレメトリーのデータ ストレージが、大規模なデバイス フリートのデプロイ時に大量のデータを処理できるようになります。Spanner は分散型で可用性が高くスケーラブルなトランザクション データベースであるため、テレメトリー データとデバイス登録情報の保存に適しています。
- ロギングとモニタリングのメカニズムを強化する: ロギングとモニタリングのメカニズムを最適化して統合し、一元化されたソリューションを形成します。また、特定のモニタリング指標を改善して、エッジデバイスと IoT ソリューションの相互作用を把握することもできます。接続イベント、切断イベント、テレメトリー イベントなどのアクティビティを記録し、関連付ける必要があります。システムエラーやアプリケーション エラーをモニタリングすることもおすすめします。可能であれば、システムレベルで特定の重大な障害が発生した場合のアラートを設定します。
- Google Cloud セキュリティ サービスを使用してワークロードを保護する: Security Command Center は、脆弱性と脅威の報告を一元的に行うサービスであり、セキュリティとデータの攻撃対象領域を評価することによって、セキュリティ ポスチャーの強化に役立ちます。アセット インベントリと検出が提供されるので、構成ミス、脆弱性、脅威を特定するのに役立ちます。Security Command Center では、リスクを軽減して修正することもできます。Google Kubernetes Engine（GKE）で実行されるワークロードを保護する方法については、Google Kubernetes Engine のセキュリティの概要で GKE ワークロードの保護方法をご覧ください。
最適化を実施する
最適化要件のリストを作成した後、最適化フェーズを完了します。方法については、Google Cloud への移行: 環境の最適化をご覧ください。
次のステップ
- Google Cloud 上のコネクテッド デバイス アーキテクチャについて読む。
- エッジシステム、ベアメタル システム、サーバーのプロビジョニングと構成を自動的に行うためのベスト プラクティスについて学習する。
- 移行計画の検証に関するベスト プラクティスについて読む。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
- 環境のセキュリティを強化するためのオプションを理解する。