Modelo operativo - SageMaker Mejores prácticas de administración de Studio

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Modelo operativo

Un modelo operativo es una infraestructura que combina las personas, los procesos y las tecnologías para ayudar a una organización a ofrecer valor empresarial de manera escalable, coherente y eficiente. El modelo operativo de machine learning proporciona un proceso de desarrollo de productos estándar para los equipos de toda la organización. Hay tres modelos para implementar el modelo operativo, según el tamaño, la complejidad y los factores que impulsan el negocio:

  • Equipo de ciencia de datos centralizado: en este modelo, todas las actividades de ciencia de datos se centralizan en un solo equipo u organización. Esto es similar al modelo del Centro de excelencia (COE), donde todas las unidades de negocio recurren a este equipo para realizar proyectos de ciencia de datos.

  • Equipos de ciencia de datos descentralizados: en este modelo, las actividades de ciencia de datos se distribuyen en diferentes funciones o divisiones comerciales, o en función de diferentes líneas de productos.

  • Equipos de ciencia de datos federados: en este modelo, las funciones de servicios compartidos como, por ejemplo, los repositorios de código, los procesos de integración y entrega continuas (CI/CD), etc., están administradas por un equipo centralizado, y cada unidad de negocio o función a nivel de producto está administrada por equipos descentralizados. Esto es similar al modelo en estrella, donde cada unidad de negocio tiene sus propios equipos de ciencia de datos; sin embargo, estos equipos de unidades de negocio coordinan sus actividades con el equipo centralizado.

Antes de decidir lanzar su primer dominio de estudio para casos de uso de producción, tenga en cuenta el modelo operativo y las prácticas recomendadas de AWS para organizar su entorno. Para obtener más información, consulte Organización de su entorno de AWS con varias cuentas.

La siguiente sección proporciona orientación sobre cómo organizar la estructura de la cuenta para cada uno de los modelos operativos.

En esta sección, presentamos brevemente una estructura contable de modelo operativo con la que puede empezar y modificar de acuerdo con los requisitos operativos de su organización. Independientemente del modelo operativo que elija, le recomendamos implementar las siguientes prácticas recomendadas comunes:

  • Utilice AWS Control Tower para configurar, administrar y gobernar sus cuentas.

  • Centralice sus identidades con su proveedor de identidades (IdP) y AWS IAM Identity Center con una cuenta Securitiy Tooling de administrador delegado y permita el acceso seguro a las cargas de trabajo.

  • Ejecute cargas de trabajo de machine learning con aislamiento a nivel de cuenta en todas las cargas de trabajo de desarrollo, prueba y producción.

  • Transmita los registros de las cargas de trabajo de machine learning a una cuenta de archivo de registros y, a continuación, filtre y aplique el análisis de registros en una cuenta de observabilidad.

  • Ejecute una cuenta de gobierno centralizada para aprovisionar, controlar y auditar el acceso a los datos.

  • Integre los servicios de seguridad y gobierno (SGS) con las barreras de protección y detección adecuadas en cada cuenta para garantizar la seguridad y la conformidad, según los requisitos de su organización y su carga de trabajo.

Estructura de cuentas de modelo centralizado

En este modelo, el equipo de la plataforma de machine learning es responsable de proporcionar:

  • Una cuenta de herramientas de servicios compartidos que aborda los requisitos de Machine Learning Operations (MLOp) de los equipos de ciencia de datos.

  • Cuentas de desarrollo, prueba y producción de cargas de trabajo de machine learning que se comparten entre los equipos de ciencia de datos.

  • Políticas de gobierno para garantizar que cada carga de trabajo de equipo de ciencia de datos se ejecute de forma aislada.

  • Prácticas recomendadas comunes.

Un diagrama que muestra la estructura de cuentas de un modelo operativo centralizado.

Estructura de cuentas de un modelo operativo centralizado

Estructura de cuentas de modelo descentralizado

En este modelo, cada equipo de machine learning opera de forma independiente para aprovisionar, administrar y gobernar las cuentas y los recursos de machine learning. Sin embargo, recomendamos que los equipos de machine learning utilicen un enfoque centralizado de modelo de observabilidad y gobernanza de datos para simplificar la gobernanza de los datos y la administración de las auditorías.

Un diagrama que describe la estructura de cuentas de un modelo operativo descentralizado.

Estructura de cuentas de modelo operativo descentralizado

Estructura de cuentas de modelo federado

Este modelo es similar al modelo centralizado; sin embargo, la diferencia clave es que cada equipo de ciencia de datos y machine learning tiene su propio conjunto de cuentas de carga de trabajo de desarrollo/prueba/producción, que permiten un aislamiento físico sólido de sus recursos de machine learning y, además, habilitan el escalado independiente de cada equipo sin afectar a los demás.

Un documento que describe la estructura de cuentas de un modelo operativo federado.

Estructura de cuentas de modelo operativo federado

Multitenencia de plataforma de ML

La multitenencia es una arquitectura de software donde una sola instancia de software puede atender a varios grupos de usuarios distintos. Un inquilino es un grupo de usuarios que comparten un acceso común con privilegios específicos a la instancia de software. Por ejemplo, si está creando varios productos de machine learning, cada equipo de producto con requisitos de acceso similares puede considerarse un inquilino o un equipo.

Aunque es posible implementar varios equipos dentro de una instancia de SageMaker Studio (por ejemplo, un Dominio de SageMaker), sopese las ventajas y desventajas como el radio de alcance, la atribución de costos y los límites a nivel de cuenta cuando agrupe varios equipos en un único dominio de SageMaker Studio. Obtenga más información sobre las ventajas/desventajas y las prácticas recomendadas en las siguientes secciones.

Si necesita un aislamiento absoluto de los recursos, considere la posibilidad de implementar dominios de SageMaker Studio para cada inquilino en una cuenta diferente. En función de sus requisitos de aislamiento, puede implementar varias líneas de negocio (LOB) como varios dominios dentro de una sola cuenta y región. Utilice los espacios compartidos para una colaboración prácticamente en tiempo real entre los miembros del mismo equipo/LOB. Con varios dominios, seguirá utilizando los permisos y las políticas de Identity and Access Management (IAM) para garantizar el aislamiento de los recursos.

Los recursos de SageMaker creados a partir de un dominio se etiquetan automáticamente con el Nombre de recurso de Amazon (ARN) del dominio y el perfil de usuario o el ARN del espacio para facilitar el aislamiento de los recursos. Para ver ejemplos de políticas, consulte la documentación sobre el aislamiento de recursos del dominio. Aquí puede ver la referencia detallada sobre cuándo usar una estrategia de múltiples cuentas o múltiples dominios, junto con las comparaciones de características en la documentación, y ver ejemplos de scripts para reponer etiquetas para los dominios existentes en el repositorio de GitHub.

Por último, puede implementar una implementación de autoservicio de los recursos de SageMaker Studio en varias cuentas utilizando AWS Service Catalog. Para obtener más información, consulte Administrar productos de AWS Service Catalog en varias Cuentas de AWS y Regiones de AWS.