SageMakerパイプラインの複数アカウント監視

Amazon SageMaker Pipelines を活用すれば、組織は機械学習（ML）ワークロードを自動化し、MLOps 戦略の一環として複数の AWS アカウントやリージョンにまたがって分散実行することが可能になります。

しかし、SageMaker Pipelines が多数の AWS 環境にまたがって分散されている場合、その監視は複雑化しがちです。開発者や運用エンジニアは、Pipeline の実行状況を確認するために手動で複数のアカウントやリージョンを行き来する必要があり、運用負荷が増大してしまいます。

Amazon SageMaker Studio は、単一のアカウントおよびリージョン内での SageMaker Pipelines 監視を提供します。一方、複数の AWS 環境にまたがる Pipeline 実行の追跡には、Amazon CloudWatch や AWS Lambda、Amazon DynamoDB、Amazon EventBridge などのサービスを活用し、組織の観測要件に合わせてカスタマイズしたダッシュボードを構築することが推奨されます。

本稿では、Amazon CloudWatch のカスタムダッシュボードを活用し、複数の AWS アカウントやリージョンにまたがる SageMaker Pipelines の監視を一元化するソリューションをご紹介します。必要なインフラストラクチャの例として、カスタマイズ可能な AWS Cloud Development Kit (AWS CDK) のサンプルコードを GitHub リポジトリで公開しています。

このソリューションは、多数のリージョンとアカウントで実行される SageMaker Pipelines の実行状況を、単一のインターフェースから詳細かつほぼリアルタイムに可視化することを目的としています。これにより、日々の運用業務を効率化できます。次節では、本ソリューションのアーキテクチャについて詳しく解説します。

ソリューション概要

本ソリューションは、複数の AWS アカウントおよびリージョンで稼働する SageMaker Pipelines の状況を一元監視できる、対話型の CloudWatch ダッシュボードを実装しています。

イベント駆動型のサーバーレスアーキテクチャを採用し、SageMaker Pipeline のイベント発生時にリアルタイムで対応します。常時稼働する監視システムやポーリング機構によるオーバーヘッドを排除しました。マネージドサービスやサーバーレスサービスの活用、およびネイティブなサービス連携により、初期コストと運用負荷の削減も図っています。

実装はハブ・アンド・スポークモデルを採用しています。監視を主要なアカウントとリージョンに集約することで複雑さを軽減し、各従属アカウントやリージョンには軽量コンポーネントを設置して Amazon SageMaker Pipelines のデータを収集し、監視ハブへ転送する仕組みです。

図に示されたソリューションは、モジュール化されたコンポーネントで構成されており、主に 2 つの AWS CloudFormation スタックから成り立っています。それが「ダッシュボードスタック」と「フォワーダースタック」です。

ダッシュボードスタックには、データ処理と可視化に必要な Amazon CloudWatch ダッシュボード、Amazon DynamoDB の保存テーブル、および AWS Lambda 関数が含まれています。これは監視ハブとして機能する主要なアカウントとリージョンにのみデプロイされます。

フォワーダースタックは、SageMaker Pipeline データのソースとなる監視対象の各アカウントに展開されます。これらの軽量スタックは Amazon EventBridge を活用して、加工されたデータを監視ハブへ送信します。

これら 2 つのスタックを組み合わせることで、以下のワークフローを通じて集約された情報を収集・処理し、ユーザーに対して表示することが可能になります：

SageMaker Pipeline の各ステップの状態が変更されると、Amazon SageMaker AI がイベントを生成します。このイベントには、発生時刻やパイプラインの ARN（Amazon Resource Name）、実行 ID、ステップの状態といったメタデータが含まれています。

これらのイベントは Amazon EventBridge ルールによってリアルタイムで捕捉され、処理のために AWS Lambda 関数へ転送されます。

Lambda 関数はイベントデータを解析し、パイプラインの実行ステータスや表示名などの追加情報を付加してエンリッチ化します。その後、ローカルの EventBridge バスへ送信されます。

カスタム EventBridge ルールがこの enriched データを捕捉し、監視用ハブアカウントへ転送します。

AWS Identity and Access Management (IAM) ロールとリソースポリシーが、アカウント間でのイベント転送を安全に保護しています。

監視アカウント内の別の EventBridge ルールが Lambda 関数をトリガーし、各 SageMaker Pipeline の実行情報を取り込んで DynamoDB テーブルへ保存します。保存されるデータには、リージョンやアカウント ID、作成時刻、開始・終了時刻、表示名、そしてパイプライン全体および各ステップの状態などが含まれます。

Lambda 関数がダッシュボードのバックエンドを支え、DynamoDB テーブルからデータを読み込んで整形された HTML を返します。

ユーザーが AWS マネジメントコンソール内で操作できるカスタムウィジェットを備えた Amazon CloudWatch ダッシュボードがフロントエンドとして機能します。ここでは、各 SageMaker Pipeline の実行状況が、対応するアカウント ID、リージョン、作成時刻、現在のステータスとともに表示されます。ユーザーはパイプライン名でデータをフィルタリングしたり、単一の実行に関する詳細情報にアクセスしたりできます。詳細情報には、ステップ名、タイプ、開始・終了時刻、ステータスなどが含まれます。

ダッシュボードのユーザーから異常な活動が検知された場合、CloudWatch がアラームをトリガーします。その後、Amazon Simple Notification Service (SNS) 経由で購読者へ通知が送信されます。この SNS トピックは、顧客管理型の AWS Key Management Service (KMS) キーを用いて暗号化されています。アラームは、ウィジェットから各 Lambda 関数への呼び出し回数がダッシュボードスタックで定義した閾値を超えた際に発令されます。

本ソリューションは、サーバーレスかつイベント駆動のハブ・アンド・スポーク型アーキテクチャを採用し、SageMaker Pipeline の跨アカウント・跨リージョンな観測性を提供する単一のダッシュボードを実現することを目的としています。

この監視ソリューションのデータは、SageMaker AI のイベントと API 呼び出しから取得されます。取得したデータを加工してパイプラインの実行状況を包括的に把握し、中央集約された DynamoDB テーブルに保存した後、カスタム CloudWatch ダッシュボードに表示します。

ダッシュボードの機能を拡張したい場合は、Lambda 関数を利用して追加情報を取得・処理し、それを DynamoDB に格納する仕組みを追加できます。

次節では、このソリューションをデプロイする方法について解説します。

事前準備

以下の環境とリソースが整っている必要があります。

• AWS CDK のブートストラップが完了しているリージョンが少なくとも 2 つ含まれる AWS アカウント 1 つ。一方のリージョンで監視ダッシュボードをホストし、もう一方のリージョンからクロスリージョンの SageMaker Pipelines イベントを生成してダッシュボードに表示させます。
• クロスアカウントイベントを生成し、それをダッシュボードに表示させるための、ブートストラップ済みのリージョンが少なくとも 1 つ含まれる AWS アカウント 2 つ目。
• 本ソリューションをデプロイするための十分な権限を持つ AWS 認証情報（シェル環境変数として設定）。
• Python（バージョン 3.14 以降）。
• AWS CDK のインストール済み（バージョン 2.1100.1 以降）。
• AWS CLI のインストール済み（バージョン 2.32.12 以降）。
• Lambda 関数のパッケージングに必要な Docker。
• 各アカウントとリージョンの組み合わせにおいて、少なくとも 1 つの SageMaker Pipeline が存在すること。既存のパイプラインがない場合は、Amazon SageMaker AI ドメイン内の SageMaker Studio から「SageMaker AI Projects」を使用して作成できます。

ソリューションのデプロイ

前提条件を満たしたら、以下の手順を実行してソリューションをデプロイします。

• GitHub リポジトリをクローンする
• README ファイルに記載された詳細なデプロイ手順に従い、AWS CDK と AWS CLI を使用してスタックを展開する
• 各アカウントとリージョンの AWS CloudFormation コンソールに移動し、「DashboardStack」または「ForwarderStack」を選択します。これにより、展開内容や作成されたリソースの詳細を確認できます。

これでソリューションがデプロイされましたので、機能テストを行うことができます。次章では、その能力を検証する方法を解説します。

ソリューションのテスト

ソリューションをデプロイした後、ダッシュボードの機能をテストするために以下の手順を実行してください。SageMaker Studio から パイプラインの作成 や 実行の起動 の両方に対応しています。

Amazon CloudWatch コンソールで、ナビゲーションペインから「ダッシュボード」を選択します。

次に、「PipelineMonitoringDashboard」という名前のダッシュボードをクリックしてください。

実行を促すプロンプトが表示されたら、Lambda 関数の実行を許可します。ベストプラクティスに従い、関数名に customWidget が含まれていることを確認しておきましょう。これでダッシュボードが更新され、以下の画像のような表示になります。

もし直近の SageMaker Pipeline の実行履歴がない場合は、監視対象のアカウントとリージョンで新しいパイプラインの実行を開始してください。まずはシンプルにするため、ダッシュボードと同じアカウントとリージョンから実行するのがおすすめです。

ダッシュボードに戻り、ウィジェットの右上にある「更新」ボタンをクリックして結果を再読み込みします。すると、新しい SageMaker Pipeline の実行ステータスが反映されているはずです。また、ダッシュボード上部のバーを使って、パイプラインの実行が含まれる時間範囲を選択することも忘れないでください。

次に、「ステップ詳細」ボタンをクリックします。先ほどと同様に、カスタムウィジェット用の Lambda 関数の実行を許可してください。ポップアップ画面には、以下の画像に示すように、個々の SageMaker Pipeline ステップに関する詳細情報が表示されます。

• ダッシュボード上部の日付範囲設定を活用して、カスタム日付範囲内の SageMaker Pipeline 実行をフィルタリングできます。選択した時間範囲内でのみ実行履歴が表示されるはずです。

• ウィジェット左上の「Pipeline 名」フィルターを使用します。特定の SageMaker Pipeline の名前を入力し、ウィジェットを更新すれば、検索条件に一致するパイプラインの実行履歴のみを表示できます。

ベストプラクティスと考慮事項

このような監視ソリューションを実装する際は、信頼性やセキュリティの向上、運用効率の改善、あるいは組織のニーズに合わせたカスタマイズを実現するために、以下の推奨事項を参考にしてください。

柔軟性とカスタマイズ性：Lambda 関数を通じて DynamoDB テーブルに追加データを格納したり、可視化ロジックを追加することで、カスタムダッシュボードをさらに充実させることができます。また、フィルタやメトリクス、インタラクティブなポップアップ、組み込みの CloudWatch ウィジェットを追加して、ML ワークロードの監視範囲を広げたり統合したりすることも可能です。さらに、このソリューションは AWS Step Functions のステートマシン実行、AWS Batch や AWS Glue でのジョブ、ML ワークロードをサポートする Amazon EMR クラスターの監視にも拡張できます。そのような場合は、監視トラフィックを他のイベントから隔離するために、専用の EventBridge イベントバスを作成することを検討してください。

メトリクスとアラーム：SageMaker Pipeline は複数のレイヤーで監視しましょう。サービスイベントには EventBridge ルールを、ML ジョブの実行ログには CloudWatch のログ異常検出を、リソース利用率には CloudWatch メトリクスを使用します。ログやメトリクス、あるいは直接のイベント通知に対して追加アラームを設定し、Amazon SNS を経由してチームにアラートを送信できるようにしておきましょう。

ダッシュボードへのアクセスとカスタマイズ：AWS マネジメントコンソールを経由せずに、より迅速なアクセスを可能にするために、CloudWatch ダッシュボードを共有する異なる方法を検討してください。また、データ可視化の代替手段として Amazon Managed Grafana の利用も選択肢の一つです。

プライベートネットワーク：セキュリティ要件が厳しい組織では、ソリューションを Amazon VPC（仮想プライベートクラウド）内にデプロイして隔離性を高めることを検討してください。VPC ピアリング接続や AWS Transit Gateway を使用すれば、リージョンやアカウントを超えて VPC を接続することも可能です。

CI/CD との統合：より高い信頼性を実現するために、ML ワークロードを実行する各環境に対して CI/CD パイプラインでソリューションをデプロイしましょう。具体的には、AWS Organizations や AWS Deployment Framework (ADF) を活用すれば、すべての環境で一貫性があり再現性の高いデプロイが可能になります。

リソースのクリーンアップ

デプロイした各アカウントとリージョンの組み合わせに対して、リソースを削除するには、CloudFormation サービスコンソール にアクセスし、「DashboardStack」または「ForwarderStack」のスタックを削除してください。

あるいは、以前実行した AWS CDK コマンドを同じ認証情報と CLI 引数で再度実行する代わりに、cdk deploy を cdk destroy に置き換えて実行する方法もあります。

なお、このソリューションのテスト目的のみで作成した場合は、各アカウントおよびリージョン内の SageMaker プロジェクト、リソース、そして SageMaker AI ドメインのインスタンス も忘れずに削除してください。

結論

今回は、AWS アカウント間およびリージョン間で SageMaker Pipelines を監視し、運用効率を向上させるためのソリューション構築方法を紹介しました。この仕組みは、インタラクティブな CloudWatch ダッシュボードを活用してリアルタイムで更新情報を提供し、AWS マネジメントコンソールと直接連携します。さらに、スケーラビリティを高めるために、サーバーレスかつイベント駆動型のアーキテクチャを採用しています。

このソリューションをさらに組織の基準に合わせて調整し、クラウドへの移行を加速したい場合は、AWS Professional Services のサポートを活用してください。

MLOps のベストプラクティスについては、以下のリソースもご参照ください。