Amazon SageMaker Workshop をやってみた３ ~ 4. データ & AI ガバナンス ~
2025.06.18こんにちは！コンサルティング部のくろすけです！
前回(Amazon SageMaker Workshop をやってみた２ ~ 3. Lakehouse ~ | DevelopersIO)に引き続きこちらのワークショップをやっていこうと思います。
今回は[4. データ & AI ガバナンス]のセクションについて記載しようと思います！
目次
- ワークショップのセクション構成
-
- データ & AI ガバナンス
- あとがき
※前回同様、つまづいたポイントなどかいつまんで記載していきます。
ワークショップのセクション構成
- 1. Getting Started [必須]（ワークショップへの参加方法等なのでスキップ）
- 2. Unified Studio [必須]
- 3. Lakehouse
- 4. データ & AI ガバナンス <- 今回はここ
- 5. データ 処理
- 6. SQL 分析
- 7. ML/GenAI モデル 開発
- 8. GenAI アプリケーション 開発
- 9. おわりに
4. データ & AI ガバナンス
概要
若干構図がわかりづらかったんですが、Data and AI Governance という概念の実現のために、提供される Amazon SageMaker Catalog という機能という構図のようです。
以下は、Amazon SageMaker Catalog からの引用です。
次世代の Amazon SageMaker は、レイクハウス、AI モデル、アプリケーション全体にわたるデータや AI の検出、ガバナンス、コラボレーションを簡素化します。Amazon DataZone 上に構築された Amazon SageMaker Catalog では、ユーザーが生成 AI 作成のメタデータを用いたセマンティック検索を使用して承認されたデータやモデルをセキュアに検出してアクセスすることができ、Amazon Q Developer にデータを見つけるよう自然言語で指示することも可能です。ユーザーは、Amazon SageMaker Unified Studio できめ細かなアクセスコントロールを備えた単一の許可モデルを一元的に使用して、アクセスポリシーを一貫した方法で定義および適用できます。簡単なパブリッシュとサブスクライブのワークフローを通じて、データと AI アセットをシームレスに共有し、コラボレーションできます。SageMaker では、Amazon Bedrock のガードレールを使用して AI モデルを保護するとともに、責任ある AI ポリシーを実装することができます。データ品質の監視とオートメーション、機密データの検出、データと機械学習 (ML) のリネージを通じて、組織全体で信頼性を築きましょう。
ワークショップの内容
- ポータル上の管理者ワークフロー
- ドメインユニットの作成
- ユーザーとポリシーの認可
- パブリッシャー ワークフロー
- Salesドメインユニット向けのプロジェクト作成
- データ品質とデータ系譜の作成
- アセットメタデータのインポート
- 用語集とメタデータ フォームの設定
- データ製品のカタログ化と公開
- コンシューマー ワークフロー
- マーケティングドメインユニット向けのプロジェクト作成
- データアセットの検索とサブスクライブ
- サブスクライブしたデータアセットの Query Editor での分析
ソースデータセットの準備
デプロイフォームの 2 ページ目の パラメータ セクションで:
AdminRoleName フィールドに、AWS ワークショップイベントに参加している場合は WSParticipantRole と入力します。それ以外の場合は、SageMaker 管理者ユーザー を入力します。
こちらは自分の IAM ユーザー/ロール を指定します。
ただし、自分の IAM ユーザー/ロール を Lake Formation の Data lake administrators に登録している場合は削除してください。
これは CloudFormation で作成しますので、設定されているとエラーが発生します。
- デプロイフォームの 3 ページ目の アクセス許可 - オプション セクションで:
- 名前が sm-us-wrk-cfn-role の IAM ロール を選択します。
このオプションには、CFn 実行用の IAM ロール を設定します。
自分は一時的に Admin 権限を付与した IAM ロール を作成しました。
さらに CFn 実行前に CFn 実行用の IAM ロール を Lake Formation の Data lake administrators に登録しておく必要があります。
手間取りましたが、なんとか作成完了
ちなみに
このスタックには Retain 設定のリソースが複数ありますので、失敗した場合は下記のリソースの手動削除が必要です。
- S3
- aws-glue-assets-${ACCOUNT_ID}-${REGION}
- datalake-${ACCOUNT_ID}-${REGION}-data
- datalake-${ACCOUNT_ID}-${REGION}-spark
- Lake Formation
- Data permissions の Database および Table に紐づく IAM ロール
- Data lake administrators の IAM ロール
他は手順通りで問題ありませんでした！
ポータル上の管理者ワークフロー
自分はそれぞれ用語がなんぞやってところからだったんですが、下記の公式ドキュメントに詳しく記載がありました。
Amazon SageMaker Unified Studio terminology and concepts - Amazon SageMaker Unified Studio
下記に一部抜粋します。
- 管理者（ドメイン管理者）
（機械翻訳）ドメイン内のエンティティを編集するためのスーパー管理者権限を持つ IAM プリンシパル ID。
Amazon SageMaker Unified Studio では、Amazon SageMaker Unified Studio ドメインを作成した IAM プリンシパルが、そのドメインのデフォルトのドメイン管理者となります。Amazon SageMaker Unified Studio のドメイン管理者は、ドメインの作成、他のドメイン管理者の割り当て、プロジェクトプロファイルの作成と管理、ブループリントの設定、ユーザー管理、アカウントの関連付け、Amazon Bedrock モデル、Git 接続、Amazon Q など、ドメインの主要な機能を実行します。
- ドメインユニット
（機械翻訳）ドメインユニットを使用して、アセットやその他のドメインエンティティを特定のビジネスユニットやチームの下に整理します。組織内のビジネスユニット内およびビジネスユニット間で安全かつ効率的なデータ共有を設定するには、Amazon SageMaker Unified Studio 内にドメインユニットを作成し、各ビジネスユニット内の特定のユーザーにアクセス権を付与して、ログインし、アセットを Amazon SageMaker カタログと共有できるようにします。また、ドメインユニットは、AWS アカウント所有者などのリソース所有者が、自分のリソースに対する Amazon SageMaker Unified Studio の承認権限を設定するためにも使用できます。ドメインユニットは、アカウント所有者からドメインユニット所有者への委任権限を提供し、ドメインユニット所有者はアカウント所有者に代わって承認権限を設定できます。
- 認可ポリシー
（機械翻訳）プロジェクト、ブループリント、環境、用語集、メタデータフォームなどのエンティティに適用される、Amazon SageMaker Unified Studio 内の一連のコントロールです。
Amazon SageMaker Unified Studio ドメインユニット内では、ユーザーとグループに次の承認ポリシーを割り当てて、特定の権限を付与することができます。
- ドメインユニット作成ポリシー
- プロジェクト作成ポリシー
- プロジェクトメンバーシップポリシー
- ドメインユニット所有権引受ポリシー
- プロジェクト所有権引受ポリシー
Amazon SageMaker Unified Studio ドメインユニット内では、プロジェクトに次の承認ポリシーを割り当てて、特定の権限を付与することができます。
- 用語集作成ポリシー
- メタデータフォーム作成ポリシー
- カスタムアセットタイプ作成ポリシー
特定のブループリント構成内で、プロジェクトおよびドメイン ユニット所有者に次の承認ポリシーを割り当てることができます。
- このブループリントを使用して環境プロファイルを作成します。このポリシーは Amazon SageMaker Unified Studio プロジェクトに割り当てることができ、このブループリントを使用して環境プロファイルを作成することを許可します。
- このブループリントを使用して環境プロファイルを作成するための権限を付与します。このポリシーはドメインユニット所有者に割り当てることができ、このブループリントを使用して環境プロファイルを作成するための権限をプロジェクトに付与することを許可します。
ポータル上の管理者ワークフロー (ドメインユニットの作成)
- クリックすると新しいタブが開きます。Sign in with SSO を選択します。
この手順では画像が dg-data-owner でのログインになっていますが、ルートドメインの管理者でないと後続の手順が権限不足で実行できません。
正しくは手順に記載の通り、dg-corp-admin でログインしてください。
他は手順通りで問題ありませんでした！
最終的にはこんな感じです。
ポータル上の管理者ワークフロー (ユーザーとポリシーの認可)
認可ポリシー
- プロジェクト作成ポリシー
Project creation policy の変更は、Corporate ドメインユニットの Project creation policy を変更してください。
冒頭の画像が Marketing だったこともあり、自分は早とちりしました。
他の手順については特につまづくポイントはありませんでしたが、Project creation policy の設定が、設定表示に反映されませんでした。
手順以外の設定やドキュメントの確認を行いましたが、仕様ではなさそうなので現状の不具合かもしません。
他の設定については、最終的には下記の通りです。
パブリッシャー ワークフロー
下記がこのセクションの概要（転記）です。
概要
グローバルポリシーとリソース、権限委譲がルートドメインオーナーによって定義されると、個々のドメインユニットオーナーはビジネスユニット内でリソースをプロビジョニングできるようになります。このモジュールでは、ドメインユニットオーナーとドメインユニットユーザーの役割と責任について説明します。
ドメインユニットオーナーの責任
- プロジェクトの作成
- プロジェクトプロファイルの作成
- ビジネスユースケースに基づくプロジェクトメンバーの追加 (オプション)
これらの責任により、個々のビジネスユニット内のデータに対する明確な所有権と説明責任が促進され、ドメイン固有のコンプライアンスが容易になります。ドメインユニットユーザー
- データソースの作成とメタデータのインポート
- ビジネス説明、メタデータフォーム、ビジネス用語集によるカタログの強化
- データ品質スコアの統合とリニエージイベントの生成
- データアセットの公開
- サブスクリプション許可の承認
- サブスクリプション時の細かいアクセス許可
ドメインユニットユーザーが、パブリッシャーとなります。
パブリッシャー ワークフロー (販売ドメインユニット 向け プロジェクトの作成)
- Domain units を Sales、Project profile を Data analytics and AI-ML model development と選択します。Continue をクリックします。
現在は Data analytics and AI-ML model development ではなく All capabilities になっていました。
他は手順通りで問題なく、最終的に下記のように作成できました。
パブリッシャー ワークフロー (自分のデータをプロジェクトに持ち込む)
既存の AWS Glue Data Catalog リソースに対してプロジェクトロールの承認を提供する
こちらは手順通りで問題なく、最終的に下記のように作成できました。
パブリッシャー ワークフロー (データ品質と データ系譜)
データ品質メトリクスとリネージュイベントの生成
こちらは手順通りで問題なく作成できました。
下記は Data quality の作成結果です。Data lineage は後段の手順で確認することになります。
パブリッシャー ワークフロー (アセットメタデータの インポート)
アセットメタデータのインポート
こちらも手順通りで問題ありませんでした。
下記が設定のキャプチャです。
パブリッシャー ワークフロー (ビジネスデータ カタログ (用語集とメタデータ フォーム))
ビジネス用語集
こちらも手順通りで問題ありませんでした。
下記が設定のキャプチャです。
メタデータフォーム
こちらも手順通りで問題ありませんでした。
下記が設定のキャプチャです。
パブリッシャー ワークフロー (データ製品のカタログ化と公開)
- Metadata Forms セクションで、Ownership の隣の Edit Values ボタンを選択します。
自分の場合上記の手順に到達した段階では、Ownership が存在しませんでした。
そのためまずは、[ADD METADATA FORM] で Ownershipを追加する必要がありました。
最終的には下記のように設定できます。
コンシューマー ワークフロー
下記がこのセクションの概要（転記）です。
概要
ルートドメインの所有者がグローバルポリシーとリソース、権限委譲を定義すると、個々のドメインユニットの所有者はそのビジネスユニット内でリソースをプロビジョニングできるようになります。このラボでは、ドメインユニットの所有者とドメインユニットユーザーの役割と責任について見ていきます。
ドメインユニット所有者の責任
- プロジェクトの作成
- プロジェクトプロファイルの作成
- ビジネスユースケースに基づくプロジェクトメンバーの追加 (オプション)
これらの責任により、個々のビジネスユニット内のデータに対する明確な所有権と説明責任が促進され、ドメイン固有のコンプライアンスが容易になります。ドメインユニットユーザー
- データアセットの検出
- データアセットの購読
- データアセットの消費
ドメインユニットユーザーが、コンシューマーとなります。
コンシューマー ワークフロー (マーケティングドメインユニット用のプロジェクトを作成する)
こちらも手順通りで問題ありませんでした。
このセクションは、プロジェクトを作成するのみなので特につまづかないかと思います。
↓作成したプロジェクト
コンシューマー ワークフロー (発見して購読する)
こちらも手順通りで問題ありませんでした。
サブスクリプションをAPPROVEすると下記のようになります。
コンシューマー ワークフロー （Query Editor を使用してデータを分析する）
こちらも手順通りで問題ありませんでした。
データアセットをサブスクライブして、Athenaでクエリすることができました。
あとがき
今回は データ & AI ガバナンスについて、ワークショップをやってみました。
下記がポイントだったかなと思います。
- 管理者、パブリッシャー、コンシューマーの3つの役割による権限分離
- きめ細かなアクセス制御によるセキュアなデータ共有の実現
また実際にやってみて、下記が気になったのでまた別途考察・検証してみようと思います。
- ドメイン、ドメインユニット、プロジェクトなどの各エンティティと企業組織との対応関係
- 公開データアセットの管理方法
- 大規模組織における権限管理のベストプラクティス
以上、くろすけでした！
