Configuração avançada: compartilhar endpoints de desenvolvimento entre vários usuários - AWS Glue

Configuração avançada: compartilhar endpoints de desenvolvimento entre vários usuários

Esta seção explica como você pode aproveitar os endpoints de desenvolvimento com cadernos do SageMaker em casos de uso típicos a fim de compartilhar endpoints de desenvolvimento entre vários usuários.

Configuração de locação única

Em casos de uso de locatário único, para simplificar a experiência do desenvolvedor e para evitar contenção por recursos, é recomendável que cada desenvolvedor use seu próprio endpoint de desenvolvimento dimensionado para o projeto em que está trabalhando. Isso também simplifica as decisões relacionadas ao tipo de operador e à contagem de DPU, deixando-as à discrição do desenvolvedor e do projeto em que estão trabalhando.

Você não precisará cuidar da alocação de recursos, a menos que execute vários arquivos de caderno simultaneamente. Se você executar um código em vários arquivos de caderno ao mesmo tempo, várias sessões do Livy serão iniciadas simultaneamente. Para segregar configurações de cluster do Spark a fim de executar várias sessões do Livy ao mesmo tempo, você pode seguir as etapas que são introduzidas em casos de uso multilocatário.

Por exemplo, se o endpoint de desenvolvimento tiver dez operadores e o tipo de operador for G.1X, então você terá nove executores do Spark e todo o cluster terá 90G de memória de executor, uma vez que cada executor terá 10G de memória.

Independentemente do tipo de operador especificado, a alocação dinâmica de recursos do Spark será ativada. Se um conjunto de dados for grande o suficiente, o Spark pode alocar todos os executores em uma única sessão do Livy, já que spark.dynamicAllocation.maxExecutors não é definido por padrão. Isso significa que outras sessões do Livy no mesmo endpoint de desenvolvimento esperarão para iniciar novos executores. Se o conjunto de dados for pequeno, o Spark poderá alocar executores em várias sessões do Livy ao mesmo tempo.

nota

Para obter mais informações sobre como os recursos são alocados em diferentes casos de uso e como você define uma configuração para modificar o comportamento, consulte Configuração avançada: compartilhar endpoints de desenvolvimento entre vários usuários.

Configuração de locação múltipla

nota

Observe que os endpoints de desenvolvimento são destinados a emular o ambiente de ETL do AWS Glue como um ambiente de locatário único. Embora o uso de multilocatário seja possível, esse é um caso de uso avançado e é recomendado que a maioria dos usuários mantenha um padrão de locação única para cada endpoint de desenvolvimento.

Em casos de uso multilocatário, talvez seja necessário cuidar da alocação de recursos. O principal fator é o número de usuários simultâneos que usam um caderno Jupyter ao mesmo tempo. Se sua equipe estiver distribuída ao redor do mundo de forma a seguir um fluxo de trabalho de 24 horas por dia e houver apenas um usuário do Jupyter em cada fuso horário, então o número de usuários simultâneos será apenas um e você não precisará se preocupar com a alocação de recursos. No entanto, se seu caderno for compartilhado entre vários usuários e cada um enviar código de forma ad-hoc, então você precisará considerar os pontos abaixo.

Para particionar recursos de cluster do Spark entre vários usuários, você pode usar as configurações do SparkMagic. Há duas maneiras diferentes de configurar o SparkMagic.

(A) Usar a diretiva %%configure -f

Se você quiser modificar a configuração por sessão do Livy a partir do caderno, poderá executar a diretiva %%configure -f no parágrafo do caderno.

Por exemplo, se você deseja executar a aplicação Spark em cinco executores, pode executar o seguinte comando no parágrafo do caderno.

%%configure -f {"numExecutors":5}

Em seguida, você verá apenas cinco executores em execução para o trabalho na IU do Spark.

Recomendamos limitar o número máximo de executores para alocação dinâmica de recursos.

%%configure -f {"conf":{"spark.dynamicAllocation.maxExecutors":"5"}}

(B) Modificar o arquivo Config do SparkMagic

O SparkMagic funciona com base na API do Livy. O SparkMagic cria sessões do Livy com configurações como: driverMemory, driverCores, executorMemory, executorCores, numExecutors, conf etc. Esses são os principais fatores que determinam a quantidade de recursos consumidos de todo o cluster do Spark. O SparkMagic permite que você forneça um arquivo de configuração para especificar os parâmetros que são enviados ao Livy. Você pode ver um arquivo de configuração de exemplo neste repositório do GitHub.

Se você quiser modificar a configuração em todas as sessões do Livy a partir de um caderno, poderá modificar /home/ec2-user/.sparkmagic/config.json para adicionar session_config.

Para modificar o arquivo de configuração em uma instância de cadernos do SageMaker, siga estas etapas.

  1. Abra um caderno do SageMaker.

  2. Abra o kernel do terminal.

  3. Execute os seguintes comandos:

    sh-4.2$ cd .sparkmagic sh-4.2$ ls config.json logs sh-4.2$ sudo vim config.json

    Por exemplo, você pode adicionar estas linhas a /home/ec2-user/.sparkmagic/config.json e reiniciar o kernel do Jupyter a partir do caderno.

    "session_configs": { "conf": { "spark.dynamicAllocation.maxExecutors":"5" } },

Diretrizes e práticas recomendadas

Para evitar esse tipo de conflito de recursos, você pode usar algumas abordagens básicas, como:

  • Ter um cluster do Spark maior, aumentando NumberOfWorkers (escalonando horizontalmente) e atualizando workerType(escalonando verticalmente)

  • Alocar menos recursos por usuário (menos recursos por sessão do Livy)

Sua abordagem dependerá do seu caso de uso. Se você tiver um endpoint de desenvolvimento maior e não houver uma grande quantidade de dados, a possibilidade de um conflito de recursos diminuirá significativamente porque o Spark pode alocar recursos com base em uma estratégia de alocação dinâmica.

Como descrito acima, o número máximo de executores do Spark é calculado automaticamente pela combinação de DPU (ou NumberOfWorkers) e tipo de operador. Cada aplicação do Spark inicia um driver e vários executores. Para calcular, você precisará de NumberOfWorkers = NumberOfExecutors + 1. A matriz abaixo explica quanta capacidade você precisa em seu endpoint de desenvolvimento com base no número de usuários simultâneos.

Número de usuários simultâneos de cadernos Número de executores do Spark que você deseja alocar por usuário NumberOfWorkers (número de operadores) total para seu endpoint de desenvolvimento
3 5 18
10 5 60
50 5 300

Se você quiser alocar menos recursos por usuário, spark.dynamicAllocation.maxExecutors (ou numExecutors) seria o parâmetro mais fácil de configurar como um parâmetro de sessão do Livy. Se você definir a configuração abaixo em /home/ec2-user/.sparkmagic/config.json, então o SparkMagic atribuirá um máximo de cinco executores por sessão do Livy. Isso ajudará a segregar recursos por sessão do Livy.

"session_configs": { "conf": { "spark.dynamicAllocation.maxExecutors":"5" } },

Suponha que haja um endpoint de desenvolvimento com 18 operadores (G.1X) e que haja três usuários de cadernos simultâneos. Se a configuração da sua sessão tiver spark.dynamicAllocation.maxExecutors=5, então cada usuário poderá fazer uso de um driver e cinco executores. Não haverá conflitos de recursos, mesmo quando você executar vários parágrafos do caderno ao mesmo tempo.

Trade-offs

Com esta configuração de sessão "spark.dynamicAllocation.maxExecutors":"5", você poderá evitar erros de conflito de recursos e não precisará aguardar a alocação de recursos quando houver acessos simultâneos de usuários. No entanto, mesmo quando há muitos recursos livres (por exemplo, não há outros usuários simultâneos), o Spark não pode atribuir mais de cinco executores à sessão do Livy.

Outras observações

É uma boa prática interromper o kernel do Jupyter quando você parar de usar um caderno. Isso liberará recursos e outros usuários de cadernos poderão usar esses recursos imediatamente, sem aguardar a expiração do kernel (desligamento automático).

Problemas comuns

Mesmo ao seguir as diretrizes, você pode enfrentar certos problemas.

Sessão não encontrada

Ao tentar executar um parágrafo do caderno mesmo que sua sessão do Livy já tenha terminado, você verá a mensagem abaixo. Para ativar a sessão do Livy, você precisa reiniciar o kernel do Jupyter escolhendo Kernel > Restart (Reiniciar) no menu do Jupyter e, em seguida, executar o parágrafo do caderno novamente.

An error was encountered: Invalid status code '404' from http://localhost:8998/sessions/13 with error payload: "Session '13' not found."

Não há recursos suficientes do YARN

Ao tentar executar um parágrafo do caderno mesmo que o cluster do Spark não tenha recursos suficientes para iniciar uma nova sessão do Livy, você verá a mensagem abaixo. Muitas vezes, você pode evitar esse problema seguindo as diretrizes, no entanto, ainda haverá a possibilidade de você encontrar esse problema. Para contornar o problema, você pode conferir se há sessões ativas e desnecessárias do Livy. Se houver sessões do Livy desnecessárias, você precisará terminá-las para liberar os recursos do cluster. Consulte a próxima seção para obter detalhes.

Warning: The Spark session does not have enough YARN resources to start. The code failed because of a fatal error: Session 16 did not start up in 60 seconds.. Some things to try: a) Make sure Spark has enough available resources for Jupyter to create a Spark context. b) Contact your Jupyter administrator to make sure the Spark magics library is configured correctly. c) Restart the kernel.

Monitoramento e depuração

Esta seção descreve técnicas para monitorar recursos e sessões.

Monitorar e depurar a alocação de recursos do cluster

Você pode observar a interface do usuário do Spark para monitorar quantos recursos são alocados por sessão do Livy e quais são as configurações efetivas do Spark no trabalho. Para habilitar a interface do usuário do Spark, consulte Habilitar a interface do usuário Web do Apache Spark para endpoints de desenvolvimento.

(Opcional) Se você precisar de uma visualização em tempo real da interface do usuário do Spark, poderá configurar um túnel SSH para o servidor de histórico do Spark em execução no cluster do Spark.

ssh -i <private-key.pem> -N -L 8157:<development endpoint public address>:18080 glue@<development endpoint public address>

Você pode abrir http://localhost:8157 no navegador para visualizar a interface do usuário do Spark localmente.

Liberar sessões do Livy desnecessárias

Reveja estes procedimentos para encerrar quaisquer sessões desnecessárias do Livy a partir de um caderno ou de um cluster do Spark.

(a). Terminar sessões do Livy a partir de um caderno

Você pode desligar o kernel em um caderno Jupyter para terminar sessões do Livy desnecessárias.

(b). Terminar sessões do Livy a partir de um cluster do Spark

Se houver sessões do Livy desnecessárias que ainda estejam em execução, você pode terminá-las no cluster do Spark.

Como pré-requisito para executar esse procedimento, você precisa configurar sua chave SSH pública para o seu endpoint de desenvolvimento.

Para fazer login no cluster do Spark, execute o seguinte comando:

$ ssh -i <private-key.pem> glue@<development endpoint public address>

Você pode executar o seguinte comando para ver as sessões do Livy ativas:

$ yarn application -list 20/09/25 06:22:21 INFO client.RMProxy: Connecting to ResourceManager at ip-255-1-106-206.ec2.internal/172.38.106.206:8032 Total number of applications (application-types: [] and states: [SUBMITTED, ACCEPTED, RUNNING]):2 Application-Id Application-Name Application-Type User Queue State Final-State Progress Tracking-URL application_1601003432160_0005 livy-session-4 SPARK livy default RUNNING UNDEFINED 10% http://ip-255-1-4-130.ec2.internal:41867 application_1601003432160_0004 livy-session-3 SPARK livy default RUNNING UNDEFINED 10% http://ip-255-1-179-185.ec2.internal:33727

Em seguida, você pode desligar a sessão do Livy com o seguinte comando:

$ yarn application -kill application_1601003432160_0005 20/09/25 06:23:38 INFO client.RMProxy: Connecting to ResourceManager at ip-255-1-106-206.ec2.internal/255.1.106.206:8032 Killing application application_1601003432160_0005 20/09/25 06:23:39 INFO impl.YarnClientImpl: Killed application application_1601003432160_0005