O blog da AWS
Realizando simulações em escala com o Amazon SageMaker Processing e R no RStudio
Por Michael Hsieh e Joshua Broyde
A análise estatística e a simulação são técnicas predominantemente empregadas em diversas áreas, como saúde, ciências da vida e serviços financeiros. A linguagem estatística de código aberto R e seu rico ecossistema com mais de 16.000 pacotes tem sido a melhor escolha para estatísticos, analistas quantitativos, cientistas de dados e engenheiros de aprendizado de máquina (ML). RStudio é um ambiente de desenvolvimento integrado (IDE) projetado para ciência de dados e estatísticas para usuários de R. No entanto, uma IDE de RStudio hospedada em uma única máquina usada para análise estatística interativa do dia-a-dia, não é adequada para simulações em grande escala que podem exigir GB de RAM (ou mais). Isso é especialmente difícil para os cientistas que desejam executar análises localmente em um laptop ou em uma equipe de estatísticos que desenvolvem em uma única instância no RStudio.
Neste post, mostramos uma solução que permite você transferir uma simulação de Monte Carlo com uso intensivo de recursos para máquinas mais poderosas, enquanto ainda é capaz de desenvolver seus scripts na sua IDE RStudio. Essa solução aproveita o processamento do Amazon SageMaker.
Amazon SageMaker e SageMaker Processing
O Amazon SageMaker é um serviço totalmente gerenciado que oferece a todos os desenvolvedores e cientistas de dados a capacidade de criar, treinar e implantar modelos de ML rapidamente. O SageMaker remove o trabalho pesado de cada etapa do processo de ML para facilitar o desenvolvimento de artefatos de ML de alta qualidade. Executar cargas de trabalho no SageMaker é fácil. Quando estiver pronto para ajustar um modelo no SageMaker, basta especificar a localização dos seus dados no Amazon Simple Storage Service (Amazon S3) e indicar o tipo e a quantidade de instâncias do SageMaker ML necessárias. O SageMaker configura um cluster de computação distribuído, executa o treinamento, gera o resultado para o Amazon S3 e finaliza o cluster quando concluído.
O SageMaker Processing permite que você execute de forma rápida e fácil o pré-processamento e o pós-processamento em dados usando seus próprios scripts ou modelos de ML. Esse caso de uso se encaixa no padrão de muitos usuários R e RStudio, que freqüentemente realizam análises estatísticas personalizadas usando seu próprio código. O SageMaker Processing usa a infraestrutura da Nuvem AWS para desacoplar o desenvolvimento do script R de sua implantação e oferece flexibilidade para escolher a instância em que foi implantada. Você não está mais limitado às limitações de RAM e espaço em disco da máquina em que você desenvolve; você pode implantar a simulação em uma instância maior de sua escolha.
Outra grande vantagem de usar o SageMaker Processing é que você só é cobrado (por segundo) pelo tempo e recursos usados. Quando o script terminar de ser executado, os recursos são desativados e você não será mais cobrado além desse tempo.
Estatísticos e cientistas de dados que usam a linguagem R podem acessar os recursos do SageMaker e a capacidade de dimensionar sua carga de trabalho por meio da biblioteca Reticulate, que fornece uma interface R para a biblioteca do SDK do SageMaker Python . O Reticulate incorpora uma sessão Python na sua sessão de R, permitindo uma interoperabilidade contínua e de alto desempenho. O pacote Reticulate fornece uma interface R para fazer chamadas de API para o SageMaker com o SDK Python do SageMaker. Usamos o Reticulate para interagir com o SDK do SageMaker Python neste post.
Como alternativa, você pode acessar o SageMaker e outros serviços da AWS por meio do Paws. Paws não é um SDK oficial da AWS, mas abrange a maioria das mesmas funcionalidades que os SDKs oficiais para outras linguagens. Para obter mais informações sobre como acessar recursos da AWS usando Paws, consulte Introdução ao R na Amazon Web Services.
Neste post, demonstramos como executar programas R nativos não distribuídos com o SageMaker Processing. Se você tiver casos de uso de computação distribuídos usando Spark e SparKr no RStudio, você pode usar o Amazon EMR para inicializar sua instância do RStudio. Para saber mais, consulte as seguintes publicações:
- Análise estatística com R de código aberto e RStudio no Amazon EMR
- Implante um nó de borda do Amazon EMR com o RStudio usando o AWS Systems Manager
Caso de uso
Em muitos casos de uso, instâncias de computação mais poderosas são desejadas por desenvolvedores que realizam análises no RStudio. Para este post, consideramos o seguinte caso de uso: os estatísticos da sua equipe desenvolveram uma simulação de Monte Carlo no IDE RStudio. O programa requer algumas bibliotecas R e é executado sem problemas com um pequeno número de iterações e cálculos. Os estatísticos estão cautelosos sobre a execução de uma simulação completa porque o RStudio está sendo executado em uma instância do Amazon Elastic Compute Cloud (Amazon EC2) compartilhada por 10 outros estatísticos da mesma equipe. Você está executando análises R em uma determinada escala, o que torna a instância muito ocupada na maioria das vezes. Se alguém iniciar uma simulação em grande escala, ela retarda a sessão do RStudio de todos e possivelmente congela a instância do RStudio.
Mesmo para um único usuário, executar uma simulação em grande escala em uma única instância do EC2 de pequeno ou médio porte é um problema que essa solução pode resolver.
Para demonstrar a solução para este caso de uso, projetamos uma simulação de Monte Carlo: dada uma área de certa largura e comprimento e um certo número de pessoas, a simulação coloca aleatoriamente as pessoas na área e calcula o número de violações de distanciamento social; cada vez que uma pessoa está a 6 unidades de outra, duas violações são contadas (porque cada pessoa está violando as regras de distância social). A simulação calcula a violação média por pessoa. Por exemplo, se houver 10 pessoas e duas violações, a média é 0,2. Quantas violações ocorrem também é uma função que depende de como as pessoas na área estão posicionadas. As pessoas podem ser agrupadas, causando muitas violações ou espalhadas, causando menos violações. A simulação realiza muitas iterações deste experimento, colocando aleatoriamente as pessoas na área para cada iteração (essa é a característica que a torna uma simulação de Monte Carlo).
Visão geral da solução
Com algumas linhas de código R e um contêiner Docker que encapsula as dependências de tempo de execução, você pode enviar o programa de simulação para a infraestrutura de computação SageMaker de maneira totalmente gerenciada e com os recursos de computação desejados em escala. Você pode enviar interativamente o script de simulação de dentro do RStudio hospedado em uma instância do EC2, para o SageMaker Processing com um contêiner Docker definido pelo usuário hospedado no Amazon Elastic Container Registry (Amazon ECR) e com os dados armazenados no Amazon S3 (discutimos os conceitos básicos de contêiner do Docker em a Criação de um contêiner R no RStudio IDE e como hospedá-lo na seção Amazon ECR). O SageMaker Processing, cuida do provisionamento da infraestrutura, de executar a simulação, ler e salvar os dados no Amazon S3 e também finalizar os recursos de computação sem intervenção manual na infraestrutura.
O diagrama a seguir ilustra a arquitetura de solução.
Implantando os recursos
Primeiro, implantamos um servidor do RStudio em uma instância do EC2 dentro de uma VPC usando um modelo do AWS CloudFormation, que é amplamente baseado no post Usando R com o Amazon SageMaker, mas com algumas modificações. Além do RStudio Server, instalamos a engine do Docker, o SDK do SageMaker Python e o Reticulate como parte da implantação. Para implantar seus recursos, execute as seguintes etapas:
- Baixar o modelo do CloudFormation
- No console do AWS CloudFormation, escolha O template está pronto.
- Escolha Carregar um arquivo de template.
- Escolha Escolher arquivo.
- Carregue o template ec2_ubuntu_rstudio_sagemaker.yaml fornecido.
O modelo foi projetado para funcionar nas seguintes regiões:
- us-east-1
- us-east-2
- us-west-2
- eu-west-1
No arquivo YAML, você pode alterar o tipo de instância para uma instância diferente. Para essa carga de trabalho, recomendamos uma instância não menor que um t3.xlarge para poder executar o RStudio sem problemas.
6. Escolha Próximo.
7. Em Nome da stack, insira o nome da sua stack.
8. Para AcceptrStudioLicenseAndInstall, revise e aceite a licença AGPL v3 para instalar o RStudio Server no Amazon EC2.
9. Para KeyName, insira um par de chaves do Amazon EC2 que você gerou anteriormente para acessar uma instância do Amazon EC2.
Para obter instruções sobre como criar um par de chaves, consulte Pares de chaves do Amazon EC2 e instâncias do Linux.
10. Escolha Próximo.
11. Na seção Configurar opções de stack, mantenha tudo em seus valores padrão.
12. Escolha Próximo.
13. Revise os detalhes da pilha e escolha Criar stack.
A criação da pilha leva cerca de 15 a 20 minutos para ser concluída.
14. Quando a criação da pilha estiver concluída, acesse a guia Saídas da pilha no console do AWS CloudFormation para encontrar a URL de login do RStudio IDE: ec2-xx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com:8787
15. Copie a URL e insira-a no seu navegador preferido.
Você deve ver a página de login do RStudio, como na captura de tela a seguir:
- Faça login na instância do RStudio com o nome de usuário ubuntu e a senha rstudio7862
Esta configuração é para fins de demonstração. Usar uma instância do EC2 públic e uma credencial de login simples não é a prática de segurança recomendada para hospedar sua instância do RStudio.
Agora você pode clonar o repositório através do terminal de linha de comando no IDE RStudio.
17. Mude para a guia Terminal e execute o comando:
git clone https://github.com/aws-samples/amazon-sagemaker-statistical-simulation-rstudio.git
Este repositório contém os scripts relevantes necessários para executar as simulações e os arquivos para criar nosso contêiner Docker.
Executando pequenas simulações localmente
No console R (guia Console), insira o seguinte código para definir o diretório de trabalho para o local correto e instalar algumas dependências:
setwd("~/amazon-sagemaker-statistical-simulation-rstudio/Submit_SageMaker_Processing_Job/")
install.packages(c('doParallel'))
Para fins ilustrativos, executamos pequenas simulações na máquina de desenvolvimento (a instância do EC2 na qual o RStudio está instalado). Você também pode encontrar o seguinte código no script Local_Simulation_Commands.R
No Console R, executamos uma simulação muito pequena com 10 iterações:
# 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)
O resultado é um número médio de 0,11 violações por pessoa, e o tempo que levou para calcular esse resultado foi de cerca de 5,5 segundos em um t3.xlarge (o número preciso de violações por pessoa e tempo necessário para realizar a simulação pode variar).
Você pode brincar com a execução desta simulação com diferentes números de iterações. Cada aumento de dez vezes corresponde a um aumento de aproximadamente dez vezes no tempo necessário para a simulação. Para testar isso, executei essa simulação com 10.000 iterações, e ela terminou após 1 hora e 33 minutos. Claramente, é necessária uma abordagem melhor para os desenvolvedores. (Se você estiver interessado em executá-los, você pode encontrar o código em Local_Simulation_Commands.R)
Criando um contêiner R no RStudio IDE e hospedando no Amazon ECR
O SageMaker Processing executa seus scripts R com um contêiner Docker em uma infraestrutura de computação remota. Nesta seção, fornecemos uma introdução ao Docker, como criar uma imagem de contêiner Docker e como hospedá-la na AWS para usar no SageMaker Processing.
O Docker é uma plataforma de software que permite criar e implantar rapidamente aplicativos em qualquer ambiente de computação. O Docker empacota software em unidades padronizadas chamadas contêineres que contêm tudo o que o software precisa para ser executado, incluindo bibliotecas, ferramentas de sistema, código e tempo de execução. Os contêineres do Docker fornecem isolamento e portabilidade para sua carga de trabalho.
Uma imagem do Docker é um modelo somente de leitura que define um contêiner. A imagem contém o código a ser executado, incluindo quaisquer bibliotecas e dependências que seu código precisa. O Docker constrói imagens lendo as instruções de um Dockerfile, que é um documento de texto que contém todos os comandos que você pode chamar na linha de comando para montar uma imagem. Você pode criar suas imagens Docker do zero ou baseá-las em outras imagens Docker que você ou outras pessoas criaram.
As imagens são armazenadas em repositórios indexados e mantidos por registros. Uma imagem pode ser enviada ou retirada de um repositório usando seu endereço de registro, que é semelhante a um URL. A AWS fornece o Amazon ECR, um registro de contêiner do Docker totalmente gerenciado que facilita o armazenamento, o gerenciamento e a implantação de imagens de contêiner Docker.
Suponha que o Social_Distancing_Simulations.R foi originalmente desenvolvido com R 3.4.1 Single Candle a partir de uma versão do RStudio no ubuntu 16.04. O programa usa a biblioteca doParallel para fins de paralelismo. Queremos executar a simulação usando um cluster de computação remota exatamente como desenvolvido. Precisamos então, instalar todas as dependências no cluster remoto, o que pode ser difícil de dimensionar, ou podemos criar uma imagem do Docker que tenha todas as dependências instaladas nas camadas e executá-la em qualquer lugar como um contêiner.
Nesta seção, criamos uma imagem do Docker que possui um interpretador R com as bibliotecas necessárias para executar a simulação e enviar a imagem para o Amazon ECR, e que com a imagem, possamos executar nosso script R da maneira exata em qualquer máquina que possa ou não ter o R compatível ou os pacotes R instalados, contanto que haja um Docker no sistema host. O código a seguir é o Dockerfile que descreve o requisito de runtime e como o contêiner deve ser executado.
#### 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 linha é uma instrução para criar uma camada para a imagem:
- FROM cria uma camada a partir da imagem Docker ubuntu:16.04
- RUN executa linhas de comando shell para criar uma nova camada
- ENTRYPOINT permite configurar como um contêiner pode rodar como um executável
O Dockerfile descreve qual dependência (ubuntu 16.04, r-base ou doParallel) deve incluir na imagem do contêiner.
Em seguida, precisamos criar uma imagem Docker a partir do Dockerfile, criar um repositório ECR e enviar a imagem para o repositório para uso posterior. O script shell fornecido build_and_push_docker.sh executa todas essas ações. Nesta seção, percorremos as etapas do script.
Execute o script principal build_and_push_docker.sh que nós preparamos para você, no terminal:
cd /home/ubuntu/amazon-sagemaker-statistical-simulation-rstudio/ sh build_and_push_docker.sh r_simulation_container v1
O script shell, usa dois argumentos de entrada: um nome para a imagem e repositório do contêiner, seguido de um nome de tag. Você pode substituir o nome r_simulation_container por outra coisa se quiser. v1 é a tag, que é a versão do contêiner. Você pode mudar isso também. Porém, se você fizer isso, lembre-se de depois alterar o repositório e o nome da imagem correspondentes.
Se tudo correr bem, você deve ver muitas ações e uma saída indicando que o Docker está criando e enviando as camadas para o repositório, seguido de uma mensagem como a seguinte:
v1: digest: sha256:91adaeb03ddc650069ba8331243936040c09e142ee3cd360b7880bf0779700b1 size: 1573
Você talvez possa receber avisos sobre o armazenamento de credenciais. Esses avisos não interferem em enviar o contêiner para o ECR, porém também podem ser corrigidos. Para obter mais informações, consulte Armazenamento de credenciais.
No script, o comando de docker build constrói a imagem e suas camadas, seguindo a ordem das instruções do Dockerfile:
Os comandos a seguir interagem com o Amazon ECR para criar um repositório:
Finalmente, o script faz a tag da imagem e a envia para o repositório ECR:
Até este ponto, criamos um contêiner e o enviamos para um repositório no Amazon ECR. Podemos confirmar que ele existe, acessando o próprio console do Amazon ECR.
Copie e salve o URI da imagem; precisaremos dela em uma etapa posterior.
Podemos usar esta imagem repetidamente para executar quaisquer scripts R que usem o doParallel. Se você tiver outras dependências, sejam elas pacotes nativos do R que possam ser baixados e instalados a partir do CRAN (Comprehensive R Archive Network) com o comando install.packages () ou até mesmo pacotes que tenham outras dependências de runtime, por exemplo, RStan, um pacote probabilístico, que implementa inferência estatística bayesiana completa de Monte Carlo via Cadeia de Markov, que depende de Stan e C++, também pode ser instalado em uma imagem Docker, sendo necessário traduzir suas instruções de instalação para um Dockerfile.
Modificando seu script R para o SageMaker Processing
Em seguida, precisamos modificar o script de simulação existente, para que ele possa conversar com os recursos disponíveis do contêiner em execução, disponível na infraestrutura do SageMaker Processing. O recurso que precisamos inserir no script, são normalmente os dados de entrada e saída do bucket S3. A API de processamento do SageMaker permite especificar onde estão os dados de entrada e como eles devem ser mapeados para o contêiner, de forma que você possa acessá-los programaticamente no script.
Por exemplo, no diagrama a seguir, se você mapear os dados de entrada do s3: //bucket/path/to/input_data para /opt/ml/processing/input, você poderá acessá-los dentro do script e do contêiner em /opt/ml/processing/input. O SageMaker Processing gerencia a transferência de dados entre os buckets S3 e o contêiner. Da mesma forma, para a saída, se você precisar persistir qualquer artefato, você poderá salvá-los dentro do próprio script em /opt/ml/processing/output. Dessa maneira, os arquivos ficarão disponíveis no s3: //bucket/path/to/output_data.
A única alteração para o script Social_Distancing_Simulations.R é onde o arquivo de saída será gravado. Em vez de um caminho na instância local do EC2, nós o alteramos para escrever em /opt/ml/processing/output/output_result_mean.txt.
Enviando seu script R para o SageMaker Processing
Simulações muito grandes podem ser lentas em uma máquina local. Como vimos anteriormente, fazer 10.000 iterações da simulação de distanciamento social, leva cerca de 1 hora e 33 minutos na máquina local usando 1 vCPU. Agora estamos prontos para executar a simulação com o SageMaker Processing.
Com o SageMaker Processing, podemos usar a infraestrutura de computação remota para executar a simulação e liberar os recursos de computação locais. O SageMaker gera uma infraestrutura de processamento, pega seu script, copia seus dados de entrada do Amazon S3 (se houver) e extrai a imagem do contêiner do Amazon ECR para executar a simulação.
O SageMaker gerencia totalmente a infraestrutura subjacente para um job de Processamento. Os recursos do cluster, são provisionados durante a execução do trabalho e limpos quando concluído. A saída do trabalho de Processamento é armazenada no bucket do S3 que você especificou. Você pode tratar sua instância do RStudio, como uma estação de inicialização para enviar simulações para a sua computação remota, com diversos parâmetros ou conjuntos de dados de entrada.
A API completa do SageMaker é acessível através da biblioteca Reticulate, que fornece uma interface de R que é usada para fazer chamadas ao SDK Python do SageMaker. Para orquestrar essas etapas, usamos outro script R.
Copie o seguinte código para o console do RStudio. Defina a variável container para a URI do contêiner com a tag (lembre-se de incluir a tag, e não apenas o contêiner). Deve ser parecido com xxxxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com/r_simulation_container:v1. Você pode recuperar essa URI através do console do Amazon ECR escolhendo o repositório r_simulation_container e copiando a URI do campo URI de imagem (esse código também está no script SageMaker_Processing_SDS.R):
No código anterior, estamos aliviando a carga de trabalho pesada da simulação, para uma instância EC2 remota e maior (instance_type = ‘ml.m5.4xlarge’). Não só não consumimos nenhum recurso de computação local, como também temos a oportunidade de escolher de forma ideal uma instância de tamanho certo para executar a simulação por job. A máquina em que executamos essa simulação é uma instância de uso geral com 64 GB de RAM e 16 CPUs virtuais. A simulação é executada mais rapidamente na instância de tamanho certo. Por exemplo, quando usamos o ml.m5.4xlarge (64 GB de RAM e 16 vCPUs), a simulação levou 10,8 minutos. Por meio de comparação, realizamos exatamente essa mesma simulação na máquina de desenvolvimento local usando apenas 1 vCPU e a mesma simulação levou 93 minutos.
Se você quiser executar outra simulação mais complexa, com mais iterações ou com um conjunto de dados maior, não será necessário interromper e alterar o tipo de instância do EC2. Você pode facilmente alterar o argumento instance_type para uma instância maior e obter mais RAM ou CPUs virtuais, ou utilizar uma instância otimizada para computação, como a ml.c5.4xlarge, para obter um alto desempenho a um preço baixo por taxa de computação.
Configuramos nosso job (definindo wait = TRUE) para que seja executado de forma síncrona. O interpretador R ficará ocupado até que a simulação seja concluída, mesmo que o trabalho esteja sendo executado em uma computação remota. Em muitos casos (como simulações que duram muitas horas) é mais útil definir wait = FALSE para executar o job de forma assíncrona. Isso permite que você continue executando seu script e outras tarefas dentro do RStudio, enquanto a simulação pesada continua ocorrendo através do job de processamento do SageMaker.
Você pode inspecionar e monitorar o andamento de seus jobs na página Processing jobs no console do SageMaker (você também pode monitorar jobs por meio de chamadas de API).
A captura de tela a seguir, mostra os detalhes do nosso job.
A seção Monitoramento fornece links para os logs dos seus jobs no Amazon CloudWatch. Esse é um recurso importante, que permite que você monitore os seus logs enquanto eles são executados em tempo quase real, e possa tomar as medidas necessárias se erros ou bugs forem detectados.
Como os logs são reportados em tempo quase real, você não precisa esperar até que um job inteiro seja concluído para detectar problemas; você pode contar com os logs emitidos.
Para obter mais informações sobre como o SageMaker Processing executa sua imagem de contêiner e script de simulação, consulte Como o processamento do Amazon SageMaker executa sua imagem de contêiner de processamento.
Acessando resultados da simulação a partir do seu script R
O seu job de processamento grava seus resultados no Amazon S3; você pode controlar o que está escrito e em que formato ele está escrito. O contêiner do Docker no qual o job de processamento é executado, grava os resultados no diretório /opt/ml/processing/output; quando o job de processamento for concluído, eles serão copiados para o Amazon S3. No script Social_Distancing_Simulations.R, escrevemos a média de toda a execução da simulação (esse número corresponde ao número médio de violações por pessoa na sala). Para acessar esses resultados, insira o seguinte código (esse código também está no script SageMaker_Processing_SDS.R):
No código anterior, apontamos para o bucket do S3 onde os resultados são armazenados, lemos o resultado e o exibimos. Para o nosso caso de uso, nosso job de processamento apenas escreve a média dos resultados da simulação, mas você pode configurá-lo para escrever outros valores também.
A tabela a seguir, compara o tempo total que levou para realizar a simulação na máquina local uma vez, assim como outras duas instâncias que você também pode usar para o Processamento do SageMaker. Para essas simulações, o número de iterações muda, mas x_length, y_length e num_people são iguais a 1000 em todos os casos.
| Tipo de instância | |||
| Número de iterações | t3.xlarge (máquina local) | ml.m5.4xlarge (Processamento do SageMaker) | ml.m5.24xlarge (Processamento do SageMaker) |
| 10 | 5.5 (segundos) | 254 | 285 |
| 100 | 87 | 284 | 304 |
| 1,000 | 847 | 284 | 253 |
| 10.000 | 5602 | 650 | 430 |
| 100.000 | Não testado | Não testado | 1411 |
Para testar na máquina local, restringimos o número de CPUs virtuais (vCPU) a 1; o t3.xlarge tem 4 vCPUs. Essa restrição imita um padrão comum no qual uma máquina grande é compartilhada por vários estatísticos ao mesmo tempo; e um estatístico pode não distribuir trabalho para várias CPUs por medo de atrasar o trabalho de seus colegas. Para o tempo das instâncias ml.m5.4xlarge e ml.m5.24xlarge, usamos todas as vCPUs e incluímos o tempo necessário para o SageMaker Processing abrir a instância solicitada e gravar os resultados, além do tempo necessário para executar a própria simulação. Realizamos cada simulação uma vez.
Como você pode ver na tabela, as máquinas locais são mais eficientes para menos iterações, mas as máquinas maiores que usam o SageMaker Processing são mais rápidas quando o número de iterações chega a 1.000 ou mais.
(Opcional) Protegendo sua carga de trabalho na VPC
Até agora, enviamos os jobs de processamento do SageMaker para uma VPC gerenciada pelo próprio SageMaker e acessamos os buckets do S3 via internet pública. No entanto, nos setores de saúde, ciências biológicas e serviços financeiros, geralmente é necessário executar cargas de trabalho de produção em uma VPC privada, com configurações de rede rigorosas para fins de segurança. É também uma prática de segurança recomendada, iniciar os jobs de processamento do SageMaker em uma VPC privada, onde você pode ter mais controle sobre a configuração de rede e acessar os buckets do S3 por meio de um endpoint de VPC do Amazon S3. Para obter mais informações e instruções de configuração, consulte Conceder ao SageMaker Processing Jobs acesso aos recursos em sua Amazon VPC.
Provisionamos um endpoint de VPC do Amazon S3 anexado à VPC como parte do modelo do CloudFormation. Para inicializar um job em uma VPC privada, precisamos adicionar a configuração de rede, um argumento adicional chamado network_config à construção do ScriptProcessor:
orçado a ser executado dentro da VPC especificada em vez da VPC gerenciada do SageMaker. E também acessar o bucket do S3 por meio do endpoint VPC do Amazon S3 em vez da Internet pública.
Limpeza
Ao concluir esta demonstração, exclua a pilha do console do AWS CloudFormation selecionando a stack e escolhendo Excluir. Isso limpa todos os recursos que criamos para este post.
Conclusão
Neste post, apresentamos uma solução usando o SageMaker Processing como uma extensão do recurso de computação para usuários de R que executam carga de trabalho estatística no RStudio. Você pode obter a escalabilidade desejada com algumas linhas de código para chamar a API do SageMaker e uma imagem de contêiner Docker reutilizável, sem sair do IDE RStudio. Também mostramos como você pode iniciar jobs do SageMaker Processing em sua própria VPC privada para fins de segurança.
Uma pergunta que você pode estar se fazendo é: Por que o cientista de dados deve se preocupar com o envio de jobs? Por que não apenas executar o RStudio em uma única instância muito grande que consiga lidar com as simulações localmente? A resposta é que, embora isso seja tecnicamente possível, pode ser caro e não é escalável, mesmo para equipes de tamanho pequeno. Por exemplo, suponha que sua empresa tenha 10 estatísticos que precisam executar simulações que usam até 60 GB de RAM; eles precisam executar simulações no total de 1.200 horas (50 dias seguidos). Se cada estatístico tiver sua própria instância m5.4xlarge para operar 24/7, custará cerca de 10 * 24 * 30 * 0,768 USD = US$ 5.529 por mês (definição de preço do Amazon EC2 sob demanda em us-west-2 a partir de dezembro de 2020). Por comparação, o provisionamento de uma instância m5.4xlarge a ser compartilhada por 10 estatísticos para realizar análises exploratórias e enviar simulações em larga escala no Processamento do SageMaker custa apenas US$ 553 por mês no Amazon EC2 e um adicional de US$ 1.290 para as totais 1.200 horas de simulação nas instâncias ml.m5.4xlarge de ML do SageMaker (US$ 1,075 por hora).
Para obter mais informações sobre R e SageMaker, consulte o R User Guide to Amazon SageMaker. Para obter detalhes sobre a definição de preço do SageMaker Processing, consulte a guia Processamento na definição de preço do Amazon SageMaker.
Este artigo foi traduzido do Blog da AWS em Inglês.
Sobre os Autores
Michael Hsieh é um arquiteto sênior de soluções especialista em AI/ML. Ele trabalha junto com os clientes para ajudá-los avançar em sua jornada de ML usando uma combinação do seu domínio em ML e de ofertas de ML da AWS. Como recém-chegado em Seattle, ele adora explorar a grande mãe natureza que a cidade tem para oferecer, como trilhas para caminhadas, passeios de caiaque no SLU e o pôr do sol na Baía de Shilshole.
Joshua Broyde é um arquiteto de soluções especialista em AI/ML na equipe global de saúde e ciências biológicas da Amazon Web Services. Ele trabalha com clientes em saúde e ciências biológicas em várias frentes de AI/ML, incluindo a análise de imagens e vídeos médicos, análise de dados de sensores de máquinas e realização de processamento de linguagem natural de textos médicos e de saúde.
Revisor
Andreza Cruz é um arquiteta de soluções na Amazon Web Services (AWS). Trabalha com foco em desenvolvimento ajudando os clientes em sua jornada na nuvem, e tem se especializado em inteligência artificial e aprendizado de máquina (AI/ML).