Amazon Web Services ブログ

AWS での IoT ワークロードのデプロイと管理

はじめに

モノのインターネット ( IoT ) ワークロードを導入しようとする場合、企業はプラットフォームを複数の選択肢から選択することになります。この選択肢はさまざまで、独自デバイスのハードウェアを含めて完全にゼロから構築する方法や、事前に設定されたハードウェアを購入して、完全な SaaS (Software as a Service) IoT プラットフォームに接続するような方法があります。

このブログの目的は、IoT ソリューションの設計に必要なスキルや知識を理解し、どのコンポーネントを自前で開発して、どのコンポーネントを外部の技術ソリューションとして買ってくるのかを判断できるようにすることです。IoT ワークロードを AWS に移行しようと考えている場合は、 「 AWS IoT Core へのシームレスな移行を計画する 」 をご参照ください。 AWS を利用することによる、移行プロセスの簡略化、提供可能なサポート、得られるメリットなどを理解するための最初のステップとして役立ちます。

一般的な AWS IoT アーキテクチャのコンポーネント

A diagram that shows the common components for an IoT device and AWS Cloud.

デバイスの製造

ハードウェアの設計と製造では、考慮すべき要素がいくつかあります。 要件に基づき、ソリューションの現在および将来のニーズを満たすためにハードウェアを選択する必要があります。 IoT の一般的な制約、つまり電力(供給と消費)、接続性、セキュリティ、オペレーティングシステムの管理に関する意思決定が必要です。

ハードウェアを社内で製造していない場合、オリジナルデバイスメーカー ( ODM ) を選択する必要があります。ODM には、大量のデバイスを生産するための製造ライン、ツール、プロセスが揃っています。 通常、プリント基板 ( PCB ) の回路図、部品表、ファームウェア、プロビジョニング要件など、提供する仕様に基づいて製造できます。

デバイスのハードウェア制約を考慮する項目 :

  • 消費電力 : デバイスの使用方法と場所は、電源供給に大きな影響を与えます。ウェアラブルデバイスは小さなバッテリーで動作しますが、テレビは AC 電源を必要とします。バッテリーを必要とするデバイスの場合、バッテリーが再充電可能か交換可能か、ハードウェアの寿命まで利用可能かを判断する必要があります。
  • オペレーティングシステムとファームウェア : オペレーティングシステムやファームウェアの選択は、デバイスの種類と期待されるタスクによって異なります。小型で低消費電力のデバイスは FreeRTOS などのリアルタイムオペレーティングシステムが必要かもしれませんし、大型で専用の電源を必要とするデバイスは Linux などのフルスタックオペレーティングシステムが必要になる場合もあります。
  • 接続性 : IoT ソリューションには、イーサネット、Wi-Fi 、セルラー、LoRaWAN 、Bluetooth Low Energy ( BLE ) など、多くの接続性とプロトコルのオプションがあります。デバイスの設置場所、可用性、消費電力、セキュリティ、ユースケースによって、ソリューションに最適な接続オプションが決まります。

AWS ではこのコンポーネントを支援するために、AWS デバイス認定プログラム を完了した AWS パートナー製デバイスのリストである AWS Partner Device Catalog を提供しています。 このリストにあるデバイスは、AWS IoTとAWSのベストプラクティスとの互換性を確保し、市場への投入を高速化するのに役立ちます。さらに、自社製造のデバイスをお持ちの場合は、AWS IoT Core Device Advisor を使用して、AWS IoT Core と確実かつ安全に接続できることを検証できます。

デバイスのプロビジョニング

IoT ソリューションにおけるデバイスのプロビジョニング方法は、デバイスの機能とその製造プロセスによって異なります。ここでの主な焦点は、デバイスとその認証情報の作成方法にあります。

セキュリティは、あなた、エンドユーザ、デバイス製造業者にとって最優先事項であるべきです。X.509 証明書を使用する場合、製造プロセスで、デバイスが一意となる証明書と秘密鍵のペアを取得するタイミングと、IoT ソリューションにどのように登録するかを明確にする必要があります。

デバイスプロビジョニングと証明書管理を検討する際のポイント :

  • メーカーの選択 : 信頼できる証明書チェーンは、ハードウェアを社内開発または OEM パートナーを選択することから始まります。後者の場合、サプライチェーン全体で証明書の整合性が維持されていることを確認するために、そのプロセスを検査する必要があります。 
  • 認証局 ( CA ) : デバイスの製造に柔軟性を持たせるために、AWS では独自の CA、サードパーティの CA、Amazon ルート認証局 ( CA ) など、複数の選択肢を用意しています。 
  • ハードウェアセキュリティモジュール : IoT デバイスに組み込まれたセキュアエレメントは、デバイスセキュリティの基盤を形成します。これにより、証明書やシークレットの暗号化と改ざん防止の保存、ファームウェアとアプリケーションの検証が可能になります。これを支援するために、AWS には AWS IoT ExpressLink を搭載したさまざまな接続モジュールがあります。これらのモジュールには AWS が要求するセキュリティ要件を実装したソフトウェアが含まれています。
  • 外部リソース : カスタムプロビジョニングプロセスを可能にするために、IoTソリューション内でのリソース作成が必要になる場合があります。 これらのリソースは、デバイスの稼働台数が増加するにつれてスケールするように設計する必要があります。 AWS の場合、これは Pre-provisioning hook として機能する AWS Lambda function になる可能性があります。
  • デバイスレベルのロジック : デバイスには、確実かつ安全にプロビジョニングされるため、オンデバイスのロジックが必要になる場合があります。 AWS では、AWS IoT SDKs はこのオンデバイスのロジックを可能にするために設計されています。

AWS IoT Core を使用したデバイスのセキュアなプロビジョニングと登録の詳細については、AWS IoT Core Device Provisioning  や AWS ホワイトペーパーの Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core をご参照ください。

デバイス管理

成熟したプロビジョニングのプロセスがあれば、デバイスは最初に接続したときからセキュアで最新の状態に保たれますが、ファームウェアや証明書のローテーションなどの更新が必要になる場合があります。完全にコンプライアンスを遵守し、最高のユーザーエクスペリエンスを提供するためにはこうした更新が必要です。これらの更新のためのソリューションは、配信の中断、接続性、ロールバックルーチン、自動スケーリングへの対応が必要となるでしょう。

デバイス管理戦略を検討する際の考慮事項 :

  • デバイス整理 : デバイスをすばやく識別し操作できることで、コンプライアンスから外れた場合のトラブルシューティングと隔離が可能になります。多数のデバイスを運用する場合、デバイスの整理、インデックス作成、分類を行うソリューションが必要になります。AWS では、Fleet Hub for AWS IoT Device Management を使用できます。
  • デバイス監視 : デバイス群のステータスを監視できることは、誤動作やコンプライアンス違反のデバイスを特定するのに重要です。デバイスのメトリクス、ログ、設定などの観測データとセキュリティデータを収集する監視ソリューションを用意してください。AWS IoT Device Defender は、稼働している多数のデバイスのセキュリティのための監査と継続的なインテリジェントな監視を提供します。
  • イベントへ対応 : ログ、メトリクス、アラームの最小セットを定義することで、運用チームは大きなビジネスの中断を防ぐことができます。監視ソリューションと統合できるスケーラブルなアラートソリューションが必要です。AWS では Amazon CloudWatch を使用できます。
  • Over-The-Air ( OTA ) アップデート対応 : デバイスは更新を受信して適用できるように設計する必要があります。IoT ソリューションは更新を送信し、デバイスの更新進捗を監視できる必要があります。AWS では、AWS IoT Device Management Jobs を使用できます。

このコンポーネントを支援するために、AWS IoT Device Management、AWS IoT Device Defender、AWS IoT Core は、稼働している IoT デバイス全体のデバイス整理、監視、アラート、OTA 更新のための完全な機能セットを提供します。

デバイスデータの取り込み

すべての IoT ソリューションがデータ取り込みに焦点を当てるわけではありませんが、そうしたソリューションでは、このデータ取り込みがプライマリなコンポーネントとなり、ソリューションの全体的なアーキテクチャに影響します。このコンポーネントに対する要件は、ソリューションのスケール、コスト、セキュリティ、パフォーマンスに影響するため、現在と将来のデータ取り込みを考慮した IoT ソリューションのアーキテクチャを設計する必要があります。

データ取り込み戦略を検討する際の考慮事項 :

  • データサイズ : デバイスがハードウェア的に制約されていない場合、効率を高めるためにメッセージサイズを一定に 保ち、小さいメッセージをバッチ処理することを検討してください。バッチ処理は、メッセージ送信時だけでなく、IoT Core に取り込んだ後に IoT ルールを使用して実行できることに留意してください。
  • データの頻度と構造 : デバイスがメッセージを送信する頻度を考慮し、ソリューションがそのスケールに対応できるように設計してください。頻度に加えて、データの構造がメッセージベースかストリーミングベースの IoT ワークロードかを決定します。
  • MQTT トピック設計 : このプロトコルを使用する場合は、最小限の権限コミュニケーションを実施しつつ、将来のデバイス導入をサポートできるスキーマのバランスをとる必要があります。適切なトピックスキーマは 、柔軟なメッセージフィルタリングとメッセージルーティングを可能にする共通の命名規則を実装します。
  • データストレージ : メッセージのフローと使用法を分析し、適切なストレージソリューションを特定してください。これらのストレージソリューションは、ユースケース、全体的なメッセージ構造、スケール ( 現在と将来の成長 ) 、コストなど、複数の考慮事項があります。 
  • ルーティング : 取り込んだ後、メッセージをストレージや他のサービスにルーティングするための、ルールベースの簡単なソリューションが必要です。これらのルールは、さらなるメッセージのバッチ処理、処理、アラートなどに使用できます。 
  • エッジゲートウェイ : 一般的なアーキテク チャパターンは、データを取り込み、処理、バッチ処理してから IoT ソリューションに送信するゲートウェイまたはブローカーを用意することです。これは、デバイスに近いローカルエンドポイント、または IoT ソリューションに近いクラウドベースのゲートウェイとして実装できます。

このコンポーネントの支援として、AWS IoT Core を使用すると、インフラを管理することなく、数十億ものIoTデバイスを接続し、Amazon SQS 、Amazon Kinesis 、Amazon SNS などの他の AWS サービスに何兆ものメッセージをルーティングできます。AWS には、エッジランタイムを提供するオープンソースの AWS IoT Greengrass もあります。AWS IoT Core を使用したデータ取り込みのパターンの詳細は、AWS IoT ブログの「IoT データの取り込みと可視化のための7つのパターン – ユースケースに最適なものを決定する方法」をご参照ください。

リアルタイムのビデオとデータストリーム

前のセクションで説明したものに加えて、IoT ワークロードがビデオやその他の高容量データストリームで構成されている場合は、さらにいくつかの点を考慮する必要があります。データストリームを扱う IoT ワークロードは、ビデオ処理や分析などのアプリケーション向けに、高頻度かつ非構造化の生データを扱うことが多くなります。

ストリーミングベースのワークロードを考慮するポイント : 

  • プロデューサ側 : データストリームがどのように生成されるかは、IoT ソリューションの下流でどのようにインジェスト、処理、保存されるかに直接影響します。 デバイスのストリーミングプロトコル、ネットワークの可用性、アクセシビリティ 、コストの制約などの側面が、ストリームの生成方法に影響します。 
  • コンシューマ側 : データストリームの消費と処理は、IoT ソリューションの必要なスケールと全体的なコストに影響を与える可能性があります。ビデオストリームなどの高頻度データは、高可用性で管理が容易で、スループット要件を処理できる堅牢なアーキテクチャーが必要になります。 これらのストリームの直接的なビジネス価値を総合的な IoT ソリューションで考慮して、最もコスト効果的かつスケーラブルな方法で消費および処理することを決定してください。 

このようなアーキテクチャを支援するために、AWS には AWS IoT Greengrass 、Amazon Kinesis 、Amazon Kinesis Video Streams があります。 AWS IoT Greengrass は、エッジでデータストリームを 容易に消費および処理し、AWS 提供のコンポーネントを介して AWS に転送できるエッジランタイムを提供するオープンソースです。 Amazon Kinesis は、デバイスから直接、AWS IoT Greengrass Stream manager コンポーネントから、または AWS IoT ルールから生成されるストリーミングデータをコスト効果的に処理および分析できるマネージドサービスです。 Amazon Kinesis Video Streamsは、デバイスから直接、または AWS IoT Greengrass の Edge connector for Kinesis Video Streams を介して生成されたビデオストリームを、ソースプロトコルに関係なく安全に表示、処理、分析できるマネージド AWS サービスです。

デバイスのコマンド・アンド・コントロール

コマンド・アンド・コントロールは、デバイスにアクションの実行を要求するメッセージを送信し、成功または失敗の確認応答を受け取る操作です。これは、デバイスへのコマンドメッセージまたは IoT ソリューションからデバイスの状態を変更して伝達することで実現できます。データ取り込みとコマンド・アンド・コントロールのための IoT ソリューションのメッセージングニーズを評価および最適化することで、パフォーマンスとコストのバランスが最適になります。

デバイスのコマンド・アンド・コントロール戦略についての検討パターン :

  • コマンドメッセージング : 選択したメッセージングプロトコルを使用して、コマンドを直接デバイスに送信します。デバイス側のロジックを実装して、コマンドの受信、実行、デバイスの実行ステータスの報告をする必要があります。このパターンでは、IoT ソリューションでコマンドメッセージを確実に配信する必要があり、デバイスがオフラインになったり接続が切断された場合には、対処可能な障害が発生することに留意してください。
  • デバイスの状態 : デバイスの状態は IoT ソリューションで処理し、コマンドの設定や実行ステータスの更新に使用できます。この状態は、IoT ソリューションからの変更があった際にデバイスへ送信され、デバイス自身が変更を加えた場合にもそれを送り返すことができる、単純なドキュメントとすることができます。このパターンでは、デバイスが接続されていなくても、IoT ソリューションと対話できます。

このコンポーネントを支援するために、AWS IoT Core は AWS IoT Device Shadow service　、MQTT5 リクエスト/レスポンスパターン、AWS IoT デバイス管理は AWS IoT Job 機能を提供しています。デバイスのコマンド・アンド・コントロールの実装パターンの詳細は、「 AWS IoT Lens for the AWS Well-Architected Framework 」のデバイスコマンドの項を参照してください。

クラウドアーキテクチャ

IoT ソリューションがクラウドに存在する場合、地域を限定した1つのサービスや小規模なデバイス群から始めることができます。これは概念実証やデモンストレーションには十分ですが、ソリューションを本番に移行する際には、クラウドベースのベストプラクティスを考慮して構築されていることを確認する必要があります。「 AWS Well-Architected framework 」は、ソリューションの設計、構築、レビューの際に、AWS を安全かつ高パフォーマンス、回復性が高く、効率的に使用していることを確認するのに役立ちます。AWS IoT におけるクラウドベースのベストプラクティスの詳細は、IoT Lens – AWS Well-Architected Framework を参照してください。

まとめ

このブログでは、典型的な IoT ソリューションを構成する主要な技術要素に分解し、それぞれについて考慮すべき要件と注意点を明らかにしました。IoT ソリューションの構築は間違いなく複雑ですが、AWS IoT を活用することによって、その道のりを簡素化、合理化することができます。さらに、AWS パートナーが構築した AWS IoT ソリューションを利用することで、市場投入までの時間を短縮することもご検討ください。

著者紹介

Kai-Matthias Dickman は、Amazon Web Services ( AWS ) の IoT ソリューションアーキテクトです。大企業の開発者や意思決定者と協力して、AWS IoT サービスの導入を推進することを楽しんでいます。IoT とクラウドに関する深い知識を持っており、スタートアップから大企業に至る世界中のお客様と協力して、AWS エコシステムを使った IoT ソリューションの構築を可能にする役割を担っています。

Nicholas Switzer は、Amazon Web Services の IoT ソリューションアーキテクトです。2022年に AWS に加入し、IoT 、エッジコンピューティング、コネクテッドプロダクト分野を専門としています。アメリカに拠点を置き、日常生活を改善するスマートプロダクトの構築を楽しんでいます。

この記事は Kai-Matthias Dickman , Nicholas Switzer によって書かれた Deploying and managing an IoT workload on AWS の日本語訳です。この記事は ソリューションアーキテクト の伊藤 一成が翻訳しました。