Cron은 Lambda의 Ver2015.09를 사용합니다.

며칠 전 "JAWS-UG 지바 지부 Vol.5~가을 AWS Lambda & API Gateway제!!!~"친목회에서 LT에 뛰어들게 한 내용이다.

지금까지의 Lambda cron성 있는 시도.

■ Cron 대신 AWS Lambda를 사용해 보세요.

S3의 Event에서 시작하여 S3의 object를 만들어서 순환하는 방법

Lambda에서 Object를 S3에 넣는 데 실패하면 순환이 중단됩니다. 또한 주파수는 최대 1분에 1회 정도입니다.

■ Azure Job Scheduler+AWS Lambda에서 꿈을 실현하는 서버 없는 정기 작업

자신도 이 기사를 보고 같은 형식으로 오랫동안 사용했다(무료 프레임이라도 1시간에 한 번은 사용할 수 있다).

어째서 AWS의 서비스로만 실시할 수 있습니까?

■ 실험1 Dead Dead Queue DeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDe

처음에 두 개의 SQL을 만들어서 Dead Queue로 지정하면 서로 메시지를 보낼 수 없나요?생각해 봤어요.

→ 받지 못한 메시지가 Dead Queue에 들어가지 않았습니다...
#Lambda에서 SQL을 다 읽어도 될 줄 알았는데 실패할 때 끊겨서 심심했어요.

■ 실험2 myself 파틴으로 돌아가기

Alarm을 설정하는 과정에서 SQS가 갑자기 Subscribe SNS Topic을 사용할 수 있다는 것을 알아차렸기 때문에 다음 절차에 따라 정기적으로 SNS Alarm을 울린다.

SQS 대기열을 만듭니다(이 경우 메시지를 반복하려는 시간 - 5분 등으로 설정됨)

SQS에 메시지 상태(approximate Number OfMessages Visible<=0)가 일정시간(5분) 지속되지 않으면 CloudWatch Alarm에서 SNS Topic에 경보를 보냅니다

상기 SNS Topic에서 상기 SQLS Queue Subscribe를 미리 사용합니다

이로 인해 메시지가 없는 경보가 SQL 메시지로 같은 대기열에 도달하고 메시지 유지 기간이 지나면 메시지가 도착하는 순환 상태로 날아갈 수 있습니다.
이를 사용하여 SNS Topic에서 Lambda function을 지정하면 일정 시간마다 Lambda function을 실행하는 상태가 됩니다.

SNS에서 SQS로의 경보 실패는 위험으로 존재한다. 예를 들어 1시간 이상 0이 지속되면 경보가 울리는 설정을 추가함으로써 어떤 문제가 발생하더라도 1시간 이내에 다시 시도하는 것이다.
그러나 SQS의 Aproximate Number OfMessages Visible 도량은 메시지에서 검출된 숫자 사이로 들어가기 때문에 메시지 유지 기간은 10분 미만으로 설정하지 않는 것이 좋다고 생각합니다.

총결산

통용되는 스케줄러(REST의 URL과 AWS의 API 호출이 가능한 것)가 있으면 좋겠다!