Azure IoT 参照アーキテクチャ

Blob Storage
関数
IoT Hub
Logic Apps
Stream Analytics

この参照アーキテクチャは、PaaS (サービスとしてのプラットフォーム) コンポーネントを使用する Azure の IoT アプリケーションの推奨アーキテクチャを示しています。

アーキテクチャの図

IoT アプリケーションは、分析情報 を生成するデータを送信する もの (デバイス) として説明することができます。 これらの分析情報によりビジネスやプロセスを改善するための アクション が生成されます。 温度データを送信するエンジン (もの) はその一例です。 このデータは、エンジンが想定どおりに実行されているかどうかを評価するために使用されます (分析情報)。 分析情報は、エンジンのメンテナンス スケジュールを事前に優先順位付けするのに使用されます (アクション)。

この参照アーキテクチャでは、Azure PaaS (サービスとしてのプラットフォーム) コンポーネントを使用します。 Azure で IoT ソリューションを構築するためのその他の推奨されるオプションには、次のものがあります。

  • Azure IoT Central。 IoT Central は、フル マネージド SaaS (サービスとしてのソフトウェア) ソリューションです。 技術的な選択肢を抽象化することで、自分のソリューションだけに注力できるようにします。 この簡素化には、PaaS ベースのソリューションと比べてカスタマイズしにくいというトレードオフが伴います。

テレメトリ データの処理方法には、大まかに言ってホット パスとコールド パスの 2 種類があります。 違いは、待機時間とデータ アクセスの要件にあります。

  • ホット パス は、データが到着すると、ほぼリアルタイムでそのデータを分析します。 ホット パスでは、非常に短い待機時間でテレメトリを処理する必要があります。 ホット パスは通常、ストリーム処理エンジンを使用して実装されます。 出力は、アラートをトリガーしたり、分析ツールを使用してクエリ可能な構造化された形式に書き込むことができます。
  • コールド パス は、より長い間隔 (毎時または毎日) でバッチ処理を実行します。 コールド パスは通常、大量のデータで動作しますが、結果は、ホット パスほどタイムリーである必要はありません。 コールド パスでは、未加工のテレメトリがキャプチャされ、バッチ処理にフィードされます。

Architecture

このアーキテクチャは、次のコンポーネントで構成されます。 アプリケーションの中には、以下に一覧表示するすべてのコンポーネントを必要としないものもあります。

IoT デバイス。 デバイスはクラウドに安全に登録でき、クラウドに接続してデータを送受信できます。 一部のデバイスは、デバイス自体でまたはフィールド ゲートウェイで一部のデータ処理を実行する エッジ デバイス の場合があります。 エッジ処理には、Azure IoT Edge をお勧めします。

クラウド ゲートウェイ。 クラウド ゲートウェイは、デバイスがクラウドに安全に接続してデータを送信するためのクラウド ハブを提供します。 デバイスの管理や、コマンドやデバイスの制御などの機能も提供します。 クラウド ゲートウェイには、IoT Hub をお勧めします。 IoT Hub は、デバイスからイベントを取り込むホスト型クラウド サービスで、デバイスとバックエンド サービス間のメッセージ ブローカーとして機能します。 IoT Hub は、セキュリティで保護された接続、イベント インジェスト、双方向通信、およびデバイス管理を提供します。

デバイス プロビジョニング。 多数のデバイスの登録と接続には、IoT Hub Device Provisioning Service (DPS) の使用をお勧めします。 DPS を使用すると、デバイスを特定の Azure IoT Hub エンドポイントに大規模に割り当てて登録することができます。

ストリーム処理。 ストリーム処理は、データ レコードの大規模なストリームを分析し、これらのストリームの規則を評価します。 ストリーム処理には、Azure Stream Analytics をお勧めします。 Stream Analytics では、time windowing 関数、ストリーム集計、外部データ ソース結合を使用して、大規模で複雑な分析を実行できます。 もう 1 つのオプションは、Azure Databricks の Apache Spark です。

機械学習 では、履歴テレメトリ データに対して予測アルゴリズムを実行できるようにすることで、予測メンテナンスなどのシナリオを可能にします。 機械学習には、Azure Machine Learning をお勧めします。

ウォーム パス ストレージ には、レポートと視覚化のためにデバイスからすぐに使用できる必要があるデータが保持されます。 ウォーム パス ストレージには、Cosmos DB をお勧めします。 Cosmos DB は、グローバル分散型のマルチモデル データベースです。

コールド パス ストレージ には、長期間保持され、バッチ処理に使用されるデータが保持されます。 コールド パス ストレージには、Azure Blob Storage をお勧めします。 データは、低コストで無期限に Blob Storage にアーカイブすることができ、バッチ処理のために簡単にアクセスできます。

データ変換 は、テレメトリ ストリームを操作または集計します。 例には、バイナリ データの JSON への変換などのプロトコル変換や、データ ポイントの結合が含まれます。 IoT Hub に到達する前にデータを変換する必要がある場合は、プロトコル ゲートウェイ (示されていません) の使用をお勧めします。 そうでない場合、データは IoT Hub に到達した後で変換できます。 その場合は、Azure Functions を使用することをお勧めします。Azure Functions には IoT Hub、Cosmos DB、および Blob Storage との統合が組み込まれています。

ビジネス プロセス統合 は、デバイス データからの分析情報に基づいてアクションを実行します。 これには、情報メッセージの格納、アラームの発生、電子メールまたは SMS メッセージの送信、CRM との統合などが含まれる場合があります。 ビジネス プロセス統合には、Azure Logic Apps の使用をお勧めします。

ユーザー管理 は、デバイスでファームウェアのアップグレードなどのアクションを実行できるユーザーまたはグループを制限します。 アプリケーションでユーザーが利用できる機能も定義します。 ユーザーの認証と承認には、Azure Active Directory の使用をお勧めします。

セキュリティの監視 Azure Security Center for IoT により、IoT ワークロード用にエンド ツー エンドのセキュリティ ソリューションが提供され、統合された可視性と制御、アダプティブな脅威の防止、およびリーフ デバイスからエッジやクラウドまでのワークロード全体に対するインテリジェントな脅威の検出と対応により、保護が簡素化されます。

スケーラビリティに関する考慮事項

IoT アプリケーションは、個別にスケールできる個別のサービスとしてビルドする必要があります。 次のスケーラビリティ ポイントを検討してください。

IoT Hub。 IoT Hub については、次のスケール係数を検討してください。

  • IoT Hub に送信されるメッセージの日単位の最大クォータ
  • IoT Hub インスタンスで接続されたデバイスのクォータ。
  • インジェストのスループット — IoT Hub がメッセージを取り込むことができる速度。
  • 処理スループット — 受信メッセージの処理速度。

各 IoT Hub は、特定のレベルのユニット数でプロビジョニングされます。 レベルとユニット数により、デバイスがハブに送信できるメッセージの 1 日あたりの最大クォータが決定されます。 詳細については、IoT Hub のクォータと調整に関するページを参照してください。 既存の操作を中断することなく、ハブをスケール アップすることができます。

Stream Analytics。 Stream Analytics ジョブは、クエリへの入力から出力まで、Stream Analytics パイプラインのすべてのポイントで並列化されると最適にスケールされます。 完全な並列ジョブにより、Stream Analytics は複数のコンピューティング ノード間で作業を分割することができます。 それ以外の場合、Stream Analytics はストリーム データを 1 つの場所に結合する必要があります。 詳細については、「Azure Stream Analytics でのクエリの並列処理の活用」を参照してください。

デバイス ID に基づいて、IoT Hub によりデバイス メッセージが自動的にパーティション分割されます。 特定のデバイスからのメッセージはすべて、常に同じパーティションに送信されますが、1 つのパーティションが複数のデバイスからのメッセージを受け取ります。 そのため、並列処理の単位はパーティション ID です。

Functions。 Event Hubs エンドポイントから読み取る場合、イベント ハブ パーティションごとに関数のインスタンスの最大値があります。 最大処理レートは、1 つの関数インスタンスが 1 つのパーティションからイベントを処理できる速度によって決まります。 この関数は、メッセージをバッチで処理する必要があります。

Cosmos DB。 Cosmos DB コレクションをスケール アウトするには、パーティション キーを使用してコレクションを作成し、記述する各ドキュメントにそのパーティション キーを含めます。 詳細については、パーティション キーを選択する際のベスト プラクティスに関するページを参照してください。

  • デバイスごとに 1 つのドキュメントを格納して更新する場合、デバイス ID が適切なパーティション キーとなります。 書き込みはキー間で均等に分散されます。 キー値ごとに 1 つのドキュメントが存在するため、各パーティションのサイズは厳密にバインドされます。
  • すべてのデバイス メッセージに対して個別のドキュメントを保存する場合、パーティション キーとしてデバイス ID を使用すると、パーティションあたり 10 GB の制限をすぐに超えてしまいます。 その場合は、メッセージ ID の方が適切なパーティション キーとなります。 通常、インデックス作成とクエリのため、ドキュメントにデバイス ID を含めることもできます。

Azure Time Series Insights (TSI) は、時系列データ用の分析、ストレージ、視覚化サービスであり、SQL に似たフィルター処理や集計などの機能が提供されて、ユーザー定義関数の必要性が軽減されます。 Time Series Insights には、データの視覚化とクエリを行うためのデータ エクスプローラーと、REST Query API が用意されています。 時系列データだけでなく、TSI は、大量のデータセットに対する集計のクエリを実行する必要があるソリューションにも適しています。 多層ストレージ、豊富な API、モデルおよびその Azure IoT エコシステムとの統合、視覚化のためのエクスプローラー、Power BI による拡張性などがサポートされています。時系列データのストレージと分析には、TSI を使用することをお勧めします。

セキュリティに関する考慮事項

信頼できるセキュリティで保護された通信

デバイスと送受信するすべての情報は、信頼できる必要があります。 デバイスで次の暗号化機能をサポートできないのであれば、そのデバイスをローカル ネットワークに制限し、すべてのネットワーク間通信をフィールド ゲートウェイを経由して行う必要があります。

  • 証明可能な安全性を備え、公的に分析され、広く実装されている対称キー暗号化アルゴリズムを使用したデータの暗号化。
  • 証明可能な安全性を備え、公的に分析され、広く実装されていいる対称キー署名アルゴリズムを使用したデジタル署名。
  • TCP またはその他のストリーム ベースの通信パス向けの TLS 1.2、またはデータグラム ベースの通信パス向けの DTLS 1.2 のいずれかのサポート。 X.509 証明書の処理のサポートはオプションで、より計算効率が高く転送効率の高い TLS の事前共有キー モードで置き換えることができます。このモードは、AES および SHA-2 のアルゴリズムをサポートするために実装できます。
  • 更新可能なキー ストアとデバイスごとのキー。 各デバイスには、システムに対して認証を行う一意のキー マテリアルまたはトークンが必要です。 デバイスは、(セキュリティで保護されたキー ストアを使用するなどして) キーを安全に保存する必要があります。 デバイスは、キーまたはトークンを定期的、またはシステムのセキュリティ侵害などの緊急の状況では事後的に更新できる必要があります。
  • デバイスのファームウェアとアプリケーション ソフトウェアは、更新プログラムが検出されたセキュリティの脆弱性を修復できるようする必要があります。

ただし、多くのデバイスでは、制約が多すぎてこれらの要件をサポートできません。 その場合は、フィールド ゲートウェイを使用する必要があります。 デバイスは、ローカル エリア ネットワーク経由でフィールド ゲートウェイに安全に接続し、ゲートウェイはクラウドへのセキュリティで保護された通信を有効にします。

物理的な改ざん防止

セキュリティの整合性とシステム全体の信頼性を確保するため、デバイスの設計に物理操作の試行を防御する機能を組み込むことを強くお勧めします。

次に例を示します。

  • セキュリティで保護されたストレージを備え、トラステッド プラットフォーム モジュール (TPM) の統合などの暗号化キー マテリアルを使用する、マイクロコントローラー/マイクロプロセッサまたは補助ハードウェアを選択します。
  • TPM に固定されている、セキュリティで保護されたブート ローダーとセキュリティで保護されたソフトウェアの読み込み。
  • センサーを使用して、侵入の試みや、アラートを生成したりデバイスの "デジタル自己破壊" を引き起こす可能性があるデバイス環境の操作を検出します。

セキュリティに関するその他の考慮事項については、「モノのインターネット (IoT) のセキュリティ アーキテクチャ」を参照してください。

監視およびログ記録

ログ記録と監視システムは、ソリューションが機能しているかどうかを判断するため、および問題のトラブルシューティングのために使用されます。 監視とログ記録システムは、次の運用上の質問に答えるときに役立ちます。

  • デバイスまたはシステムはエラー状態か。
  • デバイスまたはシステムは正しく構成されているか。
  • デバイスまたはシステムは正確なデータを生成しているか。
  • システムは企業の顧客とエンド カスタマーの両方の期待を満たしているか。

ログ記録と監視ツールは通常、次の 4 つの構成要素で構成されます。

  • システムを監視し、基本的なトラブルシューティングを行うためのシステム パフォーマンスとタイムライン視覚化ツール。
  • ログ データをバッファーするバッファー処理されたデータ インジェスト。
  • ログ データを格納する永続化ストア。
  • 詳細なトラブルシューティングで使用するためにログ データを表示する検索とクエリ機能。

監視システムは、正常性、セキュリティ、および安定性に関する分析情報と、IoT ソリューションのパフォーマンスを提供します。 これらのシステムは、より詳細なビューも提供できます。コンポーネントの構成変更を記録し、潜在的なセキュリティの脆弱性を明らかにし、インシデント管理プロセスを強化し、システムの所有者が問題をトラブルシューティングするのに役立つ、抽出したログ データを提供します。 包括的な監視ソリューションには、特定のサブシステムの情報や複数のサブシステムの集計に対してクエリを実行する機能が含まれます。

監視システムの開発は、正常な動作、規制に対するコンプライアンス、監査要件を定義することから始める必要があります。 収集されるメトリックには、次のものが含まれます。

  • 構成の変更を報告している物理デバイス、エッジ デバイス、およびインフラストラクチャ コンポーネント。
  • 構成の変更を報告しているアプリケーション、セキュリティ監査ログ、要求レート、応答時間、エラー率、およびマネージド言語のガベージ コレクションの統計情報。
  • データベース、永続化ストア、クエリと書き込みのパフォーマンスを報告しているキャッシュ、スキーマの変更、セキュリティ監査ログ、ロックまたはデッドロック、インデックスのパフォーマンス、CPU、メモリ、ディスク使用量。
  • 正常性メトリックと依存システムの正常性とパフォーマンスに影響を与える構成の変更を報告しているマネージド サービス (IaaS、PaaS、SaaS、FaaS)。

監視メトリックを視覚化することで、システムが不安定であることをオペレーターに警告し、インシデント対応を促します。

テレメトリのトレース

テレメトリをトレースすることで、オペレーターはシステム全体で作成時からテレメトリを追跡することができます。 トレースは、デバッグとトラブルシューティングにとって重要です。 Azure IoT Hub および IoT Hub Device SDK を使用する IoT ソリューションの場合、データグラムのトレースは、クラウドからデバイスへのメッセージとして始めることができ、テレメトリ ストリームに含めることができます。

ログ記録

ログ記録システムは、ソリューションが実行したアクションまたはアクティビティの内容、発生したエラーを把握するうえで不可欠で、こうしたエラーを修正するのにも役立ちます。 ログは分析して、エラー状態の理解と修正、パフォーマンス特性の強化、および適用される規則や法令の順守に役立てることができます。

プレーン テキスト ログは、開発の初期コストへの影響はあまりありませんが、マシンでの解析/読み取りがより困難になります。 収集された情報はマシンで解析可能で人間が判読できるため、構造化ログを使用することをお勧めします。 構造化ログにより、状況コンテキストとメタデータがログ情報に追加されます。 構造化ログでは、プロパティは、検索およびクエリ機能を強化するために、キー/値のペアとしてまたは固定スキーマで書式設定された重要な要素です。

DevOps の考慮事項

コードとしてのインフラストラクチャ (IaC) を使用します。 IaC は、宣言型アプローチによるインフラストラクチャ (ネットワーク、仮想マシン、ロード バランサー、接続トポロジ) の管理です。 テンプレートがバージョン管理され、リリース パイプラインに含まれている必要があります。 最も信頼性の高いデプロイ プロセスは、自動化されていて、べき等です。 1 つの方法は、Azure Resource Manager テンプレートを作成し、IoT リソースとインフラストラクチャをプロビジョニングすることです。

インフラストラクチャのデプロイを自動化するには、Azure DevOps Services、Jenkins、またはその他の CI/CD ソリューションを使用できます。 Azure PipelinesAzure DevOps Services の一部であり、自動化されたビルド、テスト、およびデプロイを実行します。

ワークロードをステージングすることを検討してください。さまざまなステージにデプロイし、各ステージで検証を実行してから、次のステージに進みます。これにより、高度に制御された方法で、更新プログラムを運用環境にプッシュし、予期しないデプロイの問題を最小限に抑えることができます。 アクティブな運用環境を更新するためのデプロイ戦略としては、ブルーグリーン デプロイカナリア リリースをお勧めします。 また、デプロイが失敗したときのために、適切なロールバック戦略を用意することも検討します。たとえば、以前に成功したデプロイを、デプロイ履歴から自動的に再デプロイできます。その良い例が、Azure CLI の --rollback-on-error フラグ パラメーターです。

Azure Monitor を使用してご自分のソリューションを監視することを検討してください。 Azure Monitor はすべての Azure サービスの監視とログの主要なソースであり、Azure リソースに関する診断情報を提供します。 たとえば、IoT ハブ内で行われる操作を監視できます。 Azure Monitor でサポートされる特定のメトリックとイベントがあるほか、Azure 診断ログ用のサービス、スキーマ、カテゴリがあります。

詳細については、「Microsoft Azure Well-Architected Framework」の DevOps のセクションを参照してください。

コストに関する考慮事項

一般的に、コストを見積もるには、Azure 料金計算ツールを使用します。 その他の考慮事項については、Microsoft Azure Well-Architected Framework のコストに関するセクションに説明されています。

この参照アーキテクチャで使用されるサービスに関連するコストを最適化する方法があります。

Azure IoT Hub

このアーキテクチャでは、IoT Hub は、デバイスからイベントを取り込むクラウド ゲートウェイです。 IoT Hub の課金は、操作の種類によって異なります。 作成、更新、挿入、削除は無料です。 device-to-cloud および cloud-to-device メッセージなど、成功した操作は課金されます。

正常に送信された device-to-cloud メッセージは、IoT Hub に入った時点で 4 KB のチャンク単位で課金されます。 たとえば、6 KB のメッセージは 2 メッセージとして課金されます。

IoT Hub は、接続されている各デバイスに関する状態情報をデバイス ツインの JSON ドキュメントに保持します。 デバイス ツイン ドキュメントからの読み取り操作は課金されます。

IoT Hub には、次の 2 つのサービス レベルがあります。BasicStandard

IoT アーキテクチャで双方向通信機能が使用されている場合は、Standard レベルを使用することを検討してください。 このレベルには、テスト目的に最も適した無料のエディションも用意されています。

デバイスからクラウドへの一方向の通信のみが必要な場合は、Basic レベルを使用します。これはコストが安くなります。

詳細については、「IoT Hub の価格」を参照してください。

Azure Stream Analytics

Azure Stream Analytics は、ストリームの処理とルールの評価に使用されます。 Azure Stream Analytics の価格は、データを処理するために必要なコンピューティング、メモリ、スループットを考慮した、ストリーミング ユニット (SU) の数に基づいて決まります。 Azure Stream Analytics on IoT Edge はジョブごとに課金されます。 課金は、Stream Analytics ジョブの状態 (実行中、失敗、または停止) に関係なく、ジョブがデバイスにデプロイされると開始されます。

価格の詳細については、「Stream Analytics の価格」をご覧ください。

Azure Functions

Azure Functions は、IoT Hub に到達したデータを変換するために使用されます。 従量課金プラン では使用したコンピューティング リソースにしか支払いが発生しないため、コストの観点から、こちらのプランを使用することをお勧めします。 イベントによって関数の実行がトリガーされるたびに、1 秒あたりのリソース消費量に基づいて課金されます。 1 回の実行またはバッチで複数のイベントを処理すると、コストを削減できます。

Azure Logic Apps

このアーキテクチャでは、ビジネス プロセスの統合に Logic Apps が使用されます。

Logic Apps の料金は従量課金制モデルに従います。 トリガー、アクション、およびコネクタの実行は、ロジック アプリを実行するたびに課金されます。 トリガーを含め、成功したアクションと失敗したアクションすべてが実行と見なされます。

たとえば、ロジック アプリで 1 日に 1000 メッセージを処理するとします。 5 つのアクションのワークフローの料金は、$6 未満になります。

詳細については、「Logic Apps の価格」をご覧ください。

データ ストレージ

コールド パス ストレージの場合、Azure Blob Storage は最もコスト効率の高いオプションです。

ウォーム パス ストレージの場合は、Azure Cosmos DB の使用を検討してください。 詳細については、「Cosmos DB の価格」を参照してください。

次のステップ

  • 推奨されるアーキテクチャと実装の選択の詳細については、「Microsoft Azure IoT Reference Architecture」 (Microsoft Azure IoT 参照アーキテクチャ) (PDF) を参照してください。

  • 各種 Azure IoT サービスの詳細なドキュメントについては、「Azure IoT の基礎」を参照してください。