IoT ワークロードでのコストの最適化

[アーティクル]
07/18/2024

コスト効率は、IoT プロジェクトの成功の鍵となる主な要因の 1 つです。一般的な IoT ソリューションでは、デバイスは大量のテレメトリを生成し、クラウドテクノロジが処理および格納するためにクラウドに送信します。デバイスとアプリケーションを開発し、大量のデータを処理し、アーキテクチャを設計する方法は、全体的なコストに影響します。

IoT ソリューションは多層のテクノロジスタックであるため、考慮すべきコスト削減要因が多数あり、コストを最適化する機会が多数あります。コストの最適化は、ソリューションのライフサイクル全体を通じて継続的に監視、分析、改善する必要がある、クローズドループのコスト管理のプロセスです。

ソリューション要件は、IoT アーキテクチャの決定の重要な条件です。これらの要件は機能要件と運用要件に分けられます。機能要件によってシステム設計が決まりますが、運用要件はシステムアーキテクチャに影響するため、コストに関する考慮事項は、要件の種類ごとに分離します。要件に基づいて複数のユースケースを開発し、設計を終了する前に比較します。

この記事では、Azure IoT サービスとテクノロジのさまざまな組み合わせに関するコストに関する考慮事項について説明します。接続されたファクトリ、予測メンテナンス、リモート監視などの特定の業界やユースケースのコスト最適化については、「業界固有の Azure IoT 参照アーキテクチャ」を参照してください。

IoT ワークロードのコスト最適化を評価する

Well-Architected フレームワークのコスト最適化の柱のレンズを使用して IoT ワークロードを評価するには、「Azure Well-Architected レビュー」で IoT ワークロードのコスト最適化に関する質問を完了します。評価で IoT ソリューションの主要なコスト最適化の推奨事項が特定されたら、次のコンテンツを使用して推奨事項を実装します。

設計原則

アーキテクチャの卓越性の 5 つの柱は、IoT ワークロードの設計手法を支えます。これらの柱は、キー IoT 設計領域全体で後続の設計決定のための羅針盤として機能します。次の設計原則は、Azure Well-Architected フレームワーク - コストの最適化の品質の柱を拡張します。

設計原則	考慮事項
コスト管理規範を開発する	計画時に直接コストと間接コストの両方を考慮して、総保有コスト (TCO) を理解します。
業界標準の戦略とアプローチを使用する	IoT 固有の業界では、製造、エネルギーと環境、自動車や輸送などの独自のエコシステムを備えた、業界標準の戦略とアプローチを使用します。
レート最適化を設計する	各 IoT アーキテクチャレイヤーの実装計画を定義します。
時間の経過に伴う監視と最適化	ソリューションを実装した後、継続的なコスト最適化アクティビティを使用してコストを監視および最適化します。

総保有コスト (TCO)

IoT コストは、さまざまなテクノロジ上の選択肢の間のトレードオフです。 IoT はエンドツーエンドシステムであるため、単純な比較ではない場合があります。複数のサービスとテクノロジを調整する場合は、相乗効果のコスト上のメリットを考慮してください。たとえば、Azure IoT Hub デバイスツインを使用して、Azure Digital Twins のイベントを処理できます。 IoT Hub のデバイスツインは、IoT Hub の標準レベルでのみ使用できます。

長期的な集計コストを正しく見積もる必要があります。 IoT テクノロジスタックを確認し、関連するすべてのサービスを実装して運用するためのコストを含むコストモデルを開発します。 Azure 料金計算ツールは、開始時のコストと運用コストの両方を見積もるのに役立ちます。

一部の領域では、1 回限りのコストが、定期的なコストよりも効果的な場合があります。たとえば、ハッキング手法が常に変化するセキュリティ領域の場合、信頼性の高い商用オペレーティングシステムや Azure Sphere などのモジュールを導入するのが最適である可能性があります。 1 回限りの支払いの場合、このようなサービスでは、毎月デバイスセキュリティパッチが継続的に提供されます。

概念実証 (PoC) アーキテクチャでなく、運用環境での大規模な実行に基づいて、ソリューションコストを見積もります。アーキテクチャとコストは、PoC の後に急速に変化します。 IoT Signals EDITION 3 のレポートによると、PoC の失敗の第一の理由は、スケーリングのコストが高いことです。 IoT プロジェクトをスケーリングするコストの高さは、デバイス、エッジ接続、アプリケーション間の互換性など、レイヤー間の統合の複雑さから生まれます。

コストモデルには、次の領域が含まれている必要があります。

デバイス: 限られた数の接続されたデバイスから始めて、デプロイ済みのデバイスの数とそのメッセージングパターンの増加を見積もります。デバイスとメッセージの両方に、時間の経過に伴って、線形または非線形の増加が生じます。
インフラストラクチャ: インフラストラクチャのコストを評価するには、まず、ストレージ、コンピューティング、ネットワークという基本を考慮します。次に、ソリューションがデータの取り込み、エグレス、準備に必要なすべてのサービスを考慮します。
運用: オペレーター、ベンダー、カスタマーサポートチームの採用など、インフラストラクチャコストと並行して増加する長期的な運用コストを含めます。
監視: 計画コストと実績コストのギャップを特定するために、コストを継続的に監視およびレビューします。コストレビュー会議を定期的に開催すると、コストの最適化実現に役立ちます。

IoT アーキテクチャレイヤー

コスト最適化の設計原則は、IoT ワークロードが基本 IoT アーキテクチャレイヤー全体の要件を満たしていることを確認するための考慮事項の明確化に役立ちます。

IoT アーキテクチャレイヤーを理解することは、コストベースラインを定義し、コスト比較のために複数のアーキテクチャを検討するのに役立ちます。各レイヤーには、デバイス、通信、エッジの場所など、複数のテクノロジとエコシステムのオプションがあるため、各レイヤーのコスト戦略を確立する必要があります。

IoT コアレイヤー: デバイスとゲートウェイ、デバイスの管理とモデリング、インジェストと通信、IoT 固有のソリューションを特定します。他のレイヤーと横断的なアクティビティも、他のワークロードに共通であり、多くの場合、共有されます。ただし、TCO とコストの最適化ではすべてのコストを考慮する必要があるため、一般的なアクティビティと横断的なアクティビティの IoT 関連のコストと並行して、IoT 固有のレイヤーのコストを考慮する必要があります。

IoT アーキテクチャのレイヤーと横断的なアクティビティを示す図。

デバイスとゲートウェイのレイヤー

このレイヤーは、データを生成し、場合によっては最適化し、クラウドにデータを転送する役割を担います。コストは、このレイヤーを設計するための重要な考慮事項です。コストの最適化は、計画、プロビジョニング、構成、監視、廃止のデバイスライフサイクル全体を考慮する必要があります。

デバイスのライフサイクルを示す図。

エッジソリューションでは、IoT デバイスを現場にデプロイする必要があります。デプロイには、コストに影響するネットワークと電源インフラストラクチャが必要な場合があります。既存のインフラストラクチャでは導入コストは最小限に抑えられますが、導入が既存のシステムに影響しないようにする必要がある場合があります。

IoT デバイスを開発または導入するには、専用の内部または外部の担当者のトレーニングと採用が必要になる場合があります。必要なスキルには、ハードウェア設計、埋め込みアプリケーション開発、クラウドとローカル接続、セキュリティとプライバシー、IoT ソリューションアーキテクチャなどがあります。業界固有の専門知識も必要になる場合があります。これらのコストをデバイスの全体的なコストに含めます。

デバイスコストには、ストレージ、在庫管理、輸送などの物流の整理が含まれます。デバイスが運用ライフサイクルの終了に達した場合の使用停止アクティビティのコストを含めます。

クラウドに接続されているデバイスの場合は、コストの境界を維持するために、データ転送を最適化します。戦略には、ペイロードサイズの最小化、メッセージのバッチ処理、オフピーク期間中の送信が含まれます。これらの最適化では、実装のためのコストも発生します。

Azure IoT デバイスの詳細については、以下を参照してください。

ハードウェアの選択

ほとんどのデバイス開発プロセスは、ハードウェアの選択に依存します。デバイスの購入決定では、WiFi 認定などの定性的要因と、部品表のコストや市場投入までの時間などの定量的要因が考慮されます。既製のハードウェアとカスタム設計のどちらを選択するかは、IoT デバイスのコストと市場投入までの時間に影響します。

既製のデバイスはユニットあたりのコストが高くなりますが、コストとリードタイムが予測できます。既製のデバイスでは、複雑なサプライチェーン管理の必要もありません。
カスタムデバイスを使用すると、単体コストを削減できますが、開発時間が伴い、設計、テスト、認定申請、製造など、繰り返し発生しないエンジニアリングコストが発生します。
事前に認定されたシステムコンポーネントまたはモジュールでは、市場投入までの時間が短縮される可能性があり、セミカスタムデバイスを作成できますが、個別のチップよりも高価です。サプライチェーンと在庫管理を適切にリソース化する必要があります。

Azure Certified Device カタログは、Azure IoT で適切に動作し、コストと市場投入までの時間を削減するのに役立つデバイスを提供します。認定デバイスの広範な一覧からハードウェアを柔軟に選択できるように、IoT ソリューションの設計とアーキテクチャ設計に重点を置きます。 IoT プラグアンドプレイデバイスでは、デバイスコストとクラウド開発コストの両方を削減できます。 Azure Certified Device を選択すると、デバイスのカスタマイズと統合を IoT ソリューションへのオンボードに直接スキップできます。

プラグアンドプレイアプローチによる節約を示す図。

ラムダアーキテクチャパターン

IoT ソリューションでは、一般的に、クラウドでホット/ウォーム/コールドラムダアーキテクチャパターンが使用されます。このパターンは、パフォーマンスの高いエッジデバイスまたは Azure IoT Edge ランタイムを使用する場合にも、エッジに適用されます。エッジでこのパターンを最適化すると、ソリューション全体のコストが削減されます。クラウドデータの取り込みと処理に最もコスト効率の高いサービスを選択できます。

ホットパス処理には、ほぼリアルタイムの処理、プロセスアラート、またはエッジ通知が含まれます。 Azure IoT Hub イベントストリームを使用して、クラウド内のアラートを処理できます。
ウォームパス処理には、オープンソースの時系列データベースや Azure SQL Edge など、エッジでのストレージソリューションの使用が含まれます。 Azure SQL Edge には、エッジストリーム処理機能と時系列最適化ストレージが含まれています。
コールドパス処理には、重要度の低いイベントのバッチ処理と、Azure Blob Storage モジュールを介したファイル転送オプションの使用が含まれます。この方法では、IoT Hub 経由のストリーミングと比較して、低コストのデータ転送メカニズムが使用されます。 Azure Blob Storage にコールドデータが到着した後、クラウドでデータを処理するための多くのオプションがあります。

デバイスセキュリティ

Device Provisioning Service (DPS) と IoT Central を備えた IoT Hub では、対称キー、トラステッドプラットフォームモジュール (TPM) 構成証明、X.509 証明書を使用したデバイス認証がサポートされます。各オプションには、それらに関連付けられるコスト要因があります。

X.509 証明書は、Azure IoT Hub への認証に最も安全なオプションですが、証明書の管理にはコストがかかる場合があります。証明書のライフサイクル管理計画が不足すると、証明書のコストがさらに高くなります。通常は、CA および証明書管理ソリューションを提供するサードパーティベンダーと連携します。このオプションでは、公開キー基盤 (PKI) を使用する必要があります。オプションには、自己管理 PKI、サードパーティ PKI、または Azure Sphere セキュリティサービスが含まれます。これは、Azure Sphere デバイスでのみ使用できます。
X.509 証明書を持つ TPM は、セキュリティの追加レイヤーを提供します。 DPS では、TPM 保証キーによる認証もサポートされています。主なコストは、ハードウェア、ボードの再設計の可能性、複雑さです。
対称キー認証は最もシンプルで低コストのオプションですが、セキュリティへの影響を評価する必要があります。多くの場合、デバイスとクラウドでキーを保護し、キーをデバイスに安全に格納するには、より安全なオプションが必要です。

これらの各オプションに関連するコストを確認し、潜在的に高いハードウェアまたはサービスのコストとセキュリティの強化のバランスを取ります。製造プロセスとの統合は、全体的なコストにも影響を与える可能性があります。

詳細については、「Azure IoT デバイス製造元向けのセキュリティプラクティス」を参照してください。

Azure RTOS 用の

Azure RTOS は、デバイス用の埋め込み開発スイートです。 Azure RTOS には、リソースに制約のあるデバイスに対して信頼性の高い超高速パフォーマンスを提供する、小さくて強力なオペレーティングシステムが含まれています。 Azure RTOS は使いやすく、100 億を超えるデバイスにデプロイされています。 Azure RTOS では、最も一般的な 32 ビットマイクロコントローラーと埋め込み開発ツールがサポートされているため、既存のデバイス構築スキルを最大限に活用できます。

Azure RTOS は、ライセンス付きハードウェアを使用する商用デプロイの場合無料です。 Azure RTOS には、Azure IoT クラウドの機能と、デバイスの更新やセキュリティなどの機能が付属しています。これらの機能は、デバイスとクラウドの両方の開発コストを削減するのに役立ちます。

Azure RTOS は、安全性とセキュリティに関する認定を受けています。これにより、医療、自動車、製造などの特定の業種向けに準拠したデバイスを構築する時間とコストを削減できます。

LPWAN デバイス

LoRaWAN、NB-IoT、LTE-M などの LPWAN デバイスが既に別の IoT クラウドに接続されている場合、Azure IoT Central デバイスブリッジは Azure IoT Central へのブリッジ構築に役立ちます。 Azure IoT Central Device Bridge を使用すると、既存のデバイスを変更するためのコストを発生させることなく、業界の知識の追加とソリューションの評価に注力できます。

エンタープライズ対応ソリューションを構築するときは、LPWAN デバイスを Azure IoT Hub と統合するためのコストを考慮する必要があります。

Azure Sphere

Azure Sphere とは、インターネットに接続されたデバイスのための通信およびセキュリティ機能が組み込まれている、セキュリティで保護されたエンドツーエンドの IoT ソリューションプラットフォームです。 Azure Sphere は、セキュリティで保護されたコネクテッドクロスオーバーマイクロコントローラーユニット (MCU) と、カスタムの高レベル Linux ベースオペレーティングシステム (OS) と、継続的で更新可能なセキュリティを提供するクラウドベースのセキュリティサービスとによって構成されています。 Azure Sphere を使用すると、デバイスからクラウドへのセキュリティで保護された環境を構築および維持するための労力が削減されます。

Azure Sphere では、追加コストなしの 10 年以上の X.509 ベースの PKI、ユーザーアプリの更新プログラム、エラー報告、デバイス管理に加えて、10 年間の OS 更新プログラムと 0 日間の更新可能なセキュリティが提供されます。 Azure Sphere を使用すると、何百万ものデバイスを最新のセキュリティで最新の状態に保つ運用コストが削減されます。

Azure Stack

Azure Stack ソリューションでは、オンプレミスのデータセンターやエッジの場所など、Azure データセンター以外の環境に Azure サービスと機能が拡張されます。 Azure Stack ソリューションには、Azure Stack Edge と Azure Stack HCI が含まれます。

Azure Stack Edge は、エッジの場所でのハードウェアアクセラレータによる機械学習ワークロードに最適な Azure マネージドアプライアンスです。 Azure Stack Edge はコンテナーなどの最新のテクノロジスタックで実行されるため、エッジの場所にデプロイされた Azure Stack Edge は複数のワークロードに対応できます。ワークロード間でコンピューティング能力を共有すると、TCO が削減されます。
Azure Stack HCI は、ネイティブ Azure 統合を備えた専用のハイパーコンバージドソリューションです。 Azure Stack HCI は、IoT ソリューションをホストするためのスケーラブルな仮想化を提供します。仮想化には、セキュリティ、スケーラビリティ、柔軟な環境などの追加の利点があり、ハードウェアを他のワークロードと共有することで TCO を削減できます。 Azure Stack HCI は、Azure Stack Edge よりも多くのコンピューティング能力を提供し、業界のプロセス変革に最適です。

Azure Stack ソリューションは、Azure の機能をエッジにもたらしますが、ハードウェアのサイズ設定によって、コンピューティング能力の合計が制限されます。ユースケースと推定コンピューティング能力を特定し、コストとパフォーマンスのニーズに合わせてサイズ変更を考慮します。

Azure パブリックまたはプライベート MEC

IoT デバイスでは大量のデータが生成される可能性があり、また、低消費電力と低コストの要件が強い場合もあります。小型で安価な IoT デバイスは、センサーや位置情報データの収集、さらに処理するためのオフロードなどの 1 つまたはいくつかのタスク用に設計されています。

Azure パブリックまたはプライベートマルチアクセスエッジコンピューティング (MEC) と 5G は、デバイスからデータをオフロードするコストを最適化するのに役立ちます。 MEC ベースの IoT ソリューションを使用すると、デバイスやクラウド上ではなく、エッジでの待機時間の短いデータ処理が可能になります。待機時間は、クラウドで一般的な 100 から 150 ミリ秒でなく、1 から 5 ミリ秒です。 MEC ベースの IoT ソリューションは柔軟性があり、デバイス自体は安価で、最小限のメンテナンスで動作し、より小さく、安価で長持ちするバッテリーを使用します。 MEC は、データ分析、AI、最適化の各機能をエッジで維持し、IoT ソリューションをシンプルかつ安価に保ちます。

MEC は、IoT ワークロード用のエッジ処理、コンピューティング、および 5G 通信デバイスとして機能するだけでなく、パブリッククラウドまたはリモートサイトへの高速接続を確立するための通信デバイスとして他のワークロードを提供します。

Azure IoT Edge

Azure IoT Edge には、大量のメッセージのための組み込み機能があります。ゲートウェイ機能を備えた Azure IoT Edge Managed デバイスは、ローカル処理とエッジのシナリオを通じて、ネットワークコストを削減し、メッセージの数を最小限に抑えることができます。

デバイス間またはモジュール間のエッジ通信や、多数の小さなメッセージを使用するデバイスからクラウドへの対話が避けられます。組み込みのメッセージバッチ機能を使用して、複数のテレメトリメッセージをクラウドに送信します。これらの機能は、IoT Hub の使用コストを削減するのに役立ちます。 1 日のメッセージの数と 1 秒あたりのデバイスからクラウドへの操作の数の両方を減らすと、IoT Hub で下位レベルを選択できます。詳細については、IoT Edge のパフォーマンス制限の拡張に関する記事を参照してください。

データ交換コストを削減するために、Azure Stream Analytics、Azure Functions などの Azure サービスを IoT Edge にデプロイできます。 Azure Stream Analytics と Azure Functions では、エッジで大量のデータを集計およびフィルター処理し、重要なデータのみをクラウドに送信できます。 IoT Edge 上の Azure Blob Storage を使用すると、ネットワーク経由で大量のデータを転送する必要性を低減できます。エッジストレージは、大量のデータをクラウドに送信する前に変換および最適化するのに役立ちます。

OPC Publisher や Modbus などのオープンプロトコル用の無料の Azure IoT Edge モジュールは、最小限の開発でさまざまなデバイスを接続するのに役立ちます。アップロードパフォーマンスが重要な場合は、ベンダーから実証済みの IoT Edge モジュールを選択すると、カスタムモジュールを構築するよりもコスト効率が高くなります。 Azure Marketplace から IoT Edge モジュールを検索してダウンロードできます。

インジェストと通信のレイヤー

クラウド IoT ゲートウェイは、デバイスとクラウドサービスの間のブリッジです。ゲートウェイは、クラウドプラットフォームのフロントエンドサービスとして、プロトコル変換を使用してすべてのデータを集約し、デバイスとの双方向通信を提供できます。

デバイスから IoT ゲートウェイの間の通信には、デバイス接続、ネットワーク、プロトコルなど、多くの要因を考慮する必要があります。 IoT 通信プロトコル、ネットワークの種類、メッセージングパターンを理解することは、コスト効率の高いアーキテクチャを設計および最適化するのに役立ちます。

デバイス接続の場合は、ネットワークの種類を指定することが重要です。 WiFi や LoraWAN などのプライベート LAN または WAN ソリューションを選択する場合は、全体的なコストの一部としてネットワーク TCO を検討してください。 4G、5G、LPWAN などの通信事業者ネットワークを使用する場合は、定期的な接続コストが含まれます。

IoT ソリューションプラットフォーム

ビジネス用の IoT ソリューションを構築するには、通常、"マネージドアプリプラットフォーム" アプローチを使用してソリューションを評価し、"プラットフォームサービス" を使用してエンタープライズ対応ソリューションを構築します。

プラットフォームサービスを使用すると、サービスを微調整し、全体的なコストを制御できます。カスタマイズされた柔軟な IoT アプリケーションのすべての構成要素を提供します。デバイスを接続し、データの取り込み、格納、および分析を行うときに、より多くのオプションを選択してコーディングすることができます。 Azure IoT プラットフォームサービスには、Azure IoT Hub と Azure Digital Twins 製品が含まれます。
Azure IoT Central マネージドアプリプラットフォームを使用すると、結果を達成するのに必要な意志決定の数を減らすことで、IoT ソリューションを迅速に評価できます。ソリューションのほとんどのインフラストラクチャ要素は、Azure IoT Central マネージドアプリプラットフォームによって処理されるため、業界の知識の追加とソリューションの評価に専念できます。

IoT Hub レベル

ほとんどの IoT ソリューションでは、デバイスとクラウド間の双方向通信が完全に機能し、セキュリティで保護されている必要があります。基本的な IoT Hub レベルでコア機能が提供されますが、双方向制御は含まれません。一部の初期ソリューション実装では、Basic レベルを使用してコストを削減できる場合があります。ソリューションが進むにつれて、Standard レベルに切り替えてセキュリティで保護された通信チャネルを最適化でき、クラウドからデバイスへのメッセージングコストの削減を図れます。詳細については、「ソリューションに適した IoT Hub のレベルを選択する」を参照してください。

IoT Hub メッセージのサイズと頻度

メッセージングのコストは、デバイスのメッセージ送信頻度とメッセージサイズによって大きく異なります。メッセージ送信頻度の高いデバイスは、毎分クラウドに多くのメッセージを送信することがありますが、比較的静かなデバイスは、1 時間ごと、またはそれ以上の間隔でデータを送信するだけの場合があります。多数の小さなメッセージを使用するデバイスからクラウドへの対話が発生するのを回避します。デバイスのメッセージ送信頻度の高さとメッセージサイズを明確にすることで、使用されていないクラウド容量やプロビジョニング不足が発生し、スケーリングの困難が生じる可能性がある過剰なプロビジョニングの可能性を減らせます。インフラストラクチャが適切なサイズであり、スケーリングの準備ができていることを確認するために、メッセージペイロードのサイズと頻度を検討します。

多数の小さなメッセージを使用するクラウドからデバイスへの対話が発生するのを回避します。たとえば、複数のデバイスまたはモジュールツインの更新プログラムを 1 つの更新プログラムにグループ化し、独自の調整を行います。 1 日のクォータに使用されるメッセージサイズ (無料ではない IoT Hub レベルの場合は 4K バイト) に注意してください。サイズの小さいメッセージを送信すると、使用されない容量が残る一方で、大きいメッセージは 4 KB のチャンクで課金されます。

1 つのダイレクトメソッドを使用して直接フィードバックを取得します。 1 つのデバイスまたはモジュールツインの状態更新を使用して、構成と状態の情報を非同期的に交換します。

ヒント

Azure IoT Hub 上の Microsoft Defender for IoT および Defender for IoT マイクロエージェントを使用して、メッセージ送信頻度の高い通信を監視できます。特定のしきい値を超えるデバイスからクラウドまたはクラウドからデバイスへの対話用に、IoT Hub カスタムアラートを作成できます。

メッセージサイズがコスト管理にとって重要な場合、オーバーヘッドの削減は、デバイスのライフサイクルが長い場合や大規模なデプロイを行う場合に特に重要です。このオーバーヘッドを削減するオプションは次のとおりです。

短いデバイス ID、モジュール ID、ツイン名、メッセージトピックを使用して、MQTT パケットのペイロードを減らします。 MQTT ペイロードは devices/{device_id}/modules/{module_id}/messages/events/ のようになります。
固定長オーバーヘッドとメッセージを省略します。
たとえば、Gzip を使用してペイロードを圧縮します。

IoT Hub メッセージのクォータと調整の制限

IoT Hub レベルのサイズは異なり、特定のクォータと操作の調整制限があります。 IoT Hub の制限とクォータを理解して、デバイスからクラウドへのメッセージングとクラウドからデバイスへのメッセージングのコストを最適化します。

たとえば、Standard S1 レベルの 1 日あたりのクォータは 400,000 個のメッセージです。料金は、いくつかの要因に基づいて 4 KB のチャンクで増加します。

1 つの device-to-cloud (D2C) メッセージは最大 4 KB です。
4 KB を超える D2C メッセージは、4 KB のチャンク単位で課金されます。
4 KB 未満のメッセージでは、Azure IoT SDK SendEventBatchAsync メソッドを使用して、デバイス側でのバッチ処理を最適化できます。たとえば、エッジで最大 4 つの 1 KB のメッセージをバンドルすると、1 日のメーターが 1 つのメッセージ分だけ増加します。バッチ処理は、AMQP または HTTPS にのみ適用されます。
クラウドからデバイスへのメッセージやデバイスツイン操作などのほとんどの操作では、メッセージも 4 KB のチャンク単位で課金されます。これらの操作はすべて、毎日のスループットとメッセージの最大クォータに追加されます。

詳細な価格例については、「Azure IoT Hub の価格情報」ドキュメントを参照してください。

毎日のメッセージクォータに加えて、サービス操作には調整制限があります。 IoT Hub のコスト最適化の重要な部分は、メッセージクォータと操作の調整制限の両方を最適化することです。 1 秒あたりの操作または 1 秒あたりのバイト数の形式の制限の違いを調査します。詳細については、IoT Hub のクォータと調整に関するページを参照してください。

異なる調整制限は、さまざまな IoT Hub 操作に適用されます。デバイスからクラウドへの操作には、階層に依存する 1 秒あたりの操作スロットルがあります。 4 KB のチャンク単位で測定されるメッセージサイズに加えて、操作の数も考慮してください。エッジでバッチ処理を行うと、1 回の操作でより多くのメッセージを送信できます。

2 KB の単一メッセージ、10 KB のバッチメッセージ、または 256 KB のバッチメッセージは 1 回の操作としてのみカウントされるため、調整制限に達することなくエンドポイントにさらに多くのデータを送信できます。

IoT Hub の自動スケール

IoT Hub ユニットの数を動的に調整すると、メッセージの量が変動する場合のコストを最適化できます。 IoT Hub サービスを自動的に監視およびスケーリングする自動スケーリングサービスを実装できます。自動スケール機能を実装するためのカスタマイズ可能なサンプルについては、「Azure IoT Hub の自動スケーリング」を参照してください。独自のカスタムロジックを使用して、IoT Hub レベルとユニット数を最適化できます。

スケーリング用のデプロイスタンプ

デプロイスタンプは、柔軟なデプロイ戦略、予測可能なスケール、コストのための一般的な設計パターンです。このパターンは、デバイスのグループの地理的分散、特定のスタンプへの新機能のデプロイ、デバイスあたりのコストの監視など、IoT ソリューションにいくつかのメリットを提供します。詳細については、「デプロイスタンプを使用して IoT ソリューションをスケーリングする」を参照してください。

デバイス管理とモデリングのレイヤー

デバイスの管理は、サプライチェーン管理、デバイスインベントリ、デプロイ、インストール、運用準備、デバイス更新、双方向通信、プロビジョニングなどの複雑なプロセスを調整するタスクです。デバイスモデリングにより、管理コストとメッセージングトラフィック量を削減できます。

IoT プラグアンドプレイ

TCO の削減については、プラットフォームの選択の一環として拡張ユースケースを検討してください。 IoT プラグアンドプレイを使用すると、ソリューション構築者は、手動で構成することなく、デバイスを IoT Hub または Azure Digital Twins と統合できます。 IoT プラグアンドプレイでは、Digital Twins Definition Language (DTDL) V2 を使用します。どちらも、サービスおよびツールをまたいで簡単に導入できるオープンな W3C 標準 (JSON-LD や RDF など) に基づいています。

IoT プラグアンドプレイと DTDL を使用する場合、追加料金は発生しません。 IoT Hub、Azure Digital Twins、その他の Azure サービスの Standard 料金は変わりません。

詳細については、「既存のデバイスを IoT プラグアンドプレイデバイスに変換する方法」を参照してください。

IoT Hub DPS

IoT Hub DPS は IoT Hub のヘルパーサービスであり、人間の介入を必要とせずに、低コストでゼロタッチの Just-In-Time プロビジョニングを適切な IoT ハブにプロビジョニングできます。 DPS により、数百万台のデバイスのセキュリティで保護されたスケーラブルなプロビジョニングが可能になり、エラーとコストが削減されます。

DPS を使用すると、人間の介入が少ない、または必要ないデバイスのプロビジョニングが可能になるため、作業者をトレーニングして現場に送る必要がありません。 DPS を使用すると、トラックロールのコストが削減され、トレーニングと構成に費やされる時間が短縮されます。 DPS では、手動プロビジョニングによるエラーのリスクも軽減されます。

DPS は、登録割り当てポリシー、ゼロタッチプロビジョニング、初期構成設定、再プロビジョニング、プロビジョニング解除を通じて、IoT Hub でのデバイスライフサイクル管理をサポートします。詳細については、以下を参照してください:

資産とデバイスの状態のモデリング

複数のデバイストポロジとエンティティストア (Azure Cosmos DB、Azure Digital Twins、Azure SQL Database など) のコスト差を比較します。各サービスは異なるコスト構造を持ち、IoT ソリューションに異なる機能を提供します。必要な使用に応じて、最もコスト効率の高いサービスを選択します。

Azure Digital Twins では、資産管理、デバイスの状態、テレメトリデータ用の IoT 環境のグラフベースのモデルを実装できます。 Azure Digital Twins をツールとして使用して、リアルタイムの IoT データストリーミングを使用して環境全体をモデル化し、非 IoT ソースからのビジネスデータをマージできます。カスタムオントロジを構築し、RealEstateCore、CIM、NGSI-LD などのオントロジに基づく標準を使用して、第三者とのデータ交換を簡素化できます。 Azure Digital Twins には、従量課金の価格モデルがあり、固定料金は発生しません。
Azure Cosmos DB は、グローバル分散型のマルチモデルデータベースです。コストは、リージョンまたはグローバルに分散されたレプリケートされたデータオプションを使用して、ストレージとスループットの影響を受けます。
Azure SQL Database は、デバイスと資産のモデリングのための効率的なソリューションです。 SQL Database には、コストの最適化に役立ついくつかの価格モデルがあります。

資産デプロイモデル

複数のエンドポイント、IoT デバイス、クラウドに直接接続されている、エッジゲートウェイまたはクラウドゲートウェイ経由で接続されている、さまざまなアーキテクチャを持つエッジソリューションをデプロイできます。エッジデバイスをソーシングするためのさまざまなオプションは、TCO と市場投入までの時間に影響を与える可能性があります。デバイスフリートの継続的なメンテナンスとサポートは、ソリューション全体のコストにも影響します。

特定の IoT ソリューションでデータが格納および処理される場所は、待機時間、セキュリティ、コストなどの多くの要因に影響します。各ユースケースを分析し、エッジ処理とデータストレージを使用するのが最も理にかなっている場所と、それがコストにどのように影響するかを調べます。エッジでデータを格納および処理すると、ストレージ、輸送、および処理のコストを節約できます。ただし、スケールを考慮すると、多くの場合、コストと開発のオーバーヘッドのために、クラウドサービスの方が優れたオプションになります。

Azure 料金計算ツールは、これらのオプションを比較するのに役立つツールです。

イベント処理と分析レイヤー

イベント処理と分析レイヤーの目的は、データ主導の決定を可能にすることです。イベントのタイミングと分析の目的は、考慮すべき重要な要因です。適切なサービスの選択により、アーキテクチャの効率が向上し、データとイベントの処理コストが削減されます。

要件に基づいて、IoT データ分析用にホットパス、ウォームパス、またはコールドパス処理を実装します。 Azure IoT リファレンスアーキテクチャは、これらの分析パスの違いを理解し、各パスで使用可能な分析サービスを確認するのに役立ちます。

開始するには、ホットパス、ウォームパス、コールドパスを通過するデータの種類を決定します。

ホットパスデータはメモリに保持され、通常はストリーム処理を使用してほぼリアルタイムで分析されます。出力によってアラートがトリガーされることがあり、分析ツールがすぐにクエリを実行できる構造化された形式に書き込まれることがあります。
ウォームパスデータ (最終日、週、月など) は、すぐに照会できるストレージサービスに保持されます。
コールドパス履歴データは、大規模なバッチでクエリを実行するために、低コストのストレージに保持されます。

ホット、ウォーム、コールドの分析パスを示す図。

ストレージレイヤー

IoT ソリューションの目標の 1 つは、エンドユーザーにデータを提供することです。ストレージコストを最適化するための戦略を作成するには、ストレージの種類、容量、価格を理解することが重要です。

ストレージの種類

テレメトリのリポジトリの選択は、IoT データのユースケースによって異なります。目的が IoT データを監視するだけで、ボリュームが少ない場合は、データベースを使用できます。シナリオにデータ分析が含まれている場合は、テレメトリデータをストレージに保存する必要があります。時系列に最適化された追加専用のストレージとクエリの場合は、Azure Data Explorer などの目的に合わせて設計されたソリューションを検討してください。

ストレージとデータベースは相互に排他的ではありません。特に、明確に定義されたホット、ウォーム、コールドの分析パスを使用する場合、どちらのサービスも共存して動作できます。 Azure Data Explorer とデータベースは、ホットパスとウォームパスのシナリオでよく使用されます。

Azure Storage の場合は、アクセス頻度、データ保持要件、バックアップなどのデータライフサイクル要因を考慮することも重要です。 Azure Storage は、データライフサイクルを定義し、ホット層から他の層にデータを移動するプロセスを自動化するのに役立ちます。これにより、長期的なストレージコストが削減されます。詳細については、「ライフサイクル管理ポリシーを構成する」を参照してください。

データベースソリューション

データベース機能の場合は、SQL ソリューションと NoSQL ソリューションのどちらかを選択するのが一般的です。 SQL データベースは、単純なデータ変換またはデータ集計の要件を持つ固定スキーマテレメトリに最適です。詳細については、「Azure 上のデータベースの種類」を参照してください。

Azure SQL Database と TimescaleDB for PostgreSQL は、SQL データベースの一般的な選択肢です。詳細については、次の記事をご覧ください。

データが最適に表現されるのが、固定スキーマを持たないオブジェクトまたはドキュメントとしてである場合は、NoSQL がより適した選択肢となります。 Azure Cosmos DB には、SQL や MongoDB などの複数の API が用意されています。どのデータベースでも、パーティションとインデックスの戦略は、パフォーマンスの最適化と不要なコストの削減のために重要です。詳細については、以下を参照してください:

Azure Synapse Analytics は最新の Azure データウェアハウスです。 Synapse Analytics は、Data Warehouse Units (DWU) ごとにスケーリングされます。また、ソリューションの要件を処理するために適切な容量を選択する必要があります。ユースケースに応じて、ジョブが実行されていないときにコンピューティングを一時停止して、運用コストを削減できます。

Transport layer

トランスポート層は、他のレイヤー間でデータを転送およびルーティングします。データがレイヤーとサービスの間を移動するときは、プロトコルの選択がコストに影響します。フィールドゲートウェイ、業界向けオープンプロトコル、IoT ネットワークの選択などのユースケースも、トランスポート層のコストに影響します。

送信サイズとコストを削減するには、IoT デバイスがテレメトリを送信するために適切なプロトコルを選択します。

デバイスクライアントは、IoT Hub にキープアライブ メッセージを定期的に送信します。操作ごとの料金によると、キープアライブメッセージに料金はかかりません。ただし、テレメトリに特定の要件がない場合は、キープアライブプロパティをテレメトリに追加する必要はありません。柔軟性を高めるために、Azure IoT Device SDK には、AMQP または MQTT プロトコルを使用している場合に、これらのメッセージの期間を設定するオプションが用意されています。

バッテリ駆動の IoT デバイスの場合は、デバイスが起動したときに接続を維持するか再接続するかを選択できます。この選択は、電力消費量とネットワークコストに影響します。

再接続では、TLS 接続、デバイス認証、デバイスツインの取得に約 6 KB のパケットが消費されますが、デバイスが 1 日に 1 回または 2 回だけウェイクアップすると、バッテリ容量が節約されます。メッセージをバンドルして、TLS のオーバーヘッドを減らすことができます。キープアライブは数百バイトを消費しますが、デバイスが数時間以下の時間で起動する場合は、接続を維持するとネットワークコストが節約されます。

Azure IoT device SDK の接続性と信頼性の高いメッセージング機能の概要については、「Azure IoT Hub device SDK を使用して、接続と信頼できるメッセージングを管理する」を参照してください。このガイダンスは、デバイスと Azure IoT サービス間の予期しない動作を処理するコストを削減するのに役立ちます。

DPS では、ゼロタッチプロビジョニングから提供終了までのデバイスライフサイクル管理コストが削減されますが、DPS に接続すると、TLS と認証のネットワークコストが消費されます。ネットワークトラフィックを減らすために、デバイスはプロビジョニング中に IoT Hub 情報をキャッシュし、再プロビジョニングが必要になるまで IoT Hub に直接接続する必要があります。詳細については、「デバイスからプロビジョニング要求を送信する」を参照してください。

相互作用とレポートレイヤー

IoT では時系列データが処理されるため、多数のデバイスから多くの対話が行われます。レポートと視覚化は、このデータの価値を実現します。直感的で簡素化されたユーザーエクスペリエンスと適切に設計されたデータ操作は、構築にコストがかかる場合があります。

Grafana は、時系列データ用に最適化されたダッシュボードを提供するオープンソースのデータ視覚化ツールです。 Grafana コミュニティには、環境内で再利用およびカスタマイズできる例が用意されています。時系列データのメトリックとダッシュボードを少しの手間で実装できます。 Azure には、Azure Monitor 用の Grafana プラグインが用意されています。

Power BI などのレポートツールやダッシュボードツールを使用すると、非構造化 IoT データからすばやく開始できます。 Power BI には、直感的なユーザーインターフェイスと機能が用意されています。時系列データを使用してダッシュボードとレポートを簡単に開発し、低コストでセキュリティとデプロイの利点を得ることができます。

統合レイヤー

他のシステムやサービスとの統合は複雑になる可能性があります。多くのサービスは、効率を最大限に高め、統合レイヤーのコストを最適化するのに役立ちます。

Azure Digital Twins では、さまざまなシステムやサービスを IoT データと統合できます。 Azure Digital Twins は、すべてのデータを独自のデジタルエンティティに変換するため、コスト削減のためのサービス制限とチューニングポイントを理解することが重要です。アーキテクチャを設計するときは、Azure Digital Twins サービスの制限を確認します。ビジネスシステムとの効果的な統合に役立つ機能制限について理解します。

クエリ API を使用すると、Azure Digital Twins はクエリユニット (QU) ごとに課金されます。クエリが応答ヘッダーで使用した QU の数をトレースできます。クエリの複雑さと結果の数を減らしてコストを最適化します。詳細については、「Azure Digital Twins でのクエリユニット消消費量の確認」を参照してください。

DevOps レイヤー

クラウドプラットフォームは、設備投資 (CAPEX) を運用支出 (OPEX) に変換します。このモデルは柔軟性と機敏性を提供しますが、クラウドプラットフォームを最大限に活用するには、明確に定義されたデプロイと運用モデルが必要です。適切に計画されたデプロイにより、反復可能な資産が作成され、市場投入までの時間が短縮されます。

クラウドプラットフォームは、開発者が数秒でリソースをデプロイできる機敏性を提供しますが、リソースを意図せずにプロビジョニングする、過剰にプロビジョニングするリスクがあります。適切なクラウドガバナンスモデルは、このようなリスクを最小限に抑え、不要なコストを回避するのに役立ちます。

開発環境

開発者は、開発コストを最適化するために Azure が提供する柔軟性を利用できます。 IoT Hub Free レベルは、サブスクリプションごとに 1 つのインスタンスに制限され、標準機能を提供しますが、1 日に 8,000 個のメッセージに制限されます。このレベルは、デバイスとメッセージの数が限られている初期段階の開発には十分です。

コンピューティング環境では、クラウドネイティブ IoT ソリューションにサーバーレスアーキテクチャを採用できます。 IoT ワークロードで一般的な Azure サービスには、Azure Functions や Azure Stream Analytics などがあります。課金メカニズムはサービスによって異なります。リアルタイム処理用の Azure Stream Analytics などの一部のサービスでは、開発者は追加コストを発生させずにサービスを一時停止できます。その他のサービスは使用量によって課金されます。たとえば、Azure Functions では、トランザクションの数に基づいて課金されます。開発者は、これらのクラウドネイティブ機能を利用して、開発コストと運用コストの両方を最適化できます。

統合開発環境 (IDE) により、開発とデプロイが高速化されます。 Visual Studio Code などの一部のオープンソース IDE では、開発者がコードを開発して Azure IoT サービスに無償でデプロイできる Azure IoT 拡張機能が提供されます。

Azure IoT には、無料の GitHub コードサンプルガイダンスが用意されています。これらのサンプルは、開発者がデバイス、IoT Edge、IoT Hub、Azure Digital Twins アプリケーションを拡張するのに役立ちます。 GitHub には、低コストと労力でシームレスな継続的インテグレーションと継続的デプロイ (CI/CD) 環境を実装する機能もあります。 GitHub Actions は、オープンソースプロジェクトの場合は無料です。詳細については、GitHub のプランと機能に関するページを参照してください。

コスト見積もりのロードテスト

ロードテストを使用して、エンドツーエンドの IoT ソリューションのクラウドサービスを含む全体的なコストを見積もることができます。 IoT ソリューションでは大量のデータが使用されるため、シミュレーターはロードテストに役立ちます。 Azure IoT Device Telemetry Simulator などのシミュレーションコードのサンプルは、さまざまなパラメーターを使用して大規模なコストをテストおよび見積もるのに役立ちます。

デプロイ環境

開発や運用環境など、複数の環境にワークロードをデプロイするのが一般的です。コードとしてのインフラストラクチャ (IaC) を使用すると、コードを再利用することでデプロイを高速化し、市場投入までの時間を短縮できます。 IaC は、間違ったレベルなどの意図しないデプロイを回避するのに役立ちます。 Azure Resource Manager や Azure Bicep などの Azure サービス、または Terraform や Pulumi などのサードパーティのサービスは、IaC オプションとして一般的です。

ビルドパイプラインとリリースパイプラインを使用して、さまざまな環境に DevOps デプロイプラクティスを IoT ソリューションに適用できます。例については、DevOps パイプラインを使用した予測メンテナンスソリューションのデプロイに関する記事を参照してください。

サポートおよびメンテナンス

フィールドデバイスの長期的なサポートとメンテナンスは、デプロイされたソリューションの最大のコスト負担になるまでにエスカレートする可能性があります。投資収益率 (ROI) を実現するには、システム TCO を慎重に検討することが重要です。

ソリューションの有効期間中、IoT デバイスをサポートして維持する必要があります。タスクには、ハードウェアの修復、ソフトウェアのアップグレード、OS のメンテナンス、セキュリティ修正プログラムの適用が含まれます。商用ソフトウェアと専用のドライバーとプロトコルの継続的なライセンスコストを検討してください。リモートメンテナンスを実行できない場合は、オンサイトの修復と更新の予算を設定する必要があります。ハードウェアの修理や交換には、適切なスペアを在庫に保管する必要があります。

携帯ネットワークまたは有料の接続メディアを使用するソリューションの場合は、デバイスの数、データ転送のサイズと頻度、デバイスの展開場所に基づいて適切なデータプランを選択します。サービスレベルアグリーメント (SLA) がある場合は、SLA を満たすために、ハードウェア、インフラストラクチャ、トレーニングしたスタッフをコスト効率よく組み合わせる必要があります。

クラウドガバナンス

クラウドガバナンスは、コンプライアンス、セキュリティ、不要なコストの防止に不可欠です。

コスト管理 API を使用すると、多次元分析を使用してコストと使用状況のデータを調べることができます。 Azure リソース消費関連の質問に答えるのに役立つ、カスタマイズされたフィルターと式を作成できます。コスト管理 API は、使用量が構成されたしきい値に達したときに、アラートを生成できます。コスト管理 API は、IoT Central、IoT Hub、DPS に使用できます。
リソースのタグ付けにより、デプロイされたリソースにラベルが適用されます。タグ付けは、Microsoft Cost Management と共に、ラベルに基づく継続的なコストに関する分析情報を提供します。詳細については、「一般的なコスト分析の使用」を参照してください。
Azure Policy には、リソースに自動的にラベルを付けのか、タグ付けせずにリソースにフラグを付けるための組み込みのポリシーが付属しています。詳細については、「タグの準拠のためのポリシー定義を割り当てる」を参照してください。 Azure Policy のもう 1 つのユースケースは、特定のレベルのプロビジョニングを防ぐことです。これは、開発環境または運用環境での過剰プロビジョニングを防ぐのに役立ちます。

監視

Azure サブスクリプションに含まれる多くのツールは、組織が財務ガバナンスを実装し、IoT サービスからさらに価値を引き出すのに役立ちます。これらのツールを使用すると、単一の統合ビューを使用して、すべてのクラウドでリソースの使用状況を追跡し、コストを管理できます。豊富な運用と財務に関する分析情報にアクセスして、情報に基づいた意思決定を行うことができます。

テレメトリログは、Azure Monitor の Log Analytics ワークスペースを一般的に使用します。 Log Analytics には 5 GB のストレージが含まれており、データ保持の最初の 30 日間は無料です。ビジネスニーズによっては、より長いデータ保持期間が必要になる場合があります。意図しないコストを回避するために、適切なデータ保持期間を確認して決定します。

Log Analytics には、ログを対話形式でクエリするためのワークスペース環境が用意されています。 Azure Data Explorer などの外部の場所にログを定期的にエクスポートし、ストレージアカウント内のログをアーカイブして、コストの低いストレージオプションを使用できます。詳細については、「Azure Monitor での使用量と推定コストの監視」を参照してください。

Azure Advisor

Azure Advisor は、ベストプラクティスに従って Azure デプロイメントを最適化できるようにする、個人用に設定されたクラウドコンサルタントです。 Azure Advisor は、リソース構成と利用統計情報を分析し、費用対効果、パフォーマンス、信頼性、セキュリティを向上させるために役立つソリューションを推奨します。

Advisor は、アイドル状態にあるリソースや活用されていないリソースを識別することによって Azure を最適化し、総合的な Azure の支出を削減します。コストに関する推奨事項は、Advisor ダッシュボードの [コスト] タブで取得できます。

Advisor では IoT サービスに関する特定の推奨事項は提供されませんが、Azure インフラストラクチャ、ストレージ、および分析サービスに役立つ推奨事項を提供できます。詳細については、「Azure Advisor を使用してサービスコストを削減する」を参照してください。

次のステップ

IoT ワークロードのオペレーショナルエクセレンス

次の方法で共有