「Amazon CloudWatchを使用して、Amazon SageMakerのための集中監視およびレポートソリューションを構築する」

Build centralized monitoring and reporting solution for Amazon SageMaker using Amazon CloudWatch

Amazon SageMakerは、エンドツーエンドのMLワークロードを提供する包括的なサービスセットを提供する、完全に管理された機械学習（ML）プラットフォームです。AWSによるベストプラクティスとして推奨されているように、顧客はユーザーのポリシー管理を簡素化し、ワークロードとアカウントごとにリソースを分離するために別々のアカウントを使用してきました。しかし、クラウドでMLプラットフォームを使用するユーザーやチームが増えると、スケーリングマルチアカウント環境での大規模なMLワークロードの監視がより困難になります。より良い可観測性のために、顧客はクロスアカウントのリソース使用状況やジョブの起動と実行状態などの活動を監視するためのソリューションを探しています。これは彼らのMLガバナンスと管理の要件に不可欠です。

Processing、Training、HostingなどのSageMakerサービスは、実行中のインスタンスからメトリクスとログを収集し、ユーザーのAmazon CloudWatchアカウントにプッシュします。異なるアカウントのこれらのジョブの詳細を表示するには、各アカウントにログインし、対応するジョブを見つけ、ステータスを確認する必要があります。このようなクロスアカウントおよびマルチジョブの情報を簡単に表示できる単一の表示画面はありません。さらに、クラウド管理チームは異なるSageMakerワークロードアカウントへの個別のアクセスを提供する必要があり、クラウドプラットフォームチームに追加の管理オーバーヘッドを追加します。

この記事では、複数アカウント間でSageMakerユーザーの活動とリソースを監視するための中央集権的なダッシュボードを紹介します。このダッシュボードでは、エンドユーザーやクラウド管理チームが実行中のMLワークロードを効率的に監視でき、これらのワークロードのステータスを表示し、特定の時点で異なるアカウントの活動を追跡できます。このダッシュボードを使用すると、SageMakerコンソールからジョブの詳細を探すために移動したり、ジョブログの詳細を確認する必要はありません。代わりに、実行中のジョブとジョブのステータスを簡単に表示し、ジョブの問題をトラブルシューティングし、共有アカウントで問題が特定された場合にジョブの失敗、リソースの未使用などのアラートを設定できます。また、この中央監視ダッシュボードへのアクセスを制御したり、関連する機関と共有したりして、監査および管理の要件を満たすこともできます。

ソリューションの概要

このソリューションは、マルチアカウント環境全体でのSageMakerジョブと活動の中央監視を可能にするために設計されています。このソリューションは、AWS組織に依存せずに採用できるように設計されていますが、組織またはAWS Control Tower環境でも簡単に採用できます。このソリューションは、運用チームが単一の表示画面から複数のワークロードアカウントに広がるすべてのSageMakerワークロードの高レベルなビューを持つことを支援します。また、中央監視アカウントでCloudWatchクロスアカウントの可観測性を有効にするオプションもあります。これにより、メトリクス、ログ、トレースなどの監視テレメトリにアクセスできます。例として、以下のスクリーンショットに示すダッシュボードがあります。

以下の図は、この中央監視ダッシュボードソリューションのアーキテクチャを示しています。

SageMakerは、Amazon EventBridgeとネイティブに統合されており、SageMakerのステータス変更イベントを監視します。EventBridgeを使用すると、トレーニングジョブのステータス変更やエンドポイントのステータス変更などのイベントに対して自動化された処理や応答を行うことができます。SageMakerからのイベントはほぼリアルタイムでEventBridgeに配信されます。EventBridgeによって監視されるSageMakerのイベントについての詳細は、「Amazon EventBridgeを使用したAmazon SageMakerの自動化」を参照してください。SageMakerネイティブのイベントに加えて、API呼び出し時にAWS CloudTrailがイベントを公開し、これもEventBridgeにストリーミングされるため、多くのダウンストリームの自動化や監視ユースケースで利用できます。このソリューションでは、ワークロードアカウントのEventBridgeルールを使用して、SageMakerサービスイベントとAPIイベントを監視アカウントのイベントバスにストリーム配信するため、中央監視が可能です。

中央監視アカウントでは、イベントはEventBridgeルールによってキャプチャされ、さらに異なるターゲットに処理されます：

  • 次の用途で使用するためのCloudWatchロググループ：
    • 監査およびアーカイブ目的。詳細については、Amazon CloudWatch Logsユーザーガイドを参照してください。
    • CloudWatch Log Insightsクエリを使用してログデータを分析します。CloudWatch Logs Insightsを使用すると、CloudWatch Logs内のログデータを対話型で検索および分析することができます。クエリを実行して、操作上の問題により効率的かつ効果的に対応できます。問題が発生した場合、CloudWatch Logs Insightsを使用して潜在的な原因を特定し、展開された修正を検証できます。
    • CloudWatchダッシュボードの高レベルな操作に対するCloudWatch Metrics Insightsクエリウィジェットのサポート、ダッシュボードへのCloudWatch Insightsクエリの追加、およびクエリ結果のエクスポート。
  • 次のタスクを完了するためのAWS Lambda関数：
    • SageMakerサービスイベントを拡張するためのカスタムロジックを実行します。ジョブの完了イベントを受け取った場合、SageMakerジョブホストの利用率メトリックスに対してメトリッククエリを実行するなどの例があります。
    • イベント情報を特定のログ形式のメトリックスに変換し、EMFログとして投入します。詳細については、「ログにメトリックスを埋め込む」を参照してください。

この投稿の例は、ネイティブのCloudWatchのクロスアカウント可観測性機能によって、クロスアカウントのメトリックス、ログ、トレースにアクセスするためにサポートされています。アーキテクチャ図の下部に示されているように、この機能と統合して、クロスアカウントのメトリックスとログを有効にします。これを有効にするには、監視アカウントとソースのワークロードアカウントの両方に必要な権限とリソースを作成する必要があります。

このソリューションは、組織によって管理されるAWSアカウントまたはスタンドアロンアカウントのいずれかに使用できます。次のセクションでは、それぞれのシナリオに対する手順を説明します。ただし、各シナリオ内では、異なるAWSアカウントで手順が実行されます。便宜上、各ステップの実行アカウントタイプがステップの最初に強調表示されています。

前提条件

この手順を開始する前に、GitHubリポジトリからソースコードをローカル環境またはAWS Cloud9にクローンし、次のものが必要です：

  • Node.js 14.15.0（またはそれ以降）およびnmpのインストール
  • AWS Command Line Interface（AWS CLI）バージョン2のインストール
  • AWS CDK Toolkit
  • Docker Engineのインストール（デプロイ手順を実行する際に実行中の状態であること）

組織環境でソリューションをデプロイする

監視アカウントとすべてのSageMakerワークロードアカウントが同じ組織にある場合、ソースのワークロードアカウントの必要なインフラストラクチャは組織の管理アカウントからAWS CloudFormation StackSetを介して自動的に作成されます。したがって、ソースのワークロードアカウントへの手動のインフラストラクチャ展開は不要です。新しいアカウントが作成されたり、既存のアカウントがターゲットの組織単位（OU）に移動されたりすると、ソースのワークロードインフラストラクチャスタックが自動的に展開され、集中監視の範囲に含まれます。

監視アカウントのリソースを設定する

監視アカウントのリソースを設定するために、次のAWSアカウント情報を収集する必要があります。これらは後でセットアップスクリプトの入力として使用します。

入力 説明 例
ホームリージョン ワークロードが実行されるリージョンです。 ap-southeast-2
監視アカウントのAWS CLIプロファイル名 ~/.aws/configからプロファイル名を見つけることができます。これはオプションです。指定しない場合、チェーンからデフォルトのAWS認証情報を使用します。 .
SageMakerワークロードOUパス SageMakerワークロードアカウントを持つOUパスです。パスの末尾に/を保持します。 o-1a2b3c4d5e/r-saaa/ou-saaa-1a2b3c4d/

OUパスを取得するには、組織コンソールに移動し、AWSアカウントの下でOUパスを構築するための情報を見つけます。次の例では、対応するOUパスはo-ye3wn3kyh6/r-taql/ou-taql-wu7296by/です。

この情報を取得したら、次のコマンドを実行して監視アカウントに必要なリソースをデプロイします：

./scripts/organization-deployment/deploy-monitoring-account.sh

デプロイから次の出力を取得できます。次のステップで管理アカウントスタックをデプロイする際に使用するために、出力をメモしておいてください。

管理アカウントリソースの設定

管理アカウントリソースの設定スクリプトに入力として使用するため、以下のAWSアカウント情報を収集する必要があります。

入力 説明 例
ホームリージョン ワークロードが実行されるリージョン。監視スタックと同じである必要があります。 ap-southeast-2
管理アカウントAWS CLIプロファイル名 ~/.aws/configからプロファイル名を見つけることができます。これはオプションです。指定しない場合は、チェーンからデフォルトのAWS認証情報が使用されます。 .
SageMakerワークロードOU ID パスではなく、OU IDのみを使用します。 ou-saaa-1a2b3c4d
監視アカウントID 監視スタックが展開されるアカウントIDです。 .
監視アカウントロール名 前の手順からのMonitoringAccountRoleNameの出力です。 .
監視アカウントイベントバスARN 前の手順からのMonitoringAccountEventbusARNの出力です。 .
監視アカウントシンク識別子 前の手順からのMonitoringAccountSinkIdentifierの出力です。 .

次のコマンドを実行することで、管理アカウントリソースをデプロイできます：

./scripts/organization-deployment/deploy-management-account.sh

非組織環境でのソリューションの展開

環境が組織を使用していない場合、監視アカウントのインフラストラクチャスタックは同様の方法で展開されますが、いくつかの変更があります。ただし、ワークロードのインフラストラクチャスタックは各ワークロードアカウントに手動で展開する必要があります。そのため、この方法はアカウント数が限られた環境に適しています。大規模な環境では、組織を使用することをお勧めします。

監視アカウントリソースの設定

監視アカウントリソースの設定スクリプトに入力として使用するため、以下のAWSアカウント情報を収集する必要があります。

入力 説明 例
ホームリージョン ワークロードが実行されるリージョン。 ap-southeast-2
SageMakerワークロードアカウントリスト SageMakerワークロードを実行し、イベントを監視アカウントにストリーミングするアカウントのリスト（カンマ区切り）です。 111111111111,222222222222
監視アカウントAWS CLIプロファイル名 ~/.aws/configからプロフィール名を見つけることができます。これはオプションです。指定しない場合は、チェーンからデフォルトのAWS認証情報が使用されます。 .

必要な情報を収集した後、次のコマンドを実行することでモニタリングアカウントのリソースを展開することができます：

./scripts/individual-deployment/deploy-monitoring-account.sh

デプロイが完了すると、以下の出力が表示されます。次のステップで管理アカウントスタックを展開する際に使用するため、出力をメモしておきます。

ワークロードアカウントのモニタリングインフラストラクチャの設定

ワークロードアカウントのモニタリングインフラストラクチャを設定するために、次のAWSアカウント情報を収集する必要があります。これらは後でセットアップスクリプトの入力として使用します。

入力 説明 例
ホームリージョン ワークロードが実行されるリージョン。モニタリングスタックと同じである必要があります。 ap-southeast-2
モニタリングアカウントID モニタリングスタックが展開されたアカウントのID。 .
モニタリングアカウントのロール名 前のステップからのMonitoringAccountRoleNameの出力。 .
モニタリングアカウントのイベントバスARN 前のステップからのMonitoringAccountEventbusARNの出力。 .
モニタリングアカウントのシンク識別子 MonitoringAccountSinkIdentifierの前のステップからの出力。 .
ワークロードアカウントのAWS CLIプロファイル名 ~/.aws/configからプロファイル名を見つけることができます。これはオプションです。指定しない場合は、チェーンからデフォルトのAWS認証情報を使用します。 .

次のコマンドを実行することで、モニタリングアカウントのリソースを展開することができます：

./scripts/individual-deployment/deploy-workload-account.sh

CloudWatchダッシュボード上でMLタスクを可視化する

ソリューションが動作しているかどうかを確認するために、前のセクションで使用したワークロードアカウントで複数のSageMakerプロセッシングジョブとSageMakerトレーニングジョブを実行する必要があります。CloudWatchダッシュボードは、独自のシナリオに基づいてカスタマイズできます。サンプルのダッシュボードには、SageMakerプロセッシングジョブとSageMakerトレーニングジョブを可視化するためのウィジェットが含まれています。ワークロードアカウントのすべてのジョブがこのダッシュボードに表示されます。各ジョブのタイプごとに、ジョブの総数、失敗したジョブの数、および各ジョブの詳細を表示します。このダッシュボードでは、2つのワークロードアカウントがあります。このダッシュボードを使用すると、1つのワークロードアカウントにはプロセッシングジョブとトレーニングジョブの両方があり、もう1つのワークロードアカウントにはトレーニングジョブだけがあることが簡単にわかります。CloudWatchで使用する関数と同様に、リフレッシュ間隔を設定したり、グラフの種類を指定したり、ズームイン/アウトしたり、CSVファイルでログをダウンロードしたりすることができます。

ダッシュボードのカスタマイズ

GitHubリポジトリで提供されるソリューションには、SageMakerトレーニングジョブとSageMakerプロセッシングジョブのモニタリングが含まれています。バッチトランスフォームジョブなど、他のSageMakerジョブをモニタリングするためにさらにダッシュボードを追加したい場合は、このセクションの手順に従ってダッシュボードをカスタマイズすることができます。index.pyファイルを変更することで、ダッシュボードに表示するフィールドをカスタマイズすることができます。CloudWatchでキャプチャされたすべての詳細にアクセスすることができます。Lambda関数では、ダッシュボードに表示する必要のあるフィールドを選択することができます。以下のコードを参照してください：

@metric_scope
def lambda_handler(event, context, metrics):
    
    try:
        event_type = None
        try:
            event_type = SAGEMAKER_STAGE_CHANGE_EVENT(event["detail-type"])
        except ValueError as e:
            print("Unexpected event received")

        if event_type:
            account = event["account"]
            detail = event["detail"]

            job_detail = {
                "DashboardQuery": "True"
            }
            job_detail["Account"] = account
            job_detail["JobType"] = event_type.name


            metrics.set_dimensions({"account": account, "jobType": event_type.name}, use_default=False)
            metrics.set_property("JobType", event_type.value)
            
            if event_type == SAGEMAKER_STAGE_CHANGE_EVENT.PROCESSING_JOB:
                job_status = detail.get("ProcessingJobStatus")

                metrics.set_property("JobName", detail.get("ProcessingJobName"))
                metrics.set_property("ProcessingJobArn", detail.get("ProcessingJobArn"))

                job_detail["JobName"]  = detail.get("ProcessingJobName")
                job_detail["ProcessingJobArn"] = detail.get("ProcessingJobArn")
                job_detail["Status"] = job_status
                job_detail["StartTime"] = detail.get("ProcessingStartTime")
                job_detail["InstanceType"] = detail.get("ProcessingResources").get("ClusterConfig").get("InstanceType")
                job_detail["InstanceCount"] = detail.get("ProcessingResources").get("ClusterConfig").get("InstanceCount")
                if detail.get("FailureReason"):

ダッシュボードやウィジェットをカスタマイズするには、monitoring-account-infra-stack.tsファイルのソースコードを変更することができます。ただし、このファイルで使用するフィールド名は、Lambdaファイルで定義されているもの（job_detailのキー）と同じである必要があります：

 // CloudWatchダッシュボード
    const sagemakerMonitoringDashboard = new cloudwatch.Dashboard(
      this, 'sagemakerMonitoringDashboard',
      {
        dashboardName: Parameters.DASHBOARD_NAME,
        widgets: []
      }
    )

    // 処理ジョブ
    const processingJobCountWidget = new cloudwatch.GraphWidget({
      title: "処理ジョブの総数",
      stacked: false,
      width: 12,
      height: 6,
      left:[
        new cloudwatch.MathExpression({
          expression: `SEARCH('{${AWS_EMF_NAMESPACE},account,jobType} jobType="PROCESSING_JOB" MetricName="ProcessingJobCount_Total"', 'Sum', 300)`,
          searchRegion: this.region,
          label: "${PROP('Dim.account')}",
        })
      ]
    });
    processingJobCountWidget.position(0,0)
    const processingJobFailedWidget = new cloudwatch.GraphWidget({
      title: "処理ジョブの失敗数",
      stacked: false,
      width: 12,
      height:6,
      right:[
        new cloudwatch.MathExpression({
          expression: `SEARCH('{${AWS_EMF_NAMESPACE},account,jobType} jobType="PROCESSING_JOB" MetricName="ProcessingJobCount_Failed"', 'Sum', 300)`,
          searchRegion: this.region,
          label: "${PROP('Dim.account')}",
        })
      ]
    })
    processingJobFailedWidget.position(12,0)
    
    const processingJobInsightsQueryWidget = new cloudwatch.LogQueryWidget(
      {
        title: 'SageMaker処理ジョブの履歴',
        logGroupNames: [ingesterLambda.logGroup.logGroupName],
        view: cloudwatch.LogQueryVisualizationType.TABLE,
        queryLines: [
          'sort @timestamp desc',
          'filter DashboardQuery == "True"',
          'filter JobType == "PROCESSING_JOB"',
          'fields Account, JobName, Status, Duration, InstanceCount, InstanceType, Host, fromMillis(StartTime) as StartTime, FailureReason',
          'fields Metrics.CPUUtilization as CPUUtil, Metrics.DiskUtilization as DiskUtil, Metrics.MemoryUtilization as MemoryUtil',
          'fields Metrics.GPUMemoryUtilization as GPUMemoeyUtil, Metrics.GPUUtilization as GPUUtil',
        ],
        width:24,
        height: 6,
      }
    );
    processingJobInsightsQueryWidget.position(0, 6)
    sagemakerMonitoringDashboard.addWidgets(processingJobCountWidget);
    sagemakerMonitoringDashboard.addWidgets(processingJobFailedWidget);
    sagemakerMonitoringDashboard.addWidgets(processingJobInsightsQueryWidget);

ダッシュボードを変更した後は、このソリューションを最初から再デプロイする必要があります。SageMakerパイプラインを再実行するために、GitHubリポジトリで提供されているJupyterノートブックを実行することができます。これにより、SageMaker処理ジョブが再度起動されます。ジョブが完了したら、CloudWatchコンソールに移動し、ナビゲーションペインのダッシュボードの下にあるカスタムダッシュボードを選択します。SageMaker-Monitoring-Dashboardという名前のダッシュボードが表示されます。

クリーンアップ

このカスタムダッシュボードが不要になった場合は、リソースをクリーンアップすることができます。作成されたすべてのリソースを削除するには、このセクションのコードを使用します。組織環境と非組織環境では、クリーンアップの方法が若干異なります。

組織環境の場合、次のコードを使用します：

make destroy-management-stackset # 管理アカウントで実行
make destroy-monitoring-account-infra # モニタリングアカウントで実行

非組織環境の場合、次のコードを使用します：

make destroy-workload-account-infra # 各ワークロードアカウントで実行
make destroy-monitoring-account-infra # モニタリングアカウントで実行

または、CloudFormationコンソールからモニタリングアカウント、ワークロードアカウント、および管理アカウントにログインして、スタックを削除することもできます。

結論

この記事では、CloudWatchを使用したSageMakerの集中モニタリングおよびレポートソリューションの実装について説明しました。この記事で概説されたステップバイステップの手順に従うことで、リアルタイムで異なるアカウントのさまざまなSageMakerジョブに関連する主要なメトリクスとログを表示するマルチアカウントモニタリングダッシュボードを作成することができます。この集中モニタリングダッシュボードを使用することで、複数のアカウントでのSageMakerジョブの活動をより良く把握し、問題を迅速にトラブルシューティングし、リアルタイムデータに基づいて情報を得ることができます。全体として、CloudWatchを使用した集中モニタリングおよびレポートソリューションの実装は、組織がクラウドベースのMLインフラストラクチャとリソース利用を効率的に管理するための効果的な方法を提供します。

このソリューションを試して、ご意見をお知らせください。Amazon SageMakerのAWSフォーラムまたは通常のAWSの連絡先を通じてフィードバックを送信してください。

クロスアカウント観測性機能について詳しくは、ブログ「Amazon CloudWatch クロスアカウント観測性」を参照してください。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!

Share:

Was this article helpful?

93 out of 132 found this helpful

Related articles

Discover more

データサイエンス

GOAT-7B-Communityモデルをご紹介します：GoatChatアプリから収集されたデータセットでLLaMA-2 7Bモデルを微調整したAIモデルです

最近、AI研究所の科学者たちは、GoatChatアプリのデータを使用して、LLaMA-2 7Bモデルを洗練させたGOAT-7B-Communityモデルを...

AI研究

このAI研究は、CoDi-2を紹介します：インターリーブされた指示処理とマルチモーダルな出力生成の風景を変える画期的なマルチモーダル大規模言語モデルです

研究者たちは、UCバークレー、Microsoft Azure AI、Zoom、UNC-Chapel Hillによって開発されたCoDi-2 Multimodal Large Langua...

AI研究

バイトダンスAI研究がStemGenを紹介：音楽の文脈を聞いて適切に反応するためにトレーニングされたエンドツーエンドの音楽生成ディープラーニングモデル

音楽生成は、既存の音楽に存在するパターンと構造を模倣するためにモデルを訓練することで行われるディープラーニングの一環...

機械学習

視覚のない人のための音声ビジョン

科学者たちは、「音波タッチ」という技術を作成しましたこの技術は音を使用して、視覚障がいの人々に「見る」ことを手助けします

機械学習

テンセントAI研究所では、GPT4Videoを紹介していますこれは統合マルチモーダル大規模言語モデルであり、指示に従った理解と安全意識のある生成を目指しています

テンセントAIラボとシドニー大学の研究者たちによって、ビデオの理解と生成シナリオの問題がGPT4Videoで解決されました。この...

機械学習

「MatFormerをご紹介します：プラットフォーム間で柔軟なモデル展開を可能にする、汎用なネストされたTransformerアーキテクチャ」

Transformerモデルは、強力なマルチアクセラレータクラスタから個々のモバイルデバイスまで、さまざまなアプリケーションで使...

Want to read more? Go here