Cree flujos de trabajo de aprendizaje automático repetibles, seguros y extensibles de extremo a extremo con Kubeflow en AWS

Esta es una publicación de blog invitado coescrita con athenahealth.

athenahealth un proveedor líder de software y servicios de red para grupos médicos y sistemas de salud en todo el país. Sus registros de salud electrónicos, la gestión del ciclo de ingresos y las herramientas de participación del paciente permiten el acceso en cualquier momento y en cualquier lugar, lo que genera mejores resultados financieros para sus clientes y permite que sus clientes proveedores brinden una atención de mejor calidad.

En el espacio de la inteligencia artificial (IA), athenahealth utiliza la ciencia de datos y el aprendizaje automático (ML) para acelerar los procesos comerciales y proporcionar recomendaciones, predicciones y conocimientos en múltiples servicios. Desde su primera implementación en servicios de documentos automatizados, el procesamiento sin contacto de millones de documentos entre proveedores y pacientes, hasta su trabajo más reciente en asistentes virtuales y la mejora del rendimiento del ciclo de ingresos, athenahealth continúa aplicando IA para ayudar a impulsar la eficiencia, las capacidades de servicio y mejores resultados para los proveedores. y sus pacientes.

Esta publicación de blog demuestra cómo athenahealth utiliza Kubeflow en AWS (una distribución de Kubeflow específica de AWS) para crear y optimizar un flujo de trabajo de ciencia de datos integral que conserva las herramientas esenciales, optimiza la eficiencia operativa, aumenta la productividad de los científicos de datos y sienta las bases para ampliar sus capacidades de aprendizaje automático con mayor facilidad.

Kubeflow es la plataforma de ML de código abierto dedicada a hacer que las implementaciones de flujos de trabajo de ML en Kubernetes sean simples, portátiles y escalables. Kubeflow logra esto mediante la incorporación de herramientas de código abierto relevantes que se integran bien con Kubernetes. Algunos de estos proyectos incluyen Argo para orquestación de canalizaciones, Istio para malla de servicios, Jupyter para portátiles, Spark, TensorBoard y Katib. Kubeflow Pipelines ayuda a crear e implementar flujos de trabajo de aprendizaje automático escalables y portátiles que pueden incluir pasos como extracción de datos, preprocesamiento, entrenamiento de modelos y evaluación de modelos en forma de canalizaciones repetibles.

AWS está contribuyendo a la comunidad de Kubeflow de código abierto al proporcionar su propia distribución de Kubeflow (llamada Kubeflow en AWS) que ayuda a organizaciones como athenahealth a crear flujos de trabajo de aprendizaje automático altamente confiables, seguros, portátiles y escalables con una sobrecarga operativa reducida a través de la integración con los servicios administrados de AWS. AWS ofrece varias opciones de implementación de Kubeflow, como la implementación con Cognito Amazonas, despliegue con Servicio de base de datos relacional de Amazon (Amazon RDS) y Servicio de almacenamiento simple de Amazon (Amazon S3) e implementación estándar. Para obtener detalles sobre la integración de servicios y los complementos disponibles para cada una de estas opciones, consulte Despliegue.

Actualmente, Kubeflow en AWS proporciona una ruta clara para usar Kubeflow, aumentada con los siguientes servicios de AWS:

Muchos clientes de AWS aprovechan la distribución de Kubeflow en AWS, incluido athenahealth.

Aquí, el equipo de MLOps de athenahealth analiza los desafíos que encontraron y las soluciones que crearon en su proceso de Kubeflow.

Desafíos con el entorno ML anterior

Antes de nuestra adopción de Kubeflow en AWS, nuestros científicos de datos usaban un conjunto estandarizado de herramientas y un proceso que permitía flexibilidad en la tecnología y el flujo de trabajo utilizados para entrenar un modelo determinado. Los componentes de ejemplo de las herramientas estandarizadas incluyen una API de ingesta de datos, herramientas de análisis de seguridad, la canalización de CI/CD creada y mantenida por otro equipo dentro de athenahealth, y una plataforma de servicio común creada y mantenida por el equipo de MLOps. Sin embargo, a medida que maduró nuestro uso de IA y ML, creció la variedad de herramientas e infraestructura creadas para cada modelo. Aunque todavía pudimos apoyar el proceso existente, vimos los siguientes desafíos en el horizonte:

• Mantenimiento y crecimiento – Reproducir y mantener entornos de entrenamiento de modelos requirió más esfuerzo a medida que aumentaba la cantidad de modelos implementados. Cada proyecto mantuvo una documentación detallada que describía cómo se utilizó cada script para construir el modelo final. En muchos casos, este fue un proceso elaborado que involucró de 5 a 10 guiones con varios resultados cada uno. Estos tenían que ser rastreados manualmente con instrucciones detalladas sobre cómo se usaría cada salida en procesos posteriores. Mantener esto a lo largo del tiempo se volvió engorroso. Además, a medida que los proyectos se volvían más complejos, también aumentaba el número de herramientas. Por ejemplo, la mayoría de los modelos utilizaban Spark y TensorFlow con GPU, lo que requería una mayor variedad de configuraciones de entorno. Con el tiempo, los usuarios cambiaban a versiones más nuevas de las herramientas en sus entornos de desarrollo, pero luego no podían ejecutar scripts más antiguos cuando esas versiones se volvían incompatibles. En consecuencia, mantener y aumentar los proyectos más antiguos requería más tiempo y esfuerzo de ingeniería. Además, a medida que nuevos científicos de datos se unieron al equipo, las transferencias de conocimientos y la incorporación tomaron más tiempo, porque la sincronización de entornos locales incluía muchas dependencias no documentadas. El cambio entre proyectos enfrentaba los mismos problemas porque cada modelo tenía sus propios flujos de trabajo.
• Seguridad – Nos tomamos la seguridad en serio y, por lo tanto, priorizamos el cumplimiento de todas las obligaciones contractuales, legales y reglamentarias asociadas con el ML y la ciencia de datos. Los datos deben utilizarse, almacenarse y accederse a ellos de maneras específicas, y hemos integrado procesos sólidos para garantizar que nuestras prácticas cumplan con nuestras obligaciones legales y se alineen con las mejores prácticas de la industria. Antes de la adopción de Kubeflow, garantizar que los datos se almacenaran y se accediera a ellos de una manera específica implicaba una verificación regular en múltiples y diversos flujos de trabajo. Sabíamos que podíamos mejorar la eficiencia al consolidar estos diversos flujos de trabajo en una sola plataforma. Sin embargo, esa plataforma tendría que ser lo suficientemente flexible para integrarse bien con nuestras herramientas estandarizadas.
• Operaciones – También vimos una oportunidad para aumentar la eficiencia operativa y la gestión mediante la centralización del registro y la supervisión de los flujos de trabajo. Debido a que cada equipo había desarrollado sus propias herramientas, recopilamos esta información de cada flujo de trabajo individualmente y la agregamos.

El equipo de ciencia de datos evaluó varias soluciones para consolidar los flujos de trabajo. Además de abordar estos requisitos, buscamos una solución que se integrara perfectamente con la infraestructura y las herramientas estandarizadas existentes. Seleccionamos Amazon EKS y Kubeflow en AWS como nuestra solución de flujo de trabajo.

El ciclo de desarrollo del científico de datos que incorpora Kubeflow

Un proyecto de ciencia de datos comienza con una pizarra limpia: sin datos, sin código, solo el problema comercial que se puede resolver con ML. La primera tarea es una prueba de concepto (POC) para descubrir si los datos tienen suficiente señal para hacer que un modelo de ML sea efectivo para resolver el problema comercial, comenzando con la consulta del conjunto de datos sin procesar de nuestro almacén de datos Snowflake. Esta etapa es iterativa y los científicos de datos usan pods de Kubernetes o cuadernos Kubeflow Jupyter durante este proceso.

Nuestro clúster de Kubeflow utiliza el escalador automático de clústeres de Karpenter, lo que facilita la activación de recursos para los científicos de datos, ya que solo deben centrarse en definir los tipos de instancia deseados, mientras que el trabajo de aprovisionamiento lo realiza un conjunto de aprovisionadores de Karpenter predefinidos. Tenemos aprovisionadores separados para tipos de instancias de CPU y GPU, y todas las instancias admitidas por Amazon EKS se encuentran en una de estas dos categorías según nuestra configuración de aprovisionamiento. Los científicos de datos eligen tipos de instancias mediante selectores de nodos y Karpenter se encarga de la gestión del ciclo de vida de los nodos.

Una vez que se desarrolla la consulta, los científicos de datos extraen los datos sin procesar a una ubicación en Amazon S3 y luego inician un cuaderno Jupyter desde la interfaz de usuario de AWS Kubeflow para explorar los datos. El objetivo es crear el conjunto de funciones que se utilizará para entrenar el primer modelo. Esto permite a los científicos de datos determinar si hay suficiente señal en los datos para satisfacer las necesidades comerciales del cliente.

Una vez que los resultados son satisfactorios, los científicos de datos pasan a la siguiente etapa del ciclo de desarrollo y convierten sus descubrimientos en una tubería sólida. Convierten el código POC en código de calidad de producción que se ejecuta a escala. Para garantizar el cumplimiento mediante el uso de bibliotecas aprobadas, se crea un contenedor con la imagen base de Docker adecuada. Para nuestros científicos de datos, hemos descubierto que proporcionar una imagen base estándar de Python, TensorFlow y Spark brinda suficiente flexibilidad para la mayoría de las cargas de trabajo, si no para todas. Luego pueden usar el Dockerfile de su componente para personalizar aún más su entorno de desarrollo. Este Dockerfile luego es utilizado por el proceso de CI/CD para construir la imagen de los componentes que se usará en la producción, manteniendo así la coherencia entre los entornos de desarrollo y producción.

Tenemos una herramienta que brinda a los científicos de datos la capacidad de lanzar su entorno de desarrollo en un pod que se ejecuta en Kubernetes. Cuando este pod se está ejecutando, los científicos de datos pueden adjuntar el IDE de Visual Studio Code directamente al pod y depurar su código de modelo. Una vez que el código se ejecuta correctamente, pueden enviar sus cambios a git y se crea un nuevo entorno de desarrollo con los cambios más recientes.

La tubería de ciencia de datos estándar consta de etapas que incluyen extracción, preprocesamiento, capacitación y evaluación. Cada etapa de la canalización aparece como un componente en Kubeflow, que consiste en un pod de Kubernetes que ejecuta un comando con cierta información pasada como parámetros. Estos parámetros pueden ser valores estáticos o referencias a la salida de un componente anterior. La imagen de Docker utilizada en el pod se crea a partir del proceso de CI/CD. Los detalles sobre este proceso aparecen en el flujo de trabajo de CI/CD que se analiza en la siguiente sección.

Ciclo de desarrollo en Kubeflow. El flujo de trabajo de desarrollo comienza a la izquierda con el POC. El modelo completo se implementa en la plataforma de servicio de modelos athenahealth que se ejecuta en Amazon ECS.

Proceso de CI/CD compatible con flujos de trabajo automatizados

Como parte de nuestro proceso de CI/CD, usamos Jenkins para compilar y probar todas las imágenes de los componentes de Kubeflow en paralelo. Al completarse con éxito, la plantilla del componente de canalización contiene punteros de referencia a las imágenes y la canalización resultante se carga en Kubeflow. Los parámetros en la canalización de Jenkins permiten a los usuarios iniciar las canalizaciones y ejecutar sus pruebas de entrenamiento de modelos después de compilaciones exitosas.

Alternativamente, para mantener un ciclo de desarrollo corto, los científicos de datos también pueden lanzar la tubería desde su máquina local, modificando los parámetros de la tubería con los que puedan estar experimentando.

Existen herramientas para garantizar que los punteros de referencia de la compilación de CI/CD se utilicen de forma predeterminada. Si hay un artefacto implementable en el repositorio, la lógica de CI/CD continuará implementando el artefacto en la plataforma de servicio del modelo athenahealth (el servicio de predicción) que se ejecuta en Amazon ECS con AWS Fargate. Una vez que han pasado todas estas etapas, el científico de datos fusiona el código con la rama principal. Luego, las canalizaciones y los artefactos implementables se envían a producción.

Flujo de trabajo de implementación de CI/CD. Este diagrama describe el flujo de trabajo de compilación e implementación de Data Science. El proceso de CI/CD está impulsado por Jenkins.

Seguridad

Al consolidar nuestros flujos de trabajo de ciencia de datos, pudimos centralizar nuestro enfoque para asegurar la canalización de capacitación. En esta sección, analizamos nuestro enfoque de la seguridad de datos y clústeres.

Seguridad de los datos

La seguridad de los datos es de suma importancia en athenahealth. Por esta razón, desarrollamos y mantenemos una infraestructura que cumple con las normas y estándares que protegen la seguridad e integridad de estos datos.

Para garantizar que cumplimos con los estándares de cumplimiento de datos, aprovisionamos nuestra infraestructura de AWS de acuerdo con nuestras pautas empresariales de athenahealth. Los dos principales almacenes de datos son Amazon RDS para metadatos de canalización altamente escalables y Amazon S3 para canalizaciones y artefactos de modelo. Para Amazon S3, nos aseguramos de que los depósitos estén encriptados, los puntos finales HTTPS se apliquen y las políticas y Gestión de identidades y accesos de AWS (IAM) siguen los principios de privilegio mínimo al permitir el acceso a los datos. Esto también se aplica a los datos de Amazon RDS: el cifrado siempre está habilitado y los grupos de seguridad y el acceso con credenciales siguen el principio de privilegio mínimo. Esta estandarización garantiza que solo las partes autorizadas tengan acceso a los datos, y se realiza un seguimiento de este acceso.

Además de estas medidas, la plataforma también se somete a evaluaciones de amenazas de seguridad y escaneos continuos de seguridad y cumplimiento.

También abordamos los requisitos de retención de datos a través de la gestión del ciclo de vida de los datos para todos los segmentos de S3 que contienen datos confidenciales. Esta política mueve automáticamente los datos a Glaciar Amazon S3 después de 30 días de la creación. Las excepciones a esto se gestionan a través de solicitudes de recuperación de datos y se aprueban o deniegan caso por caso. Esto garantiza que todos los flujos de trabajo cumplan con la política de retención de datos. Esto también resuelve el problema con la recuperación de datos si un modelo funciona mal y se requiere una nueva capacitación, o cuando se debe evaluar un nuevo modelo contra una iteración histórica del conjunto de datos de un modelo anterior.

Para restringir el acceso a Amazon S3 y Amazon RDS desde Kubeflow en AWS y Amazon EKS, utilizamos IRSA (roles de IAM para cuentas de servicio), que proporciona aprovisionamiento de permisos basado en IAM para recursos dentro de Kubernetes. Cada inquilino en Kubeflow tiene una cuenta de servicio única creada previamente que vinculamos a un rol de IAM creado específicamente para cumplir con los requisitos de acceso del inquilino. El acceso de los usuarios a los arrendatarios también está restringido mediante la pertenencia a grupos de grupos de usuarios de Amazon Cognito para cada usuario. Cuando un usuario se autentica en el clúster, el token generado contiene notificaciones de grupo y Kubernetes RBAC usa esta información para permitir o denegar el acceso a un recurso en particular en el clúster. Esta configuración se explica con más detalle en la siguiente sección.

Seguridad de clúster mediante aislamiento multiusuario

Como señalamos en la sección anterior, los científicos de datos realizan análisis de datos exploratorios, ejecutan análisis de datos y entrenan modelos de ML. Para asignar recursos, organizar datos y administrar flujos de trabajo basados ​​en proyectos, Kubeflow en AWS proporciona aislamiento basado en espacios de nombres de Kubernetes. Este aislamiento funciona para interactuar con la interfaz de usuario de Kubeflow; sin embargo, no proporciona ninguna herramienta para controlar el acceso a la API de Kubernetes mediante Kubectl. Esto significa que el acceso de los usuarios se puede controlar en la interfaz de usuario de Kubeflow, pero no en la API de Kubernetes a través de Kubectl.

La arquitectura que se describe en el siguiente diagrama soluciona este problema unificando el acceso a los proyectos en Kubeflow en función de la pertenencia a grupos. Para lograr esto, aprovechamos los manifiestos de Kubeflow en AWS, que tienen integración con los grupos de usuarios de Amazon Cognito. Además, utilizamos el control de acceso basado en roles (RBAC) de Kubernetes para controlar la autorización dentro del clúster. Los permisos de usuario se aprovisionan en función de la pertenencia al grupo de Amazon Cognito. Esta información se pasa al clúster con el token generado por el cliente OIDC. Este proceso se simplifica gracias a la funcionalidad integrada de Amazon EKS que permite asociar proveedores de identidad OIDC para autenticarse con el clúster.

De forma predeterminada, la autenticación de Amazon EKS la realiza el autenticador de IAM, que es una herramienta que permite la autenticación con un clúster de EKS mediante las credenciales de IAM. Este método de autenticación tiene sus méritos; sin embargo, no es adecuado para nuestro caso de uso porque athenahealth usa Microsoft Azure Active Directory para el servicio de identidad en toda la organización.

Aislamiento del espacio de nombres de Kubernetes. Los científicos de datos pueden obtener membresía en uno o varios grupos según sea necesario para su trabajo. El acceso se revisa periódicamente y se elimina según corresponda.

Azure Active Directory, al ser un servicio de identidad para toda la empresa, es la fuente de la verdad para controlar el acceso de los usuarios al clúster de Kubeflow. La configuración para esto incluye la creación de una aplicación empresarial de Azure que actúa como entidad de servicio y agrega grupos para varios inquilinos que requieren acceso al clúster. Esta configuración en Azure se refleja en Amazon Cognito mediante la configuración de un proveedor de identidad OIDC federado que subcontrata la responsabilidad de autenticación a Azure. El acceso a los grupos de Azure está controlado por SailPoint IdentityIQ, que envía solicitudes de acceso al propietario del proyecto para permitir o denegar según corresponda. En el grupo de usuarios de Amazon Cognito, se crean dos clientes de aplicaciones: uno se utiliza para configurar la autenticación para el clúster de Kubernetes mediante el proveedor de identidad OIDC y el otro para proteger la autenticación de Kubeflow en la interfaz de usuario de Kubeflow. Estos clientes están configurados para pasar notificaciones de grupo tras la autenticación con el clúster, y estas notificaciones de grupo se usan junto con RBAC para configurar la autorización dentro del clúster.

Los enlaces de funciones de RBAC de Kubernetes se configuran entre grupos y la función de clúster Kubeflow-edit, que se crea al instalar Kubeflow en el clúster. Esta vinculación de roles garantiza que cualquier usuario que interactúe con el clúster después de iniciar sesión a través de OIDC pueda acceder a los espacios de nombres para los que tiene permisos, según lo definido en sus notificaciones de grupo. Aunque esto funciona para los usuarios que interactúan con el clúster mediante Kubectl, la interfaz de usuario de Kubeflow actualmente no proporciona acceso a los usuarios en función de la pertenencia al grupo porque no utiliza RBAC. En su lugar, utiliza el recurso de política de autorización de Istio para controlar el acceso de los usuarios. Para superar este desafío, desarrollamos un controlador personalizado que sincroniza a los usuarios mediante el sondeo de los grupos de Amazon Cognito y agrega o elimina los enlaces de roles correspondientes para cada usuario en lugar de por grupo. Esta configuración permite a los usuarios tener el mismo nivel de permisos al interactuar tanto con la interfaz de usuario de Kubeflow como con Kubectl.

Eficiencia operacional

En esta sección, analizamos cómo aprovechamos el código abierto y las herramientas de AWS disponibles para administrar y depurar nuestros flujos de trabajo, así como para minimizar el impacto operativo de la actualización de Kubeflow.

Registro y seguimiento

Para el registro, utilizamos FluentD para enviar todos nuestros registros de contenedores a Servicio Amazon OpenSearch y métricas del sistema a Prometheus. Luego usamos Kibana y la interfaz de usuario de Grafana para buscar y filtrar registros y métricas. El siguiente diagrama describe cómo configuramos esto.

Registro de Kubeflow. Usamos la interfaz de usuario de Grafana y Kibana para ver y revisar los registros

La siguiente captura de pantalla es una vista de la interfaz de usuario de Kibana de nuestra canalización.

Muestra de la vista de la interfaz de usuario de Kibana. Kibana permite vistas personalizadas.

Actualizaciones seguras de clústeres de Kubeflow

A medida que incorporamos a los usuarios a Kubeflow en AWS, mantenemos una experiencia de usuario confiable y consistente al tiempo que permitimos que el equipo de MLOps se mantenga ágil con el lanzamiento e integración de nuevas funciones. En la superficie, Kustomize parece modular para que podamos trabajar y actualizar un componente a la vez sin afectar a otros, lo que nos permite agregar nuevas capacidades con una interrupción mínima para los usuarios. Sin embargo, en la práctica, hay escenarios en los que el mejor enfoque es simplemente activar un nuevo clúster de Kubernetes en lugar de aplicar actualizaciones a nivel de componentes para los clústeres existentes. Encontramos dos casos de uso en los que tenía más sentido crear clústeres completamente nuevos:

• Actualizar a una versión de Kubernetes donde AWS proporciona actualizaciones de clúster en el lugar. Sin embargo, se vuelve difícil probar si cada uno de los recursos de Kubeflow y Kubernetes funciona según lo previsto y si los manifiestos conservan la compatibilidad con versiones anteriores.
• Actualizar Kubeflow a una versión más reciente donde se agregan o modifican varias funciones y casi siempre no es una idea prometedora realizar actualizaciones en el lugar en un clúster de Kubernetes existente.

Al abordar este problema, desarrollamos una estrategia que nos permite tener reemplazos de clúster seguros sin afectar las cargas de trabajo existentes. Para lograr esto, tuvimos que cumplir con los siguientes criterios:

• Separe los recursos informáticos y de almacenamiento de Kubeflow para que los metadatos de canalización, los artefactos de canalización y los datos de usuario se conserven al desaprovisionar el clúster anterior.
• Integre con Kubeflow en los manifiestos de AWS para que cuando se produzca una actualización de la versión de Kubeflow, se requieran cambios mínimos
• Tenga una forma sencilla de revertir si las cosas salen mal después de la actualización del clúster
• Tenga una interfaz simple para promover un clúster candidato a producción

El siguiente diagrama ilustra esta arquitectura.

Actualización segura del clúster de Kubeflow. Una vez que la prueba de Kubeflow Candidate es exitosa, se promueve a Kubeflow Prod a través de una actualización de Route 53.

Los manifiestos de Kubeflow en AWS vienen preempaquetados con integraciones de Amazon RDS y Amazon S3. Con estos servicios administrados actuando como almacenes de datos comunes, podemos configurar una estrategia de implementación azul-verde. Para lograr esto, nos aseguramos de que los metadatos de la canalización se conserven en Amazon RDS, que funciona independientemente del clúster de EKS, y que los registros y artefactos de la canalización se conserven en Amazon S3. Además de los metadatos y los artefactos de canalización, también configuramos FluentD para enrutar los registros de pod a Amazon OpenSearch Service.

Esto garantiza que la capa de almacenamiento esté completamente separada de la capa informática y, por lo tanto, permite probar los cambios durante las actualizaciones de la versión de Kubeflow en un clúster de EKS completamente nuevo. Después de que todas las pruebas sean exitosas, podemos simplemente cambiar el Ruta del Amazonas 53 Registro DNS al clúster candidato que aloja Kubeflow. Además, mantenemos el clúster anterior ejecutándose como copia de seguridad durante unos días en caso de que necesitemos revertirlo.

Beneficios de Amazon EKS y Kubeflow en AWS para nuestra canalización de ML

Amazon EKS y el paquete Kubeflow en AWS trasladaron nuestro flujo de trabajo de desarrollo a un patrón que fomenta encarecidamente el entrenamiento de modelos repetibles. Estas herramientas nos permiten tener clústeres completamente definidos con inquilinos completamente definidos y ejecutar código completamente definido.

Muchas de las ganancias de la construcción de esta plataforma son menos cuantitativas y tienen más que ver con la forma en que los flujos de trabajo han mejorado tanto para los desarrolladores como para los usuarios de la plataforma. Por ejemplo, MinIO se reemplazó con acceso directo a Amazon S3, lo que nos acerca a nuestros flujos de trabajo originales y reduce la cantidad de servicios que debemos mantener. También podemos utilizar Amazon RDS como back-end para Kubeflow, lo que permite migraciones más sencillas entre clústeres y nos brinda la capacidad de realizar copias de seguridad de nuestras canalizaciones todas las noches.

También encontramos beneficiosas las mejoras en la integración de Kubeflow con los servicios administrados de AWS. Por ejemplo, con Amazon RDS, Amazon S3 y Amazon Cognito preconfigurados en los manifiestos de Kubeflow en AWS, ahorramos tiempo y esfuerzo al actualizar a distribuciones más nuevas de Kubeflow. Cuando solíamos modificar manualmente los manifiestos oficiales de Kubeflow, la actualización a una nueva versión tomaba varias semanas, desde el diseño hasta la prueba.

Cambiar a Amazon EKS nos brinda la oportunidad de definir nuestro clúster en Kustomize (ahora parte de Kubectl) y Terraform. Resulta que para el trabajo de plataforma, es muy fácil trabajar con Kubernetes y Terraform después de dedicar suficiente tiempo para aprender. Después de muchas iteraciones, las herramientas disponibles para nosotros hacen que sea muy fácil realizar operaciones estándar de la plataforma, como actualizar un componente o cambiar un clúster de desarrollo completo. En comparación con la ejecución de trabajos sin formato Nube informática elástica de Amazon (Amazon EC2), es difícil comparar la enorme diferencia que supone tener pods bien definidos con limpieza de recursos garantizada y mecanismos de reintento integrados.

Kubernetes proporciona excelentes estándares de seguridad y solo hemos arañado la superficie de lo que nos permite hacer el aislamiento multiusuario. Vemos el aislamiento multiusuario como un patrón que tiene más beneficios en el futuro cuando la plataforma de capacitación produce datos de nivel de producción y contratamos a desarrolladores externos a nuestro equipo.

Mientras tanto, Kubeflow nos permite tener un modelo de entrenamiento reproducible. Incluso con los mismos datos, ningún entrenamiento produce modelos idénticos, pero tenemos la siguiente mejor opción. Con Kubeflow, sabemos exactamente qué código y datos se usaron para entrenar un modelo. La incorporación ha mejorado mucho porque cada paso en nuestra canalización está definido clara y programáticamente. Cuando los nuevos científicos de datos tienen la tarea de corregir un error, necesitan mucha menos ayuda porque existe una estructura clara sobre cómo se utilizan los resultados del código entre las etapas.

El uso de Kubeflow también produce muchas mejoras de rendimiento en comparación con la ejecución en una sola instancia de EC2. A menudo, en el entrenamiento de modelos, los científicos de datos necesitan diferentes herramientas y optimizaciones para el preprocesamiento y el entrenamiento. Por ejemplo, el preprocesamiento suele ejecutarse con herramientas de procesamiento de datos distribuidos, como Spark, mientras que el entrenamiento suele ejecutarse con instancias de GPU. Con las canalizaciones de Kubeflow, pueden especificar diferentes tipos de instancias para diferentes etapas de la canalización. Esto les permite utilizar las potentes instancias de GPU en una etapa y una flota de máquinas más pequeñas para el procesamiento distribuido en otra etapa. Además, debido a que las canalizaciones de Kubeflow describen las dependencias entre etapas, las canalizaciones pueden ejecutar etapas en paralelo.

Finalmente, debido a que creamos un proceso para agregar inquilinos al clúster, ahora hay una forma más formal de registrar equipos en un inquilino en el clúster. Debido a que usamos Kubecost para realizar un seguimiento de los costos en nuestro clúster de EKS, nos permite atribuir el costo a un solo proyecto en lugar de atribuir el costo a nivel de cuenta, que incluye todos los proyectos de ciencia de datos. Kubecost presenta un informe del dinero gastado por espacio de nombres, que está estrechamente relacionado con el inquilino o el equipo responsable de ejecutar la canalización.

A pesar de todos los beneficios, le advertimos que solo lleve a cabo este tipo de migración si hay una aceptación total por parte de los usuarios. Los usuarios que dedican tiempo obtienen muchos beneficios al usar Amazon EKS y Kubernetes, pero hay una curva de aprendizaje significativa.

Conclusión

Con la implementación de la canalización de Kubeflow en AWS en nuestra infraestructura de ML de extremo a extremo, pudimos consolidar y estandarizar nuestros flujos de trabajo de ciencia de datos al tiempo que conservamos nuestras herramientas esenciales (como CI/CD y servicio de modelos). Nuestros científicos de datos ahora pueden moverse entre proyectos basados ​​en este flujo de trabajo sin la sobrecarga de aprender a mantener un conjunto de herramientas completamente diferente. Para algunos de nuestros modelos, también nos sorprendió gratamente la velocidad del nuevo flujo de trabajo (cinco veces más rápido), que permitió realizar más iteraciones de entrenamiento y, en consecuencia, producir modelos con mejores predicciones.

También hemos establecido una base sólida para aumentar nuestras capacidades de MLOps y escalar la cantidad y el tamaño de nuestros proyectos. Por ejemplo, a medida que endurecemos nuestra postura de gobierno en el seguimiento y el linaje de modelos, hemos reducido nuestro enfoque de más de 15 flujos de trabajo a solo uno. Y cuando salió a la luz la vulnerabilidad de Log4shell a fines de 2021, pudimos concentrarnos en un solo flujo de trabajo y corregir rápidamente según fuera necesario (realizar Registro de contenedores elásticos de Amazon (Amazon ECR), actualización de Amazon OpenSearch Service, actualización de nuestras herramientas y más) con un impacto mínimo en el trabajo en curso de los científicos de datos. A medida que las mejoras de AWS y Kubeflow estén disponibles, podemos incorporarlas como mejor nos parezca.

Esto nos lleva a un aspecto importante y discreto de nuestra adopción de Kubeflow en AWS. Uno de los resultados críticos de este viaje es la capacidad de implementar actualizaciones y mejoras en Kubeflow sin problemas para nuestros científicos de datos. Aunque discutimos nuestro enfoque sobre esto anteriormente, también confiamos en los manifiestos de Kubeflow proporcionados por AWS. Comenzamos nuestro viaje de Kubeflow como una prueba de concepto en 2019, antes del lanzamiento de la versión 1.0.0. (Actualmente estamos en 1.4.1, evaluando 1.5. AWS ya está trabajando en la versión 1.6). En los 3 años intermedios, ha habido al menos seis lanzamientos con contenido sustancial. A través de su enfoque disciplinado para integrar y validar estas actualizaciones y publicar los manifiestos en un cronograma predecible y confiable, el equipo de Kubeflow en AWS ha sido crucial para permitir que el equipo de MLOps de athenahealth planifique nuestra hoja de ruta de desarrollo y, en consecuencia, nuestras asignaciones de recursos y áreas de enfoque. , más adelante en el futuro con mayor confianza.

Puede seguir el Repositorio de GitHub de AWS Labs para realizar un seguimiento de todas las contribuciones de AWS a Kubeflow. También puede encontrar equipos de AWS en el Kubeflow #AWS Canal flojo; sus comentarios allí ayudan a AWS a priorizar las próximas funciones para contribuir al proyecto Kubeflow.

---

Sobre los autores

Kanwaljit Khurmi es un arquitecto de soluciones sénior en Amazon Web Services. Trabaja con los clientes de AWS para proporcionar orientación y asistencia técnica, ayudándoles a mejorar el valor de sus soluciones cuando utilizan AWS. Kanwaljit se especializa en ayudar a los clientes con aplicaciones de aprendizaje automático y en contenedores.

Tyler Kalbach es miembro principal del personal técnico de athenahealth. Tyler tiene aproximadamente 7 años de experiencia en análisis, ciencia de datos, redes neuronales y desarrollo de aplicaciones de aprendizaje automático en el espacio de atención médica. Ha contribuido a varias soluciones de Machine Learning que actualmente sirven al tráfico de producción. Tyler, que actualmente trabaja como científico principal de datos en la organización de ingeniería de athenahealth, ha sido parte del equipo que ha creado la nueva plataforma de capacitación de aprendizaje automático para athenahealth desde el inicio de ese esfuerzo.

Víctor Krilov es miembro principal del personal técnico de athenahealth. Victor es ingeniero y experto en scrum, y ayuda a los científicos de datos a crear canalizaciones seguras y rápidas de aprendizaje automático. En athenahealth ha trabajado en interfaces, pedidos clínicos, prescripciones, programación, análisis y ahora aprendizaje automático. Valora el código bien escrito y bien probado, pero tiene una obsesión enfermiza con las frases ingeniosas del código. En su tiempo libre disfruta escuchando podcasts mientras pasea a su perro.

Sasank Vemuri es miembro principal del personal técnico de athenahealth. Tiene experiencia trabajando en el desarrollo de soluciones basadas en datos en dominios como la atención médica, los seguros y la bioinformática. Sasank actualmente trabaja en el diseño y desarrollo de plataformas de inferencia y capacitación de aprendizaje automático en AWS y Kubernetes que ayudan con la capacitación y la implementación de soluciones de ML a escala.

Anu Tumkur es arquitecto en athenahealth. Anu tiene más de dos décadas de experiencia en arquitectura, diseño y desarrollo creando varios productos de software en aprendizaje automático, operaciones en la nube, macrodatos, canalizaciones de datos distribuidos en tiempo real, tecnología publicitaria, análisis de datos, análisis de redes sociales. Anu actualmente trabaja como arquitecto en la organización de ingeniería de productos de athenahealth en los equipos de plataforma de aprendizaje automático y canalización de datos.

Guillermo Tsen es gerente sénior de ingeniería en athenahealth. Tiene más de 20 años de experiencia en liderazgo de ingeniería en la creación de soluciones en TI para el cuidado de la salud, computación distribuida de big data, redes ópticas inteligentes, sistemas de edición de video en tiempo real, software empresarial y suscripción de atención médica grupal. William actualmente lidera dos equipos increíbles en athenahealth, los equipos de ingeniería de Operaciones de aprendizaje automático y DevOps, en la organización de Ingeniería de productos.