

AWS Cloud Engineer
AWS Cloud Engineer
Este artículo es el segundo de una serie de dos que pretende abordar la integración de Databricks en entornos AWS analizando las alternativas ofrecidas por el producto respecto al diseño de arquitectura. En el primero se habló acerca de temas más relacionados con la arquitectura y networking, en esta segunda entrega hablaremos sobre temas relacionados con la seguridad y administración general.
Los contenidos de cada artículo son los siguientes:
Primera entrega:
Esta entrega:
El primer artículo puede visitarse en el siguiente enlace [1].
En este apartado se analizará la seguridad de la información tratada en Databricks desde dos perspectivas: mientras la información se encuentra en tránsito y mientras los datos se encuentran en reposo.
Este apartado trata sobre la encriptación de los datos enviados a los buckets desde el cluster para así poder definir unas policies en los buckets para rechazar toda comunicación entrante sin encriptar. La configuración necesaria para el root bucket y los buckets donde se guardan los datos (raw, prepared y trusted) son diferentes ya que el root bucket forma parte del DBFS.
Para poder encriptar la comunicación desde el cliente debemos incluir un fichero llamado core-site.xml en cada nodo del cluster a través de un init script, ya sea global o específico a un cluster. Esta configuración se rellena para el DBFS ya que el root bucket forma parte de este.
En este fichero debemos añadir el algoritmo a utilizar y la clave en KMS, pudiendo ser claves administradas por el cliente. Un ejemplo del contenido de este fichero podría ser el siguiente:
<property>
<name>fs.s3a.server-side-encryption-algorithm</name>
<value>SSE-KMS</value>
</property>
<property>
<name>fs.s3a.server-side-encryption.key</name>
<value>${kms_key_arn}</value>
</property>
Definición del algoritmo y clave KMS a utilizar en la encriptación del root bucket
En el caso de los buckets del Data Lake debemos añadir unas configuraciones de Spark en el cluster para que éste configure la encriptación.
Un ejemplo de configuración podría ser el siguiente, donde en la parte inferior incluimos la misma información que en el anterior apartado, es decir, el algoritmo y clave de encriptación.
spark_conf = {
"spark.databricks.repl.allowedLanguages" : "python,sql",
"spark.databricks.cluster.profile" : "serverless",
"spark.databricks.passthrough.enabled" : true,
"spark.databricks.pyspark.enableProcessIsolation" : true,
"spark.databricks.hive.metastore.glueCatalog.enabled" : true,
"spark.hadoop.aws.region" : var.aws_region,
#caches for glue to run faster
"spark.hadoop.aws.glue.cache.db.enable" : true,
"spark.hadoop.aws.glue.cache.db.size" : 1000,
"spark.hadoop.aws.glue.cache.db.ttl-mins" : 30,
"spark.hadoop.aws.glue.cache.table.enable" : true,
"spark.hadoop.aws.glue.cache.table.size" : 1000,
"spark.hadoop.aws.glue.cache.table.ttl-mins" : 30,
#encryption
"spark.hadoop.fs.s3a.server-side-encryption.key" : var.datalake_key_arn
"spark.hadoop.fs.s3a.server-side-encryption-algorithm" : "SSE-KMS"
}
Definición del algoritmo y clave a utilizar en la encriptación de los buckets del Data Lake
Esta configuración puede también incluirse a través de la UI de Databricks en la sección Spark config a la hora de crear el cluster.
Existe la posibilidad de añadir una capa más de seguridad implementando la encriptación cuando la información es compartida entre los worker nodes cuando la consecución de las tareas así lo requiera.
Para facilitar la integración de este servicio se puede hacer uso de las instancias EC2 de AWS que encriptan el tráfico entre ellas por defecto. Estas son los siguientes:
En este apartado se describe cómo encriptar la información cuando esta está en reposo. Los métodos para encriptar estos datos son diferentes para el Data Plane y Control Plane ya que estos están administrados por diferentes entidades (Databricks y el cliente, respectivamente).
Para la encriptación de nuestra capa de persistencia dentro del Data Plane es necesario crear una clave dentro de KMS y registrar esta en Databricks a través de la Account API. Existe la posibilidad de elegir si encriptar solo el root bucket o el root bucket y EBS. Esta diferenciación se logra a través de la política que se adjunte a la propia clave, dando los permisos necesarios para encriptar buckets del Data Lake o incluir además la posibilidad de encriptar EBS.
Las características de esta funcionalidad son las siguientes:
Toda la información sobre este tipo de encriptación está en el siguiente enlace [2].
En este apartado se describe la manera de encriptar todos los elementos alojados en el Control Plane (notebooks, secretos y queries SQL e historial de queries).
Por defecto el Control Plane aloja una Databricks Managed Key (DMK) para cada workspace, una clave de encriptación administrada por Databricks. A continuación se deberá crear una Customer Managed Key (CMK) administrada por el usuario y registrarla a través de la Account API Databricks. Databricks entonces utiliza ambas claves para encriptar y desencriptar la Data Encryption Key (DEK), que es guardada como un secreto encriptado.
La DEK se cachea en memoria para varias operaciones de lectura y escritura y es desalojada de ésta en ciertos intervalos para que las consecuentes operaciones necesiten una nueva llamada a la infraestructura del cliente para obtener otra vez la CMK. Por lo tanto, en el caso de perder los permisos a esta clave, una vez el intervalo de tiempo de refresco se cumpla se perderá el acceso a los elementos alojados en el Control Plane.
Esto se puede ver más en detalle en la siguiente imagen:
Es importante resaltar que en el caso de querer añadir una clave de encriptación a un workspace ya creado habrá que realizar una PATCH request adicional a través de la Account API.
Toda la información sobre este tipo de encriptación está en el siguiente enlace [3].
El desarrollo de pipelines o workflows generalmente conlleva la necesidad de comunicación de información crítica o de carácter confidencial entre las distintas fases del proceso. Esta información en otros entornos Cloud suelen almacenarse en un Secret Scope para evitar comprometer la integridad de la misma. Un ejemplo de la información tratada en estos Secret Scopes podrían ser las credenciales de acceso a una base de datos.
Databricks posibilita una gestión integral con AWS, tanto del Secret Scope como de los secretos, mediante la API de Databricks. Se debe tener muy en cuenta que de forma predeterminada se asignan permisos de gestión completa (Manage permission) del Secret Scope a menos que esto se declare a la hora de desplegarlo (los permisos asignables al conjunto de usuarios son Read, Write y Manage).
Para suscripciones Premium o Enterprise, Databricks ofrece la posibilidad de gestionar los permisos a los usuarios de una manera más granular mediante el ACL (Access Control List) pudiendo así asignar distintos niveles de permisos en función del grupo de usuarios.
Estos secretos por defecto son almacenados en una base de datos encriptada gestionada por Databricks y el acceso a la misma puede gestionarse mediante Secret ACLs. Este tipo de información puede ser gestionada directamente desde el KMS de AWS volcando los pares clave-valor y gestionando los permisos de acceso al mismo mediante IAM.
Para todas aquellas tareas de administración en las que no proceda que las ejecute un miembro de la organización en particular podremos hacer uso del Service Principal.
Un Service Principal es una entidad creada para usarse con herramientas automatizadas, correr trabajos y aplicaciones, es decir, una cuenta de administración no nominal. Es posible restringir los accesos de esta entidad a través de permisos. Un Service Principal no puede acceder a Databricks a través de la UI, sus acciones son solo posibles a través de la APIs.
La manera recomendada para trabajar con esta entidades es que un administrador cree un token en representación del Service Principal para que este pueda autenticarse con el token y realizar las acciones necesarias.
Se han encontrado las siguientes limitaciones al trabajar con un Service Principal:
Databricks, al igual que otros servicios que ofrecen la posibilidad de desplegar un cluster serverless también ofrece una funcionalidad común al resto como es el auto-escalado. Esta funcionalidad está gestionada completamente por Databricks en cuanto a las distintas situaciones que deben darse para que se decida auto-escalar el número de nodos del cluster (scaling out) o la tipología de los mismos (scaling up).
Databricks destaca en esta funcionalidad respecto a la competencia debido a que ofrece un auto-escalado optimizado que consigue de promedio un ahorro del 30% mayor respecto al resto de soluciones (aunque también ofrece la posibilidad de implantar la versión estándar). La principal diferencia entre la versión optimizada y la estándar está en la incorporación del scale-down.
El que otras soluciones no incluyan el “scale-down” se debe a que la eliminación de nodos puede comprometer al proceso, ya que aunque el nodo en cuestión no esté realizando ninguna tarea puede contener información en caché o shuffle files que sí vayan a ser necesarios para procesos futuros en otros nodos. Esta acción se considera como sensible ya que la eliminación de un nodo que contenga información utilizada en otros procesos provocaría la necesidad de reprocesamientos, lo cual generaría unos costes mayores al del ahorro generado por el scale-down.
Databricks, en la nueva actualización, implementa una validación en la identificación de los nodos menos requeridos cuando se produce una infrautilización del cluster, teniendo en cuenta lo siguiente:
Con esto lo que se permite es un “scale-down” más agresivo ya que en todo momento se tienen identificados qué nodos son susceptibles de eliminar sin poner en riesgo la integridad del proceso. Databricks toma medidas preventivas en este tipo de escalado e implanta tiempos de espera extra para validar con una mayor seguridad que esta acción es correcta (Job Cluster: 30’’ , All-Purpose Cluster: 2’ 30’’)
A la hora de autoescalar, ya sea scale-up o scale-down, se tiene en cuenta tanto el grado de saturación/infrautilización de CPU general, como la de los nodos por individual, pudiendo identificarse los siguientes escenarios:
El autoescalado optimizado de Databricks se recomienda especialmente cuando las tareas tienen picos pronunciados, ya que esto genera un rápido escalado para soportar la demanda y en caso de que sea un pico puntual y la demanda no se mantenga, estos nodos quedarían operativos aunque no vayan a procesar información:
En búsqueda de la eficiencia general del cluster surgen iniciativas como la posibilidad de realizar agrupaciones para que la asignación de tareas sea lo más óptima posible y haga que otras acciones, como el auto-escalado, puedan llevarse a cabo de una forma más eficiente y sin comprometer la integridad de los procesos.
Esta agrupación de nodos en función del uso se realiza por dos motivos principales, la priorización en la asignación de tareas a nodos (indicado el orden de prioridad en la siguiente imagen), y la correcta identificación de saturación o infrautilización generalizada de los nodos del clúster. La agrupación es la siguiente:
Como se ha mencionado anteriormente, son dos las grandes ventajas que se consiguen con este tipo de agrupaciones:
Como alternativa a esta agrupación, Databricks ofrece un soporte de almacenamiento externo (External Shuffle Service – ESS) para así tener el grado de saturación del nodo como único factor a tener en cuenta a la hora de decidir qué nodo eliminar en los procesos de scaling-down.
A la hora de poder definir más las características del cluster que aporten más poder de adaptación a las diferentes casuísticas que se puedan dar existe la alternativa que se denomina EC2 Fleet.
Esta se basa en poder solicitar instancias ofreciendo un abanico de posibilidades en cuanto al tipo de instancias (ilimitado) y las availability zones donde se deben adquirir estas. Permite también definir si las instancias son On-Demand o Spot, pudiendo especificar en ambos casos el precio máximo de adquisición:
El uso de EC2 Fleet no supone un coste extra, se paga únicamente por el coste de las instancias.
Existen las siguientes limitaciones relacionadas con este servicio:
Cabe destacar que dicha solución se encuentra en Private-Preview en el momento en el que se escribió este artículo.
Con el fin de posibilitar el despliegue de los cluster de Spark, Databricks recurre a DBFS como sistema de almacenamiento distribuido. Este se apoya en terceros, como es el caso de S3, para así ser capaz tanto de lanzar como de llevar a cabo las tareas requeridas.
DBFS permite la vinculación de fuentes de almacenamiento como S3 mediante los mount, lo que permite simular la visualización de los archivos almacenados en local, aunque estos sigan estando físicamente almacenados en S3. Esta simulación facilita tanto las tareas de autenticación a la hora de consultar los archivos y a su vez la simplificación de los paths a la hora de referenciar los mismos, evitando así tener que cargar los archivos en DBFS cada vez que estos sean consultados.
Además, la información almacenada por el cluster al desplegarse, como puede ser los scripts iniciales, tablas generadas, metadata, etc. Pueden ser almacenados en fuentes de almacenamiento como S3 para que estén disponibles aunque el clúster no lo esté.
A la hora de elegir como y donde desplegar el metastore Databricks propone las siguientes alternativas:
Es importante resaltar que es necesario tener una Customer Managed VPC para las opciones de Hive externo y Glue. Ver primer artículo para más información.
Las alternativas de un metastore externo, ya sea Hive o Glue, podrían ser interesantes en los casos que se necesite acceder a un metastore ya existente, centralizando estos catálogos, o que se busque tener más autonomía y control. También al realizar la implementación con Glue se podría facilitar el acceso a estos metadatos desde otros servicios en AWS, como por ejemplo Athena, y también presenta una latencia de acceso a estos más baja al poder realizar la comunicación a través de la red privada de AWS.
En este apartado se describe brevemente donde poder acceder con detalle a la información acerca de los costes que Databricks va a imputar al cliente.
Para poder acceder a esta información es necesario completar la configuración necesaria para generar y alojar estos logs dentro de la infraestructura desplegada en AWS. Toda esta información puede consultarse en el siguiente enlace [4].
Los logs presentan una generación diaria (debe haber estado operativo el workspace al menos 24 h) en el que se imputan las horas de cómputo y la tarifa que se aplica a dichas horas en función de las características del cluster y el paquete asignado por Databricks.
Campos | Descripción |
---|---|
workspaceId | Workspace Id |
timestamp | Frecuencia establecida (horaria, diaria,...) |
clusterId | Cluster Id |
clusterName | Nombre asignado al Cluster |
clusterNodeType | Tipo de nodo asignado |
clusterOwnerUserId | Id user creador del cluster |
clusterCustomTags | Etiquetas de información personalizables del cluster |
sku | Paquete asignado por Databricks en relación a las características del cluster |
dbus | Consumo de DBUs por hora máquina |
machineHours | Horas máquinas de despliegue del cluster |
clusterOwnerUserName | Username del creador del cluster |
tags | Etiquetas de información personalizables del cluster |
En este apartado se describirán las diferentes alternativas y herramientas que se pueden utilizar para poder desplegar un entorno funcional y seguro de Databricks sobre AWS.
Esta alternativa se caracteriza por la ejecución de un script de CloudFormation creado por Databricks que da la posibilidad de crear una Databricks Managed VPC o Customer Managed VPC.
Para ambas modalidades Databricks crea un cross-account role con los permisos necesarios (que difieren para cada alternativa, siendo los de la opción de Customer Managed VPC más limitados) y crea una Lambda a través de llamadas a las APIs de Databricks para levantar la infraestructura necesaria, configurar esta y registrarla dentro del Control Plane. Todas estas llamadas harán uso del cross-account role para poder autenticarse en la cuenta de AWS del cliente.
CloudFormation
CloudFormation es el servicio de infraestructura como código de AWS. Se podría reutilizar el código creado por Databricks en el Quickstart pero esta alternativa supondría un uso demasiado intensivo de las APIs ya que no existen módulos específicos para el despliegue con Databricks.
Terraform
Terraform es una herramienta de infraestructura como código que es agnóstica a los distintos proveedores de nube, es decir, se puede utilizar con cualquiera de ellos.
Terraform presenta unos módulos disponibles para Databricks que simplifican el despliegue y reducen la necesidad de hacer llamadas a las APIs de Databricks pero que no la eliminan completamente. Por ejemplo, habrá que hacer llamadas a una API para poder utilizar el Credentials Passthrough sin una Identity Provider (SSO).
En esta iniciativa se ha creado un repositorio [5] de GitHub público para poder desplegar un entorno haciendo uso de esta herramienta.
Se ha dividido la infraestructura a desplegar en diferentes módulos por simplicidad, los principales son los siguientes:
Por lo tanto, el diagrama de la arquitectura a alto nivel es el siguiente:
El despliegue completo se puede realizar por debajo de los 5 minutos.
A la hora de estimar un tiempo promedio en el lanzamiento y disponibilidad de las instancias se ha considerado oportuno diferenciar en subgrupos debido a la similitud del tiempo empleado en cada uno de ellos:
En la siguiente tabla se especifican los requisitos mínimos respecto a redes, computación y almacenamiento que desde nuestro punto de vista debe tener un despliegue en cliente. Es importante resaltar que esta presenta diferencias con el repositorio de GitHub presentado en el capítulo de Despliegue.
Las diferencias son las siguientes:
GROUP | SUBGROUP | MINIMUM REQUIREMENTS | EXTERNAL NEEDS |
---|---|---|---|
Networking | Subnets | 3 private subnets with 3 Availability Zones | N/A |
| VPC Endpoints | S3 Gateway Endpoint STS Interface Endpoint
| N/A N/A N/A |
| Private Links | VPC Endpoint for connection Cluster (Data Plane) - Control Plane VPC Endpoint for connection with REST APIs (Control Plane) VPC Endpoint for connection user-frontend (Control Plane) | Contact with authorized Databricks support contact
|
| VPN | Site to site VPN para conectar la red del cliente con la VPC de tránsito | Communication with the customer |
Compute | Minimal instances | Zero with one autoscaling group | N/A |
Storage | Bucket Instances | S3 EBS Volumes | N/A N/A |
Requisitos mínimos necesarios para el despliegue de Databricks en AWS
[1] Databricks on AWS – Architectural Perspective (part 1) [link] (January 13, 2022)
[2] EBS and S3 Encryption on Data Plane [link]
[3] Control Plane Encryption [link]
[4] Billing Logs Access [link]
[5] Databricks Deployment on AWS – GitHub Repository Guide [link]
Inicié mi carrera con el desarrollo, mantenimiento y explotación de bases de datos multidimensionales y Data Lakes. A partir de ahí empecé a interesarme sobre sistemas de datos y arquitecturas en la nube, certificándome en AWS cómo Solutions Architect y entrando en la práctica de Cloud Native dentro de Bluetab.
Actualmente trabajo como Cloud Engineer desarrollando un Data Lake con AWS para una empresa que organiza eventos deportivos internacionales.
Durante los últimos años me he especializado como Data Scientist en distintos sectores (banca, consultoría,…) y la apuesta por cambiar a Bluetab estuvo motivada por el interés en especializarme como Data Engineer y comenzar a trabajar con los principales proveedores Cloud (AWS, GPC y Azure).
Consiguiendo así en primer lugar acceder al grupo de práctica de Data Engineer y colaborar en proyectos reales de data como el actual con Olympics.
Patrono
Patrocinador
© 2022 Bluetab Solutions Group, SL. All rights reserved.