Blog de Amazon Web Services (AWS)

Realización de simulaciones a escala con Amazon SageMaker Processing y R en RStudio

Por Michael Hsieh y Joshua Broyde

El análisis estadístico y la simulación son técnicas predominantes empleadas en diversos campos, como la salud, las ciencias de la vida y los servicios financieros. El lenguaje estadístico de código abierto R y su rico ecosistema con más de 16.000 paquetes han sido una opción ideal para estadísticos, cientificos financieros (quants), científicos de datos e ingenieros de Machine Learning (ML). RStudio es un entorno de desarrollo integrado (IDE) diseñado para la ciencia de datos y estadísticas para los usuarios de R. Sin embargo, un IDE de RStudio alojado en una sola máquina utilizada para el análisis estadístico interactivo diario no es adecuado para simulaciones a gran escala que pueden requerir puntuaciones de GB de RAM (o más). Esto es especialmente difícil para los científicos que desean ejecutar análisis localmente en una computadora portátil o en un equipo de estadísticos que se desarrollan en RStudio en una sola instancia.

En este post, te mostramos una solución que te permite descargar una simulación de Monte Carlo que requiere muchos recursos a máquinas más potentes, sin dejar de poder desarrollar tus scripts en tu IDE de RStudio. Esta solución aprovecha el procesamiento de Amazon SageMaker.

Amazon SageMaker y SageMaker Processing

Amazon SageMaker es un servicio totalmente gestionado que ofrece a todos los desarrolladores y científicos de datos la capacidad de crear, entrenar e implementar modelos de ML rápidamente. SageMaker elimina el trabajo pesado de cada paso del proceso de ML para facilitar el desarrollo de artefactos ML de alta calidad. Ejecutar cargas de trabajo en SageMaker es fácil. Cuando esté listo para colocar un modelo en SageMaker, simplemente especifique la ubicación de sus datos en Amazon Simple Storage Service (Amazon S3) e indique el tipo y la cantidad de instancias de SageMaker ML que necesita. SageMaker configura un clúster de cómputo distribuido, realiza la entrenamiento, envía el resultado a Amazon S3 y destruye el clúster cuando se complete.

SageMaker Processing le permite realizar de forma rápida y sencilla el preprocesamiento y el postprocesamiento de datos utilizando sus propios scripts o modelos de ML. Este caso de uso se ajusta al patrón de muchos usuarios de R y RStudio, que con frecuencia realizan análisis estadísticos personalizados utilizando su propio código. SageMaker Processing utiliza la infraestructura de la nube de AWS para desacoplar el desarrollo del script R de su despliegue y le ofrece flexibilidad para elegir la instancia en la que se despliega. Ya no está limitado a las limitaciones de memoria RAM y espacio en disco de la máquina en la que desarrolla; puede implementar la simulación en una instancia más grande de su elección.

Otra ventaja importante de usar SageMaker Processing es que solo se le facturará (por segundo) el tiempo y los recursos que utiliza. Cuando el script termine de ejecutarse, los recursos son apagados y ya no se le facturará más allá de ese tiempo.

Los estadísticos y los científicos de datos que utilizan el lenguaje R pueden acceder a las funciones de SageMaker y a la capacidad de escalar su carga de trabajo a través de la biblioteca Reticulate, que proporciona una interfaz R a la biblioteca SDK de SageMaker Python . Reticulate incrusta una sesión de Python dentro de su sesión R, lo que permite una interoperabilidad perfecta y de alto rendimiento. El paquete Reticulate proporciona una interfaz R para realizar llamadas API a SageMaker con el SDK de Python de SageMaker. Utilizamos Reticulate para interactuar con SageMaker Python SDK en esta publicación.

También puede acceder a SageMaker y a otros servicios de AWS a través de Paws. Paws no es un SDK oficial de AWS, pero cubre la mayor parte de la misma funcionalidad que los SDK oficiales para otros lenguajes. Para obtener más información sobre cómo acceder a los recursos de AWS mediante Paws, consulte Introducción a R en Amazon Web Services.

En esta publicación, demostramos cómo ejecutar programas R nativos no distribuidos con SageMaker Processing. Si ha distribuido casos de uso informáticos utilizando Spark y SparkR dentro de RStudio, puede utilizar Amazon EMR para encender la instancia de RStudio. Para obtener más información, consulte las siguientes publicaciones:

 

Caso de uso

En muchos casos de uso, se desean instancias informáticas más potentes para los desarrolladores que realizan análisis en RStudio. Para este post, consideramos el siguiente caso de uso: los estadísticos de su equipo han desarrollado una simulación Monte Carlo en el IDE de RStudio. El programa requiere algunas bibliotecas R y se ejecuta sin problemas con un pequeño número de iteraciones y cálculos. Los estadísticos son cautelosos al ejecutar una simulación completa porque RStudio se está ejecutando en una instancia de Amazon Elastic Compute Cloud (Amazon EC2) compartida por otros 10 estadísticos del mismo equipo. Todos están ejecutando análisis R a una escala determinada, lo que hace que la instancia esté muy ocupada la mayor parte del tiempo. Si alguien inicia una simulación a gran escala, ralentiza la sesión de RStudio de todos y posiblemente congela la instancia de RStudio.

Incluso para un solo usuario, ejecutar una simulación a gran escala en una instancia EC2 pequeña o mediana es un problema que esta solución puede resolver.

Para recorrer la solución para este caso de uso, diseñamos una simulación Monte Carlo: dado un área de cierta anchura y longitud y un cierto número de personas, la simulación coloca aleatoriamente a las personas en la zona y calcula el número de violaciones de distanciamiento social; cada vez que una persona se encuentra dentro de 6 unidades de otro, se cuentan dos violaciones (porque cada persona está violando las reglas de distancia social). A continuación, la simulación calcula la violación promedio por persona. Por ejemplo, si hay 10 personas y dos violaciones, el promedio es 0.2. Cuántas violaciones ocurren también depende de cómo se posicionan las personas en el área. Las personas pueden ser agrupadas, causando muchas violaciones, o extenderse, causando menos violaciones. La simulación realiza muchas iteraciones de este experimento, colocando aleatoriamente personas en el área para cada iteración (esta es la característica que la convierte en una simulación de Monte Carlo).

Resumen de la solución

Con un par de líneas de código R y un contenedor Docker que encapsula las dependencias de tiempo de ejecución, puede enviar el programa de simulación a la infraestructura de cómputo de SageMaker completamente administrada con los recursos informáticos deseados a escala. Puede enviar interactivamente el script de simulación desde RStudio alojado en una instancia de EC2 a SageMaker Processing con un contenedor Docker definido por el usuario alojado en Amazon Elastic Container Registry (Amazon ECR) y datos ubicados en Amazon S3 (analizamos los conceptos básicos del contenedor Docker en la Creación de un contenedor R en RStudio IDE y alojarlo en la sección Amazon ECR ). SageMaker Processing se encarga de aprovisionar la infraestructura, ejecutar la simulación, leer y guardar los datos en Amazon S3, y realiza el apagado de recurso sin que se preste atención manual a la infraestructura.

El siguiente diagrama ilustra esta arquitectura de solución.

Despliegue de los recursos

Primero desplegamos un servidor RStudio en una instancia EC2 dentro de una VPC utilizando una plantilla de AWS CloudFormation , que se basa en gran medida en la publicación Utilizando R con Amazon SageMaker con algunas modificaciones. Además del servidor RStudio, instalamos el motor Docker, el SDK de SageMaker para Python y Reticulate como parte de la implementación. Para desplegar los recursos, siga los pasos siguientes:

  1. Descargar la plantilla CloudFormation
  2. En la consola de AWS CloudFormation, seleccione Plantilla está lista (Template is ready).
  3. Selecciona Subir un archivo de plantilla (Upload a template file).
  4. Elija Elegir archivo (Choose file).
  5. Cargue la plantilla ec2_ubuntu_rstudio_sagemaker.yaml proporcionada.

La plantilla está diseñada para funcionar en las siguientes regiones:

  • us-east-1
  • us-east-2
  • us-west-2
  • eu-west-1

En el archivo YAML, puede cambiar el tipo de instancia a una instancia diferente. Para esta carga de trabajo, recomendamos una instancia no menor que una t3.xlarge para ejecutar RStudio sin problemas.

6. Elija Siguiente (Next).

7. En Nombre de stack (Stack name), escriba un nombre para el stack.

8. Para AcceptrStudioLicenseAndInstall, revise y acepte la licencia AGPL v3 para instalar RStudio Server en Amazon EC2.

9. En KeyName, introduzca un par de claves de Amazon EC2 que haya generado previamente para acceder a una instancia de Amazon EC2.

Para obtener instrucciones sobre la creación de un par de claves, consulte los pares de claves de Amazon EC2 e instancias de Linux.

10. Elija Siguiente (Next).

11. En la sección Configurar opciones de pila (Configure stack options) , mantenga todo en sus valores predeterminados.

12. Elija Siguiente (Next).

13. Revise los detalles de la pila y elija Crear stack (Create stack).

La creación del stack tarda unos 15-20 minutos en completarse.

14. Cuando haya finalizado la creación del stack, vaya a la ficha Salidas (Outputs) de la pila en la consola de AWS CloudFormation para encontrar la URL de inicio de sesión IDE de RStudio:

ec2-xx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com:8787.

15. Copia la URL e introdúzala en tu navegador preferido.

A continuación, debe ver la página de inicio de sesión de RStudio, como en la siguiente captura de pantalla.

16. Inicie sesión en la instancia de RStudio con el nombre de usuario ubuntu y la contraseña rstudio7862.

Esta configuración es para fines de demostración. Utilizar una instancia de EC2 orientada al público y una simple credencial de inicio de sesión no es la mejor práctica de seguridad para hospedar su instancia de RStudio.

Ahora clona el repositorio de código a través del terminal de línea de comandos en el IDE de RStudio.

17. Cambie a la pestaña Terminal y ejecute el comando:

git clone https://github.com/aws-samples/amazon-sagemaker-statistical-simulation-rstudio.git

Este repositorio contiene los scripts relevantes necesarios para ejecutar las simulaciones y los archivos para crear nuestro contenedor Docker.

Ejecutar pequeñas simulaciones localmente

En la consola R (ficha Console), introduzca el siguiente código para establecer el directorio de trabajo en la ubicación correcta e instalar algunas dependencias:

setwd("~/amazon-sagemaker-statistical-simulation-rstudio/Submit_SageMaker_Processing_Job/")
install.packages(c('doParallel'))

Para fines ilustrativos, ejecutamos pequeñas simulaciones en la máquina de desarrollo (la instancia EC2 en la que está instalado RStudio). También puede encontrar el siguiente código en el script Local_Simulation_Commands.R.

En la consola R, ejecutamos una simulación muy pequeña con 10 iteraciones:

# takes about: 5.5 seconds
max_iterations <- 10
x_length <- 1000
y_length <- 1000
num_people <- 1000

local_simulation <- 1 # we are running the simulation locally on 1 vCPU
cmd = paste('Rscript Social_Distancing_Simulations.R --args',paste(x_length),paste(y_length), paste(num_people),paste(max_iterations),paste(local_simulation), sep = ' ')
result = system(cmd)

El resultado es un número medio de 0.11 violaciones por persona, y el tiempo que tomó calcular este resultado fue de aproximadamente 5.5 segundos en un t3.xlarge (el número preciso de violaciones por persona y el tiempo que tarda en realizar la simulación puede variar).

Puede jugar con la ejecución de esta simulación con diferentes números de iteraciones. Cada aumento de diez veces corresponde a aproximadamente un aumento de diez veces en el tiempo necesario para la simulación. Para probar esto, ejecuté esta simulación con 10.000 iteraciones, y terminó después de 1 hora y 33 minutos. Es evidente que se necesita un mejor enfoque para los desarrolladores. (Si está interesado en ejecutarlos, puede encontrar el código en Local_Simulation_Commands.R.)

Creación de un contenedor R en RStudio IDE y alojarlo en Amazon ECR

SageMaker Processing ejecuta sus scripts R con un contenedor Docker en una infraestructura de cómputo remota. En esta sección, ofrecemos una introducción a Docker, cómo crear una imagen de contenedor Docker y cómo alojarla en AWS para utilizarla en SageMaker Processing.

Docker es una plataforma de software que le permite crear una vez e implementar aplicaciones rápidamente en cualquier entorno informático. Docker empaqueta el software en unidades estandarizadas denominadas contenedores que tienen todo lo que el software necesita para ejecutar, incluidas bibliotecas, herramientas del sistema, código y tiempo de ejecución. Los contenedores Docker proporcionan aislamiento y portabilidad para su carga de trabajo.

Una imagen Docker es una plantilla de sólo lectura que define su contenedor. La imagen contiene el código que se va a ejecutar, incluidas las bibliotecas y dependencias que su código necesite. Docker crea imágenes leyendo las instrucciones de un Dockerfile, que es un documento de texto que contiene todos los comandos a los que puede llamar en la línea de comandos para ensamblar una imagen. Puede crear sus imágenes de Docker desde cero o basarlas en otras imágenes de Docker que usted u otros hayan creado.

Las imágenes se almacenan en repositorios indexados y mantenidos por los registros. Una imagen se puede introducir o extraer de un repositorio utilizando su dirección de registro, que es similar a una URL. AWS proporciona Amazon ECR, un registro de contenedores Docker totalmente gestionado que facilita el almacenamiento, la gestión y la implementación de imágenes de contenedores de Docker.

Supongamos que Social_Distancing_Simulations.R fue desarrollado originalmente con R 3.4.1 Single Candle a partir de una versión de RStudio en ubuntu 16.04. El programa utiliza la biblioteca doParallel para fines de paralelismo. Queremos ejecutar la simulación utilizando un clúster informático remoto exactamente como se desarrolló. Necesitamos instalar todas las dependencias en el clúster remoto, que puede ser difícil de escalar, o construir una imagen Docker que tenga todas las dependencias instaladas en las capas y ejecutarla en cualquier lugar como contenedor.

En esta sección, creamos una imagen Docker que tiene un intérprete R con bibliotecas dependientes para ejecutar la simulación y enviar la imagen a Amazon ECR para que, con la imagen, podamos ejecutar nuestro script R de la manera exacta en cualquier máquina que pueda o no tener instalados los paquetes R o R compatibles, siempre y cuando haya un motor Docker en el sistema host. El siguiente código es el Dockerfile que describe los requerimientos de tiempo de ejecución y cómo se debe ejecutar el contenedor.

#### Dockerfile
FROM ubuntu:16.04

RUN apt-get -y update && apt-get install -y --no-install-recommends \
    wget \
    r-base \
    r-base-dev \
    apt-transport-https \
    ca-certificates

RUN R -e "install.packages(c('doParallel'), repos='https://cloud.r-project.org')"

ENTRYPOINT ["/usr/bin/Rscript"]

Cada línea es una instrucción para crear una capa para la imagen:

  • FROM crea una capa a partir de la  imagen ubuntu:16.04 Docker
  • RUN ejecuta líneas de comandos de shell para crear una nueva capa
  • ENTRYPOINT le permite configurar cómo se puede ejecutar un contenedor como ejecutable

Dockerfile describe qué dependencia (ubuntu 16.04, r-base o doParallel) se debe incluir en la imagen del contenedor.

A continuación, necesitamos construir una imagen Docker desde el archivo Dockerfile, crear un repositorio ECR y enviar la imagen al repositorio para su uso posterior. El script de shell proporcionado build_and_push_docker.sh realiza todas estas acciones. En esta sección, recorremos los pasos del script.

Ejecute el script principal build_and_push_docker.sh que preparamos para usted en el terminal:

cd /home/ubuntu/amazon-sagemaker-statistical-simulation-rstudio/
sh build_and_push_docker.sh r_simulation_container v1

El script de shell toma dos argumentos de entrada: un nombre para la imagen del contenedor y el repositorio, seguido de un nombre de etiqueta. Puede reemplazar el nombre r_simulation_container por otra cosa si lo desea. v1 es la etiqueta del contenedor, que es la versión del contenedor. Puedes cambiar eso también. Si lo hace, recuerde cambiar el repositorio y el nombre de la imagen correspondientes más adelante.

Si todo va bien, debería ver muchas acciones y resultados que indican que Docker está construyendo y empujando las capas al repositorio, seguido de un mensaje como lo siguiente:

v1: digest: sha 256:91 adaeb03ddc650069ba8331243936040c09e142ee3cd360b7880bf0779700b1 size: 1573

Puede recibir advertencias sobre el almacenamiento de credenciales. Estas advertencias no interfieren con publicar el contenedor a ECR, pero se pueden reparar. Para obtener más información, consulte Almacén de credenciales.

En el script, el comando docker build construye la imagen y sus capas siguiendo las instrucciones del archivo Dockerfile:

#### In build_and_push_docker.sh
docker build -t $image_name .

Los siguientes comandos interactúan con Amazon ECR para crear un repositorio:

#### In build_and_push_docker.sh
# Get the AWS account ID
account=$(aws sts get-caller-identity --query Account --output text)

# Get the region defined in the current configuration (default to us-west-2 if none defined)
region=$(aws configure get region)
region=${region:-us-west-2}

# Define the full image name on Amazon ECR
fullname="${account}.dkr.ecr.${region}.amazonaws.com/${image_name}:${tag}"

# If the repository doesn't exist in ECR, create it.
aws ecr describe-repositories --repository-names "${image_name}" > /dev/null 2>&1

if [ $? -ne 0 ]
then
    aws ecr create-repository --repository-name "${image_name}" > /dev/null
fi

# Obtener el comando login de ECR y ejecutarlo directamenteaws ecr get-login-password --region ${region} \
  | docker login \
      --username AWS \
      --password-stdin ${account}.dkr.ecr.${region}.amazonaws.com

Finalmente, el script etiqueta la imagen y la publica en el repositorio ECR:

#### In build_and_push_docker.sh
# Tag and push the local image to Amazon ECR
docker tag ${image_name} ${fullname}
docker push ${fullname}

En este punto, hemos creado un contenedor y lo hemos publicado en un repositorio en Amazon ECR. Podemos confirmar que existe en la consola de Amazon ECR.

Copie y guarde el URI para la imagen; lo necesitamos en un paso posterior.

Podemos usar esta imagen repetidamente para ejecutar cualquier script R que use doParallel. Si tiene otras dependencias, ya sea paquetes nativos de R que se pueden descargar e instalar desde CRAN (Comprehensive R Archive Network) con install.packages () o paquetes que tienen otras dependencias en tiempo de ejecución. Por ejemplo, RStan, un paquete probabilístico que implementa una inferencia estadística bayesiana completa a través de Markov Chain Monte Carlo que depende de Stan y C++, se puede instalar en una imagen Docker traduciendo sus instrucciones de instalación en un Dockerfile.

Modificación del R para SageMaker Processing

A continuación, tenemos que modificar el script de simulación existente para que pueda hablar con los recursos disponibles para el contenedor en ejecución en la infraestructura de cómputo de procesamiento de SageMaker. El recurso que necesitamos para hacer que el script sea consciente es típicamente los datos de entrada y salida de los buckets S3. La API de procesamiento de SageMaker le permite especificar dónde están los datos de entrada y cómo deben ser mapeados al contenedor para que pueda acceder mediante programación en el script.

Por ejemplo, en el siguiente diagrama, si especifica los datos de entrada s3: //bucket/path/to/input_data que se asignarán a /opt/ml/processing/input, puede acceder a los datos de entrada dentro del script y el contenedor en /opt/ml/processing/input. SageMaker Processing administra la transferencia de datos entre los buckets S3 y el contenedor. Del mismo modo, para la salida, si necesita persistir cualquier artefacto, puede guardarlos en /opt/ml/processing/output dentro del script. Los archivos están disponibles en s3: //bucket/ruta/to/output_data.

El único cambio para el script Social_Distancing_Simulations.R es donde se escribe el archivo de salida. En lugar de una ruta de archivo en la instancia local EC2, la cambiamos para escribir en /opt/ml/processing/output/output_result_mean.txt.

Envío de su script R a SageMaker Processing

Simulaciones muy grandes pueden ser lentas en una máquina local. Como vimos anteriormente, hacer 10.000 iteraciones de la simulación de distanciamiento social tarda aproximadamente 1 hora y 33 minutos en la máquina local usando 1 vCPU. Ahora estamos listos para ejecutar la simulación con SageMaker Processing.

Con SageMaker Processing, podemos utilizar la infraestructura de cómputo remota para ejecutar la simulación y liberar los recursos informáticos locales. SageMaker levanta una infraestructura de procesamiento, toma el script, copia los datos de entrada de Amazon S3 (si los hay) y extrae la imagen del contenedor de Amazon ECR para realizar la simulación.

SageMaker administra completamente la infraestructura subyacente para un trabajo de procesamiento. Los recursos de clúster se aprovisionan durante el trabajo y se limpian cuando se completa un trabajo. La salida del trabajo de procesamiento se almacena en el bucket de S3 especificado. Puede tratar su instancia de RStudio como una estación de lanzamiento para enviar simulaciones a computación remota con varios parámetros o conjuntos de datos de entrada.

Se puede acceder a la API completa de SageMaker a través de la biblioteca Reticulate , que proporciona una interfaz R para realizar llamadas al SDK de SageMaker para Python. Para orquestar estos pasos, utilizamos otro script R.

Copie el siguiente código en la consola de RStudio. Establezca la variable container con en el URI del contenedor con la etiqueta (recuerde incluir la etiqueta, y no solo el contenedor). Debería verse como

xxxxxxxxxxxx.dkr.ecr.US-west-2.amazonaws.com/r_simulation_container:V1.

Puede recuperar este URI desde la consola de Amazon ECR seleccionando el repositorio r_simulation_container y copiando el URI relevante del campo URI de imagen (image URI  field) (este código también se encuentra en el script SageMaker_Processing_SDS.r ):

library(reticulate)




use_python('/usr/bin/python') # aquí es donde instalamos el SDK de Python de SageMaker

sagemaker <- import('sagemaker')

session <- sagemaker$Session()

bucket <- session$default_bucket()

role_arn <- sagemaker$get_execution_role()




## usando r_container

container <- 'URI TO CONTAINER AND TAG' # se puede encontrar en $ imágenes docker. Recuerde incluir la etiqueta




# una sola ejecución

processor <- sagemaker$processing$ScriptProcessor(role = role_arn,

                                                  image_uri = container,

                                                  command = list('/usr/bin/Rscript'),

                                                  instance_count = 1L,

                                                  instance_type = 'ml.m5.4xlarge',

                                                  volume_size_in_gb = 5L,

                                                  max_runtime_in_seconds = 3600L,

                                                  base_job_name = 'social-distancing-simulation',

                                                  sagemaker_session = session)




max_iterations <- 10000

x_length <- 1000

y_length <- 1000

num_people <- 1000

x_length <- 1000

y_length <- 1000

num_people <- 1000




is_local <- 0 #we are going to run this simulation with SageMaker processing

result=processor$run(code = 'Social_Distancing_Simulations.R',

              outputs=list(sagemaker$processing$ProcessingOutput(source='/opt/ml/processing/output')),

              arguments = list('--args', paste(x_length), paste(y_length), paste(num_people), paste(max_iterations),paste(is_local)),

              wait = TRUE,

              logs = TRUE)

En el código anterior, estamos descargando el trabajo pesado de simulación a una instancia remota de EC2 más grande (instance_type = ‘ml.m5.4xlarge’). No solo no consumimos recursos informáticos locales, sino que también tenemos la oportunidad de elegir de forma óptima una instancia del tamaño correcto para realizar la simulación por trabajo. La máquina en la que ejecutamos esta simulación es una instancia de propósito general con 64 GB de RAM y 16 CPU virtuales. La simulación se ejecuta más rápido en la instancia del tamaño correcto. Por ejemplo, cuando usamos ml.m5.4xlarge (64 GB RAM y 16 vCPU), la simulación tomó 10.8 minutos. A modo de comparación, realizamos exactamente la misma simulación en la máquina de desarrollo local usando solo 1 vCPU y la misma simulación tomó exactamente 93 minutos.

Si desea ejecutar otra simulación que sea más compleja, con más iteraciones o con un dataset más grande, no necesita detener y cambiar el tipo de instancia EC2. Puede cambiar fácilmente la instancia con el argumento instance_type a una instancia más grande para obtener más RAM o CPU virtuales, o a una instancia optimizada de cómputo, como ml.c5.4xlarge, para obtener un alto rendimiento rentable a un precio bajo por relación de capacidad de cómputo.

Configuramos nuestro trabajo (estableciendo wait = TRUE) para que se ejecute sincrónicamente. El intérprete de R está ocupado hasta que se complete la simulación, aunque el trabajo se esté ejecutando en un proceso remoto. En muchos casos (como simulaciones que duran muchas horas) es más útil establecer wait = FALSE para ejecutar el trabajo de forma asíncrona. Esto le permite continuar con su script y realizar otras tareas dentro de RStudio mientras la simulación de trabajo pesado se realiza a través del trabajo de procesamiento de SageMaker.

Puede inspeccionar y supervisar el progreso de sus trabajos en la página Trabajos de procesamiento (Processing jobs) de la consola de SageMaker (también puede supervisar los trabajos mediante llamadas API).

La siguiente captura de pantalla muestra los detalles de nuestro trabajo.

La sección Monitoreo proporciona vínculos a los registros de Amazon CloudWatch para sus trabajos. Esta característica importante le permite supervisar los registros casi en tiempo real a medida que se ejecuta el trabajo, y tomar las medidas necesarias si se detectan errores o bugs.

Dado que los registros se reportan casi en tiempo real, no tiene que esperar hasta que se complete un trabajo completo para detectar problemas; puede confiar en los registros emitidos.

Para obtener más información acerca de cómo SageMaker Processing ejecuta la imagen del contenedor y el script de simulación, consulte How Amazon SageMaker Processing Runts Your Processing Container Image.

Acceder a los resultados de simulación desde su script R

El trabajo de procesamiento escribe sus resultados en Amazon S3; puede controlar lo que es escrito y en qué formato es escrito. El contenedor Docker en el que se ejecuta el trabajo de procesamiento escribe los resultados en el directorio /opt/ml/processing/output; esto se copia en Amazon S3 cuando se completa el trabajo de procesamiento. En el script Social_Distancing_Simulations.R , escribimos la media de toda la ejecución de simulación (este número corresponde al número medio de violaciones por persona en la sala). Para acceder a esos resultados, introduzca el código siguiente (este código también está en la secuencia de comandos SageMaker_Processing_SDS.r ):

get_job_results <- function(session,processor){
    #get the mean results of the simulation
    the_bucket=session$default_bucket()
    job_name=processor$latest_job$job_name
    cmd=capture.output(cat('aws s3 cp s3://',the_bucket,"/",job_name,"/","output/output-1/output_result_mean.txt .",fill = FALSE,sep="")
    )
    system(cmd)
    my_data <- read.delim('output_result_mean.txt',header=FALSE)$V1
    return(my_data)
    }

simulation_mean=get_job_results(session,processor)
cat(simulation_mean) #displays about .11

En el código anterior, señalamos el bucket S3 donde se almacenan los resultados, leemos el resultado y lo mostramos. Para nuestro caso de uso, nuestro trabajo de procesamiento solo escribe la media de los resultados de la simulación, pero también puede configurarlo para escribir otros valores.

En la siguiente tabla se compara el tiempo total que nos llevó realizar la simulación en la máquina local una vez, así como otras dos instancias que puede utilizar para SageMaker Processing. Para estas simulaciones, el número de iteraciones cambia, pero x_length, y_lengthy num_people equivale a 1000 en todos los casos.

Tipo de instancia
Número de iteraciones t3.xlarge (máquina local) ml.m5.4xlarge (Procesamiento SageMaker) ml.m5.24xlarge (Procesamiento SageMaker)
10 5.5 (segundos) 254 285
100 87 284 304
1.000 847 284 253
10.000 5602 650 430
100.000 No probado. No probado. 1411

Para realizar pruebas en la máquina local, restringimos el número de CPU virtuales (vCPU) a 1; el t3.xlarge tiene 4 vCPU. Esta restricción imita un patrón común en el que una máquina grande es compartida por varios estadísticos, y un estadístico podría no distribuir el trabajo a varias CPU por temor a ralentizar el trabajo de sus colegas. Para el tiempo de las instancias ml.m5.4xlarge y ml.m5.24xlarge, utilizamos todas las vCPU e incluimos el tiempo que toma SageMaker Processing para que aparezca la instancia solicitada y escriba los resultados, además del tiempo necesario para realizar la simulación en sí. Realizamos cada simulación una vez.

Como puede ver en la tabla, las máquinas locales son más eficientes para menos iteraciones, pero las máquinas más grandes que utilizan SageMaker Processing son más rápidas cuando el número de iteraciones llega a 1.000 o más.

(Opcional) Protección de la carga de trabajo en la VPC

Hasta ahora, hemos enviado los trabajos de procesamiento de SageMaker a una VPC administrada por SageMaker y accedido a los depósitos de S3 a través de Internet público. Sin embargo, en los sectores de la salud, las ciencias biológicas y los servicios financieros, generalmente se requiere ejecutar cargas de trabajo de producción en una VPC privada con una configuración de red estricta por motivos de seguridad. Es una práctica recomendada en materia de seguridad lanzar sus trabajos de procesamiento de SageMaker en una VPC privada donde pueda tener más control sobre la configuración de red y acceder a los buckets de S3 a través de un punto de conexión VPC de Amazon S3. Para obtener más información e instrucciones de configuración, consulte Conceder acceso a los recursos de los trabajos de procesamiento de SageMaker en su Amazon VPC.

Hemos aprovisionado un punto de conexión VPC de Amazon S3 conectado a la VPC como parte de la plantilla de CloudFormation. Para iniciar un trabajo en una VPC privada, necesitamos agregar la configuración de red a un argumento adicional network_config a la construcción ScriptProcessor :

subnet <- 'subnet-xxxxxxx'  # can be found in CloudFormation > Resources
security_group <- 'sg-xxxxxxx'  # can be found in CloudFormation > Resources
network <- sagemaker$network$NetworkConfig(subnets = list(subnet), 
                                           security_group_ids = list(security_group),
                                           enable_network_isolation = TRUE)

processor <- sagemaker$processing$ScriptProcessor(..., network_config = network)

Cuando ejecuta el método processor$run (…), el trabajo de procesamiento de SageMaker se ve obligado a ejecutarse dentro de la VPC especificada en lugar de en la VPC administrada por SageMaker, y acceder al bucket de S3 a través del endpoint de Amazon S3 VPC en lugar de Internet público.

Limpieza

Cuando complete esta publicación, elimine el stack de la consola de AWS CloudFormation seleccionando la pila y eligiendo Eliminar. Esto limpia todos los recursos que creamos para esta publicación.

Conclusión

En este post, presentamos una solución usando SageMaker Processing como una extensión de recursos informáticos para los usuarios de R que realizan cargas de trabajo estadísticas en RStudio. Puede obtener la escalabilidad que desee con unas pocas líneas de código para llamar a la API de SageMaker y una imagen de contenedor de Docker reutilizable, sin salir de su IDE de RStudio. También mostramos cómo puede lanzar trabajos de procesamiento de SageMaker en su propia VPC privada por motivos de seguridad.

Una pregunta que usted podría estar haciendo es: ¿Por qué el científico de datos debería molestarse en presentar un puesto de trabajo en primer lugar? ¿Por qué no simplemente ejecutar RStudio en una instancia muy, muy grande que pueda manejar las simulaciones localmente? La respuesta es que aunque esto es técnicamente posible, podría ser costoso y no se escala a equipos de tamaños pequeños. Por ejemplo, supongamos que su empresa tiene 10 estadísticos que necesitan ejecutar simulaciones que utilizan hasta 60 GB de RAM; necesitan ejecutar en total 1,200 horas totales (50 días seguidos) de simulaciones. Si cada estadístico se aprovisiona con su propia instancia m5.4xlarge para una operación ininterrumpida, cuesta alrededor de 10 * 24 * 30 * 0.768$ = 5,529$ al mes (precios de Amazon EC2 bajo demanda en us-west-2 a partir de diciembre de 2020). En comparación, el aprovisionamiento de una instancia m5.4xlarge para que sea compartida por 10 estadísticos para realizar análisis exploratorios y enviar simulaciones a gran escala en SageMaker Processing cuesta solo 553 USD al mes en Amazon EC2, y 1,290 dólares adicionales para las 1,200 horas totales de simulación en ml.m5.4xlarge SageMaker ML instancias (1,075 USD por hora).

Para obtener más información acerca de R y SageMaker, consulte la Guía del usuario de R de Amazon SageMaker. Para obtener más información sobre los precios de procesamiento de SageMaker, consulte la pestaña Procesamiento en Precios de Amazon SageMaker.

Este artículo fue traducido del Blog de AWS en Inglés


Sobre los Autores

Michael Hsieh es un Arquitecto de Soluciones Especialista en AI/ML Senior. Trabaja con los clientes para avanzar en su trayectoria de ML con una combinación de ofertas de AWS ML y sus conocimientos de dominio ML. Como trasplante de Seattle, le encanta explorar la gran madre naturaleza que la ciudad tiene para ofrecer, como rutas de senderismo, kayak en paisajes en la SLU y la puesta de sol en la bahía de Shilshole.

 

 

 

 

Joshua Broyde es Arquitecto de Soluciones Especializadas en AI/ML en el equipo global de salud y ciencias biológicas de Amazon Web Services. Trabaja con clientes de salud y ciencias de la vida en varios frentes AI/ML, incluyendo el análisis de imágenes médicas y video, el análisis de datos de sensores de máquinas y la realización de procesamiento en lenguaje natural de textos médicos y sanitarios.

 

 

 

 

Edzon Sanchez es Arquitecto de Soluciones en AWS México.