この記事では、高リスク レベルに分類される一般的な情報セキュリティ リスク管理 (ISRM) コントロールの分析と実装に関連する Azure アーキテクチャの考慮事項について説明します。
Architecture
アーキテクチャはこの図に示されており、エンタープライズ規模のランディング ゾーンの原則、具体的にはエンタープライズ規模の分析と AI 参照アーキテクチャに従います。
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
アーキテクチャは、以下のセクションで説明するワークフローで構成されています。 アーキテクチャの各コンポーネントには、図に対応する番号があります。 ここでは、コンポーネントの主な目的、コンポーネントがアーキテクチャにどのように適合するか、およびコンポーネントを採用する際に考慮すべきその他の重要な考慮事項について説明します。
- プラットフォーム サブスクリプション – Microsoft Entra ID を介して、管理、接続、ID を提供するコア Azure サブスクリプション。 ここでは詳しく説明していませんが、コア エンタープライズ規模のセットアップの一環として準備ができていると想定されています。
データ管理
- データ管理ゾーン – データ管理ゾーンは、プラットフォーム全体のデータ ガバナンスを担い、ガードレールを適用してデータ ランディング ゾーンで柔軟性の高いダウンストリームを提供します。 独自のサブスクリプションがあり、データのカタログ化、監視、監査などの集中型サービスをホストします。 この環境は高度に管理されており、厳格な監査の対象となります。 すべてのデータ分類タイプは、中央の Data Catalog (Azure Purview) に保存されます。 メタデータに応じて、さまざまなポリシーとアクセス パターンが適用されます。 テナント全体に対してデータ管理ゾーンのサブスクリプションは 1 つだけです。 データ管理ゾーンは、他のすべてのデータ ランディング ゾーンと (VNET ピアリングを介して) ピアリングされます。 プライベート エンドポイントは、展開されたサービスがパブリックインターネット経由でアクセスできないようにするために、可能な限り使用されます。
- ネットワーク リソース グループ – Azure Virtual Networks、ネットワーク セキュリティ グループ、およびデータ管理ゾーンに必要なその他すべてのネットワーク関連リソースは、ネットワーク リソース グループ内でプロビジョニングされます。
- デプロイ リソース グループ – デプロイ リソース グループは、データ管理ゾーンに必要なプライベート Azure DevOps CI/CD エージェント (仮想マシン) と、デプロイ関連のシークレットを保存するためのキー コンテナーをホストします。
- データ ガバナンス リソース グループ – Azure Purview は、データ ガバナンスおよびデータ カタログ ソリューションとして使用され、法律またはその他の団体によって課されるデータ要件およびデータ規制に従うためにデータセットに必要なガードレールを適用するために使用されます。 Purview は、シークレットを保存するための Key Vault インスタンスとともに、このリソース グループ内で一元的にホストされます。
- 一元化された資産 – 一元化された資産は、プラットフォームの中心となる重要で価値のある資産をホストします。次に例を示します。
- Azure Machine Learning ベースのデータ製品で使用される基本イメージ (以前にスキャンされ、脆弱性のないイメージ) をホストする Azure コンテナー レジストリ
- プラットフォーム上で公開され、コンシューマーが使用できるようになっている AI/Machine Learning モデル (必要に応じて 1 つ以上のデータ ランディング ゾーンにデプロイできます)。
- その他のサービス – 集中管理を行う必要のあるその他のサービスは、これらのリソース グループのいずれかでホストできます。これには、一元化された Azure API Management インスタンス、サードパーティ製ソフトウェアなどが含まれます。
- データ視覚化リソース グループ – このリソース グループは、データのランディング ゾーン間で共有されるデータ視覚化ソリューションをホストします。 ソリューションには、Power BI、Tableau、またはその他の視覚化ソリューションがあります。
- 追加のインフラストラクチャ制御とガバナンス – Microsoft Defender for Cloud および Azure Monitor は、ベースラインのセキュリティおよび監視ソリューションとして使用されます。
データのランディング ゾーン
データ ランディング ゾーン 001 – データ ランディング ゾーンは、データ プラットフォーム内のスケールの単位を表すサブスクリプションです。 データ ランディング ゾーンは、分析および AI のプラットフォームをホストするすべての主要な機能を含む、コア データ ランディング ゾーン アーキテクチャ (ブループリント) に基づいてデプロイされます。 環境内には、1 つまたは複数のデータ ランディング ゾーンを設定できます。 Azure Policy は、さまざまな Azure サービスのアクセスと構成をセキュリティで保護するために適用されます。 データ ランディング ゾーンは、他のすべてのデータ ランディング ゾーンおよびデータ管理ゾーンと (VNET ピアリングを介して) ピアリングされます。 プライベート エンドポイントは、展開されたサービスがパブリックインターネット経由でアクセスできないようにするために、可能な限り使用されます。
ネットワーク リソース グループ – Azure Virtual Networks、ネットワーク セキュリティ グループ、およびデータ ランディング ゾーンに必要なその他すべてのネットワーク関連リソースは、このリソース グループ内でプロビジョニングされます。
デプロイ リソース グループ – デプロイ リソース グループは、データ ランディング ゾーンに必要なプライベート Azure DevOps CI/CD エージェント (仮想マシン) と、デプロイ関連のシークレットを保存するためのキー コンテナーをホストします。
データ ストレージ リソース グループ – データ ストレージ リソース グループには、階層型名前空間を持つ Azure Data Lake Storage Gen2 としてデプロイされた、このデータ ランディング ゾーンのメイン データ ストレージ アカウントが含まれています。 これらは 3 つの主要な領域に分かれています。
- Raw – データが元の状態でデータ ソースから取り込まれます
- Curated and Enriched – データがクレンジング、検証、集約されます
- Workspace – 特定のデータ製品のデータセットや Machine Learning モデルの出力などを保存できます
図の矢印は、生データからキュレートとエンリッチされた (信頼できる) データ、さらにはデータ製品からの探索、分析、および付加価値を提供するためのワークスペースに至るまでに予想されるデータ フローを示しています。
データ統合リソース グループ – データ統合リソース グループは、オンプレミスのセルフホステッド統合ランタイム (SHIR) との接続を共有する Azure データ ファクトリをホストします。 その主な目的は、接続を確立することです。 他の Data Factory インスタンスでは、接続が 1 か所でのみ維持されるように再利用されます。 もう 1 つの目的は、Azure Purview サービスのセルフホステッド統合ランタイムをホストして、このデータ ランディング ゾーンのデータ ソースにスキャンの目的でアクセスできるようにすることです。
メタデータ管理リソース グループ – メタデータ管理リソース グループは、Azure Databricks (Hive メタ ストア) とAzure Data Factory の取り込みと処理のパイプラインのメタデータをホストします。 また、このデータにアクセスするためのシークレットを格納するキー コンテナーもホストします。 Azure SQL Database は、メタデータをホストするために使用されます。
データ インジェスト リソース グループ – データ インジェスト リソース グループは、データ ドメインに固有のデータ インジェスト パイプラインのすべてがデプロイされている Azure Data Factory インスタンスをホストします。 Azure Databricks は、データを読み込んで変換し、データ レイク アカウントに保存する処理エンジンとして使用されます。
Analytics リソース グループ – Analytics リソース グループには、詳細なデータ分析と探索ができる 2 つの共有サービス、Azure Synapse と Azure Databricks が含まれています。 これらのサービスはどちらも、大規模なデータ探索と分析の目的とした広範なコンピューティングとスケールを提供します。
データ製品リソース グループ – データ製品リソース グループはデータ製品のブループリントで、データ製品に必要となる基本的な Azure リソースを含むリソース グループが含まれます。 デプロイは、ビジネスの特定のニーズに基づいて、Azure DevOps パイプラインで構成する必要があります。 ここでデプロイされているコア Azure サービスは次のとおりです。
- Key Vault (シークレット保存用) などの関連サービスを備えたエンタープライズ機械学習プロジェクトの基盤としての Azure Machine Learning ワークスペース
- Application Insights (モデル監視用)
- Azure storage (データセット保存用)
- 開発中にモデル イメージを保存するための Azure Container Registry
Cognitive Services は、複数の AI を使用したサービスへの API アクセスを提供するバンドルとしてデプロイされ、Azure Machine Learning コンピューティング インスタンスとコンピューティング クラスターは、開発、モデルの構築、およびテストの目的で使用されます。 Azure Data Factory は、モデルのバッチ スコアリングを調整するために必要に応じて使用されます。 Azure App Service と Azure Cosmos DB は、データ製品をデプロイするための追加のレイヤーを提供します。このレイヤーでは、カスタム アプリケーションまたは API を独自の内部データ ストアでホストできます。
規制対象の業界では通常、データ アクセスに厳しい制限があり、運用データをホストできるのは運用環境内のみです。 このため、データ製品の開発ライフサイクルは運用データのランディング ゾーンでのみ発生し、開発、テスト、デプロイ用には、別の環境またはリソース グループがプロビジョニングされます。
追加のデータ製品 – 1 つのデータ ランディング ゾーンが 1 つまたは複数のデータ製品をホストできるため、これらのリソース グループは他のデータ製品をホストします。
共有コンピューティング リソース グループ – データ製品のホスティングとデプロイに必要な共有コンピューティングは、このリソース グループ内でプロビジョニングされます。 Azure Kubernetes Service クラスターがその一例です。
追加のインフラストラクチャ制御とガバナンス – Microsoft Defender for Cloud および Azure Monitor は、ベースラインのセキュリティおよび監視ソリューションとして使用されます。
追加のデータ ランディング ゾーン 002 – このランディング ゾーンは、新しいデータのランディング ゾーンをホストするために使用される追加の Azure サブスクリプションのプレースホルダーです。 これらは前述の基準に基づいており、データ所在地要件や、独自の機能横断型チームと一連のユース ケース持つ別の事業単位を使用します。
コンポーネント
- Microsoft Entra ID
- Azure Purview
- Azure Virtual Network
- Azure DevOps
- Azure Container Registry
- Azure Machine Learning
- Microsoft Defender for Cloud
- Azure Monitor
- Azure Policy
- Azure Data Lake Storage
- Azure Data Factory
- Azure SQL Database
- Azure Databricks
- Azure Synapse Analytics
- Azure Kubernetes Service
代替
分散型組織の場合、ビジネス グループは独立しており、高度な自律性を持って運営されます。 そのため、Azure ランディング ゾーンのユース ケースを完全に分離し、最小限の共通サービス セットを共有する代替ソリューション設計を検討する場合があります。 この設計では迅速な開始が可能ですが、個々のユース ケースの設計がブループリントの設計からすぐに逸脱する可能性があるため、IT 部門や ISRM 組織の多大な労力が必要になります。 さらに、Azure でホストされている AI および Machine Learning 製品ごとに、独立した ISRM プロセスと監査が必要です。
シナリオの詳細
規制された環境で AI と機械学習のイニシアチブをスケーリングすると、デジタル成熟度やサイズに関係なく、組織に大きな課題が生じます。 この記事では、規制された業界で Azure の Data Engineering と機械学習サービスを採用する際に考慮すべき重要なアーキテクチャ上の決定について説明します。 これらの決定は、Fortune 500 グローバル ライフ サイエンスおよびヘルスケア企業における最新の実装から学んだ内容に基づいています。
ここの記事で紹介するアーキテクチャは、エンタープライズ規模の分析と AI 参照アーキテクチャの設計に従っており、最初の実装の 1 つでした。
ライフ サイエンスおよびヘルスケア環境でデータ サイエンス プロジェクトを設定して機械学習モデルを開発する場合は、ほとんどすべての場合、ビジネスに大きな影響を与える (HBI) データ ソースにアクセスする必要があります。 このようなソースとしては、たとえば、患者データを除く臨床試験プロトコル情報、分子化学式、または製造プロセスの秘密などがあります。
規制を受けている業界における IT システムは、それらのシステムがアクセスするデータ ソースの分類に基づいて分類されています。 Azure で実行される AI および機械学習環境は、HBI として分類され、一連の ISRM ポリシーと制御に準拠する必要があります。
設計原則
このアーキテクチャは、次の原則に基づいています。
- エンタープライズ規模はアーキテクチャに関するアプローチであり、Azure ロードマップと Microsoft クラウド導入フレームワーク (CAF) の一部に沿った参照実装です。 これにより、Azure でのランディング ゾーンの効果的な構築と運用化を大規模に実現します。 "ランディング ゾーン" という名前は、新しい、または移行されたアプリケーションが Azure に配置される境界として使用されます。 このシナリオでは、データと AI および Machine Learning モデルをホストするために使用されるデータ プラットフォームの一部も表します。
- 従来のモノリシックなデータ プラットフォーム アーキテクチャには、機能と価値の提供を遅らせる固有の制限があります。 ここで説明するアーキテクチャにより、組織はデータ資産をスケーリングし、所有権の分離 (データ メッシュ) を使用した分散型アプローチを使用して、集中型モノリシック データ レイクの課題に対処できます。 このアプローチを使用すると、組織はコア データ プラットフォームとデータ管理サービス (データ管理ゾーンと呼ばれる別のランディング ゾーンにデプロイ) をデータ ドメインとデータ製品 (1 つまたは複数のデータ ランディング ゾーンにデプロイ) から切り離すことで、データ プラットフォームの安全性と保守性を高めながら、何千もの取り込みパイプラインとデータ製品にスケーリングできます。
- サブスクリプションは、ビジネス ニーズと優先順位に合わせた管理とスケールのユニットとして使用されます。 スケーリングは、ビジネス上の利害関係者、さまざまなビジネス目標と要件、およびデータ所在地要件 (データを特定地域の場所でホストする必要がある場合) などの基準に基づいて、事業単位に新しいサブスクリプション (データ ランディング ゾーン) を提供することで実現されます。
- Azure Policy を使用してガードレールを提供し、会社の IT 環境内で継続的なコンプライアンスを確保します。
- Azure portal を介した単一のコントロールと管理プレーンでは、ロールベースのアクセス制御とポリシー駆動型のコントロールの対象となるすべての Azure リソースとプロビジョニング チャネルで一貫したエクスペリエンスを提供します。 Azure ネイティブのプラットフォーム サービスと機能は、可能な場合は常に使用されます。
- 機能横断型のチームは、設計、開発、運用の所有権を取得して市場投入までの時間を短縮し、プラットフォーム内の機敏性を高めます。 DevOps、コードとしてのインフラストラクチャ (IaC)、回復性がある設計などの核となる原則を使用して、人的エラーや単一障害点を回避します。
- データ ドメインは、ドメインおよびデータ ソース領域の専門家が、Azure、サードパーティ、またはオンプレミスの環境からデータ資産をプルするために使用できます。 データ ドメインは、データ ランディング ゾーン内のリソース グループで、機能横断型チームがカスタム データ インジェストに使用できます。 データ ランディング ゾーン内には、1 つまたは複数のデータ ドメインを含めることができます。 データ ドメインは、ドメイン駆動設計のドメインと同様に表示できます。つまり、コンテキスト境界を提供し、自己充足的であり、分離されています。 データ ドメインの例としては、臨床試験データやサプライ チェーン データなどがあります。
考えられるユース ケース
この記事で説明するアーキテクチャ上の考慮事項は、ライフ サイエンスおよびヘルスケア業界のソースが含まれています。 ただし、他の規制対象業界の組織にも関係しています。たとえば次のような業界です。
- 金融サービス
- 医療機関
- 石油、ガス
規制された環境でのエンタープライズ規模の分析と AI 参照アーキテクチャの実装は、同様の設計パターンに従います。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
このセクションでは、先ほど説明したライフ サイエンスとヘルスケアの規制された環境におけるアーキテクチャの実装から学んだ教訓について説明します。 また、一般的な ISRM のコントロールとポリシーを満たすための高度な設計に関する考慮事項についても説明します。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
環境
規制を受けている環境の場合、HBI として分類された IT システムは、開発、品質、運用または同様のものなど、分離された環境を複数持つ必要があります。 保護されたデータ ソースへのアクセスは、運用が認定された環境でのみ許可されます。
AI と機械学習の開発には機密データ セットへのアクセスが必要になるため、モデルの構築、トレーニング、推論 (または同様のもの) など、機械学習の運用プロセスのさまざまな段階がすべて運用環境で行われます。 開発環境と品質環境は通常、インフラストラクチャ、運用、Data Engineering という種類の作業に限定され、新しい Azure サービスと機能が利用可能になった時点で継続的な機能強化が実現されます。
AI とデータ サイエンスの開発活動は、サンドボックスや初期の探索作業を除き、運用環境で行われる必要があります。
暗号化
機密性の高いビジネス データにアクセスして保存および処理を行う IT システムは、カスタマー マネージド キー (CMK) 統合を使用して、暗号化キー管理に関する特定の要件 (FIPS 140-2 レベル 2 またはレベル 3 のポリシーなど) を実装する必要があります。 保護されたデータは、TLS 1.2 以上のプロトコルを使用して、保存時および転送中に常に暗号化する必要があります。
アーキテクチャの設計時には、Azure サービスのサポートと組織のCMK インフラストラクチャへの統合を慎重に分析する必要があります。 データ暗号化に関する例外については、文書化する必要があります。 ハードウェア セキュリティ モジュール (HSM) ベンダーのサポートは常に拡張されており、追加情報は Azure Key Vault マネージド ハードウェア セキュリティ モジュールで確認できます。
ネットワークの設計とリング フェンシング
AI と機械学習の環境では、ネットワークのセグメント化とネットワーク アクセスの制御が実装されたリング フェンシングが設定されている必要があります。 アーキテクチャ コンポーネント間のネットワーク通信は、許可リストのアプローチで機能するために必要なデータ フローと基盤となるインフラストラクチャに限定されます。 シグニチャベースの分析と動作ベースの分析を適用する必要があります。
Azure ファイアウォール、受信および送信ネットワーク接続の検査、ネットワーク セキュリティ グループ、Web アプリケーション ファイアウォール (WAF) で保護された Web アプリケーション エンドポイントへのアクセスなど、アーキテクチャの複数のレイヤーにネットワーク アクセス制御を適用します。
承認管理
Azure で実行される AI および機械学習環境は、組織の主要なアカウント プロビジョニング システムと統合する必要があります。このシステムでは、重要なビジネス アプリケーションへのアクセスを許可する要求が送信、承認、および監査されます。
アカウント プロビジョニング システムは、組織の Active Directory および Microsoft Entra ID に接続することが想定されているため、ビジネス認可ロールは、対応する Active Directory および Microsoft Entra セキュリティ グループにマップされます。
AI と機械学習の環境は、ロールベースのアクセス制御モデルに従います。 アクセス レベル制御の承認により、ユーザーは各自のジョブロールとビジネス要件に応じたタスクとアクションのみを実行できます。 特定のユース ケースで作業するデータ サイエンティストは、最小限の特権の原則に従って、そのユース ケースのリソース部分にのみアクセスできるため、機械学習のユース ケースは高度に分離されると予想されます。 これらのリソースには次のものが含まれます。
- ストレージ アカウント
- Azure Machine Learning ワークスペース
- インスタンスのコンピューティング
ロールベースのアクセス制御には、Microsoft Entra ID のセキュリティ グループが使用されます。
多要素認証
Azure で実行され、ビジネスへの影響が大きいと分類されたすべての環境にアクセスするには、多要素認証を導入して実装する必要があります。 多要素認証は、Microsoft Entra 多要素認証サービスを使用して適用できます。 アプリケーション エンドポイント (Azure DevOps、Azure 管理ポータル、Azure Machine Learning、Azure Databricks、Azure Kubernetes Services など) は、多要素認証アクセス制御ポリシーで構成する必要があります。
多要素認証は、Azure サービス マネージャー、データ エンジニア、データ サイエンティストを含むすべてのユーザーに適用する必要があります。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。
ログ記録と監視
すべての Azure サービスは、セキュリティ イベントを組織のセキュリティ オペレーション センター (SOC) プラットフォームに取り込む必要があり、次のセキュリティ イベントを記録する必要があります。
- 成功および失敗した認証試行
- 機密データへのアクセス
- セキュリティ ポリシーの変更
- 管理者ユーザー グループ、ユーザー、またはロールへの変更
- 外部の場所への機密データの転送 (該当する場合)
- 属性ベースのアクセス制御 (ABAC) 制御などの保護システムのアクティブ化と非アクティブ化
- ログへのアクセスの更新とログ記録の中断
Azure のセキュリティ ログは、さまざまなパターンで SOC に取り込むことができます。
- 中央の Azure Log Analytics ワークスペース
- SOC プラットフォーム システムに接続されたイベント ハブ (Splunk など)
- SOC エージェントでデプロイされた Windows VM とその他のコンピューティング リソース
DevOps
規制対象の環境の場合、IT システムは、広範で時間のかかるサポート ドキュメントを備えたユーザー要件仕様、機能仕様、設計、テスト仕様 (または同様のもの) などのプロセス フェーズ間の正式な承認 (またはゲート) を使用して、厳格なウォーターフォールスタイルの品質管理プロセスに従う必要があります。
Azure 環境とデータ サイエンスの開発は、DevOps カルチャに固定された反復的なプロセスに従います。 AI と機械学習イニシアチブのスケーリングに多大な労力を費やして DevOps 組織の柱を伝達し、Azure DevOps エピック、機能、ユーザー ストーリー、テスト計画、CI/CD パイプライン、および必要な品質制御エンティティと証拠の間で自動化されたエンドツーエンドのトレーサビリティ マッピングを作成します。
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。
規制された環境で AI と機械学習をスケーリングし、組織のビジネス領域全体で迅速な導入を促進するには、Azure サービスによって生み出される価値を測定、監視、評価する導入フレームワークを設計して導入することをお勧めします。 ライフ サイエンスとヘルスケア業界の例から、次のビジネス価値を生み出すレバーと主要業績評価指標 (KPI) が評価されました。
スケーラビリティ – Azure アーキテクチャをビジネス要件に合わせてスケーリングできるようにするために、スケール ポイントに関係なく、次の KPI を推奨します。
- コンピューティング インスタンスの数、および使用されるストレージとメモリの合計
- 実行された実験の数
- デプロイされたモデルの数
AI 開発の加速 – AI と機械学習ソリューションの開発を加速させるために、次の KPI を推奨します。
- Azure の AI と機械学習サービスを利用しているさまざまな事業単位の数
- カテゴリごとのオンボードしたユーザー数 (データ エンジニア、データ サイエンティスト、市民データ サイエンティスト、ビジネス ユーザーなど)
- 実行された実験の数
- ユーザーのオンボードからアクティブな使用までの時間
- サービスをプロビジョニングする時間 (構成の変更要求からサービスのプロビジョニングの完了まで)
コンプライアンス – デプロイされた AI と機械学習ソリューションの継続的なコンプライアンスを確保するために、次の KPI を推奨します。
- 該当する ISRM コントロールへの全体的なコンプラインス
- セキュリティの脆弱性の警告数
- 最後の期間のセキュリティ インシデントの数
ユーザー エクスペリエンス – 高品質で一貫性のあるユーザー エクスペリエンスを確実に利用できるようにするために、次の KPI を推奨します。
- ユーザー ヘルプ デスク への要求数
- ネット プロモーター スコア (NPS)
セキュリティで保護された基盤 – 安全でセキュリティで保護された基盤を確保するために、次の KPI を推奨します。
- 重要なサービスの稼働時間
- パフォーマンスの可用性に関連して報告されたインシデントの数
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
ランニング コストは単純で予測可能なパターンに従わないため、コスト管理はスケーラブルな AI と機械学習プラットフォームの実装において設計の重要な部分です。 コストは主に、プラットフォームで実行されている AI と機械学習実験の数とサイズ、より具体的には、モデルのトレーニングと推論で使用されるコンピューティング リソースの数と SKU によって決まります。
お勧めするプラクティスをいくつか次に示します。
- すべてのユース ケースおよび AI と機械学習製品に専用の Azure サービス予算を割り当てる。これは優れたコスト管理の実践です。
- プラットフォーム共有サービスの透過的なコスト モデルを確立する。
- タグを一貫して使用して、ユース ケースと製品リソースをコスト センターに関連付ける。
- Azure Advisor と Azure Budget を使用してリソースが最適な方法で使用されていない場所を把握し、構成を定期的に確認します。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Eran Sagi | AI ソリューション アーキテクト
次のステップ
Azure Machine Learning を使用して、モデルをトレーニングおよびデプロイし、機械学習のライフサイクルを管理する方法について説明します。 チュートリアル、コード例、API リファレンスなどは、こちらから入手できます。
Azure でデータ分析と AI のためのエンタープライズ規模のランディング ゾーンを実装する方法について確認します。
製品ドキュメント:
関連リソース
Azure アーキテクチャ センターの概要に関する記事: