Ambientes de operador do Elastic Beanstalk

Se a sua aplicação do AWS Elastic Beanstalk executa operações ou fluxos de trabalho que demoram muito para serem concluídos, é possível descarregar essas tarefas em um ambiente de operador dedicado. O desacoplamento do front-end do aplicativo web de um processo que executa operações de bloqueio é uma maneira comum de garantir que seu aplicativo mantenha a capacidade de resposta sob carga.

Uma tarefa de longa execução é alguma coisa que aumenta significativamente o tempo necessário para concluir uma solicitação, como o processamento de imagens ou vídeos, o envio de e-mail ou a geração de um arquivo ZIP. Essas operações podem levar apenas um ou dois segundos para serem concluídas, mas um atraso de alguns segundos é muito para uma solicitação web que, de outra forma, seria concluída em menos de 500 ms.

Uma opção é criar um processo de operador localmente, retornar o êxito e processar a tarefa de maneira assíncrona. Isso funcionará, se a instância puder acompanhar todas as tarefas que são enviadas a ela. Sob carga elevada, no entanto, uma instância pode ficar sobrecarregada com tarefas em segundo plano e parar de responder às solicitações de prioridade mais alta. Se cada usuário puder gerar várias tarefas, o aumento na carga pode não corresponder a um aumento nos usuários, o que dificulta expandir o nível do servidor Web de modo eficaz.

Para evitar a execução de tarefas de longa execução localmente, é possível usar AWS SDK como linguagem de programação para enviá-las a uma fila do Amazon Simple Queue Service (Amazon SQS) e executar o processo que as executa em um conjunto separado de instâncias. Depois, você cria essas instâncias de operador para obter itens da fila apenas quando elas têm capacidade para executá-los, impedindo que se tornem sobrecarregadas.

Os ambientes de operador do Elastic Beanstalk simplificam esse processo gerenciando a fila do Amazon SQS e executando um processo de daemon em cada instância que lê a fila para você. Quando o daemon extrai um item da fila, envia uma solicitação HTTP POST localmente para http://localhost/, na porta 80, com o conteúdo da mensagem da fila no corpo. Tudo o que seu aplicativo precisa fazer é realizar a tarefa de longa execução em resposta ao POST. Você pode configurar o daemon para publicar em um caminho diferente, usar um tipo MIME que não seja aplicativo/JSON, conectar-se a uma fila existente ou personalizar conexões (máximo de solicitações simultâneas), tempos limite e novas tentativas.

Com as tarefas periódicas, você também pode configurar o daemon do operador para colocar as mensagens na fila com base em uma programação cron. Cada tarefa periódica pode executar POST em um caminho diferente. Para habilitar as tarefas periódicas, inclua um arquivo YAML em seu código-fonte que define a programação e o caminho para cada tarefa.

nota

O .NET na Plataforma de Windows Server não tem suporte para ambientes de operador.

Daemon SQS do ambiente de operador

Os ambientes de operador executam um processo de daemon fornecido pelo Elastic Beanstalk. Esse daemon é atualizado regularmente para adicionar recursos e corrigir erros. Para obter a versão mais recente do daemon, atualize para a última versão da Plataforma.

Quando a aplicação no ambiente de operador retorna uma resposta 200 OK para confirmar que ele recebeu e processou a solicitação com êxito, o daemon envia uma chamada DeleteMessage à fila do Amazon SQS para excluir a mensagem da fila. Se a aplicação retornar qualquer resposta diferente de 200 OK, o Elastic Beanstalk aguardará para recolocar a mensagem na fila após o período ErrorVisibilityTimeout configurado. Se não houver nenhuma resposta, o Elastic Beanstalk aguardará para recolocar a mensagem na fila após o período InactivityTimeout para que a mensagem seja disponibilizada para outra tentativa de processamento.

nota

As propriedades das filas do Amazon SQS (ordem das mensagens, entrega pelo menos uma vez e amostragem de mensagens) podem afetar o modo como você cria uma aplicação Web para um ambiente de operador. Para obter mais informações, consulte Propriedades das filas distribuídas no Guia do desenvolvedor do Amazon Simple Queue Service.

O Amazon SQS exclui automaticamente as mensagens que estão na fila há mais tempo do que o RetentionPeriod configurado.

O daemon define os seguintes cabeçalhos HTTP.

Cabeçalhos HTTP
Name (Nome)	Value (Valor)
User-Agent	aws-sqsd aws-sqsd/1.11
X-Aws-Sqsd-Msgid	ID de mensagens do SQS, usado para detectar enxurradas de mensagens (um número excepcionalmente alto de novas mensagens).
X-Aws-Sqsd-Queue	Nome da fila do SQS.
X-Aws-Sqsd-First-Received-At	Horário UTC, no formato ISO 8601, quando a mensagem foi recebida pela primeira vez.
X-Aws-Sqsd-Receive-Count	Contagem de recebimento de mensagens do SQS.
X-Aws-Sqsd-Attr-message-attribute-name	Atributos de mensagem personalizados concedidos à mensagem que está sendo processada. O message-attribute-name é o nome do atributo de mensagem real. Todos os atributos de mensagem de string e número são adicionados ao cabeçalho. Os atributos binários são descartados e não são incluídos no cabeçalho.
Content-Type	Configuração de tipo Mime. Por padrão, application/json.

Filas de mensagens mortas

Os ambientes de operador do Elastic Beanstalk são compatíveis com filas de mensagens mortas do Amazon Simple Queue Service (Amazon SQS). Dead letter queue (fila de mensagens mortas) é uma fila onde outras filas (origem) podem enviar mensagens que, por algum motivo, não puderam ser processadas com êxito. Um benefício importante de usar filas de mensagens mortas é a capacidade de segregar e isolar as mensagens que não foram processadas com êxito. Em seguida, você pode analisar todas as mensagens enviadas para a fila de mensagens mortas para tentar determinar por que elas não foram processadas com êxito.

Se você especificar uma fila do Amazon SQS gerada automaticamente no momento em que criar o nível de ambiente de operador, uma fila de mensagens mortas será habilitada por padrão para um ambiente de operador. Se você escolher uma fila do SQS existente para seu ambiente de operador, deve usar o SQS para configurar uma fila de mensagens mortas de forma independente. Para obter informações sobre como usar o SQS para configurar uma fila de mensagens mortas, consulte Usar fila de mensagens mortas do Amazon SQS.

Você não pode desabilitar filas de mensagens mortas. As mensagens que não puderem ser entregues serão eventualmente enviadas a uma fila de mensagens mortas. No entanto, você pode efetivamente desabilitar esse recurso definindo a opção MaxRetries como o valor máximo válido de 100.

Se uma fila de mensagens mortas não estiver configurada para a fila do Amazon SQS do ambiente de operador, o Amazon SQS manterá as mensagens na fila até que o período de retenção expire. Para obter detalhes sobre como configurar o período de retenção, consulte Configurar ambientes de operador.

nota

A opção MaxRetries do Elastic Beanstalk é equivalente à opção MaxReceiveCount do SQS. Se o ambiente de operador não usar uma fila do SQS gerada automaticamente, use a opção MaxReceiveCount no SQS para desabilitar efetivamente a fila de mensagens mortas. Para obter mais informações, consulte Usar filas de mensagens mortas do Amazon SQS.

Para obter mais informações sobre o ciclo de vida de uma mensagem do SQS, acesse Ciclo de vida de mensagens.

Tarefas periódicas

Você pode definir tarefas periódicas em um arquivo denominado cron.yaml em seu pacote de origem para adicionar trabalhos à fila do seu ambiente de operador automaticamente em intervalos regulares.

Por exemplo, o arquivo cron.yaml a seguir cria duas tarefas periódicas. O primeiro é executado a cada 12 horas e o segundo é executado às 11 horas UTC todos os dias.

exemplo cron.yaml

version: 1
cron:
 - name: "backup-job"
   url: "/backup"
   schedule: "0 */12 * * *"
 - name: "audit"
   url: "/audit"
   schedule: "0 23 * * *"

O name deve ser exclusivo para cada tarefa. O URL é o caminho para o qual a solicitação POST é enviada para acionar o trabalho. A programação é uma expressão CRON que determina quando a tarefa é executada.

Quando uma tarefa é executada, o daemon publica uma mensagem na fila do SQS do ambiente com um cabeçalho indicando o trabalho que precisa ser realizado. Qualquer instância no ambiente pode selecionar a mensagem e processar o trabalho.

nota

Se você configurar o ambiente de operador com uma fila do SQS existente e escolher uma fila FIFO do Amazon SQS, as tarefas periódicas não serão compatíveis.

O Elastic Beanstalk usa a eleição de líder para determinar qual instância no ambiente de operador coloca a tarefa periódica em fila. Cada instância tenta se tornar líder gravando em uma tabela do Amazon DynamoDB. A primeira instância que for bem-sucedida será líder e deverá continuar gravando na tabela para manter o status de líder. Se o líder ficar fora de serviço, outra instância rapidamente assumirá seu lugar.

Para tarefas periódicas, o daemon do operador define os seguintes cabeçalhos adicionais.

Cabeçalhos HTTP
Name (Nome)	Value (Valor)
X-Aws-Sqsd-Taskname	Para tarefas periódicas, o nome da tarefa a ser executada.
X-Aws-Sqsd-Scheduled-At	Horário programado para a tarefa periódica
X-Aws-Sqsd-Sender-Id	Número da conta da AWS do remetente da mensagem

Usar o Amazon CloudWatch para escalabilidade automática em níveis do ambiente de operador

Juntos, o Amazon EC2 Auto Scaling e o CloudWatch monitoram a utilização da CPU das instâncias em execução no ambiente de operador. A maneira como você configura o limite de escalação automática para a capacidade da CPU determina quantas instâncias o grupo de Auto Scaling executa para gerenciar adequadamente o throughput de mensagens na fila do Amazon SQS. Cada instância do EC2 publica suas métricas de utilização da CPU no CloudWatch. O Amazon EC2 Auto Scaling recupera do CloudWatch o uso médio da CPU em todas as instâncias no ambiente de operador. Você configura o limite superior e inferior e quantas instâncias devem ser adicionadas ou encerradas de acordo com a capacidade da CPU. Quando o Amazon EC2 Auto Scaling detecta que você atingiu o limite superior especificado na capacidade da CPU, o Elastic Beanstalk cria novas instâncias no ambiente de operador. As instâncias são excluídas quando a carga da CPU volta a ficar abaixo do limite.

nota

As mensagens que não foram processadas no momento em que uma instância foi encerrada são retornadas para a fila na qual elas podem ser processadas por outro daemon em uma instância que ainda está em execução.

Você também pode definir outros alarmes do CloudWatch, conforme necessário, usando o console do Elastic Beanstalk, a CLI ou o arquivo de opções. Para obter mais informações, consulte Usar o Elastic Beanstalk com o Amazon CloudWatch e Criar um grupo de Auto Scaling com políticas de escalabilidade em etapas.

Configurar ambientes de operador

É possível gerenciar a configuração de um ambiente de operador editando a configuração Worker Configuration (Configuração do operador) na página Configuration (Configuração) no console de gerenciamento do ambiente.

nota

Você pode configurar o caminho do URL para publicar mensagens na fila de operadores, mas não pode configurar a porta IP. O Elastic Beanstalk sempre publica mensagens da fila do operador na porta 80. O aplicativo do ambiente de operador ou seu proxy deve ouvir na porta 80.

Para configurar o daemon do operador

1. Abra o console do Elastic Beanstalk e, na lista Regions (Regiões), selecione a sua Região da AWS.

2. No painel de navegação, selecione Ambientes e selecione o nome do ambiente na lista.

   nota

   Se você tiver muitos ambientes, use a barra de pesquisa para filtrar a lista de ambientes.

3. No painel de navegação, escolha Configuration (Configuração).

4. Na categoria de configuração Worker (Operador), escolha Edit (Editar).

A página de configuração Modify worker (Modificar operador) tem as seguintes opções.

Na seção Queue (Fila):

• Worker queue (Fila do operador): especifique a fila do Amazon SQS de leitura do daemon. Se tiver uma, você poderá escolher uma fila existente. Se você escolher Autogenerated queue (Fila gerada automaticamente), o Elastic Beanstalk criará uma nova fila do Amazon SQS e um Worker queue URL (URL da fila do operador)correspondente.

  nota

  Quando você escolhe Autogenerated queue (Fila gerada automaticamente), a fila criada pelo Elastic Beanstalk é uma fila padrão do Amazon SQS. Ao escolher uma fila existente, você pode fornecer uma fila padrão ou uma fila FIFO do Amazon SQS. Lembre-se de que, se você fornecer uma fila FIFO, as tarefas periódicas não serão compatíveis.

• Worker queue URL ((URL da fila do operador)): se você escolher uma Worker queue (Fila do operador) existente, essa configuração exibirá o URL associado a essa fila do Amazon SQS.

Na seção Messages (Mensagens):

• HTTP path (Caminho HTTP): especifique o caminho relativo para a aplicação que receberá os dados da fila do Amazon SQS. Os dados são inseridos no corpo de uma mensagem HTTP POST. O valor padrão é /.

• MIME type (Tipo MIME): indica o tipo MIME usado pela mensagem HTTP POST. O valor padrão é application/json. No entanto, qualquer valor é válido, pois você pode criar e, em seguida, especificar seu próprio tipo MIME.

• HTTP connections (Conexões HTTP): especifique o número máximo de conexões simultâneas que o daemon pode estabelecer com qualquer aplicação em uma instância do Amazon EC2. O padrão é 50. Você pode especificar de 1 a 100.

• Visibility timeout (Tempo limite de visibilidade): indique por quanto tempo (em segundos) uma mensagem recebida da fila do Amazon SQS fica bloqueada para processamento. Após o término do tempo configurado, a mensagem ficará novamente visível na fila para outro daemon ler. Escolha um valor superior ao que seu aplicativo precisa para processar mensagens, até 43200 segundos.

• Error visibility timeout (Tempo limite de visibilidade de erros): indique quanto tempo (em segundos) o Elastic Beanstalk deve aguardar para retornar uma mensagem à fila do Amazon SQS após uma falha com erro explícito ao tentar processá-la. Você pode especificar de 0 a 43200 segundos.

Na seção Advanced options:

• Max retries (Máximo de tentativas): especifique o número máximo de vezes que o Elastic Beanstalk tenta enviar a mensagem à fila do Amazon SQS antes de movê-la para a fila de mensagens mortas. O valor padrão é 10. Você pode especificar de 1 a 100.

  nota

  A opção Max retries (Máximo de novas tentativas) só é aplicável a filas do Amazon SQS configuradas com uma fila de mensagens mortas. Para qualquer fila do Amazon SQS que não esteja configurada com uma fila de mensagens mortas, o Amazon SQS retém as mensagens na fila e as processa até a expiração do período especificado pela opção Retention period (Período de retenção).

• Connection timeout (Tempo limite de conexão): indique por quanto tempo (em segundos) aguardar por conexões bem-sucedidas com uma aplicação. O valor padrão é 5. Você pode especificar de 1 a 60 segundos.

• Inactivity timeout (Tempo limite de inatividade): indique por quanto tempo (em segundos) aguardar por uma resposta para uma conexão existente com uma aplicação. O valor padrão é 180. Você pode especificar de 1 a 36000 segundos.

• Retention period (Período de retenção): indique por quanto tempo (em segundos) uma mensagem é válida e processada ativamente. O valor padrão é 345600. Você pode especificar de 60 a 1209600 segundos.

Se você usa uma fila do Amazon SQS existente, as configurações que você define ao criar um ambiente de operador podem entrar em conflito com as configurações definidas diretamente no Amazon SQS. Por exemplo, se você configurar um ambiente de operador com um valor de RetentionPeriod maior que o valor de MessageRetentionPeriod definido no Amazon SQS, este excluirá a mensagem quando ela exceder o MessageRetentionPeriod.

Por outro lado, se o valor RetentionPeriod definido na configuração do ambiente de operador for menor do que o valor de MessageRetentionPeriod definido no Amazon SQS, o daemon excluirá a mensagem antes de o Amazon SQS poder excluí-la. Em VisibilityTimeout, o valor definido para o daemon nas configurações do ambiente de operador substitui a configuração VisibilityTimeout do Amazon SQS. Certifique-se de que as mensagens sejam excluídas adequadamente comparando suas configurações do Elastic Beanstalk às configurações do Amazon SQS.