Linux 크론 작업을 "Amazon 방식"으로 변환하는 방법은 무엇입니까?

좋든 나쁘 든 우리는 전체 LAMP 웹 애플리케이션을 전용 머신에서 클라우드 (Amazon EC2 머신) 로 마이그레이션했습니다 . 지금까지는 훌륭하지만 우리가 크론을 만드는 방식 은 차선책입니다. "Amazon 방식"을 사용하여 클라우드에서 크론 작업을 가장 잘 관리하는 방법에 대한 Amazon 관련 질문이 있습니다.

문제 : 우리는 여러 웹 서버를 가지고 있으며 RSS 피드 생성, 이메일 트리거, 실제로 많은 다른 작업과 같은 일괄 작업을 위해 크론을 실행해야합니다. 그러나 크론 작업 은 종종 데이터베이스에 쓰기 때문에 한 시스템에서만 실행되어야 하므로 여러 시스템에서 실행하면 결과가 복제됩니다.

지금까지 우리는 웹 서버 중 하나를 "마스터-웹 서버"로 지정했으며 다른 웹 서버에는없는 몇 가지 "특별한"작업이 있습니다. 클라우드 컴퓨팅의 절충점은 안정성입니다. "마스터-웹 서버"는 단일 장애 지점이기 때문에 원하지 않습니다. 우리는 이들이 모두 동일하고 마스터 웹 서버를 클러스터에서 제거하지 않는 것을 기억하지 않고 업 스케일링 및 다운 스케일 할 수 있기를 바랍니다.

Linux 크론 작업을 단일 실패 지점이없는 일시적인 작업 항목으로 변환하도록 애플리케이션을 다시 디자인하려면 어떻게해야합니까?

지금까지 내 아이디어 :

• 실행중인 크론 전용 머신을 보유하십시오. 이것은 좀 더 관리하기 쉬울 것이지만 여전히 단일 실패 지점이며 추가 인스턴스를 갖는 데 약간의 돈을 낭비 할 것입니다.
• 일부 작업은 Linux 크론에서 MySQL 이벤트 로 이동할 수 있지만 응용 프로그램 논리를 데이터베이스 계층에 넣고 싶지 않기 때문에이 아이디어를 좋아하지는 않습니다.
• 아마도 우리는 모든 컴퓨터에서 모든 크론을 실행할 수 있지만 크론 스크립트를 변경하여 모두 잠금 메커니즘을 구현하는 논리로 시작하여 하나의 서버 만 실제로 작업을 수행하고 다른 서버는 건너 뛰도록합니다. 나는 버그가있을 수있는 것처럼 들리기 때문에이 아이디어의 팬이 아니며 우리 자신을 굴리는 것보다 Amazon 모범 사례를 사용하는 것을 선호합니다.
• 작업이 어딘가에 예약되고 대기열에 추가 된 다음 웹 서버가 각각 작업자가 될 수있는 상황을 상상하고 있습니다. 즉, "이거 가져 가겠습니다"라고 말할 수 있습니다. Amazon Simple Workflow Service는 정확히 이런 식으로 들리지만 현재는 이에 대해 잘 모르기 때문에 구체적인 사항이 도움이 될 것입니다. 크론처럼 단순한 것에 대해 무거운 것 같습니까? 올바른 서비스입니까 아니면 더 적합한 Amazon 서비스가 있습니까?

업데이트 : YouTube 에서 Amazon Simple Workflow Service 웨비나를 시청하고 34:40 ( http://www.youtube.com/watch?v=lBUQiek8Jqk#t=34m40s ) 에 확인한 후 질문 을 한 후 cron 작업을 샘플 애플리케이션으로 언급하는 슬라이드. 설명서 페이지 " Amazon SWF 용 AWS Flow Framework 샘플 "에서 Amazon은 크론에 대한 샘플 코드가 있다고 말합니다.

... > 크론 작업 이 샘플에서 장기 실행 워크 플로는 주기적으로 활동을 실행합니다. 실행이 매우 오랜 기간 동안 실행될 수 있도록 새로운 실행으로 실행을 계속하는 기능이 입증되었습니다. ...

Java 용 AWS SDK ( http://aws.amazon.com/sdkforjava/ ) 를 다운로드했고 우스꽝스러운 폴더 레이어에 Java 코드 ( aws-java-sdk-1.3.6/samples/AwsFlowFramework/src/com/amazonaws/services/simpleworkflow/flow/examples/periodicworkflow) 가 충분히 묻혀 있는지 확인했습니다 .

문제는 제가 솔직히 말하자면 제 스킬 셋으로 쉽게 소화 할 수있는 것이 아니기 때문에 실제로 도움이되지 않는다는 것입니다. PHP SDK에서 동일한 샘플이 누락되었으며 프로세스를 안내하는 자습서가없는 것 같습니다. 그래서 기본적으로 저는 여전히 조언이나 팁을 찾고 있습니다.

저는 Amazon Gold 지원에 가입하여이 질문을했는데, 이것이 그들의 응답이었습니다.

톰

나는 동료들 중 일부를 빠르게 설문 조사를했고 크론에 비어있는 것으로 나타 났지만, 잠을 자고 나서 중요한 단계가 잠금으로 제한 될 수 있음을 깨달았습니다. 그래서 "분산 크론 작업 잠금"을 찾고 Apache 프로젝트 인 Zookeeper에 대한 참조를 찾았습니다.

http://zookeeper.apache.org/doc/r3.2.2/recipes.html

http://highscalability.com/blog/2010/3/22/7-secrets-to-successfully-scaling-with-scalr-on-amazon-by-se.html

또한 TTL을 사용하여 잠금을 생성하는 방법으로 memcached 또는 유사한 캐싱 메커니즘을 사용하는 것에 대한 참조를 보았습니다. 이런 식으로 TTL이 300 초인 플래그를 설정하면 다른 크론 작업자가 작업을 실행하지 않습니다. 잠금은 TTL이 만료 된 후 자동으로 해제됩니다. 이것은 어제 논의한 SQS 옵션과 개념적으로 매우 유사합니다.

또한보십시오; Google의 통통한 http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/chubby-osdi06.pdf

이것이 도움이되는지 알려 주시고 자유롭게 질문하십시오. 우리의 서비스가 초보자와 숙련 된 개발자 모두에게 복잡하고 어려울 수 있다는 것을 잘 알고 있습니다. 우리는 항상 아키텍처 및 모범 사례 조언을 제공하게되어 기쁩니다.

친애하는,

Ronan G. Amazon Web Services

이 비디오가 정확한 질문에 대한 답이라고 생각합니다. cronjobs aws 방식 (확장 가능하고 내결함성) :

Amazon Simple Workflow를 통해 클라우드에서 Cron 사용

이 비디오는 cronjob을 구현하는 특정 사용 사례를 사용하여 SWF 서비스를 설명합니다 .

crontab에서 직접 오는 경우 솔루션의 상대적 복잡성을 삼키기 어려울 수 있습니다. 마지막에 추가 복잡성이 당신을 구입하는 것을 이해하는 데 도움이 된 사례 연구가 있습니다. 사례 연구를보고 확장 성 및 내결함성에 대한 요구 사항을 고려하여 기존 crontab 솔루션에서 마이그레이션해야하는지 여부를 결정하는 것이 좋습니다.

cronjob에 SQS를 사용할 때는 "하나의 컴퓨터에만 하나의 작업 만 표시"되는 것을 보장하지 않으므로주의하십시오. 그들은 "적어도 하나"가 메시지를받을 것이라고 보장합니다.

보낸 사람 : http://aws.amazon.com/sqs/faqs/#How_many_times_will_I_receive_each_message

Q : 각 메시지를 몇 번 받게됩니까?

Amazon SQS는 대기열에있는 모든 메시지를 "최소 한 번"전달하도록 설계되었습니다. 대부분의 경우 각 메시지는 애플리케이션에 정확히 한 번 전달되지만 메시지를 두 번 이상 처리해도 오류나 불일치가 발생하지 않도록 시스템을 설계해야합니다.

지금까지 Gearman Job Server 인스턴스가 설치된 하나의 인스턴스가있는 솔루션에 대해 생각할 수 있습니다 : http://gearman.org/ . 동일한 시스템에서 명령을 생성하는 cron 작업을 구성하여 백그라운드에서 cronjob 작업을 실행합니다. 그런 다음 웹 서버 (작업자) 중 하나가이 작업을 실행하기 시작하고 하나만 작업을 수행하도록 보장합니다. 작업자 수는 중요하지 않습니다 (특히 Auto Scaling을 사용하는 경우).

이 솔루션의 문제점은 다음과 같습니다.

• Gearman 서버는 분산 스토리지로 구성하지 않는 한 (예 : memcached 또는 일부 데이터베이스 사용) 단일 실패 지점입니다.
• 그런 다음 여러 Gearman 서버를 사용하여 cronjob을 통해 작업을 생성하는 서버를 선택해야하므로 다시 동일한 문제로 돌아갑니다. 그러나 Gearman을 사용하여 이런 종류의 단일 실패 지점으로 살 수 있다면 꽤 좋은 솔루션처럼 보입니다. 특히이를 위해 큰 인스턴스가 필요하지 않습니다 (우리 경우에는 마이크로 인스턴스로 충분합니다).

Amazon은 방금 Elastic Beanstalk의 새로운 기능을 출시했습니다 . 로부터 문서 :

AWS Elastic Beanstalk는
컨테이너 이름에 "v1.2.0"이 포함 된 솔루션 스택으로 사전 정의 된 구성을 실행하는 환경에서 작업자 환경 계층에 대한 주기적 작업을 지원합니다 . "

이제 cron.yaml예약 작업을 구성 하는 파일이 포함 된 환경을 만들 수 있습니다 .

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 * * *"

자동 확장 환경에서 한 번만 실행하는 보험이 메시지 대기열 (SQS)을 통해 활용되는 것을 상상할 수 있습니다. cron 데몬이 이벤트를 트리거하면 해당 호출을 SQS 대기열에 넣고 대기열의 메시지는 한 번만 평가됩니다. 문서에 따르면 SQS에 처리 할 메시지가 많은 경우 실행이 지연 될 수 있습니다.

나는이 질문을 세 번째로 만났고 내가 끼어들 것이라고 생각했다. 우리는 잠시 동안이 딜레마를 겪었다. 나는 아직도 정말 AWS 여기에 기능이 없습니다 생각합니다.

우리의 경우 가능한 솔루션을 살펴본 후 두 가지 옵션이 있다고 결정했습니다.

• 한 번에 한 번만 실행해야하는 작업을 실행하는 cronjob 서버를 설정하고, 자동으로 확장하고, 특정 CloudWatch 통계가 올바른 것이 아닐 때 교체되었는지 확인합니다. cloud-init스크립트를 사용 하여 cronjob을 실행합니다. 물론 이것은 다운 타임을 동반하여 cronjob을 놓치게됩니다 (우리처럼 매분 특정 작업을 실행할 때).
• 사용하는 논리를 rcron사용하십시오. 물론 마법은 rcron그 자체 가 아닙니다 . 실패한 노드를 감지하고 ( keepalived여기서 사용하는 ) 다른 노드를 마스터로 "업그레이드" 하는 데 사용하는 논리에 있습니다 .

우리는 두 번째 옵션을 사용하기로 결정했습니다. 그 이유는 놀랍도록 빠르고 AWS 이전 시대에 이러한 cronjob을 실행하는 웹 서버에 대한 경험이 있기 때문입니다.

물론이 솔루션은 타이밍이 결정적인 요소 인 기존의 1 노드 cronjob 접근 방식을 대체하기위한 것입니다 (예 : "작업 A가 매일 오전 5시에 한 번 실행되기를 원합니다" ) 또는 우리의 경우 "작업 B를 원합니다. 1 분에 한 번 실행 " ). 당신이 트리거 일괄 처리 로직에 cronjobs를 사용하는 경우, 당신은해야 정말 좀 봐 SQS. 액티브-패시브 딜레마가 없습니다. 즉, 단일 서버 또는 전체 인력을 사용하여 대기열을 처리 할 수 ​​있습니다. 또한 SWF인력 확장을 고려 하는 것이 좋습니다 ( auto scaling대부분의 경우에도 트릭을 수행 할 수 있음).

다른 제 3 자에 따라 우리는 피하고 싶었습니다.

2016 년 2 월 12 일 Amazon은 AWS Lambda를 사용하여 SSH 작업 예약 에 대해 블로그를 게시했습니다 . 나는 이것이 질문에 대한 답이라고 생각합니다.

이미 Redis 서비스가있는 경우 다음과 같은 좋은 솔루션이 될 것입니다.

https://github.com/kvz/cronlock

더 읽기 : http://kvz.io/blog/2012/12/31/lock-your-cronjobs/

"Amazon"방식은 배포되는 것입니다. 즉, 부피가 큰 크론은 여러 개의 작은 작업으로 분할되어 올바른 컴퓨터에 전달되어야합니다.

유형이 FIFO로 설정된 SQS 대기열을 사용하여 각 작업이 하나의 시스템에서만 실행되도록 함께 붙입니다. 또한 시스템이 백업 될 때까지 대기열이 버퍼링되므로 오류를 허용합니다.

FIFO Exactly-Once Processing : 메시지는 한 번 전달되고 소비자가 처리하고 삭제할 때까지 사용 가능한 상태로 유지됩니다. 중복은 대기열에 도입되지 않습니다.

또한 이러한 작업을 실제로 '일괄 처리'해야하는지 고려하십시오. 하룻밤의 업데이트가 예상보다 상당히 크면 어떻게됩니까? 동적 리소스를 사용하더라도 충분한 시스템이 회전 할 때까지 처리가 지연 될 수 있습니다. 대신 SDB에 데이터를 저장하고, SQS를 통해 시스템에 업데이트를 알리고, RSS 피드를 즉시 생성하십시오 (캐싱 사용).

일괄 작업은 처리 리소스가 제한되고 '라이브'서비스가 우선시되었던 시간입니다. 클라우드에서는 그렇지 않습니다.

당신은 왜 당신 자신을 만들 것입니까? Quartz와 같은 것을 사용하지 않는 이유는 무엇입니까 (클러스터 드 스케줄링 포함). 문서를 참조하십시오.

http://quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigJDBCJobStoreClustering

우리가하는 일은 ELB 뒤에 웹 애플리케이션 클러스터의 일부인 특정 서버가 하나 있고 특정 DNS 이름이 할당되어 특정 서버에서 작업을 실행할 수 있다는 것입니다. 또한 작업으로 인해 서버 속도가 느려지면 ELB가 클러스터에서이를 제거한 다음 작업이 끝나면 반환하고 다시 정상 상태가되는 이점도 있습니다.

챔피언처럼 작동합니다.

cron 표현식이 Amazon 방식으로 작동하는지 확인하는 한 가지 방법은 events 명령을 통해 실행하는 것입니다. 예를 들면 :

aws events put-rule --name "DailyLambdaFunction" --schedule-expression "<your_schedule_expression>

일정 표현식이 유효하지 않으면 실패합니다.

추가 리소스 : https://docs.aws.amazon.com/cli/latest/reference/events/put-rule.html

비 AWS 서비스를 사용하려는 경우 Microsoft Azure를 확인할 수 있습니다 . Azure는 훌륭한 작업 스케줄러를 제공합니다 .

아무도 CloudWatch Event 를 언급하지 않았기 때문에 cron 작업을 수행하는 AWS 방식이라고 말하고 싶습니다. Lambda 함수, ECS 작업과 같은 많은 작업을 실행할 수 있습니다.