SageMakerの三層アーキテクチャ
Amazon SageMakerは、機械学習(Machine Learning)のモデルの構築、トレーニング、デプロイメントをサポートするサービスです。SageMakerは、ドメイン、ユーザプロファイル、アプリケーションの3つの主要な層で構造化されています。
-
ドメイン(Domain)
-
ユーザプロファイル(User Profile)
-
アプリケーション(Application)
AWS re:Invent 2023以後、急にアーキテクチャが複雑になり、アーキテクチャを説明するドキュメントがなかったので、作成しました。
ドメイン(Domain)全体像
新UIでnotebookを利用する場合は、JypyterLab、旧UIでnotebookを利用する場合は、Studio Classicアプリをクリックします。
-
ドメイン(Domain)
ドメインは、SageMakerの最上位の階層であり、組織全体の機械学習リソースをグループ化します。- 各ドメインは、特定のビジネスユースケースやプロジェクトに関連する一連の機械学習リソースを含みます。
- 例えば、異なる部門やプロジェクトごとに異なるドメインを作成でき、それぞれが独自の環境を持つことができます。
-
ユーザプロファイル(User Profile)
ユーザプロファイルは、特定のユーザやチームに関連する機械学習の設定やリソースを管理します。- ユーザプロファイルには、ユーザごとのアクセス権や環境設定が含まれます。
- 各ユーザプロファイルは、ドメイン内で個別に管理され、ユーザやチームが必要なリソースにアクセスできるようにします。
-
アプリケーション(Application)
アプリケーションは、具体的な機械学習プロジェクトやワークフローを指します。- アプリケーションは、データの前処理、モデルのトレーニング、デプロイなどのフェーズを含む、完全な機械学習パイプラインを表します。
- 各アプリケーションは、関連するユーザプロファイルに基づいて構成され、特定のユーザやチームがそのアプリケーションにアクセスできるようになります。
これらの3つの層を組み合わせることで、SageMakerは異なる組織やプロジェクトに対して柔軟かつ効率的な機械学習環境を提供します。それぞれの層は、セキュリティやアクセス制御、リソースの管理などの側面でカスタマイズ可能であり、ユーザや組織のニーズに合わせて調整できます。
現在、新UI JypyterLabと旧UI Studio Classcのアプリ、どちらからでもノートブックを起動できるのですが、アーキテクチャが異なるので、ロールの使い分け等、注意が必要な状況となっております。新UIでは、プライベートスペースだけなので、ドメイン実効ロールを使います。しかし、旧UIでは、プライベートスペースでは、ドメイン実効ロールを使い、共有スペースでは、ユーザプロファイルロールを使うという事を気を付けないと、混乱するかと思います。
新UI JypterLabのアーキテクチャ
SageMakerのセキュリティ
一見すると、ルートアクセスできるように見えます。
ただ、こちらは、対策が取られており、
ユーザーの再マッピングが行われています。
SageMakerはユーザー再マッピングを実行して、コンテナ内のユーザーをホストインスタンス上のユーザーにマップします。コンテナ内のユーザーIDの範囲(0~65535)は、インスタンス上の65535を超える非特権ユーザーIDにマッピングされます。例えば、sagemaker-user (1000)は、インスタンス上のユーザー(200001)にマップされることがあります。
ユーザー再マッピングにより、コンテナ内のユーザーはリソースにアクセスできなくなり、ホストインスタンスに変更を加えることができません。ユーザーの新規作成に関係なく、権限は与えられません。コンテナのrootユーザーも、インスタンス上の非特権ユーザーにマップされます。
これにより、セキュリティが向上し、コンテナーが適切に分離されるようになります。
https://docs.aws.amazon.com/sagemaker/latest/dg/security-access-control-studio-nb.html
旧UI Studio Classicのアーキテクチャ
ドメイン実効ロールは、プライベートスペースで使われる。
ユーザプロファイルロールは、共有スペースで使われる。
https://repost.aws/ja/knowledge-center/sagemaker-studio-role-change
AWS re:Invent 2023以前のアーキテクチャは、下記のようなものです。(旧UI Classic環境)