# 運用モデル
<a name="operating-model"></a>

 運用モデルは、人材、プロセス、テクノロジーを結び付けて、組織がスケーラブルで一貫性のある効率的な方法でビジネス価値を実現できるようにするフレームワークです。**ML 運用モデルは、組織全体のチームに標準的な製品開発プロセスを提供します。運用モデルの実装には、規模、複雑さ、ビジネス推進要因に応じて、次の 3 つのモデルがあります。
+  **一元化されたデータサイエンスチーム** — このモデルでは、すべてのデータサイエンス活動が単一のチームまたは組織内に一元化されます。これは、センターオブエクセレンス (COE) モデルに似ており、データサイエンスプロジェクトに関してはすべてのビジネスユニットがこのチームに参加します。
+  **分散型データサイエンスチーム** — このモデルでは、データサイエンス活動が複数の異なるビジネス機能や部門に分散されるか、異なる製品ライン別に分散されます。
+  **フェデレーションデータサイエンスチーム** — このモデルの場合、コードリポジトリ、継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインなどの共有サービス機能は一元化されたチームによって管理され、各ビジネスユニットや製品レベルの機能は分散型チームによって管理されます。これは、ハブアンドスポークモデルに似ており、ビジネスユニットごとに独自のデータサイエンスチームがありますが、これらのビジネスユニットチームは、一元化されたチームとの間で活動を調整します。

 最初の Studio ドメインを本番環境のユースケースで立ち上げるかどうかを決める前に、運用モデルと環境整理の AWS ベストプラクティスを検討します。詳細については、「[複数のアカウントを使用して AWS 環境を整理する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)」を参照してください。

次のセクションでは、運用モデルごとにアカウント構造を整理するためのガイダンスを提供します。

## 推奨されるアカウント構造
<a name="recommended-account-structure"></a>

 このセクションでは、運用モデルのアカウント構造を簡単に紹介します。この構造から始めて、組織の運用要件に応じて変更できます。どの運用モデルを選択するかにかかわらず、以下の一般的なベストプラクティスを実装することをお勧めします。
+  [AWS Control Tower](https://aws.amazon.com/controltower/) を使用してアカウントの設定、管理、ガバナンスを行います。
+  ID プロバイダー (IdP) と [AWS IAM アイデンティティセンター](https://aws.amazon.com/iam/identity-center/)を使用して ID を一元管理します。そのために、委任された管理者の[セキュリティツール](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html)アカウントを使用し、ワークロードへの安全なアクセスを可能にします。
+  開発、テスト、本番環境のワークロードにわたってアカウントレベルの分離を使用して ML ワークロードを実行します。
+  ML ワークロードログをログアーカイブアカウントにストリーミングし、オブザーバビリティアカウントでログ分析をフィルタリングして適用します。
+  データアクセスをプロビジョニング、制御、監査するための一元化されたガバナンスアカウントを実行します。
+  組織やワークロードの要件に応じて、セキュリティとコンプライアンスを確保するために、セキュリティとガバナンスサービス (SGS) を適切な予防および検出ガードレールと共に各アカウントに組み込みます。

### 一元化されたモデルアカウント構造
<a name="centralized-model-account-structure"></a>

 このモデルでは、ML プラットフォームチームが以下を提供する責任があります。
+  データサイエンスチーム間で機械学習オペレーション ([MLOps](https://en.wikipedia.org/wiki/MLOps)) の要件に対処する共有サービスツールアカウント。
+  データサイエンスチーム間で共有される ML ワークロードの開発、テスト、および本番環境のアカウント。
+  データサイエンスチームのワークロードごとに分離して実行するためのガバナンスポリシー。
+  一般的なベストプラクティス。

![\[一元化された運用モデルのアカウント構造を示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/sagemaker-studio-admin-best-practices/images/com-account-structure.png)


### 分散型モデルのアカウント構造
<a name="decentralized-model-account-structure"></a>

 このモデルでは、各 ML チームが独立して ML アカウントとリソースのプロビジョニング、管理、ガバナンスを行います。ただし、機械学習チームには、データガバナンスと監査管理を簡素化するために、一元化されたオブザーバビリティとデータガバナンスモデルのアプローチを使用することをお勧めします。

![\[分散型運用モデルのアカウント構造を示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/sagemaker-studio-admin-best-practices/images/decentralized-model.png)


### フェデレーションモデルのアカウント構造
<a name="federated-model-account-structure"></a>

 このモデルは一元化されたモデルに似ていますが、主な違いは、データサイエンス/ML チームごとに独自の開発/テスト/本番環境のワークロードアカウントを持つことです。これにより、ML リソースの堅牢な物理的分離を可能にし、各チームが他のチームに影響を与えることなく独立してスケールできます。

![\[フェデレーション運用モデルのアカウント構造を示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/sagemaker-studio-admin-best-practices/images/fom-account-structure.png)


## ML プラットフォームのマルチテナンシー
<a name="ml-platform-multitenancy"></a>

 マルチテナンシーは、1 つのソフトウェアインスタンスが複数の異なるユーザーグループにサービスを提供できるソフトウェアアーキテクチャです。**テナントは、ソフトウェアインスタンスへの特定の権限を持つ、共通のアクセスを共有するユーザーのグループです。**例えば、複数の ML 製品を構築している場合、同様のアクセス要件を持つ各製品チームはテナントまたはチームと見なすことができます。

 SageMaker AI Studio インスタンス ([SageMaker AI ドメイン](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-entity-status.html)など) 内に複数のチームを実装することは可能ですが、複数のチームを 1 つの SageMaker AI Studio ドメインにまとめることに伴う利点とトレードオフ (影響範囲、コスト属性、アカウントレベルの制限など) を比較検討します。これらのトレードオフとベストプラクティスの詳細については、以下のセクションを参照してください。

リソースを完全に分離する必要がある場合は、SageMaker AI Studio ドメインをテナントごとに異なるアカウントに実装することを検討します。分離要件によっては、複数の事業部門 (LOB) を単一のアカウントおよびリージョン内の複数のドメインとして実装できます。共有スペースを使用すると、同じチーム/LOB のメンバー間でほぼリアルタイムのコラボレーションが可能になります。ドメインが複数ある場合でも、ID アクセス管理 (IAM) ポリシーとアクセス許可を使用してリソースを確実に分離します。

ドメインから作成した SageMaker AI リソースには、ドメインの [Amazon リソースネーム](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) (ARN) とユーザープロファイルまたはスペースの ARN が自動的にタグ付けされるため、リソースを簡単に分離できます。ポリシーの例については、[ドメインリソース分離に関するドキュメント](https://docs.aws.amazon.com/sagemaker/latest/dg/domain-resource-isolation.html)を参照してください。このドキュメントでは、マルチアカウント戦略またはマルチドメイン戦略をいつ使用するかについての詳細なリファレンスと、機能の比較を確認できます。また、[GitHub リポジトリ](https://github.com/aws-samples/sm-studio-best-practices/tree/main/domain-management)で既存のドメインのタグをバックフィルするサンプルスクリプトも確認できます 

最後に、[AWS Service Catalog](https://aws.amazon.com/servicecatalog/) を使用して複数のアカウントに SageMaker AI Studio リソースのセルフサービスデプロイを実装できます。詳細については、「[複数の AWS アカウントと AWS リージョンで AWS Service Catalog 製品を管理する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/manage-aws-service-catalog-products-in-multiple-aws-accounts-and-aws-regions.html)」を参照してください。