次の方法で共有


Edge ワークロード構成パターン

現場でさまざまなシステムやデバイスを使用すると、ワークロードの構成が困難な問題になる可能性があります。 この記事では、それを解決する方法について説明します。

コンテキストと問題

製造会社は、デジタル変革の過程の一環として、共有機能として再利用できるソフトウェア ソリューションの構築にますます注力しています。 現場にはさまざまなデバイスとシステムがあるため、モジュール型ワークロードは、さまざまなプロトコル、ドライバー、データ形式をサポートするように構成されています。 ワークロードの複数のインスタンスでも、同じエッジの場所で異なる構成で実行される場合があります。 一部のワークロードでは、構成は 1 日に 1 回以上更新されます。 そのため、エッジ ソリューションのスケールアウトに対する構成管理の重要性がますます高まっています。

解決策

エッジ ワークロードの構成管理には、いくつかの一般的な特性があります。

  • ソフトウェア ソース、CI/CD パイプライン、クラウド テナント、エッジの場所など、個別のレイヤーにグループ化できる構成ポイントがいくつかあります。 ワークロード構成を特徴付けるレイヤーの図:ソフトウェア ソース、C I/C D パイプライン、クラウド テナント、エッジの場所。
  • さまざまなレイヤーは、さまざまなユーザーが更新できます。
  • 構成を更新する方法に関係なく、慎重に追跡および監査する必要があります。
  • ビジネス継続性のためには、エッジでオフラインで構成にアクセスできる必要があります。
  • また、クラウドで使用可能な構成のグローバル ビューが必要です。

問題と考慮事項

このパターンを実装する方法を決定するときは、次の点を考慮してください。

  • エッジがクラウドに接続されていないときに編集を許可すると、構成管理の複雑さが大幅に増加します。 クラウドに変更をレプリケートすることは可能ですが、次の課題があります。
    • ユーザー認証は、Microsoft Entra ID などのクラウド サービスに依存するためです。
    • ワークロードが手動介入を必要とする予期しない構成を受け取った場合、再接続後の競合の解決。
  • トポロジが ISA-95 要件に準拠している場合は、エッジ環境にネットワーク関連の制約を設定できます。 このような制約を克服するために、Azure IoT Edgeデバイス階層など、レイヤー間の接続を提供するテクノロジを選択します。
  • ランタイム構成がソフトウェア リリースから切り離されている場合は、構成の変更を個別に処理する必要があります。 履歴機能とロールバック機能を提供するには、過去の構成をクラウドのデータストアに格納する必要があります。
  • 存在しないエンドポイントに構成された接続コンポーネントなど、構成の障害によってワークロードが中断される可能性があります。 そのため、監視可能ダッシュボードがシステム エラーと構成変更の関連付けを支援できるように、監視ソリューションの他のデプロイ ライフサイクル イベントを処理する際に、構成の変更を処理することが重要です。 可観測性の詳細については、「 クラウド監視ガイド: 可観測性」を参照してください。
  • クラウドおよびエッジ データストアがビジネス継続性で果たす役割について説明します。 クラウド データストアが信頼できる唯一のソースである場合、エッジ ワークロードは、自動化されたプロセスを使用して目的の状態を復元できる必要があります。
  • 回復性のために、エッジ データストアはオフライン キャッシュとして機能する必要があります。 これは、待機時間に関する考慮事項よりも優先されます。

このパターンを使用する場合

このパターンは次の状況で使用します。

  • ソフトウェア リリース サイクルの外部でワークロードを構成する必要があります。
  • さまざまなユーザーが構成を読み取って更新できるようにする必要があります。
  • クラウドに接続していない場合でも、構成を使用できる必要があります。

ワークロードの例:

  • データ インジェストのために現場の資産 (OPC Publisher など) に接続し、コマンドと制御を行うソリューション
  • 予測メンテナンスのための機械学習ワークロード
  • 製造ラインで品質をリアルタイムで検査する機械学習ワークロード

例示

実行時にエッジ ワークロードを構成するソリューションは、外部構成コントローラーまたは内部構成プロバイダーに基づいて行うことができます。

外部構成コントローラーのバリエーション

外部構成コントローラーのバリエーションのアーキテクチャの図。

このバリエーションには、ワークロードの外部にある構成コントローラーがあります。 クラウド構成コントローラー コンポーネントの役割は、エッジ構成コントローラーを介してクラウド データストアからワークロードに編集をプッシュすることです。 エッジにはデータストアも含まれているため、クラウドから切断された場合でもシステムが機能します。

IoT Edge では、エッジ構成コントローラーをモジュールとして実装でき、構成は モジュール ツインで適用できます。 モジュール ツインにはサイズ制限があります。構成が制限を超えた場合は、 Azure Blob Storage を使用 するか、 ダイレクト メソッドよりも大きなペイロードをチャンクすることで、ソリューションを拡張できます。

このバリエーションの利点は次のとおりです。

  • ワークロード自体は、構成システムを認識する必要はありません。 この機能は、ワークロードのソース コードが編集できない場合 ( たとえば、Azure IoT Edge Marketplace のモジュールを使用する場合) に必要です。
  • クラウド構成コントローラーを使用して変更を調整することで、複数のワークロードの構成を同時に変更できます。
  • 追加の検証は、プッシュ パイプラインの一部として実装できます。たとえば、構成をワークロードにプッシュする前に、エッジにエンドポイントが存在することを検証します。

内部構成プロバイダーのバリエーション

内部構成プロバイダーのバリエーションのアーキテクチャの図。

内部構成プロバイダーのバリエーションでは、ワークロードは構成プロバイダーから構成をプルします。 実装例については、「 .NET でのカスタム構成プロバイダーの実装」を参照してください。 この例では C# を使用していますが、他の言語を使用できます。

このバリエーションでは、ワークロードには一意の識別子があるため、異なる環境で実行されている同じソース コードで異なる構成を使用できます。 識別子を構築する 1 つの方法は、ワークロードの階層関係をテナントなどの最上位グループに連結することです。 IoT Edge の場合、Azure リソース グループ、IoT ハブ名、IoT Edge デバイス名、モジュール識別子の組み合わせにすることができます。 これらの値は、データストア内のキーとして機能する一意の識別子を形成します。

モジュールのバージョンは一意の識別子に追加できますが、ソフトウェア更新プログラム間で構成を保持することが一般的な要件です。 バージョンが識別子の一部である場合は、以前のバージョンの構成を、追加の実装で移行する必要があります。

このバリエーションの利点は次のとおりです。

  • データストア以外に、ソリューションにはコンポーネントは必要なく、複雑さが軽減されます。
  • 互換性のない古いバージョンからの移行ロジックは、ワークロードの実装内で処理できます。

IoT Edge に基づくソリューション

I o T Edge ベースのバリエーションのアーキテクチャの図。

IoT Edge 参照実装のクラウド コンポーネントは、クラウド構成コントローラーとして機能する IoT ハブで構成されます。 Azure IoT Hub モジュール ツイン機能は、モジュール ツインの必要なプロパティと報告されたプロパティを使用して、構成の変更と現在適用されている構成に関する情報を伝達します。 構成管理サービスは、構成のソースとして機能します。 また、構成、ビルド システム、およびワークロード構成の作成に使用されるその他のツールを管理するためのユーザー インターフェイスにすることもできます。

Azure Cosmos DB データベースには、すべての構成が格納されます。 複数の IoT ハブと対話でき、構成履歴が提供されます。

エッジ デバイスは、構成が適用されたことを報告されたプロパティを介して示した後、構成状態サービスによってデータベース インスタンス内のイベントが記録されます。

構成管理サービスで新しい構成が作成されると、Azure Cosmos DB に格納され、デバイスが存在する IoT ハブでエッジ モジュールの必要なプロパティが変更されます。 その後、構成は IoT Hub によってエッジ デバイスに送信されます。 エッジ モジュールは構成を適用し、モジュール ツインを介して構成の状態を報告することが期待されます。 その後、構成状態サービスはツイン変更イベントをリッスンし、モジュールが構成状態の変更を報告したことを検出すると、対応する変更が Azure Cosmos DB データベースに記録されます。

エッジ コンポーネントは、外部構成コントローラーまたは内部構成プロバイダーを使用できます。 どちらの実装でも、構成はモジュール ツインの必要なプロパティで送信されるか、大規模な構成を送信する必要がある場合は、モジュール ツインの必要なプロパティに 、Azure Blob Storage または構成の取得に使用できる別のサービスへの URL が含まれます。 その後、モジュールは、新しい構成が正しく適用されたかどうかと、現在適用されている構成を、モジュール ツインで報告されるプロパティで通知します。

貢献者

この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。

主要な著者

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ