ワークロードの概要 (プレビュー)
この章では、マイクロソフトのシステムの主要なコンポーネントを紹介し、アーキテクチャの概要について説明します。 これらのコンポーネントは連携して、開発ニーズに合わせて信頼性の高い柔軟なプラットフォームを作成します。 アーキテクチャ内でのこれらのコンポーネントとその役割について詳しく見ていきましょう。
Fabric ワークロード アーキテクチャ
Fabric ワークロード アーキテクチャの主な側面の一部を次に挙げます。
データの処理、ストレージ、管理を行います。 Microsoft Entra ID トークンを処理する前に検証し、レイクハウスなどの外部 Azure サービスとやりとりします。
ワークロード フロントエンド (FE) には、ジョブの作成、編集、管理、実行のためのユーザー インターフェイスが備わっています。
FE を介したユーザー操作により、Fabric Backend (Fabric BE) を介して直接的または間接的に BE への要求が開始されます。
さまざまなコンポーネントのやりとりと認証を示すより詳細な図については、「バックエンドの認証と承認の概要」と「認証の概要」の図を参照してください。
Frontend (FE)
フロントエンドは、Fabric ポータルの iframe 内で動作するユーザー エクスペリエンス (UX) と動作の基本として機能します。 Fabric パートナーには、アイテム エディターを含む特定のユーザー インターフェイス エクスペリエンスが提供されます。 拡張クライアント SDK には、通常の Web アプリを Fabric ポータル内でシームレスに動作する Micro Frontend Web アプリに変換するのに必要なインターフェイス、API、ブートストラップ機能が備わっています。
Backend (BE)
バックエンドは、データ処理とメタデータ ストレージの強力な機能です。 CRUD 操作を使用して、メタデータと共にワークロード アイテムの作成や管理を行い、ジョブを実行してストレージ内のデータを事前設定します。 フロントエンドとバックエンドの間の通信ブリッジは、パブリック API を介して確立されます。
ワークロードは、ローカル環境とクラウド環境の 2 つの環境で実行できます。 ローカル (devmode) では、ワークロードは開発者のマシン上で実行され、API 呼び出しは DevGateway ユーティリティによって管理されます。 このユーティリティは、Fabric へのワークロードの登録も処理します。 クラウド モードでは、ワークロードはパートナー サービスで実行され、HTTPS エンドポイントへの API 呼び出しが直接行われます。
開発環境
Note
開発モードごとに、Visual Studio で BE ソリューションをビルドするときに異なるパッケージが作成されます。
- 開発モード ワークロード パッケージ: Visual Studio でバックエンド ソリューションをビルドする場合、Debug パラメーターを使用して BE NuGet パッケージを作成します。このパッケージは、DevGateWay アプリケーションを使用して Fabric テナントに読み込むことができます。
- クラウド モード ワークロード パッケージ: Visual Studio で BE ソリューションをビルドする際に、Release パラメーターを使用してスタンドアロン ワークロード パッケージ (BE および FE) を作成します。 このパッケージは、テナントに直接アップロードできます。
ワークロード NuGet パッケージの構造
ワークロードは、バックエンド コンポーネントとフロントエンド コンポーネントを組み合わせた NuGet パッケージとしてパッケージ化されます。 構造は特定の名前付け規則に準拠しており、アップロード シナリオ全体で一貫性を保つために Fabric によって適用されます。 ワークロードを表すために設計された NuGet パッケージは、バックエンド コンポーネントとフロントエンド コンポーネントの両方を含むように構成されています。
バックエンド構造
バックエンド セグメントは、Fabric への登録に不可欠なワークロードおよびその関連項目を定義する.xml ファイルで構成されます。
主なコンポーネント
WorkloadManifest.xml- ワークロード構成ファイル。Fabric の検証用にこの正確な名前が必要です。Item1.xml、Item2.xml、...- XML 形式に従って、柔軟な名前付けを持つ個々のアイテムのマニフェスト。
フロントエンド構造
フロントエンド セクションには、フロントエンドの製品とアイテムの詳細を示す.json ファイルと、アイコンの "資産" ディレクトリが含まれています。
主なコンポーネント
Product.json- 製品のフロントエンドのメイン マニフェスト。Fabric の検証用に正確に名前を付ける必要があります。assetsフォルダー - フロントエンドによって使用されるすべての.svg アイコンicon1.svg、icon2.svg、...を格納します。
必須の構造のコンプライアンス
特定のサブフォルダー名 ('BE'、'FE'、'assets' など) を含む構造は必須であり、テスト パッケージや開発パッケージを含むすべてのアップロード シナリオで Fabric によって強制されます。 構造は、./src/Packages/manifest/ManifestPackage ディレクトリの下のリポジトリにある .nuspec ファイルで指定されています。
開発サイクルでは、非実稼働テナントでのワークロードのテストは、ローカル (devmode) モードとクラウド モード (テナント モード) の 2 つのモードで実行できます。
制限
次の制限は、開発モードとクラウド モードの両方で、すべての種類の NuGet パッケージに適用されます。
BEおよびFEサブフォルダーのみが許可されます。 これらのフォルダーの外部にあるその他のサブフォルダーまたはファイルは、アップロード エラーになります。BEフォルダーは、.xmlファイルのみを受け入れます。 その他のファイルの種類では、アップロード エラーが発生します。- 最大 10 個のアイテム ファイルを使用できます。つまり、
BEフォルダーには 1 つのWorkloadManifest.xmlと最大 10 個のItem.xmlファイルを含めることができます。 フォルダーに 10 個を超えるアイテム ファイルがあると、アップロード エラーが発生します。 Assetsサブフォルダーは、FEフォルダーの下に存在する必要があります。 最大 15 個のファイルを含めることができます。各ファイルは 1.5 MB 以下です。Assetsサブフォルダーには、次のファイルの種類のみが許可されます:.jpeg、.jpg、.png。FEフォルダーには、最大 10 個のアイテム ファイルと 1 つのproduct.jsonファイルを含めることができます。Assetsフォルダー内の各資産は、アイテム ファイル内で参照する必要があります。Assetsフォルダーに存在しないアイテム ファイルから参照されるすべての資産は、アップロード エラーになります。- アイテムのファイル名は一意である必要があります。 ファイル名が重複すると、アップロード エラーが発生します。
- ファイル名には英数字 (英語) またはハイフンのみを含める必要があり、長さは 32 文字以下にする必要があります。 他の文字を使用するか、この長さを超えると、アップロード エラーが発生します。
- パッケージの合計サイズは 20 MB を超えてはなりません。
- マニフェスト固有の制限については、「ワークロード マニフェストの定義」を参照してください。
ローカル開発モード (devmode)
ワークロード バックエンド (BE) は、開発者のマシン上で動作します。 ワークロード API 呼び出しは Azure Relay 経由で送信され、Azure Relay チャンネルのワークロード側は、特殊なコマンドライン ユーティリティ DevGateway によって管理されます。 ワークロード制御 API 呼び出しは、Azure Relay チャンネルをバイパスして、ワークロードから Fabric に直接送信されます。 DevGateway ユーティリティは、特定の容量のコンテキスト内で、ワークロードのローカル開発インスタンスの Fabric への登録も監視します。 この結果、その容量に割り当てられているすべてのワークスペースでワークロードの可用性が確保されます。 DevGateway ユーティリティが終了すると、ワークロード インスタンスの登録が自動的に取り消されます。 詳細については、「バックエンド実装ガイド」を参照してください。
DevMode BE スキーマ
クラウド開発モード (クラウド モード)
ワークロード バックエンド (BE) は、パートナーのサービス内で動作します。 ワークロード API の呼び出しは、ワークロード マニフェストで規定されているように、HTTPS エンドポイントに対して直接行われます。 このシナリオでは、DevGateway ユーティリティは必要ありません。 Fabric でのワークロードの登録は、ワークロード NuGet パッケージを Fabric にアップロードし、その後テナントのワークロードをアクティブ化することで実現されます。 詳細については、「Fabric でワークロードを管理する」を参照してください。
CloudMode BE スキーマ
レイクハウス統合
マイクロソフトのアーキテクチャは、レイクハウスと完全に統合するように設計されており、データの保存、読み取り、フェッチなどの操作が可能です。 このやりとりは Azure Relay と Fabric SDKによって促進されており、認証された安全な通信が保証されています。
認証とセキュリティ
マイクロソフトでは、信頼性の高い安全な認証に Microsoft Entra ID (旧 Azure Active Directory) を使用しており、アーキテクチャ内のすべてのやりとりが承認済みで安全です。 上の図に示すように、ワークロード認証の完全な概要については、認証ドキュメントを参照してください。