しかし、Amazon Linux 2023ではcronがデフォルトで無効になっています。これはcron以外に、cronのようなバッチ実行・定期実行する仕組みがあるということなのかと思い、cronを使わずにE2上でバッチ実行・定期実行する仕組みを考えてみました。

そして、Amazon EventBridge、AWS Step Functions、およびAWS Systems Manager startAutomationExecutionを組み合わせて、EC2インスタンス上でバッチ・定期実行を試してみましたので、紹介します。

特に、Step Functionsを使用することで、エラーハンドリングや通知が容易になり、安全にバッチ実行できるようになります。

エラーハンドリングは以下の状態を把握したいという意味合いです。

• 成功
• 失敗
• タイムアウト(バッチ実行に想定以上に時間がかかっている状態)

使用するAWSサービスの概要

Amazon EventBridge

EventBridgeは、さまざまなAWSサービスやアプリケーションからのイベントをルーティングするサービスです。特定のイベントに基づいてStep Functionsをトリガーするのに適しています。

AWS Step Functions

Step Functionsは、複数のAWSサービスを連携させるワークフローを構築するためのサービスです。ワークフロー内でのエラーハンドリングやリトライ処理が容易であり、信頼性の高いタスク管理が可能です。

AWS Systems Manager startAutomationExecution

SSM オートメーション ドキュメントに則った処理をしてくれます。

実際に試してみる

EC2の準備

EC2の起動

バッチ実行環境のEC2を起動します。

• Amazon Linux 2023 AMIを指定
• インスタンスタイプは、t4g.nanoなど安いやつを選びます
• ネットワーク設定で「からの SSH トラフィックを許可」を指定する
  • セキュリティを考慮して、アクセス元は絞った方がいい
• EC2へはEC2 Instance Connectで接続するため、キーペアはなしでOK

EC2の中に入る

• 諸々設定するため、以下の流れで起動したEC2の中に入ります
  • AWSコンソールのEC2の一覧で、該当のEC2を選択して、接続を押下
    • EC2 Instance Connectタブの接続を押下

EC2上でテスト用のスクリプトを作成

vi test.sh

＜スクリプトの中身＞

exit 0;

スクリプトに実行権限をつける

chmod u+x test.sh

Step Functionsの準備

まず、Step Functionsでワークフローを作成します。このワークフローでは、Systems Manager startAutomationExecutionを使用してEC2インスタンス上でバッチジョブを実行します。

Step Functionsのステートマシンを用意

以下は、EC2インスタンス上でバッチジョブを実行するようになっています。

プログラムが異常終了・時間以内(60秒)に終わらない場合、異常終了となります。

{
  "Comment": "A description of my state machine",
  "StartAt": "StartAutomationWaitForCallBack",
  "States": {
    "StartAutomationWaitForCallBack": {
      "Type": "Task",
      "Resource": "arn:aws:states:::aws-sdk:ssm:startAutomationExecution.waitForTaskToken",
      "Parameters": {
        "DocumentName": "SfnRunCommandByInstanceIds",
        "Parameters": {
          "InstanceIds": [
            "{インスタンスID}"
          ],
          "taskToken.$": "States.Array($$.Task.Token)",
          "workingDirectory": [
            "/"
          ],
          "Commands": [
            "/test.sh"
          ],
          "executionTimeout": [
            "60"
          ],
          "deliveryTimeout": [
            "60"
          ],
          "shell": [
            "Shell"
          ]
        }
      },
      "End": true
    }
  }
}

以下のポリシーをアタッチします。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": "ssm:StartAutomationExecution",
			"Resource": "*"
		}
	]
}

SSM オートメーション ドキュメントの作成

以下の「SfnRunCommandByInstanceIds」を使用させていただきます。

GitHub - aws-samples/amazon-stepfunctions-ssm-waitfortasktoken: This pattern implements an automation document wrapper around AWS-RunShellScript execution for a AWS Step Functions waitForTaskToken integration.

This pattern implements an automation document wrapper around AWS-RunShellScript execution for a AWS Step Functions waitForTaskToken integration. - GitHub - aws...

github.com

「SfnRunCommandByInstanceIds」はCloudFormationで作成できます。

このファイルをダウンロードして、CloudFormationで実行すれば作成できます。

EventBridgeの設定

次に、EventBridgeを設定して、Step Functionsの実行をトリガーします。

1. EventBridgeのルール作成: EventBridgeのダッシュボードに移動し、「ルールを作成」をクリックします。
2. ルールの設定:
   • イベントソース: スケジュール（例えば、毎日午前2時に実行）を選択し、cron式を設定します。例えば、cron(0 2 * * ? *)。
   • ターゲット: ターゲットとして、Step Functionsのステートマシンを選択します。
3. ターゲットの設定: Step FunctionsのステートマシンのARNを指定します。

動作確認

• EC2のtest.shに「exit 0」を記載した状態で実行
  • StepFunctionsが成功していればOK
• EC2のtest.shに「exit 1」を記載した状態で実行
  • StepFunctionsが失敗していればOK
• EC2のtest.shに「sleep 61」と「exit 0」を記載した状態で実行
  • タイムアウトするので、StepFunctionsが失敗していればOK

上記記載の方法のメリットとデメリット

メリット

• 柔軟なスケジューリング: EventBridgeを使用することで、定期的なスケジュール設定が容易になります。
• 詳細なエラーハンドリング: Step Functionsを使用することで、ジョブの成功、失敗、遅延に対する詳細なエラーハンドリングと通知が可能です。

デメリット

• 設定の複雑さ: EventBridge、Step Functions、Systems Manager の設定が必要なため、設定手順が複雑になる可能性があります。
• コスト: 複数のAWSサービスを使用するため、コストが増加する可能性があります。

まとめ

Amazon Linux 2023ではcronがデフォルトで無効になっているため、AWSのサービスを組み合わせて定期的なタスクを実行する方法を検討してみました。

EventBridge、Step Functions、Systems Manager startAutomationExecutionを使用することで、EC2インスタンス上で定期的なバッチジョブを実行し、エラーハンドリングを実現できました。

エラーの場合、通知するようにしておけばEC2でのバッチ実行も安心かなと思います！

バッチの実行は他にもいろいろな方法がありますので、気になる方は以下のリンクをクリックくださーい

https://it.kensan.net/it/aws-batch-method.html

localhost

• どのAWSサービスが選択肢として考えられるか
• どのAWSサービスを選択すればいいのか

について考えていきます。

AWSでバッチ処理・定期実行する方法を4つ紹介し、それぞれ特徴やメリットとデメリットがありますので、この点について記載していきます。

バッチ処理・定期実行方式のパターンと特徴を知って適切な手段を選択しよう！という記事です。

まずはどのような構築方法があるかについて記載していきます。

4つのバッチ処理・定期実行方式

バッチ処理・定期実行方式は以下の4つを想定しています。

4つのバッチ処理・定期実行方式の詳細情報

それぞれのバッチ処理・定期実行方式について詳細を見ていきます。

EC2について

使用するAWSサービス

EC2

処理概要

Linux系OSで用いられる定時実行機能であるcronのコマンドを使用する

メリット

昔からよく使われているcronの知識が使える

デメリット

EC2インスタンスを起動しておく必要があり、使っていない時間もコストがかかる

障害に弱い。EC2サーバに障害があると終わる

サーバが複数になると管理が大変

EC2にも、EventBridgeをトリガーにStep Functionsを起動して、EC2のバッチを実行する方法もあるので、気になる方は以下のリンクをクリックくださーい

https://it.kensan.net/it/eventbridge-stepfunctions-ec2-batch.html

localhost

SQS×ECS

使用するAWSサービス

EventBridge

SQS

ECS

処理概要

EventBridgeでキューを生成。ECSコンテナでキューを取得して実行する

メリット

ECSを起動しておくため、コンテナの起動時間を要さない。

デメリット

EventBridgeでキューを生成するが、EventBridgeはまれに1 つのイベントに対して複数回トリガーされることもあるので要注意(1つの設定で複数キューが生成されることがある)

(多重起動対策をプログラムでしておく必要がある)

ECSを起動しておく必要があり、使っていない時間もコストがかかる

ECS タスクスケジューリング

使用するAWSサービス

ECS

処理概要

ECS タスクスケジューリングを利用して、コンテナを起動して実行する

メリット

処理実行時のみコンテナを立ち上げるので、無駄なコストが発生しない

デメリット

コンテナが起動するまでに時間がかかる。(ECS タスクスケジューリングが動き出してから実際にバッチが実行されるまでタイムラグがある)

1つのECS タスクスケジューリング設定で、複数コンテナが立ち上がってしまうことがあるため、多重起動対策をプログラムでしておく必要がある

Lambda

使用するAWSサービス

EventBridge

Lambda

処理概要

EventBridgeからLambdaを起動し、バッチ処理を開始する

メリット

コールドスタートの問題はあるが、比較的低レイテンシーで処理を開始できる。

デメリット

Lambdaには15分でタイムアウトする制限があるので、長時間実行のバッチ起動処理には向かない

どのサービスを使えばよいか

バッチ処理開始までに多少の遅延があっても許容される場合

「ECS タスクスケジューリング」を使用するのがいいと思われます。

デメリットの「コンテナが起動するまでに時間がかかる」が許容されるためです。

バッチ処理開始までの遅延が許容されない、かつ、バッチ処理時間が15分を超える

「SQS×ECS」を使用するのがいいです。

消去法です。

バッチ処理開始までの遅延が許容されない、かつ、バッチ処理時間が15分を超えない

遅延が少なく、実行時だけ課金される「Lambda」を選択します。

まとめ

AWS でバッチ・定期実行する際の方式について記載しました。

AWSはサービスがいっぱいあり、バッチ実行時にどのサービスを使えばいいか迷うことも多いと思いますが、迷った時は本記事の「どのサービスを使えばよいか」が参考になると嬉しいです。

WEBサイト構築についての記事もありますので、よろしければ★

https://it.kensan.net/it/aws-web-method.html

localhost