AI プラットフォームは、組織が AI モデルを実行して運用する場所です。 これは、モデル、デプロイ、インデックス、評価、および関連資産を囲むネットワーク境界、ID モデル、データ プレーン、クォータ割り当てを提供します。 Microsoft Foundry と Azure Machine Learning は、2 つのAzure AI プラットフォームです。 どちらのサービスのデプロイでも、新しいインスタンスが作成されます。
組織は、AI プラットフォーム インスタンス間で AI ワークロード環境を配置する方法を決定する必要があります。 開発、テスト、prod などの各環境は、独自のプラットフォーム インスタンスで分離できます。 複数のワークロードまたは環境で同じインスタンスを共有することもできます。 この決定は、多くの場合、コロケーションと呼ばれ、運用上またはセキュリティ上の問題の爆発半径に影響します。 また、コンプライアンスの境界とプラットフォーム のコストにも影響します。
推薦： 既定の分離要件、承認された共有境界、例外条件、運用環境と運用前の AI プラットフォーム環境に対する個別の期待を定義する組織全体のポリシーを確立します。
決定ガイダンス:
1. AI プラットフォーム共有の境界を定義する
すべての組織には、ワークロードが AI プラットフォーム インスタンスを共有してはならない境界が必要です。 この境界は、運用環境や実稼働前環境を含むすべての環境に適用されます。 同じ境界内のワークロードは、プラットフォーム インスタンスを共有する可能性があります。 異なる境界内のワークロードでは実行できません。
共有境界を描画する理由 境界を共有しないと、ワークロード チームは、現時点で便利なパターンに既定で設定され、AI プラットフォームは時間の経過と同時に競合する要件を蓄積します。 時間の経過とともに、所有権モデルの不整合、コンプライアンス要件の競合、コストの割り当てが不明確になり、関連のないワークロード間で運用上のリスクが共有されます。 たとえば、関連のないビジネス領域は、コストを削減するために、同じプラットフォーム インスタンス上でクォータを共有する場合があります。 その結果、理解と監査が困難になるガバナンス境界に一貫性のない AI プラットフォームが得られます。
共通の境界。 組織が既に責任を割り当て、テクノロジの決定を管理する方法に合わせた境界モデルを選択します。 一般的なモデルは次のとおりです。
ビジネス ユニットの境界は、一般的な運用所有権と資金調達のために最適化されます
データ ドメイン境界は、一般的なコンプライアンスとデータ処理の要件に合わせて最適化されます
製品所有者の境界は、一般的なエンジニアリング ライフサイクルとプラットフォーム運用に合わせて最適化されます
分離が理にかなっている場合でも、チームは境界内で専用のプラットフォーム インスタンスを選択できます。 境界外では、共有は許可されません。
最適な機能を見つけます。 一般的に正しいモデルはありません。 明確に適用された境界モデルは AI プラットフォームの成長に合わせてガバナンスを理解し続けるので、一貫性はどのモデルを選択するかよりも重要です。
2. 運用 AI プラットフォーム共有ポリシーを定義する
運用環境での AI プラットフォーム共有は、同じ Microsoft Foundry リソースまたは Azure Machine Learning ワークスペースで複数の運用 AI ワークロード環境を実行する方法です。 Azureでは、AI プラットフォーム インスタンスは、それを使用するワークロード環境のネットワーク境界、ID 境界、クォータ境界を定義します。 そのため、組織は運用 AI プラットフォーム共有用の特定のポリシーを定義する必要があります。
2.1 運用環境のワークロードあたり 1 つの AI プラットフォーム インスタンスに対する既定値
運用環境の AI 環境は、既定で運用環境の分離に設定する必要があります。 文書化された例外が存在しない限り、同じ Microsoft Foundry リソースまたは Azure Machine Learning ワークスペースに複数の運用ワークロードを併置しないでください。 運用環境のワークロード環境ごとに専用の AI プラットフォーム インスタンスを標準アプローチにする必要があります。 既定の手法ではなく、AI プラットフォーム共有を例外として扱います。
なぜデフォルトで分離するのか？ また、共有 AI プラットフォームでは、共有運用上のリスクも発生します。 セキュリティの問題、構成の誤り、サービスの停止、またはクォータ不足イベントは、すべての併置されたワークロード環境に影響を与える可能性があります。 分離により、ワークロード間のアクセスが偶発的に公開されるリスクも軽減され、あるワークロードが別のワークロードで必要な GPU 容量またはクォータを消費するのを防ぐことができます。 運用環境では、通常、ビジネスへの影響と規制の露出が最も高くなります。 ほとんどの組織では、これらの環境に対して明確な所有権の境界と強力な運用上の分離が必要です。
トレードオフ： 分離により、コストと管理のオーバーヘッドが増加します。 各プラットフォーム インスタンスには、ネットワーク、ID、監視、および操作に対する独自の運用オーバーヘッドが伴います。 組織は、これらのコストと、より強力な封じ込めによる運用上およびセキュリティ上の利点とのバランスを取る必要があります。
2.2 文書化された例外による生産コロケーションの許可
コロケーションにより、オーバーヘッドが削減され、プラットフォームの運用が統合されます。 たとえば、ユース ケースが入力と同じデータ ソースを共有する場合、コロケーションにより、ユース ケースごとに AI プラットフォームからそれらのリソースへの接続と認証を設定する必要がなくなります。 トレードオフ: 運用環境で AI プラットフォーム インスタンスを共有すると、インスタンスを共有するすべてのワークロードの爆発半径、ID 境界、クォータ プールもマージされます。
コロケーションのCharacteristics:次の各条件が満たされている場合にのみ、実稼働ワークロードが Microsoft Foundry または Azure Machine Learning のインスタンスを共有することを許可します。
併置されたすべてのワークロードは、同じ規制スコープ、データ分類、所在地要件、およびデータ処理標準を共有します。
すべてのワークロードは、同じネットワーク境界、同じ DNS 名前空間、および同じ ID 境界内で動作します。
組織は、共有停止リスクと、コロケーションによって発生する共有クォータ枯渇リスクを受け入れます。
個別のインスタンスのコストまたは運用上のオーバーヘッドは、分離の利点を大幅に上回ります。 コスト圧力だけでは十分な正当な理由ではありません。
チームは、ワークロードを後で分割するとコストがかかることを受け入れます。 AI プラットフォームの状態はインスタンス間で正常に転送されないため、多くの場合、再作成や再構成が必要です。
トレードオフ： すべての共有 AI プラットフォーム インスタンスには、クォータ管理、ネットワーク構成、アクセス レビュー、ライフサイクル操作、インシデント調整を担当する明確に識別されたプラットフォーム所有者が必要です。
2.3 AI プラットフォーム インスタンス内で運用環境のユース ケースをセグメント化する
プラットフォーム インスタンスが分離されているか併置されているかに関係なく、製品内セグメント化機能を使用してユース ケースを分離します。 1 つのワークロード内で完全に異なるユーザー エクスペリエンスなど、個々のユース ケースを、プラットフォーム インスタンス内の独自の論理デプロイとして扱います。 例えば次が挙げられます。
Microsoft Foundry で、Foundry リソース内のユース ケースごとに 1 つの project をプロビジョニングします。
Azure Machine Learningでは、プロジェクト ワークスペースと共に hub ワークスペース を使用してユース ケースをセグメント化します。
これらのコンストラクトは、各ユース ケースに独自の資産とロールの割り当てを提供します。 セキュリティと接続のためのインフラストラクチャ コンポーネントの共通セットを共有します。 すべてのシナリオに新しいインスタンスをプロビジョニングする必要はありません。
例外プロセスでコロケーションが許可されている場合は、この製品内の分離を推奨事項から適用されたポリシー要件に昇格させます。
ワークロードで複数の Foundry プロジェクトまたはAzure Machine Learning ワークスペース間で複雑なセグメント化が必要な場合は、現在の共有モデルが引き続き許容可能な操作のシンプルさと分離を提供するかどうかを再評価します。
これらの決定を固定するコンストラクトの背景については、Microsoft Foundry リソースおよび Azure Machine Learning ワークスペースを参照してください。
3. 実稼働前の AI プラットフォーム共有ポリシーを定義する
実稼働前環境では、運用環境の既定値が反転されます。 実稼働前環境には、開発、テスト、ステージが含まれます。 これらの環境では、実験とプレリリースの検証がサポートされています。 AI プラットフォーム リソースの専用インスタンスでは、これらのレベルのコストが正当化されることはほとんどありません。 既定では、環境レベルごとの共有インスタンスです。
実稼働前環境に併置する理由 共有運用前 AI プラットフォーム インスタンスを使用すると、チームは新しいユース ケースごとに個別のインスタンスをプロビジョニングする代わりに、Azure AI インフラストラクチャを再利用できます。 ワークロード チームは、デプロイされたモデル、承認されたネットワーク接続、既存のデータ統合、確立されたセキュリティ構成を再利用できます。 この方法では、実験を高速化し、セットアップ作業の繰り返しを減らします。 ビジネス チームが新しい AI シナリオの実現可能性を評価したり、初期段階のソリューションを検証したりする場合に最も価値があります。
実稼働前に併置しない場合。 ワークロードがテストで規制対象データを処理する場合、またはパフォーマンス検証のために運用トポロジをミラーリングする必要がある場合は、ワークロードごとに専用の実稼働前インスタンスを使用します。 その要件を例外として扱い、プロビジョニングする前に明示的な承認を必要とします。
トレードオフ： 実稼働前コロケーションにより、アイドル容量のコストが削減され、プラットフォームのインベントリが小さくなります。 ただし、すべてのワークロードが別のチームの実験からの干渉にさらされます。 正しく構成されていない微調整ジョブまたはランナウェイ評価実行では、共有クォータが消費され、他のチームの速度が低下する可能性があります。 共有インスタンスでキャプチャされたテスト結果も、運用環境の動作を常に予測するとは限りません。 厳密なパフォーマンスまたはコンプライアンス検証のニーズがあるワークロードでは、コストが高いにもかかわらず専用の環境が必要です。