次の方法で共有

IoT ワークロードの信頼性

  • [アーティクル]

IoT ワークロードは、すべてのワークロードと同様に、誤動作する可能性があります。 適切に設計された IoT ソリューションの信頼性に関する主な考慮事項は、変更を検出する速度と、操作を再開する速度です。

IoT アプリケーションは大規模に分散されることが多く、エンドツーエンドのデータ フローへの永続的なアクセスや可視性なしで信頼性の低いネットワーク上で動作する可能性があります。 これらの要因により、可用性と回復性を念頭に置いて IoT アーキテクチャを設計する必要があります。

信頼性の高い IoT ソリューションを構築するには、デバイス、クラウド サービス、およびそれらの対話方法を慎重に検討する必要があります。 デバイスのハードウェア、接続とプロトコル、およびクラウド サービスに対して行う選択は、ソリューションの信頼性の要件と機能に影響します。

IoT ワークロードの信頼性を評価する

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

設計原則

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

設計原則 考慮事項
回復性のためにデバイスを設計する エンド ツー エンド ソリューションのアップタイムと可用性の要件を満たすようにデバイスを設計します。 IoT デバイスがクラウドへの断続的な接続で効率的に動作することを確認します。
ビジネス要件の設計 サービス レベル アグリーメント (SLA) を満たすためにアーキテクチャの変更を導入する場合、コストへの影響は避けられません。 たとえば、信頼性と高可用性を高めるために、リージョン間の冗長性と自動スケーリングする自動システムを実装できます。 このトレードオフは慎重に検討する必要があります。
安全で簡単な更新手順 エンタープライズ IoT ソリューションでは、オペレーターがデバイスを管理する方法の戦略を提供する必要があります。 IoT オペレーターには、シンプルで信頼性の高い更新ツールとプラクティスが必要です。
アプリケーション正常性の監視 可観測性に基づいて、サービス レベル インジケーター (SLI) とサービス レベル目標 (SLO) を定義します。 クラウド サービスが提供するものを超えて、監査、監視、アラートのプロセスを追加します。
重要なコンポーネントの高可用性とディザスター リカバリー (HA/DR)。 リージョン間の冗長性など、冗長性を備えた回復力のあるハードウェアおよびソフトウェア コンポーネント。
容量計画 サービス クォータとスロットル、検出アクション間の待機時間を計画し、中断されないデータ フローをサポートするために運用環境の規模でベンチマークを確立します。

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

信頼性設計の原則は、 IoT ワークロードが基本的な IoT アーキテクチャ レイヤー全体の要件を満たしていることを確認するための考慮事項を明確にするのに役立ちます。 ソリューションの全体的な信頼性を実現するには、各レイヤーに許容できるレベルの信頼性が必要です。

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

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

IoT ソリューション全体の一部として、ソリューションのエンドツーエンドのアップタイムと可用性の要件を満たすようにデバイスを設計します。 デバイスとゲートウェイはさまざまな形式で提供されます。 IoT デバイスとゲートウェイでは、データ収集、監督制御、エッジ分析を実行できます。

  • データ収集は、デバイスをセンサーに接続するか、ダウンストリーム システムからのテレメトリにサブスクライブし、収集されたデータをクラウドにプッシュします。 IoT ソリューション設計では、信頼性の高いデバイス管理と、デバイスからクラウドへの信頼性の高い通信を確保する必要があります。

  • 監督制御を提供するデバイスは、クラウドに送信するデータを収集するだけでなく、そのデータに基づいてアクションを実行します。 デバイスは、監視アクションを実行するためにマシンまたは環境にデータを送り返します。 監督制御アプリケーションの信頼性は非常に重要です。

デバイスの設計

IoT デバイスを設計して選択し、予想される有効期間にわたって予想される動作条件で確実に機能するようにします。 信頼性の高いデバイスは、ハードウェアとソフトウェアの仕様に従って実行する必要があり、障害は軽減、修復、または交換によって検出および管理する必要があります。 信頼性のためにデバイスを設計しますが、障害についても計画します。

デバイスのライフサイクル

サービスの有効期間が限られていると、ソリューションの信頼性に影響します。 ソリューションでのデバイス障害の結果を評価し、ソリューション要件に従ってデバイス ライフサイクル戦略を定義します。

デバイス障害への影響評価には、次のものが含まれます。

  • 重大度 (単一障害点など)。
  • 確率 (平均故障間隔など)。
  • 障害モードや効果分析などの検出可能性。
  • 許容されるダウンタイム期間。

許容される運用上のダウンタイムによって、デバイスのメンテナンスの速度と程度が決まります。 デバイスと部品の供給の可用性または寿命は、デバイスのライフサイクルに関する重要な考慮事項です。

モジュール化された設計ほど、システムの一部を簡単に交換できます。特に、一部の部品が他の部品よりも古くなった場合は特に便利です。 信頼性の高いソリューションには、コンポーネントとモジュールのサプライ チェーンの代替またはマルチソーシングが不可欠です。

環境要件

デバイスが動作する条件は、その信頼性に影響します。 環境要件を定義し、適切な機能仕様のデバイスを使用します。 これらの仕様には、動作温度範囲、湿度、イングレス保護(IP)定格、電磁干渉(EMI)耐性、衝撃および振動耐性などのパラメータが含まれます。

操作プロファイル

パフォーマンス ストレスは、デバイスの動作に影響するため、その信頼性に影響します。 デバイスの有効期間中の動作を推定し、それに応じてデバイスの信頼性を評価する操作プロファイルを定義します。 このようなプロファイルには、ワイヤレス送信モードや低電力モードなどの動作モードや、デバイスの有効期間中の温度などの環境条件が含まれます。

通常の動作条件では、デバイスとソフトウェアは、指定された操作プロファイル内で安全に実行する必要があります。 デバイスは、ソリューションに必要なすべての外部センサーとデータ処理を処理できる必要があります。 デバイス機能の制限で実行しないでください。

規制と標準

特定の業界のデバイスは、適用される規制と標準の対象となります。 規制と標準を定義し、デバイスがコンプライアンスと適合性の要件を満たしていることを確認します。 規制には、FCC や CE などの認定とマーキングが含まれます。 標準には、ATEX や MIL-SPEC などの業界または機関のアプリケーションと、IEC 61508 などの安全準拠が含まれます。

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

クラウド サービスは、各デバイスに ID を提供し、デバイスを大規模に管理します。 クラウドは、多くの場合、デバイスから送信されるすべてのメッセージの最終的なデータイングレス ポイントです。 IoT ソリューションでは、クラウド サービスは、IoT デバイスがデータを統合して送信するための信頼性を提供する必要があります。

クラウドへのアップストリームやローカル ネットワークへのダウンストリームを含むデバイス接続条件は、IoT ソリューションの信頼性設計の一部である必要があります。 接続の中断または干渉の潜在的な影響を評価し、それに応じて接続戦略を定義します。

接続戦略には、フォールバック機能や切断管理などの堅牢性と、重要または安全機能のクラウドの依存関係を軽減するためのバックアップのバッファリングが含まれている必要があります。

次の設計、エラー処理、監視のプラクティスは、接続に関連しています。

接続の設計

IoT ソリューションでは、断続的に接続されたデバイスとクラウドベースのサービスの間の情報フローを有効にする必要があります。 IoT デバイスがクラウドへの断続的な接続で効率的に動作できることを確認します。

ベスト プラクティスには、次の推奨事項が含まれます。

  • デバイス ソフトウェアに再試行ロジックとバックオフ ロジックを実装します。
  • デバイスの状態をクラウドと同期します。
  • ソリューションでデータ損失を許容できない場合は、デバイスにデータを格納できることを確認します。
  • データ サンプリングとシミュレーションを使用して、ネットワーク容量とストレージ要件のベースラインを測定します。

接続の実装

Azure IoT デバイス SDK には、Azure IoT サービスとの接続を簡素化するためにデバイスまたはゲートウェイで使用できるクライアント ライブラリが用意されています。 SDK を使用して、次の IoT デバイス クライアントをインストルメント化できます。

  • クラウドに接続します。
  • さまざまなプラットフォームで一貫したクライアント開発エクスペリエンスを提供します。
  • ジッターと再試行ロジックを使用した指数バックオフなど、基になるプロトコルとメッセージ処理パターンの詳細を抽象化することで、一般的な接続タスクを簡略化します。

接続の監視

IoT デバイスの接続の問題は、多くの障害点が考えられるため、トラブルシューティングが困難な場合があります。 アプリケーション ロジック、物理ネットワーク、プロトコル、ハードウェア、Azure IoT Hub、およびその他のクラウド サービスに問題が発生する可能性があります。

問題の原因を検出して特定する能力は非常に重要です。 ただし、大規模な IoT ソリューションには何千ものデバイスが含まれる可能性があるため、個々のデバイスを手動でチェックすることは現実的ではありません。 Azure Monitor とAzure Event Gridは、IoT Hubでの接続の問題の診断に役立ちます。

接続のリソース

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

IoT インジェストと通信レイヤーでは、サービスのクォータと制限、容量、調整、自動スケーリングについて説明します。

冗長な容量設計

しきい値とアラートを計画する場合は、検出と実行されたアクションの間の待機時間を考慮してください。 システムとオペレーターが変更要求に対応するのに十分な時間があることを確認します。 そうしないと、ユニット数を増やす必要が検出されますが、増加が有効になる前にメッセージが失われると、システムが失敗する可能性があります。

サービス クォータの計画

すべてのプラットフォーム サービスと同様に、IoT Hubと IoT Hub Device Provisioning Service (DPS) は特定の操作にクォータとスロットルを適用するため、Azure はサービスに予測可能なサービス レベルとコストを提供できます。 クォータとスロットルは、デプロイするサービス レベルとユニット数に関連付けられているため、適切な数のリソースを使用してソリューションを設計できます。 クォータとスロットルを事前に確認し、それに応じてIoT Hubと DPS リソースを設計します。

運用規模のベンチマーク

デバイスの数またはデータの量が増えるにつれて、クラウド ゲートウェイは中断されないデータ フローをサポートするようにスケーリングする必要があります。 IoT ソリューションの分散型の性質、デバイスの数、データの量により、ソリューション全体のスケール ベンチマークを確立することが重要です。 これらのベンチマークは、容量リスクの計画に役立ちます。 Azure IoT Device Telemetry Simulator を使用して、運用環境のスケール ボリュームをシミュレートします。

クォータに動的に調整する自動スケーリング

サービスとしてのプラットフォーム (PaaS) コンポーネントを使用する利点は、ニーズに応じてほとんど労力をかからなくスケールアップおよびスケールダウンできることです。 コストと運用の労力を最小限に抑えるために、ソリューションのさまざまなニーズに合わせてリソースをスケールアップまたはスケールダウンする自動化システムの実装を検討してください。

クォータとスロットルの管理

ソリューションの信頼性を確保するには、クォータとスロットルに対してリソースの使用状況を継続的に監視し、スケーリングの必要性を示す使用量の増加を検出します。 ビジネス要件に応じて、リソースの使用状況を継続的に監視し、しきい値が満たされたときにオペレーターに警告したり、自動スケーリングする自動システムを実装したりできます。

容量とスケーリングリソース

Transport layer

データ、制御、管理のためにクラウド サービスに接続するには、デバイスがネットワークにアクセスする必要があります。 IoT ソリューションの種類によっては、接続の信頼性がユーザーの責任であるか、ネットワーク サービス プロバイダーの責任である可能性があります。 ネットワークに断続的な接続の問題が発生する可能性があり、デバイスはそれに応じて動作を管理する必要があります。

DevOps レイヤー

エンタープライズ IoT ソリューションでは、オペレーターがシステムを管理するための戦略を提供する必要があります。 信頼性に対処するために、IoT の管理と運用では、DevOps プロセスを使用して、更新、監視と監視、HA/DR の実装を処理する必要があります。

更新プログラム

IoT ソリューションのデバイスの側面は、クラウドベースのソリューションと比較して課題を提示します。 たとえば、脆弱性やアプリケーションの変更に対処するために、デバイスを継続的に更新する方法が必要です。

IoT ソリューションの分散型の性質上、更新プログラムをデプロイするための安全で安全なポリシーを採用することが重要です。 IoT オペレーターには、シンプルで信頼性の高い更新ツールとプラクティスが必要です。

デバイス更新ソリューションでは、次をサポートする必要があります。

  • デバイスのグループ化とスケジュール制御による段階的な更新ロールアウト。
  • シームレスなロールバックのための回復力のある A/B デバイス更新プログラムのサポート。
  • 詳細な更新管理およびレポート ツール。
  • 使用可能な帯域幅に基づくネットワークの最適化。

device Update for IoT Hub は、安全で安全で信頼性の高いワイヤレス (OTA) IoT デバイスの更新を可能にするサービスです。 IoT Hubの Device Update では、デバイスをグループ化し、更新プログラムを受信するデバイスを指定できます。 オペレーターは、更新プログラムの展開の状態と、各デバイスが必要な更新プログラムを正常に適用したかどうかを確認できます。

更新が失敗した場合、デバイス更新はオペレーターが失敗したデバイスを識別し、エラーの詳細を確認するのに役立ちます。 障害が発生したデバイスを特定する機能により、障害の原因を手動で特定しようとする時間を省くことができます。

デバイス更新プログラムは、デバイスの展開と更新プログラムの状態を監視し、利用可能な互換性のある更新プログラムの最高バージョンに準拠しているデバイスの数を報告します。

可観測性と監視

ソリューションの全体的な信頼性を管理し、アラート手順を定義するには、IoT ソリューションのすべてのコンポーネントを監視する必要があります。 すべての Azure IoT サービスは、サービスの正常性と可用性を説明するメトリックを発行します。 エンドツーエンドの可観測性を確立するには、デバイス側で必要なメトリックも検討してください。 これらのメトリックは、ソリューション全体の信頼性の監視の一部として使用します。

IoT アプリケーションの監視と診断は、可用性と回復性にとって非常に重要です。 何かが失敗した場合、失敗した "こと"、失敗した "とき"、失敗した "理由" を知る必要があります。 IoT アプリケーションとデバイスの操作を正常な状態に対して監視することで、信頼性の問題を検出して修正できます。

IoT アプリケーションの信頼性に影響する問題を軽減するには、エンド ツー エンドの操作で問題を検出するのに役立つログとシグナルをキャプチャできる必要があります。 ログと監視を使用して、IoT ソリューションが期待どおりに機能しているかどうかを判断し、ソリューション コンポーネントに関する問題のトラブルシューティングに役立てます。

次のアクションでは、IoT ソリューションの可観測性がサポートされています。

  • パフォーマンス メトリックとアラートを収集して分析するメカニズムを確立します。
  • Azure Monitor を収集して接続するように、デバイス、クラウド サービス、アプリケーションを構成します。
  • リアルタイムのダッシュボードとアラートを使用して、Azure バックエンド サービスを監視します。
  • イベントとアラートを監視および処理するためのロールと責任を定義します。 詳細については、「 ロール、責任、およびアクセス許可」を参照してください。
  • 継続的な監視を実装します。

Azure Monitor

Azure Monitor は、Azure IoT ソリューションに推奨される監視および視覚化プラットフォームです。 デプロイ場所に関係なく、デバイス、クラウド サービス、アプリケーションを構成して、ログ メッセージを直接、または組み込みのコネクタを介して Azure Monitor にプッシュできます。

  • IoT Edge デバイスのリモート監視には、Azure Monitor の組み込みメトリック統合を使用します。 デバイスでこの機能を有効にするには、IoT Edge Metrics Collector モジュールをデプロイに追加し、モジュール メトリックを収集して Azure Monitor に転送するように構成します。

  • Azure Monitor を使用すると、IoT Hub環境の状態を監視し、正常に実行されていることを確認し、デバイスが調整されていないか、接続の問題が発生していないことを確認できます。 IoT Hubでは、使用されるメッセージの数や接続されているデバイスの数などの使用状況メトリックが提供されます。 このデータを Azure Monitor に中継して分析したり、他のサービスにアラートを送信したりできます。

  • ソリューションで Azure IoT Central を使用している場合は、IoT Central が提供するメトリックを使用して、接続されているデバイスとアクティブなデータ エクスポートの正常性を評価できます。 IoT Central アプリケーションでは、既定でメトリックが有効になります。このメトリックは、Azure portalからアクセスできます。 Azure Monitor では、これらのメトリックを操作するためのいくつかの方法が公開され、提供されています。

  • Azure Monitor には、インデックス作成と検索のためにイベントとレコードを個々のフィールドに分解するためのカスタム ログ解析が用意されています。

  • リアルタイム ダッシュボードと Azure Monitor アラートを実装して、Azure バックエンド サービスを監視します。 アラートでは、監視データ内の特定の条件について事前に通知されるため、顧客が問題に遭遇する前に問題を特定して対処できます。 アラートはメトリック、ログ、アクティビティ ログに対して設定できます。

Application Insights: 拡張可能なアプリケーション パフォーマンス管理とライブ Web アプリの監視を提供する Azure Monitor の機能。 IoT ソリューションでカスタム Azure App Service、Azure Kubernetes Service、またはAzure Functions アプリケーションを使用している場合は、Application Insights を使用してアプリの監視と分析を行うことができます。

Application Insights では、次のことができます。

  • パフォーマンスの異常を自動的に検出する。
  • 強力な分析ツールを使用して問題を診断するのに役立つ。
  • ユーザーがアプリで実際に何を行っているかを示します。
  • アプリのパフォーマンスと使いやすさを継続的に向上させるのに役立ちます。

継続的な監視

継続的インテグレーションと継続的デプロイ (CI/CD) は、ユーザーに継続的な価値を提供するために、ソフトウェアをより迅速かつ確実に提供する DevOps プラクティスです。 継続的監視 (CM) は、DevOps サイクルのすべてのフェーズとコンポーネントにわたって監視を組み込む同様の概念です。

CM は、アプリとインフラストラクチャが開発、運用、リリースを通じて顧客に流れるにつれて、アプリとインフラストラクチャの正常性、パフォーマンス、信頼性を継続的に確保します。 詳細については、次を参照してください。

リソースの監視

重要なコンポーネントの HA/DR

IoT ソリューションを設計して構築するときは、ソリューション スタック全体の障害復旧に関する SLA を満たす必要があります。 SLA では、HA/DR が必要な重要なシステム コンポーネントについて説明する必要があります。 IoT ソリューション スタック全体の冗長性から特定のレイヤーの冗長性まで、複数のアプローチがあります。 コストは、SLA を満たすことの重要性を考慮する大きな考慮事項でもあります。

  • Azure IoT サービスには、アップタイムと可用性のターゲットが定義されています。 ソリューションの一部である Azure IoT サービスの SLA を確認して、アップタイムの目標を満たしているかどうかを確認します。 たとえば、Azure IoT Hubの SLA は 99.9% です。つまり、1 日あたり 1 分 36 秒の潜在的なダウンタイムを計画する必要があります。 Azure IoT Hub SDK には、再試行とバックオフを処理するための組み込みの構成可能なロジックが用意されています。

  • アップタイムの目標を、デバイス管理とデータ インジェスト操作の 2 つのカテゴリに分割することを検討してください。 たとえば、デバイス管理サービスが利用できない場合でも、デバイスが IoT ハブにデータを正常に送信することが重要な場合があります。 詳細については、AZURE IOT HUB SDK の信頼性機能に関するページを参照してください。

  • センサー、電源、ストレージに冗長ハードウェアを使用することを検討してください。 冗長ハードウェアを使用すると、重要なコンポーネントが使用できない場合にデバイスを機能させることができます。 ハードウェアは、接続の問題にも役立ちます。 たとえば、接続が利用できない場合は、データに対してストアと転送のアプローチを使用できます。 Azure IoT Edgeには、この機能が組み込まれています。

  • また、デバイスはクラウドの停止を処理できる必要があります。 Azure リージョンペアリングは、多くの SLA 要件を満たすIoT Hubの HA/DR 戦略を提供します。 リージョンのペアリングが不十分な場合は、セカンダリ IoT ハブの実装を検討してください。 DPS を使用して、デバイスでハードコーディングされたIoT Hub構成を回避することもできます。 プライマリ IoT ハブがダウンした場合、DPS はデバイスを別のハブに割り当てることができます。

  • ほとんどの場合、オンラインになると予想されるデバイスにハートビート メッセージ パターンを実装することを検討してください。 このパターンでは、Azure Stream Analytics、Azure Logic Apps、またはAzure Functionsを使用してカスタム IoT Hub ルートを使用して、ハートビートが失敗したかどうかを判断します。 ハートビートを使用して、必要に応じてアクションを実行する Azure Monitor アラートを定義できます。

HA/DR リソース

次の手順

IoT ワークロードのセキュリティ