アダプティブ アプリを使用してポータブル アプリケーションを構築する

移植性は、最新のアプリケーションの調達と運用の要件です。 Teams は、元に戻せるアプリケーションを設計し、ソブリン クラウド、オンプレミス インフラストラクチャ、断続的に接続されたエッジ環境など、さまざまなターゲットに移植できる必要があります。 次の条件が移植性の必要性を促進します。

• データ所在地と主権規則
• セクター固有のコンプライアンスの義務
• 断続的な接続環境
• ビジネス継続性の要件

Arc 対応 Kubernetes、 Radius、およびエッジ AI パターンは、移植性の要件を満たすことができるアーキテクチャ モデルの実用的な基盤を作成します。 このアーキテクチャ モデルは、 アダプティブ アプリ ソリューションです。

アダプティブ アプリは、アプリケーションの意図を環境固有の実装から分離します。 開発者はワークロードと必要な機能を 1 回記述します。プラットフォームオペレーターは、これらのポータブル リソースをローカル サービスレシピ、ポリシー、ID、ネットワーク、可観測性、および各環境に適したインフラストラクチャにバインドします。 この記事では、アダプティブ アプリ ソリューションについて説明し、機能ポートフォリオ、オープン プロトコル、Radius ベースのデプロイ ワークフローを使用して、アプリケーションをどこで実行しても一貫性があり、管理可能で運用可能な状態を維持する方法について説明します。

Architecture

Radius を使用してモデル化されたアプリケーションは、一連のリソースで構成されます。 これらのリソースは、アプリケーション コンポーネントと、アプリケーションをサポートするプラットフォーム レベルのリソースに分類できます。 これらのプラットフォーム レベルのリソースのコレクションは、 機能ポートフォリオと呼ばれます。

Radius リソースは、プラットフォーム レベルの機能に対する抽象インターフェイスを定義します。 Radius リソースをターゲット環境にデプロイすると、ターゲット固有のレシピでそのリソースの種類をプラットフォーム固有の具象実装にマップできます。 対応するレシピを使用して、機能ポートフォリオをさまざまなターゲット環境に投影します。

このアーキテクチャでは、特定のプラットフォームごとにアプリケーション コードを書き換える必要なく、必要な機能をアプリケーションに提供します。

このアーキテクチャのVisio ファイルをダウンロードしてください。

このアーキテクチャでは、2 つの補完的な抽象化レイヤーを使用して移植性を実現します。

• まず、Radius は、アプリケーション要件をプラットフォーム固有の実装から分離するアプリケーション モデルの抽象化を提供します。 抽象リソースの種類は、環境固有のレシピを使用してさまざまな実装にマップできるデータベース、キャッシュ、メッセージング システムなどのリソースを表します。 この方法では、デプロイ成果物を変更することなく、複数の環境に同じアプリケーション定義をデプロイできます。

• 2 つ目は、アプリケーションでプログラミング モデルの抽象化を採用できることです。 アプリケーションは、広く採用されている標準とプロトコル、またはオプションの サイドカーベースの抽象化レイヤー ( Dapr など) を介して依存関係と対話できます。 これらのアプローチにより、プラットフォーム固有のサービス API へのアプリケーションの結合が軽減され、環境全体の移植性が向上します。

これらの抽象化は、説得力のある "1 回書き込み、多くの環境で実行する" エクスペリエンスを提供しますが、トレードオフも導入します。 移植性を維持するために、アプリケーションでは、すべてのターゲット環境で使用できないプラットフォーム固有の機能と最適化の直接使用を制限する必要がある場合があります。 サイドカーまたは一般的なプログラミング抽象化を使用して移植性を実現する場合は、その抽象化レイヤーによって課される制約を受け入れる必要があります。

Teams は、サポートされている展開ターゲット全体でのアプリケーションの動作の検証にコミットする必要があり、テストと運用の複雑さが増します。 移植性は、デプロイの柔軟性、ロックインの削減、異種環境間の一貫性の向上のために、より深いプラットフォーム統合を犠牲にする意図的なアーキテクチャの選択として表示します。

Workflow

以下のワークフローは、前の図に対応しています。 このワークフローでは、フロントエンド、バックエンド、AI エージェント、メッセージ ブローカー、OpenID Connect (OIDC) ID プロバイダーなどの一般的なコンポーネントを含むサンプル アプリについて説明します。

1. アプリケーション開発者は、Radius アプリケーション定義を使用してワークロードを 1 回記述します。

   アプリケーション定義は、コンテナー化されたペイロード フロントエンドとバックエンドを記述する Applications.Core/containers リソースなどのリソースの一覧で構成されます。 アダプティブ アプリ パターンでは、アプリケーションを特定のプラットフォームから切り離す一般的なプラットフォーム機能を抽象化するいくつかのリソースの種類の拡張機能も定義されています。

   アダプティブ アプリでは、新しいデータ プレーンの抽象化を定義する代わりに、広く採用されているオープン ソース コンポーネントと、認証用の OIDC やメッセージング用のメッセージ キュー テレメトリ トランスポート (MQTT) などのオープン プロトコルが使用されます。 この方法では、アプリケーションが抽象インターフェイスによって制約されるのを防ぎ、対応するプロトコルの完全な機能を直接使用できます。

   リソースの種類	Purpose
   Radius.Resources/agentGuardrails	エージェント固有のガバナンス ポリシー
   Radius.Resources/aiModels	AI 推論をサポートする AI モデル
   Radius.Resources/governance	エンタープライズ ガバナンス ポリシー
   Radius.Resources/mqttBrokers	MQTT に基づくメッセージ ブローカー
   Radius.Resources/workloadIdentities	アプリケーション内のワークロードまたはエージェントを識別するために使用されるワークロード ID

2. 開発者は、ポータブル API を使用してアプリケーション コードを作成または更新できます。

   プログラミング モデル レベルでは、アプリケーションは Dapr などのサイドカー テクノロジをさらに採用できます。これにより、pub/sub、状態管理、シークレットなどの一般的なタスクにプラットフォームに依存しない API が提供されます。 Radius には、Dapr サイドカーのネイティブ サポートがあります。

   Azure SDKを既に使用している Brownfield サービスは、必要なAzure エンドポイント、ID フロー、ネットワーク接続が使用可能な場合、ターゲットで引き続き動作できます。 共通プロトコルを使用するサービスは、互換性のある実装が提供されている場合でも引き続き機能します。 より広範な移植性を実現するために、新しいサービスでは Dapr API を採用して、アプリケーションがより多くのプラットフォームのバリエーションに適応できるようにすることができます。

3. プラットフォーム オペレーターは、各ターゲットの機能ポートフォリオをブートストラップします。

   オペレーターは、環境のフットプリントとコンプライアンスのニーズに基づいて、 min、 core、 ent、 min-ai、 core-ai、または ent-aiの 6 つの定義済みポートフォリオのいずれかを選択します。 オペレーターは Helm チャートを使用してポートフォリオをインストールします。 次の表は、定義済みのポートフォリオがさまざまなプロトコルをサポートしているかどうかを示しています。

   ポートフォリオ	アイデンティティ (OIDC)	サービスメッシュ (Istio)	可観測性 (OTel)	ガバナンス (OPA)	クラスター上の AI (Kaito)	エージェントのガードレール
   min	✓	✗	✗	✗	✗	✗
   core	✓	✓	✓	✗	✗	✗
   ent	✓	✓	✓	✓	✗	✗
   min-ai	✓	✗	✗	✗	✓	✗
   core-ai	✓	✓	✓	✗	✓	✓
   ent-ai	✓	✓	✓	✓	✓	✓

   アダプティブ アプリには、Helm のインストール以外のインフラストラクチャ構成手順を容易にし、アプリケーションのデプロイでインフラストラクチャ情報を使用できるようにするコマンド ライン ツールも用意されています。

4. Radius は、アプリケーションを環境固有のレシピにバインドします。

   ターゲット ワークスペース rad deploy 実行すると、環境に登録されたレシピによって、アダプティブ アプリ内の各ポータブル リソースがプロビジョニングされます。 たとえば、 Radius.Resources/aiModels は、アプリがローカル Kubernetes 環境にデプロイされるときに 、Kaito によって管理されるローカルの小さな言語モデル (SLM) に解決されます。 クラウド環境にデプロイすると、同じリソースが OpenAI または Azure OpenAI エンドポイントに解決されます。 Radius は、アプリケーション定義が明示的に宣言する依存関係の接続情報を挿入します。

   

   アダプティブ アプリの例の機能が各ターゲット環境にどのように取り込まれるかを示す図。 左側のボックスには、コンピューティング、ID プロバイダー、ワークロード ID、メッセージング、AI モデル、ポリシー、監視機能を含む Radius アダプティブ アプリが表示されます。 矢印は、各機能からデプロイ ターゲット (Azure、Azure Arc、またはその他のクラウドやカスタム環境) に至ります。 各ターゲットには、その環境でその機能を実装するターゲット固有のサービスと拡張機能が含まれています。

   この図の Visio ファイル をダウンロードします。

Components

• Radius は、ワークロードを移植可能なリソースの種類のグラフとして表し、デプロイ時に各種類を環境固有のレシピに解決するオープンソース アプリケーション モデルです。 このアーキテクチャでは、Radius はアプリケーション チームとプラットフォーム オペレーター間の主要なコントラクトです。 アダプティブ アプリでは、Radius ツールを使用して、ターゲット環境にアプリケーションをデプロイすることもできます。

• 機能ポートフォリオは、 アプリケーションとそのホスティング プラットフォーム間のコントラクトです。 このアーキテクチャには、ベースライン エッジ フットプリントから、ポリシー適用とクラスター上の AI を使用した完全なエンタープライズ セットアップまで、機能レベル用の定義済みのポートフォリオが 6 つ用意されています。 プラットフォーム オペレーターは、Helm チャートとして機能ポートフォリオをインストールします。

• AI を利用したツール は、インフラストラクチャの構成と、ブラウンフィールド アプリケーションの AI 支援による移行のための CLI を提供します。 このアーキテクチャでは、ツールはマイクロサービス アプリケーション、レガシ アプリケーション、メインフレーム アプリケーションなどのブラウンフィールド アプリケーションを Radius アプリケーション モデルに移行するのに役立ちます。

シナリオの詳細

ワークロード チームは、次の環境を含めることができる異種資産全体で同じアプリケーションを実行する必要がある場合があります。

• エラスティック ワークロード用のパブリック クラウド リージョン
• データ所在地の義務を満たす主権リージョン
• 待ち時間の影響を受けやすい処理用のオンプレミス データセンター
• 断続的な接続を備えたリモート エッジ クラスターの群

各環境には、通常、独自の ID プロバイダー、サービス メッシュ オーバーレイ、監視スタック、ポリシー エンジン、AI 戦略があります。 統合契約がなければ、アプリケーション チームは、ターゲットごとにコードベースをフォークするか、単一のプラットフォームにロックするか、新しい環境を追加するたびにリファクタリング コストが発生する必要があります。

アダプティブ アプリでは、環境の変動を吸収する役割を担うアプリケーションではなく、プラットフォームを作成することで、この問題に対処します。 アプリケーションは、Radius アプリケーション モデルと、必要に応じて Dapr プログラミング モデルに対して 1 回作成されます。 各ターゲット環境には、アプリケーションに必要な機能を公開する機能ポートフォリオがインストールされます。 レシピレイヤーは、デプロイ時にポータブル リソースを環境固有の実装にバインドします。

このアーキテクチャは、コントロール プレーンに関して意図的に規範的なものではありません。 機能ベンダーは、Helm、Arc 拡張機能、Bicep、Terraform、またはカスタム インストーラーを通じてポートフォリオを提供できます。 結果として得られる環境がポートフォリオの機能契約を満たしている限り、アプリケーションは移植可能なままになります。

考えられるユース ケース

• 主権および規制対応のクラウド導入

  規制対象のワークロードは、パブリック クラウド バージョンとコードベースを共有しながら、ソブリン クラウドまたは顧客が管理するインフラストラクチャで実行する必要があります。 core-aiまたはent-aiポートフォリオは、デプロイ ターゲット間で一貫した機能コントラクトを提供し、アプリケーションの移植性を実現します。 ターゲット環境では、主権と規制の要件を満たすために、データ所在地、暗号化、アクセス制御、監査、コンプライアンス認定など、特定の機能と制御の実装が強制されます。

• 再プラットフォーム化を伴わないブラウンフィールドの最新化

  ワークロード チームは、Radius リソース定義を導入してインフラストラクチャの依存関係を記述し、Dapr 機能を選択的に採用することで、レガシ マイクロサービス アプリケーションを段階的に最新化します。 AI を利用したリファクタリング ツールは、移行の一部を加速するのに役立ちます。 このアプローチにより、チームはアプリケーションを最新化して、ビジネス要件と技術要件に合ったペースで移植性、可観測性、運用の一貫性を向上させることができます。

• エッジでのハイブリッド AI 推論

  小売ワークロードまたは産業用ワークロードは、Azure OpenAI を呼び出して本社のAzureで同じaiModel サービスを実行し、Kaito ホスト型のオープン ソース モデルを呼び出して店舗または工場内のAzure Local クラスターで実行します。 アプリケーション コードは同じであり、 aiModel レシピのみが異なります。

• 断続的に接続されたエッジ

  防御、海事、またはリモート サイトのデプロイでは、クラウドでホストされる ID または AI サービスに依存しない単一のリソース制約クラスターで、 min-ai ポートフォリオが実行されます。 同じワークロードが、 core-ai ポートフォリオを使用して AKS に再デプロイされると、メッシュと可観測性が自動的に向上します。 ent-ai ポートフォリオには、ガバナンス ポリシーの適用も追加されます。

• マルチクラウドデプロイ

  ワークロード チームは、各ターゲットが同じ機能コントラクトを実装している限り、 rad deployを使用して、モデル化されたアプリケーション リソースを別のワークスペースにデプロイします。 ワークロードのバーストとディザスター リカバリーは個別の懸念事項として扱われます。 使用可能なセカンダリ環境には、容量、成果物とデータの可用性、依存関係のシーケンス処理、ID、ネットワーク接続、トラフィック ルーティング、正常性チェック、テスト済みのフェールオーバー/フェールバック手順も必要です。

貢献者達

Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。

主な執筆者:

• 波石白 |プリンシパル ソフトウェア アーキテクト
• ボリス・ショール |VP エンジニアリング
• Will Tsai |プリンシパル プロダクト マネージャー

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

• GitHubの Adaptive Apps リポジトリを調べる