MLAMLワークフローのデプロイとオーケストレーション複数選択
あるMLチームは SageMaker Pipelines を使用した ML パイプラインを本番環境で運用しています。
新しいデータが S3 バケットに到着するたびに自動的にパイプラインを実行したいと考えています。また、パイプラインの実行状況をモニタリングして失敗時にアラートを送信する仕組みも必要です。
最小限の開発工数でこの要件を満たす構成として、正しいものをすべて選択してください。
AAmazon EventBridge ルールを使用して S3 の PutObject イベントをトリガーとし、SageMaker Pipelines の StartPipelineExecution API を呼び出す Lambda 関数を起動する
✓ 正解
EventBridge の S3 PutObject イベントをトリガーとして Lambda 関数を起動し、SageMaker Pipelines の StartPipelineExecution API を呼び出す構成は、S3 到着トリガーの標準的な実装パターンです。
BSageMaker Pipelines 自体に S3 イベントトリガー機能があるため、コンソールから直接 S3 バケットとプレフィックスを指定して到着時の自動パイプライン実行を設定する
SageMaker Pipelines 自体に S3 イベントトリガー機能は存在しません。コンソールから直接 S3 バケットを指定する設定項目はなく、EventBridge や Lambda などの外部サービスとの連携が必要です。
CAmazon EventBridge を使用して SageMaker Pipelines の実行ステータス変化(Execution Status Change)イベントを検知し、失敗時に SNS トピックを通じてアラートを送信する
✓ 正解
EventBridge は SageMaker Pipelines の実行ステータス変化イベントをネイティブに検知できます。失敗イベントを SNS トピックにルーティングすることで、低遅延かつ最小工数でアラートを実装できます。
DCloudWatch Logs のパイプライン実行ログを Lambda 関数で定期的にポーリングし、エラーパターンを検出した場合に SNS トピック経由でアラートを送信する
CloudWatch Logs のポーリングは Lambda 関数の定期実行が必要で遅延も大きく、EventBridge のイベント駆動方式と比べて開発工数が増加します。最小工数という要件を満たしません。
EAmazon S3 イベント通知を Amazon SQS キューに送信し、SageMaker Pipelines のコンソール「Trigger」設定で当該 SQS キューを直接パイプライントリガーとして指定して自動起動する。失敗監視は CloudWatch メトリクスアラームで実行失敗を検知して SNS 通知する
SageMaker Pipelines のコンソールには SQS キューを直接パイプライントリガーとして指定する機能はなく、EventBridge や Lambda 等との連携が別途必要です。また実行失敗の検知は EventBridge のステータス変化イベントがネイティブサポートされており、CloudWatch メトリクスアラームより低工数で実装できます。
解説
EventBridge と Lambda を組み合わせた S3 到着トリガーと、EventBridge による SageMaker Pipelines ステータスイベント検知の組み合わせが、最小工数で両要件を満たす標準的な構成です。
選択肢A は EventBridge の S3 PutObject イベントを Lambda 経由で StartPipelineExecution API に転送する、S3 到着トリガーの標準的な実装パターンです。
選択肢B は SageMaker Pipelines 自体には S3 イベントトリガー機能が存在しないため誤りです。外部トリガーとして EventBridge などとの連携が必要です。
選択肢C は EventBridge が SageMaker Pipelines の実行ステータス変化イベントをネイティブに検知できるため、Lambda ポーリングよりも低遅延かつシンプルにアラートを実装できます。
選択肢D は CloudWatch Logs を Lambda で定期ポーリングする方式は遅延が大きく開発工数も増えるため、最小工数という要件を満たしません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでMLAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →