La zona de aterrizaje de Azure para una plataforma de datos en la nube | de Mariusz Kujawski | agosto, 2024

La zona de aterrizaje de Azure para una plataforma de datos en la nube | de Mariusz Kujawski | agosto, 2024

Trabajar con datos confidenciales o en un entorno altamente regulado requiere una infraestructura en la nube segura para el procesamiento de datos. La nube puede parecer un entorno abierto en Internet y plantear preocupaciones de seguridad. Cuando comienza su viaje con Azure y no tiene suficiente experiencia en la configuración de recursos, es fácil cometer errores de diseño e implementación que pueden afectar la seguridad y la flexibilidad de su nueva plataforma de datos. En este artículo, describiré los aspectos más importantes del diseño de un marco habilitado para la nube para una plataforma de datos en Azure.

Imagen del autor

Una zona de aterrizaje de Azure proporciona la base para implementar recursos en la nube pública. Contiene los elementos esenciales de una plataforma robusta. Estos elementos incluyen redes, gestión de identidades y accesos, seguridad, gobernanza y cumplimiento. Al implementar una zona de aterrizaje, las organizaciones pueden agilizar el proceso de configuración de su infraestructura, garantizando que se utilicen las mejores prácticas y directrices.

Una zona de aterrizaje de Azure es un entorno que sigue principios de diseño clave para permitir la migración, la modernización y el desarrollo de aplicaciones. En Azure, las suscripciones se utilizan para aislar y ampliar los recursos de aplicaciones y plataformas. Estos se clasifican de la siguiente manera:

  • Zonas de aterrizaje de aplicaciones:Suscripciones dedicadas a alojar recursos específicos de aplicaciones.
  • Zona de aterrizaje de la plataforma: Suscripciones que contienen servicios compartidos, como identidad, conectividad y recursos de administración proporcionados para zonas de inicio de aplicaciones.

Estos principios de diseño ayudan a las organizaciones a operar con éxito en un entorno de nube y escalar una plataforma.

Imagen del autor

La implementación de una plataforma de datos en Azure implica un diseño de arquitectura de alto nivel donde se seleccionan recursos para la ingesta, transformación, difusión y exploración de datos. El primer paso puede requerir el diseño de una zona de aterrizaje. Si necesita una plataforma segura que siga las mejores prácticas, es esencial comenzar con una zona de aterrizaje. Esto le ayudará a organizar recursos dentro de suscripciones y grupos de recursos, definir la topología de la red y garantizar la conectividad a entornos locales a través de VPN, al mismo tiempo que cumple con las convenciones y estándares de nomenclatura.

diseño arquitectónico

Adaptar una arquitectura a una plataforma de datos requiere una cuidadosa selección de recursos. Azure proporciona recursos nativos para plataformas de datos como Azure Synapse Analytics, Azure Databricks, Azure Data Factory y Microsoft Fabric. Los servicios disponibles ofrecen una variedad de formas de lograr objetivos similares, lo que permite flexibilidad a la hora de elegir su arquitectura.

Por ejemplo:

  • Ingestión de datos: Azure Data Factory o Synapse Pipelines.
  • Ciencias de la Computación: Azure Databricks o Apache Spark en Synapse.
  • Análisis de datos: Paneles de Power BI o Databricks.

Podemos usar Apache Spark y Python o herramientas de arrastrar y soltar de bajo código. Diferentes combinaciones de estas herramientas pueden ayudarnos a crear la arquitectura más adecuada en función de nuestras habilidades, casos de uso y capacidades.

Arquitectura de alto nivel (Imagen del autor)

Azure también le permite utilizar otros componentes como Snowflake o crear su composición utilizando software de código abierto, máquinas virtuales (VM) o Kubernetes Service (AKS). Podemos aprovechar las VM o AKS para configurar servicios de procesamiento de datos, minería, orquestación, IA o ML.

Estructura típica de una plataforma de datos.

Una plataforma de datos típica en Azure debería incluir varios componentes clave:

1. Herramientas para ingerir datos de fuentes en una cuenta de almacenamiento de Azure. Azure ofrece servicios como Azure Data Factory, Azure Synapse Pipelines o Microsoft Fabric. Podemos utilizar estas herramientas para recopilar datos de fuentes.

2. Data Warehouse, Data Lake o Data Lakehouse: Dependiendo de tus preferencias arquitectónicas, podemos seleccionar diferentes servicios para almacenar datos y un modelo de negocio.

  • Para Data Lake o Data Lakehouse, podemos usar Databricks o Fabric.
  • Para el almacén de datos, podemos seleccionar Azure Synapse, Snowflake o MS Fabric Warehouse.

3. Para orquestar el procesamiento de datos en Azure contamos con Azure Data Factory, Azure Synapse Pipelines, Airflow o Databricks Workflows.

4. La transformación de datos en Azure puede ser gestionada por diferentes servicios.

  • Para Apache Spark: Databricks, Azure Synapse Spark Pool y MS Fabric Notebooks,
  • Para la transformación basada en SQL, podemos usar Spark SQL en Databricks, Azure Synapse o MS Fabric, T-SQL en SQL Server, MS Fabric o Synapse Dedicated Pool. Alternativamente, Snowflake ofrece funcionalidad SQL completa.

Suscripciones

Un aspecto importante del diseño de la plataforma es planificar la segmentación de suscripciones y grupos de recursos según las unidades de negocio y el ciclo de vida de desarrollo de software. Es posible utilizar suscripciones independientes para entornos de producción y no producción. Con esta distinción, podemos lograr un modelo de seguridad más flexible, políticas separadas para los entornos de producción y de prueba y evitar limitaciones de cuotas.

Organización de suscripciones (Imagen del autor)

Redes

Una red virtual es similar a una red tradicional que opera en su centro de datos. Azure Virtual Networks (VNet) proporciona una capa de seguridad fundamental para su plataforma. Deshabilitar los puntos finales públicos para los recursos reducirá significativamente el riesgo de fuga de datos en caso de pérdida de claves o contraseñas. Sin puntos de conexión públicos, solo se puede acceder a los datos almacenados en las cuentas de almacenamiento de Azure cuando están conectados a su red virtual.

La conectividad de red local admite una conexión directa entre los recursos de Azure y los orígenes de datos locales. Dependiendo del tipo de conexión, el tráfico de comunicación puede pasar a través de un túnel cifrado a través de Internet o una conexión privada.

Para mejorar la seguridad dentro de una red virtual, puede utilizar grupos de seguridad de red (NSG) y firewalls para administrar las reglas de tráfico entrante y saliente. Estas reglas le permiten filtrar el tráfico según direcciones IP, puertos y protocolos. Además, Azure permite enrutar el tráfico entre subredes, redes virtuales y locales e Internet. El uso de tablas de enrutamiento personalizadas le permite controlar el enrutamiento del tráfico.

Configuración de red (Imagen del autor)

Convención de nomenclatura

Una convención de nomenclatura establece la estandarización de los nombres de los recursos de la plataforma, haciéndolos más autodescriptivos y más fáciles de administrar. Esta estandarización permite navegar y filtrar diferentes recursos en Azure Portal. Una convención de nomenclatura bien definida le permite identificar rápidamente el tipo, el propósito, el entorno y la región de Azure de un recurso. Esta coherencia puede resultar beneficiosa en sus procesos de CI/CD porque los nombres predecibles son más fáciles de configurar.

Cuando se trata de convenciones de nomenclatura, es necesario considerar qué información desea capturar. La norma debe ser fácil de seguir, coherente y práctica. Resulta útil incluir elementos como organización, unidad de negocio o proyecto, tipo de recurso, entorno, región y número de instancia. También debe considerar el alcance de los recursos para garantizar que los nombres sean únicos en contexto. Para algunos recursos, como las cuentas de almacenamiento, los nombres deben ser globalmente únicos.

Por ejemplo, se puede nombrar un área de trabajo de Databricks con el siguiente formato:

Convención de nomenclatura (Imagen del autor)

Ejemplos de abreviaturas:

Imagen del autor

Una convención de nomenclatura completa normalmente incluye el siguiente formato:

  • Tipo de recurso: Abreviatura que representa el tipo de recurso.
  • Nombre del proyecto: Un identificador único para su proyecto.
  • Ambiente: El entorno respaldado por el recurso (por ejemplo, desarrollo, garantía de calidad, producción).
  • Región: La región geográfica o el proveedor de la nube donde se implementa el recurso.
  • Ejemplo: Un número que le permite diferenciar entre varias instancias del mismo recurso.

La implementación de infraestructura a través de Azure Portal puede parecer sencilla, pero a menudo implica muchos pasos detallados para cada recurso. La infraestructura altamente segura requerirá configuración de recursos, redes, puntos finales privados, zonas DNS, etc. Recursos como Azure Synapse o Databricks requieren una configuración interna adicional, como configurar el catálogo de Unity, administrar ámbitos secretos y configurar ajustes de seguridad (usuarios, grupos, etc.).

Una vez que se completa el entorno de prueba, debe replicar la misma configuración en los entornos de control de calidad y producción. Aquí es donde es fácil cometer errores. Para minimizar errores potenciales que podrían afectar la calidad del desarrollo, se recomienda utilizar un enfoque de Infraestructura como Código (IasC) para el desarrollo de infraestructura. IasC le permite crear infraestructura en la nube como código en Terraform o Biceps, lo que le permite implementar múltiples entornos con configuraciones consistentes.

En mis proyectos en la nube, utilizo aceleradores para lanzar rápidamente nuevas configuraciones de infraestructura. Microsoft también proporciona aceleradores que se pueden utilizar. Almacenar la infraestructura como código en un repositorio proporciona beneficios adicionales, como control de versiones, seguimiento de cambios, realización de revisiones de código e integración con canalizaciones de DevOps para gestionar y promover cambios en todos los entornos.

Si tu plataforma de datos no maneja información sensible y no necesitas una plataforma de datos altamente segura, puedes crear una configuración más sencilla con acceso público a Internet sin redes virtuales (VNet), VPN, etc. Sin embargo, en un ámbito altamente regulado, se requiere un plan de implementación completamente diferente. Este plan implicará la colaboración con diferentes equipos dentro de su organización, como los equipos de DevOps, Plataforma y Red, o incluso recursos externos.

Necesitará contar con una infraestructura de red, recursos y seguridad seguros. Sólo cuando la infraestructura esté lista se podrán iniciar actividades relacionadas con el desarrollo del procesamiento de datos.

Si este artículo te resultó interesante, te invito a expresar tu agradecimiento haciendo clic en el botón “aplaudir” o dándole me gusta en LinkedIn. Su apoyo es muy apreciado. Para cualquier duda o consejo no dudes en contactarme en LinkedIn.