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

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

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

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

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

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

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

設計原則

アーキテクチャの卓越性の 5 つの柱 が、IoT ワークロードの設計手法を支える。 これらの柱は、 主要な IoT 設計領域全体で後続の設計上の決定を行うためのコンパスとして機能します。 次の設計原則は、Azure Well-Architected Framework - コスト最適化の品質の柱を拡張します。

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

総保有コスト (TCO)

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

長期的な集計コストを正しく見積もる必要があります。 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 ソリューション アーキテクチャが含まれます。 業界固有の専門知識も必要になる場合があります。 これらのコストをデバイスの全体的なコストに含めます。

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

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

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

• Azure IoT デバイスの種類の概要
• IoT ソリューション内のデバイス構成のベスト プラクティス

ハードウェアの選択

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

• 既製のデバイスはユニットあたりのコストが高くなりますが、予測可能なコストとリード タイムがあります。 既製のデバイスを使用すると、複雑なサプライ チェーン管理も不要になります。

• カスタム デバイスを使用すると、ユニット コストを削減できますが、開発時間が伴い、設計、テスト、認定申請、製造などの定期的でないエンジニアリング コストが発生します。

• 事前に認定されたシステムコンポーネントまたはモジュールは、市場投入までの時間を短縮し、セミカスタムデバイスを作成できますが、ディスクリートチップよりも高価です。 サプライ チェーンと在庫管理を適切にリソース化する必要があります。

Azure 認定デバイス カタログは、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 では、X.509 ベースの PKI、ユーザー アプリの更新プログラム、エラー報告、およびデバイス管理に加えて、10 年間、OS の更新プログラムとゼロデイの再生可能なセキュリティが 10 年間提供されます。追加コストはかからずに行われます。 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 マネージド デバイスを使用すると、ローカル処理とエッジ シナリオを通じてネットワーク コストを削減し、メッセージの数を最小限に抑えることができます。

デバイス間またはモジュール間のエッジ通信や、多数の小さなメッセージを使用するデバイスからクラウドへの対話は避けてください。 組み込みのメッセージ バッチ処理機能を使用して、複数のテレメトリ メッセージをクラウドに送信します。 これらの機能は、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 ソリューションをすばやく評価できるマネージド アプリ プラットフォームです。 IoT Central では、ソリューション内のほとんどのインフラストラクチャ要素が処理されるため、業界の知識を追加し、ソリューションを評価することに集中できます。

IoT Hub レベル

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

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

メッセージング コストは、デバイスの チャットと メッセージ サイズに大きく依存します。 チャットデバイスは毎分クラウドに多くのメッセージを送信しますが、比較的静かなデバイスは1時間以上ごとにデータを送信するだけです。 多数の小さなメッセージを使用するデバイス間の対話は避けてください。 デバイスのチャットとメッセージ サイズに関するClarityは、過剰プロビジョニングの可能性を減らすのに役立ちます。これにより、使用されていないクラウド容量やプロビジョニング不足が発生し、スケールの課題が発生します。 メッセージ ペイロードのサイズと頻度を考慮して、インフラストラクチャが正しいサイズであり、スケーリングの準備ができていることを確認します。

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

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

ヒント

Azure IoT Hub上の IoT 用Microsoft Defenderと 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 つのデバイス間 (D2C) メッセージは最大 4 KB です。
• 4 KB を超える D2C メッセージは、4 KB のチャンクで課金されます。
• 4 KB 未満のメッセージでは、Azure IoT SDK SendEventBatchAsync メソッドを使用して、デバイス側でバッチ処理を最適化できます。 たとえば、エッジで最大 4 つの 1 KB メッセージをバンドルすると、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 サービスの標準料金は変わりません。

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

DPS のIoT Hub

IoT Hub DPS は、人間の介入を必要とせずに、適切な IoT ハブに低コストでゼロタッチの Just-In-Time プロビジョニングを可能にする、IoT Hubのヘルパー サービスです。 DPS を使用すると、数百万台のデバイスを安全かつスケーラブルにプロビジョニングして、エラーとコストを削減できます。

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

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

• DPS の価格
• デバイスを再プロビジョニングする方法

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

複数のデバイス トポロジと 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 ソリューションと非 SQL ソリューションのどちらかを選択するのが一般的です。 SQL データベースは、単純なデータ変換またはデータ集計の要件を持つ固定スキーマ テレメトリに最適です。 詳細については、「 Azure 上のデータベースの種類」を参照してください。

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

• Azure SQL Database のコストを計画および管理する
• Azure SQL Database とコストの最適化
• Azure SQL Database for PostgreSQL 拡張機能
• Azure SQL データベースのパフォーマンス チューニング

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

• Azure Cosmos DB でのパーティション分割と水平スケーリング
• Azure Cosmos DB のコストを計画および管理する

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

Transport layer

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

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

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

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

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

Azure IoT デバイス SDK の接続性と信頼性の高いメッセージング機能の概要については、「Azure IoT Hub デバイス 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 で QU 消費量を検索する」を参照してください。

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 デバイス テレメトリ シミュレーターなどのシミュレーション コード サンプルは、さまざまなパラメーターを使用して大規模なコストをテストして見積もるのに役立ちます。

デプロイ環境

開発や運用環境など、複数の環境にワークロードをデプロイするのが一般的です。 コードとしてのインフラストラクチャ (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 サブスクリプションに含まれる多くのツールは、organizationが財務ガバナンスを実装し、IoT サービスからより多くの価値を得るのに役立ちます。 これらのツールは、1 つの統合ビューを使用して、すべてのクラウドでリソースの使用状況を追跡し、コストを管理するのに役立ちます。 豊富な運用と財務に関する分析情報にアクセスして、情報に基づいた意思決定を行うことができます。

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

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

Azure Advisor

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

Advisor は、アイドル状態のリソースと使用率の低いリソースを特定することで、Azure の全体的な支出を最適化し、削減するのに役立ちます。 コストに関する推奨事項は、Advisor ダッシュボードの [コスト] タブから取得できます。

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

次の手順

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

関連リソース

• コスト最適化の設計原則
• コスト モデルを作成するための推奨事項
• コスト最適化の設計レビュー チェックリスト
• Azure IoT 参照アーキテクチャ
• Azure IoT のドキュメント