次の方法で共有

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

  • [アーティクル]

現場の多種多様なシステムやデバイスにより、ワークロードの構成が困難な問題になる場合があります。 この記事では、その解決方法について説明します。

コンテキストと問題

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

解決策

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

  • ソフトウェア ソース、CI/CD パイプライン、クラウド テナント、エッジの場所など、異なるレイヤーにグループ化できる構成ポイントがいくつかあります。ワークロード構成 (ソフトウェア ソース、CI/CD パイプライン、クラウド テナント、エッジの場所) の特性を示すレイヤーの図。
  • さまざまなレイヤーが異なる担当者によって更新される可能性があります。
  • 構成の更新方法に関係なく、慎重に追跡および監査する必要があります。
  • ビジネス継続性のためには、エッジで構成にオフラインでアクセスできる必要があります。
  • また、クラウドで利用できる、構成をグローバルに確認できるビューも必要です。

問題と注意事項

このパターンの実装方法を決めるときには、以下の点に注意してください。

  • エッジがクラウドに接続されていないときに編集を許可すると、構成管理の複雑さが大幅に増加します。 変更をクラウドにレプリケートすることはできますが、次のような課題があります。
    • ユーザー認証 (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 に基づくソリューション

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

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

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

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

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

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

共同作成者

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

プリンシパル作成者:

  • Heather Camm | シニア プログラム マネージャー

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ