amazon ec2 - Como converter tarefas cron do Linux em “Amazon way”?




amazon-ec2 scheduled-tasks (8)

A Amazon acaba de released novos recursos para o Elastic Beanstalk. Dos docs :

O AWS Elastic Beanstalk suporta tarefas periódicas para o ambiente do trabalhador
camadas em ambientes que executam uma configuração predefinida com uma pilha de solução que contém "v1.2.0" no nome do contêiner. "

Agora você pode criar um ambiente contendo um arquivo cron.yaml que configura as tarefas de planejamento:

version: 1
cron:
- name: "backup-job"          # required - unique across all entries in this file
  url: "/backup"              # required - does not need to be unique
  schedule: "0 */12 * * *"    # required - does not need to be unique
- name: "audit"
  url: "/audit"
   schedule: "0 23 * * *"

Eu imagino que o seguro de executá-lo apenas uma vez em um ambiente com autoescala é utilizado por meio da fila de mensagens (SQS). Quando o daemon do cron aciona um evento, ele coloca essa chamada na fila do SQS e a mensagem na fila é avaliada apenas uma vez. Os documentos dizem que a execução pode ser atrasada se o SQS tiver muitas mensagens para processar.

Para melhor ou pior, nós migramos todo o nosso aplicativo da Web LAMP de máquinas dedicadas para a nuvem (máquinas Amazon EC2). Está indo muito bem até agora, mas a maneira como fazemos crons é sub-ótima. Eu tenho uma pergunta específica da Amazon sobre como gerenciar melhor as tarefas do cron na nuvem usando "o jeito da Amazon".

O problema : temos vários servidores web e precisamos executar programas para tarefas em lote, como criar feeds RSS, disparar e-mails, muitas coisas diferentes, na verdade. Mas os cron jobs precisam rodar apenas em uma máquina, porque eles geralmente gravam no banco de dados, o que duplicaria os resultados se fosse executado em várias máquinas.

Até agora, designamos um dos servidores da Web como o "master-webserver" e tem algumas tarefas "especiais" que os outros servidores da Web não possuem. O trade-off para cloud computing é a confiabilidade - não queremos um "servidor master-web" porque é um ponto único de falha. Queremos que todos sejam idênticos e sejam capazes de melhorar e diminuir o desempenho sem lembrar de não tirar o servidor master-web do cluster.

Como podemos redesenhar nosso aplicativo para converter tarefas cron do Linux em itens de trabalho transitórios que não possuem um único ponto de falha?

Minhas ideias até agora:

  • Tenha uma máquina dedicada apenas a executar crons. Isso seria um pouco mais gerenciável, mas ainda seria um ponto único de falha, e gastaria algum dinheiro com uma instância extra.
  • Alguns trabalhos poderiam ser movidos do Linux para MySQL Events, mas eu não sou um grande fã dessa idéia, já que não quero colocar a lógica do aplicativo na camada do banco de dados.
  • Talvez possamos rodar todos os crons em todas as máquinas, mas mudar nossos scripts cron para que todos eles comecem com um pouco de lógica que implemente um mecanismo de bloqueio, de modo que apenas um servidor realmente atue e os outros simplesmente pulem. Eu não sou fã dessa idéia, pois ela parece potencialmente problemática e eu preferiria usar uma prática recomendada da Amazon, em vez de usar a nossa própria prática.
  • Estou imaginando uma situação em que as tarefas são agendadas em algum lugar, adicionadas a uma fila e, em seguida, os servidores da web podem ser um trabalhador, o que pode dizer "ei, eu aceito essa". O Amazon Simple Workflow Service faz exatamente esse tipo de coisa, mas atualmente não sei muito sobre isso, portanto, qualquer detalhe seria útil. Parece meio pesado para algo tão simples como um cron? É o serviço certo ou existe um serviço Amazon mais adequado?

Atualização: Desde que fiz a pergunta, assisti ao webinar do Amazon Simple Workflow Service no YouTube e notei às 34:40 ( http://www.youtube.com/watch?v=lBUQiek8Jqk#t=34m40s ) que tive um vislumbre de um slide mencionar tarefas agendadas como um aplicativo de amostra. Em sua página de documentação, " Amostras do AWS Flow Framework para o Amazon SWF ", a Amazon diz que tem código de amostra para crons:

... > Tarefas Cron Nesta amostra, um fluxo de trabalho de longa execução executa periodicamente uma atividade. A capacidade de continuar as execuções como novas execuções para que uma execução possa ser executada por longos períodos de tempo é demonstrada. ...

Eu baixei o AWS SDK para Java ( http://aws.amazon.com/sdkforjava/ ) e com certeza enterrado dentro de uma camada ridícula de pastas há algum código java ( aws-java-sdk-1.3.6/samples/AwsFlowFramework/src/com/amazonaws/services/simpleworkflow/flow/examples/periodicworkflow ).

O problema é que, se eu for honesto, isso não ajuda muito, já que não é algo que eu possa facilmente digerir com o meu conjunto de habilidades. A mesma amostra está faltando no PHP SDK e não parece haver um tutorial que passe pelo processo. Então, basicamente, eu ainda estou procurando conselhos ou dicas.


Acho que este vídeo responde à sua pergunta exata - cronjobs the aws way (escalável e tolerante a falhas):

Usando o Cron na nuvem com o Amazon Simple Workflow

O vídeo descreve o serviço SWF usando o caso de uso específico de implementação de cronjobs.

A complexidade relativa da solução pode ser difícil de engolir se você estiver vindo diretamente de um crontab. Há um estudo de caso no final que me ajudou a entender o que essa complexidade extra compra para você. Eu sugeriria observar o estudo de caso e considerar suas necessidades de escalabilidade e tolerância a falhas para decidir se você deve migrar de sua solução crontab existente.



Eu me deparei com essa pergunta pela terceira vez agora e pensei em aproveitar. Já enfrentamos esse dilema há algum tempo. Eu ainda sinto que a AWS está faltando um recurso aqui.

No nosso caso, depois de analisar as possíveis soluções, decidimos que tínhamos duas opções:

  • Configure um servidor de execução de tarefas que execute as tarefas que devem ser executadas apenas uma vez por vez, dimensione-as automaticamente e certifique-se de que elas sejam substituídas quando determinadas estatísticas do CloudWatch não forem o que deveriam. Usamos scripts cloud-init para obter os cronjobs em execução. Claro, isso vem com um tempo de inatividade, levando a perda de cronjobs (ao executar certas tarefas a cada minuto, como fazemos).
  • Use a lógica que o rcron usa. É claro que a magia não está realmente no próprio rcron , é na lógica que você usa para detectar um nó com falha (usamos o keepalived aqui) e "atualiza" outro nó para masterizar.

Decidimos optar pela segunda opção, simplesmente porque ela é incrivelmente rápida e já tivemos experiência com servidores Web que executam esses cronjobs (em nossa era pré-AWS).

Obviamente, esta solução se destina especificamente a substituir a abordagem cronjob tradicional de um nó, em que o timing é o fator decisivo (por exemplo, "Eu quero que o job A seja executado uma vez por dia às 5h" ou no nosso caso "Quero job B" para executar uma vez a cada minuto " ). Se você usa cronjobs para acionar a lógica de processamento em lote, você deve realmente dar uma olhada no SQS . Não há um dilema ativo-passivo, o que significa que você pode usar um único servidor ou uma força de trabalho inteira para processar sua fila. Também gostaria de sugerir que você SWF para dimensionar sua força de trabalho (embora o auto scaling possa fazer o truque na maioria dos casos).

Dependendo de outro terceiro, era algo que queríamos evitar.


O modo "Amazon" deve ser distribuído, o que significa que os crons volumosos devem ser divididos em muitos trabalhos menores e entregues às máquinas certas. Usar o SQS para uni-lo em conjunto garante que cada trabalho seja visto por apenas uma máquina. Ele também tolera falhas, já que as filas serão armazenadas até que a máquina volte a funcionar.

Considere também se você realmente precisa 'batch' dessas operações. O que acontece se as atualizações de uma noite forem consideravelmente maiores do que o esperado? Mesmo com o fornecimento de recursos dinâmicos, seu processamento pode ser adiado, aguardando a geração de máquinas suficientes. Em vez disso, armazene seus dados no SDB, notifique as máquinas de atualizações via SQS e crie seu feed RSS na hora (com o armazenamento em cache).

Os trabalhos em lote são de uma época em que os recursos de processamento eram limitados e os serviços 'ativos' tinham precedência. Na nuvem, isso não é o caso.


O que fazemos é que temos um servidor específico que faz parte do nosso cluster de aplicativos da web atrás de um ELB e também atribuiu um nome DNS específico para que possamos executar os trabalhos naquele servidor específico. Isso também tem o benefício de que, se esse trabalho causar lentidão no servidor, o ELB o removerá do cluster e, em seguida, o retornará quando a tarefa terminar e ficar saudável novamente.

Funciona como um campeão.







amazon-swf