Chi distribuisce workload di machine learning su più account e Region AWS conosce il problema: SageMaker Studio offre monitoring per SageMaker Pipelines all’interno di un singolo account e di una singola Region. Se le pipeline sono sparse su sei ambienti, controllarne lo stato significa cambiare account e Region a mano, ogni volta. AWS ha pubblicato una soluzione di riferimento per centralizzare quella visibilità in una dashboard CloudWatch, con un esempio CDK personalizzabile su GitHub.
Come è costruita
L’architettura è serverless ed event-driven — niente polling, niente sistemi di monitoring always-on — e segue un modello hub-and-spoke con due stack CloudFormation.
Il Dashboard stack viene deployato solo nell’account e nella Region primari, che fanno da hub: contiene la dashboard CloudWatch, le tabelle DynamoDB e le funzioni Lambda per il processing e la visualizzazione. Il Forwarder stack è leggero e va negli account monitorati: usa EventBridge per inviare i dati arricchiti verso l’hub.
Il flusso è lineare. Quando uno step di una pipeline cambia stato, SageMaker AI genera un evento con metadati come timestamp, ARN della pipeline e dell’esecuzione, e stato dello step. Le rule EventBridge intercettano l’evento e lo passano a Lambda, che lo arricchisce — per esempio con lo stato o il display name dell’esecuzione — e lo rimette sul bus locale. Rule custom inoltrano poi il dato all’account hub, con la trasmissione cross-account protetta da ruoli IAM e resource policy. Nell’hub, un’altra Lambda ingerisce il dato e lo scrive su DynamoDB: Region, account ID, tempi di creazione, avvio e fine, display name e stato di ogni esecuzione e dei singoli step.
Il front-end è la dashboard CloudWatch con custom widget: Lambda ne alimentano il backend leggendo DynamoDB e restituendo HTML formattato. L’utente resta dentro la console AWS, può filtrare per nome della pipeline e per intervallo temporale, e aprire il dettaglio degli step di una singola esecuzione. Un allarme CloudWatch collegato a un topic SNS cifrato con chiave KMS gestita dal cliente scatta quando le chiamate ai widget superano le soglie definite nello stack.
Cosa considerare prima di adottarla
I prerequisiti non sono banali: due account AWS, tre combinazioni account/Region con bootstrap CDK, Python 3.14 o successivo, CDK 2.1100.1 o successivo, AWS CLI 2.32.12 o successivo, Docker per il packaging delle Lambda, e almeno una pipeline per ogni combinazione.
La soluzione è estendibile: AWS suggerisce di aggiungere dati nelle Lambda che popolano DynamoDB, di coprire anche Step Functions, AWS Batch, Glue o cluster EMR, e in quel caso di creare un event bus EventBridge dedicato per isolare il traffico di monitoring. Fra le raccomandazioni anche il deploy in VPC per requisiti di isolamento stringenti e Amazon Managed Grafana come alternativa di visualizzazione.
In sintesi
- Architettura hub-and-spoke serverless: Dashboard stack nell’account hub, Forwarder stack leggero negli account monitorati.
- Gli eventi SageMaker passano da EventBridge e Lambda, vengono arricchiti e persistiti su DynamoDB, poi letti da custom widget CloudWatch.
- Estendibile ad altri servizi (Step Functions, Batch, Glue, EMR), con event bus dedicato consigliato per isolare il traffico di monitoring.
Fonte: Monitor Amazon SageMaker Pipelines cross-account with custom Amazon CloudWatch dashboards — https://aws.amazon.com/blogs/machine-learning/monitor-amazon-sagemaker-pipelines-cross-account-with-custom-amazon-cloudwatch-dashboards/
Hai qualcosa da aggiungere? Unisciti alla discussione.