En este artículo se describe cómo ofrecer una solución avanzada de análisis crítica con Azure Data Factory. Esta arquitectura es una extensión de la arquitectura de línea base y la arquitectura protegida por la empresa. En este artículo se proporcionan instrucciones específicas sobre los cambios recomendados necesarios para administrar una carga de trabajo como una operación crítica.
Esta arquitectura se alinea con los procedimientos recomendados y las instrucciones de Cloud Adoption Framework para Azure y las recomendaciones para cargas de trabajo críticas.
Creación de una arquitectura crítica
En la arquitectura de línea base, Contoso opera un almacén de lago medallion que admite sus primeras cargas de trabajo de datos para el departamento financiero. Contoso protege y amplía este sistema para admitir las necesidades de datos analíticos de la empresa. Esta estrategia proporciona funcionalidades de ciencia de datos y funcionalidad de autoservicio.
En la arquitectura protegida de la empresa, Contoso ha implementado una arquitectura de almacén de lago medallion que respalda sus necesidades de datos analíticos empresariales y permite a los usuarios empresariales usar un modelo de dominio. A medida que Contoso continúa su expansión global, el departamento financiero ha usado Azure Machine Learning para crear un modelo de fraude en las operaciones. Este modelo ahora necesita un ajuste adicional para funcionar como un servicio operativo crítico.
Requisitos principales
Hay varios requisitos clave para ofrecer una solución analítica avanzada crítica mediante Data Factory:
El modelo de aprendizaje automático debe diseñarse como un servicio operativo crítico que esté disponible globalmente para los distintos sistemas operativos de las operaciones.
Los resultados del modelo de aprendizaje automático y las métricas de rendimiento deben estar disponibles para el reentrenamiento y la auditoría.
Los seguimientos de auditoría del modelo de aprendizaje automático deben conservarse durante 10 años.
Actualmente, el modelo de aprendizaje automático tiene como destino Estados Unidos, Europa y Sudamérica, con planes para expandirse a Asia en el futuro. La solución debe cumplir los requisitos de cumplimiento de datos, como el Reglamento general de protección de datos para países o regiones europeos.
Se espera que el modelo de aprendizaje automático admita hasta 1000 usuarios simultáneos en cualquier región determinada durante las horas laborables punta. Para minimizar los costes, el procesamiento de aprendizaje automático debe reducirse horizontalmente cuando no esté en uso.
Decisiones de diseño clave
Un requisito no justifica el coste y la complejidad de rediseñar la plataforma para cumplir las especificaciones críticas. En su lugar, el modelo de aprendizaje automático debe incluirse en contenedores y, a continuación, implementarse en una solución crítica. Este enfoque minimiza el coste y la complejidad al aislar el servicio del modelo y cumplir con las instrucciones críticas. Este diseño requiere que el modelo se desarrolle en la plataforma y, a continuación, se contenedorice para la implementación.
Una vez contenedorizado el modelo, se puede enviar a través de una API con una arquitectura de unidad de escalado en regiones de Azure de EE. UU., Europa y Sudamérica. Solo las regiones emparejadas que tienen zonas de disponibilidad están en el ámbito, lo que admite los requisitos de redundancia.
Debido a la simplicidad de un único servicio de API, se recomienda usar la característica de Web App for Containers para hospedar la aplicación. Esta característica proporciona simplicidad. También puede usar Azure Kubernetes Service (AKS), que proporciona más control, pero aumenta la complejidad.
El modelo se implementa a través de un marco de MLOps. Data Factory se usa para mover datos dentro y fuera de la implementación crítica.
Para realizar la contenedorización, necesita:
Un front-end de API para proporcionar los resultados del modelo.
Para descargar las métricas de auditoría y rendimiento en una cuenta de almacenamiento, que se pueden transferir de nuevo a la plataforma principal a través de Data Factory mediante un trabajo programado.
Canalizaciones de implementación y reversión, que permiten que cada implementación regional se sincronice con la versión actual correcta del modelo.
Modelado de estado del servicio para medir y administrar el estado general de una carga de trabajo.
Los seguimientos de auditoría se pueden almacenar inicialmente en un área de trabajo de Log Analytics para el análisis en tiempo real y la compatibilidad operativa. Después de 30 o 90 días si se usa Microsoft Sentinel, las pistas de auditoría se pueden transferir automáticamente a Azure Data Explorer para su conservación a largo plazo. Este enfoque permite realizar consultas interactivas de hasta dos años dentro del área de trabajo de Log Analytics y conservar los datos más antiguos y de uso poco frecuente a un coste reducido durante un máximo de 12 años. Use Azure Data Explorer para el almacenamiento de datos para poder ejecutar consultas entre plataformas y visualizar datos tanto en Azure Data Explorer como en Microsoft Sentinel. Este enfoque proporciona una solución rentable para cumplir los requisitos de almacenamiento a largo plazo, a la vez que se mantiene la compatibilidad con la opcionalidad. Si no hay ningún requisito para conservar datos excesivos, debe considerar la posibilidad de eliminarlos.
Arquitectura
Flujo de trabajo
El siguiente flujo de trabajo corresponde al diagrama anterior:
El modelo de aprendizaje automático se desarrolla en la plataforma de datos. Este cambio de diseño requiere las siguientes actualizaciones de la arquitectura:
Azure Container Registry habilita la compilación, el almacenamiento y la administración de imágenes y artefactos de contenedor de Docker en un registro privado que admite la implementación del modelo de Machine Learning.
La característica Web App for Containers permite las actividades de integración continua e implementación continua que son necesarias para entregar las salidas del modelo de aprendizaje automático como servicio de API.
Data Factory permite la migración de los datos necesarios por el modelo para ejecutarse y permite la ingesta de métricas de rendimiento y salida del modelo de la implementación crítica.
La estructura de directorios de la capa de bronce del lago de datos (o la capa sin procesar) almacena las métricas de rendimiento y salida del modelo mediante el nivel de archivo para satisfacer el requisito de conservación de datos.
Azure DevOps orquesta la implementación del código base del modelo y la creación y retirada de implementaciones regionales para todos los servicios auxiliares.
El modelo de aprendizaje automático se implementa como una carga de trabajo crítica dedicada dentro de su propia suscripción definida. Este enfoque garantiza que el modelo evite los límites de componentes o de servicio que pueda imponer la plataforma.
Un conjunto de recursos compartidos abarca toda la solución y, por tanto, se definen como globales:
Container Registry habilita la distribución de la versión actual del modelo de Machine Learning en las implementaciones regionales.
Azure Front Door proporciona servicios de equilibrio de carga para distribuir el tráfico entre implementaciones regionales.
Una funcionalidad de supervisión usa Log Analytics y Azure Data Lake Storage.
La marca de implementación regional es un conjunto de componentes de solución que puede implementar en cualquier región de destino. Este enfoque proporciona escalado, resistencia del servicio y servicio específico de la región.
En función de la naturaleza del modelo de aprendizaje automático, puede haber requisitos de cumplimiento de datos regionales que requieran que el modelo de aprendizaje automático se ajuste a las regulaciones de soberanía. Este diseño admite estos requisitos.
Cada implementación regional incluye su propia pila de supervisión y almacenamiento, que proporciona aislamiento del resto de la solución.
La unidad de escalado de la solución tiene los siguientes componentes:
Web App for Containers hospeda el modelo de aprendizaje automático y ofrece las salidas. Como componente de servicio principal de esta solución, debe tener en cuenta los límites de escala de Web App for Containers como restricciones clave. Si estos límites no admiten los requisitos de las soluciones, considere la posibilidad de usar AKS en su lugar.
Azure Key Vault aplica controles adecuados sobre secretos, certificados y claves en el ámbito regional, protegidos mediante Azure Private Link.
Data Lake Storage proporciona almacenamiento de datos, que se protege mediante Private Link.
Azure DNS proporciona resolución de nombres que permite la resistencia del servicio y simplifica el equilibrio de carga en toda la solución.
Para facilitar el soporte técnico y la solución de problemas de la solución, también se incluyen los siguientes componentes:
Azure Bastion proporciona una conexión segura a hosts de salto sin necesidad de una dirección IP pública.
Azure Virtual Machines actúa como host de salto para la solución, lo que permite una mejor posición de seguridad.
Los agentes de compilación autohospedados proporcionan escala y rendimiento para admitir implementaciones de soluciones.
Diseño de red
Descargue un archivo Visio de esta arquitectura.
Debería usar un firewall de nueva generación como Azure Firewall para proteger la conectividad de red entre la infraestructura local y la red virtual de Azure.
Puede implementar un entorno de ejecución de integración autohospedado (SHIR) en una máquina virtual (VM) en el entorno local o en Azure. Considere la posibilidad de implementar la máquina virtual en Azure como parte de la zona de aterrizaje de recursos de soporte compartido para simplificar la gobernanza y la seguridad. Puede usar el SHIR para conectarse de forma segura a orígenes de datos locales y realizar tareas de integración de datos en Data Factory.
El etiquetado de datos asistido por aprendizaje automático no admite cuentas de almacenamiento predeterminadas porque están protegidas detrás de una red virtual. En primer lugar, cree una cuenta de almacenamiento para el etiquetado de datos asistido por aprendizaje automático. A continuación, aplique el etiquetado y guárdelo detrás de la red virtual.
Los puntos de conexión privados proporcionan una dirección IP privada desde la red virtual a un servicio de Azure. Este proceso incorpora el servicio de forma efectiva a la red virtual. Esta funcionalidad hace que el servicio sea accesible solo desde la red virtual o las redes conectadas, lo que garantiza una conexión más segura y privada. Los puntos de conexión privados usan Private Link, que protege la conexión a la solución de plataforma como servicio (PaaS). Si la carga de trabajo usa recursos que no admiten puntos de conexión privados, es posible que pueda usar puntos de conexión de servicio. Se recomienda usar puntos de conexión privados para cargas de trabajo críticas siempre que sea posible.
Para obtener más información, consulte Redes y conectividad.
Importante
Determine si su caso de uso es operativo, como este escenario, o si está relacionado con la plataforma de datos. Si el caso de uso incluye la plataforma de datos, como la ciencia de datos o el análisis, podría no calificarse como crítico. Las cargas de trabajo críticas requieren recursos sustanciales y solo deben definirse como tal si justifican la inversión de recursos.
Alternativas
Puede usar AKS para hospedar los contenedores. En este caso de uso, la carga de administración necesaria para AKS hace que sea una opción menos ideal.
Puede usar Azure Container Apps en lugar de la característica Web App for Containers. Actualmente, los puntos de conexión privados no se admiten para Container Apps, pero el servicio se puede integrar en una red virtual existente o nueva.
Puede usar Azure Traffic Manager como alternativa de equilibrio de carga. Azure Front Door es preferible para este escenario debido a la funcionalidad adicional disponible y un rendimiento de conmutación por error más rápido.
Si el modelo requiere funcionalidades de lectura y escritura como parte de su procesamiento de datos, considere la posibilidad de usar Azure Cosmos DB.
Consideraciones
Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Marco de buena arquitectura.
Confiabilidad
La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.
En comparación con la arquitectura de línea base, esta arquitectura:
Se alinea con la arquitectura de línea base de misión crítica.
Sigue las instrucciones de las consideraciones de diseño de confiabilidad críticas.
Implementa un modelo de estado inicial para la solución para maximizar la confiabilidad.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.
En comparación con la arquitectura de línea base, esta arquitectura:
Sigue las instrucciones de las consideraciones de diseño de seguridad críticas.
Implementa las instrucciones de seguridad de la arquitectura de referencia crítica.
Optimización de costos
La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.
Los diseños críticos son costosos, lo que hace que la implementación de controles sea importante. Algunos controles incluyen:
Alinear la selección de SKU del componente con los límites de la unidad de escalado de la solución para evitar el sobreaprovisionamiento.
Ventajas de ahorro de gastos operativos disponibles y prácticas, como reservas de Azure para cargas de trabajo estables, planes de ahorro para cargas de trabajo dinámicas y niveles de compromiso de Log Analytics.
Alertas de costes y presupuestos a través de Microsoft Cost Management.
Excelencia operativa
La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.
En comparación con la arquitectura de línea base, esta arquitectura:
Sigue las instrucciones de las consideraciones de diseño de excelencia operativa críticas.
Separa los recursos de supervisión globales y regionales para evitar un único error puntual en la observabilidad.
Implementa las instrucciones de implementación y pruebas y los procedimientos operativos de la arquitectura de referencia crítica.
Alinea la solución con las hojas de ruta de ingeniería de Azure y los lanzamientos regionales para tener en cuenta los servicios en constante evolución en Azure.
Eficiencia del rendimiento
La eficiencia del rendimiento es la capacidad que tiene la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan realizado sobre ella. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.
En comparación con la arquitectura de línea base, esta arquitectura:
Siga las instrucciones de las consideraciones de diseño de eficiencia de rendimiento críticas.
Completa una evaluación de buena arquitectura para cargas de trabajo críticas para proporcionar una línea base de preparación para la solución. Revise periódicamente esta evaluación como parte de un ciclo proactivo de medición y administración.
Antipatrones
El enfoque de la lista de compras: las partes interesadas de la empresa a menudo se presentan con una lista de compras de características y niveles de servicio, sin el contexto de coste o complejidad. Es importante asegurarse de que cualquier solución se base en los requisitos validados y que el diseño de la solución sea compatible con el modelado financiero con opciones. Este enfoque permite a las partes interesadas tomar decisiones fundamentadas y dinamizar si es necesario.
No cuestionar los requisitos: los diseños críticos pueden ser costosos y complejos de implementar y mantener. Se debe preguntar a las partes interesadas de la empresa por sus requisitos para asegurarse de que la "opción crítica" es verdaderamente necesaria.
Implementar y olvidar: el modelo se implementa sin mecanismos de soporte técnico, actualizaciones o supervisión continuas. Después de implementar el modelo, apenas requiere mantenimiento y puede funcionar de forma aislada. Esto puede provocar una degradación del rendimiento, un desfase en la precisión del modelo y vulnerabilidades a patrones de datos emergentes. En última instancia, debilita la confiabilidad y la eficacia del modelo a la hora de cumplir su objetivo.