LoginSignup
91
68

More than 3 years have passed since last update.

AWS Batchを使ってcronのような定期的処理を実現する

Last updated at Posted at 2018-07-28

はじめに

Linuxのcronのような定期的な処理をAWSで走らせられるようにしたいということになり、実際にやってみた

使った機能

AWS EC2
AWS ECS
AWS Batch
AWS CloudWatch

今回の各機能の流れ

Batchで実行したい処理を定義する(この中で自動的にECSにクラスタが作られる)
→Batchで処理を走らせる(EC2にインスタンスが立ち上がり、処理が完了したら自動でインスタンスが削除される)

基本は上記の繰り返し
これをCloudWatch内の「イベント」機能で定期実行するようにする

作ってみる

基本はAWSのドキュメントに従いながらいきます
公式ドキュメント

Batchの開始

ダッシュボードからBatchを訪問
スクリーンショット 2018-07-28 14.33.40.png

優しいチュートリアルがあります
今すぐ始めるを選択
スクリーンショット 2018-07-28 14.40.23.png

ジョブの定義

ひとまず今回は簡単なテストを走らせるため設定内容はほぼデフォルトでいきます
[ジョブをどのように実行しますか?] → Amazon EC2 の使用
[ジョブ定義] → 新しいジョブ定義の作成
[ジョブ定義名] → (適当に)first-test
[ジョブロール] → (空欄)
スクリーンショット 2018-07-28 14.47.21.png

[Job Type] → 単一
[コンテナイメージ] → busybox
[コマンド] → echo 'hello world'
[vCPU] → 1
[メモリ] → 512
[ジョブの試行] → 1

Dockerイメージはbusybox(デフォルト)を使用し仮想CPUは1個、メモリは512MBのDockerコンテナを立てるという意味

ページ下部のパラメーターはひとまずスルー

このページの設定ができたら「次へ」
スクリーンショット 2018-07-28 14.53.25.png

コンピューティング環境とジョブキュー作成

[コンピューティング環境のタイプ] → マネージド型
[コンピューティング環境の名前] → (適当に)first-test-env
[サービスロール][EC2 インスタンスロール] →新しいロールの作成でも、既存のロール使用でもどちらでも問題なし
スクリーンショット 2018-07-28 14.58.23.png

[プロビジョニングモデル] → オンデマンド
[許可されたインスタンスタイプ] → optimal
[最小 vCPU] → 0
[必要な vCPU] → 2
[最大 vCPU] → 12

インスタンスタイプ:optimalは、走らせるbatchの処理内容に応じてAWSが最適なインスタンスを都度作成してくれる
作成されるインスタンスは最小サイズでもlargeサイズなので、あまり作成しすぎると料金が半端じゃなくなるため注意
最小 vCPUは0だとbatch処理が完了した後に、作成されたインスタンスが削除され、1以上だとインスタンスは残り続ける
必要な vCPUは作成されたインスタンスが使用するCPUの数
最大 vCPUは一つのコンピューティング環境がスケールできる最大数
スクリーンショット 2018-07-28 15.16.38.png

ネットワーキングの設定はすでにデフォルトのものが選択されているはず
ジョブキューの名前だけ設定する
スクリーンショット 2018-07-28 15.18.11.png

全て入力したら「作成」を選択
作成するのに少し時間がかかるが、終了したら「ダッシュボード」を選択
スクリーンショット 2018-07-28 15.19.41.png

先ほど作ったジョブキューとコンピューティング環境が表示されている
batchを設定してすぐはテスト実行が走るため、RUNNABLEステータスのジョブが一つある
スクリーンショット 2018-07-28 15.20.03.png

時間が経つとテスト実行がSUCCEEDEDに移行するため、ログをみてみる
SUCCEEDED内のジョブを選択すると下記画像のような項目が出現するため、
[View logs]を選択する
スクリーンショット 2018-07-28 15.23.53.png

CloudWatchにリンクが飛んで、無事メッセージに「hello world」が表示されたことが確認できる
スクリーンショット 2018-07-28 15.26.58.png

ちなみにこの時点でECSにクラスタが出来上がっている
特にいじることもないため、確認だけ
スクリーンショット 2018-07-28 15.29.30.png

スクリーンショット 2018-07-28 15.29.12.png

CloudWatchで定期的実行

CloudWatchの「イベント」ページへ行き、「ルールの作成」を選択

スクリーンショット 2018-07-28 15.45.55.png

スクリーンショット 2018-07-28 15.49.09.png

今回はひとまず実行間隔は3分、先ほどのジョブでハローしまくる
[イベントソース] → スケジュール、3分ごと

ターゲットの追加で[Batch job queue]を選択
[Job queue]と[Job definition]は先ほど作った該当のジョブキューとジョブ定義のARN(例:arn:aws:batch:ap-no〜)をコピーして持ってくる
[Job name]は適当に好きなものを入れる
ロールは新規作成か既存のものを使用(今回は新規で作成)

入力したら「設定の詳細」へ
スクリーンショット 2018-07-28 16.05.34.png

名前を入力と[状態]を有効にチェックを入れ「ルールの作成」を選択
スクリーンショット 2018-07-28 16.03.15.png

数分後、Batchの結果をみてみると、3分ごとにジョブが実行されている
スクリーンショット 2018-07-28 16.16.46.png

定期実行を止める場合はCloudWatchの「ルール」において該当のルールを「無効化」させる

振り返り

今回は簡単なテストをしただけだが、BatchはAWSにdockerイメージをおいたり、dockerファイルを使用したりして、より柔軟な処理をすることができる
AWSには有名なlambdaもあるため、それぞれの特徴を把握して、使いこなせるようにしていきたい

ちなみに今回使用している機能は無料枠ではできないため、料金が発生します
検証する際はインスタンスの長時間起動などには気をつけましょう

はまったところ

Batchを触り始めた当初、job定義、コンピューティング環境を作成し、ジョブを実行後、jobのステータスがRUNNABLEから動かないトラブルが続いた

他の人の記事を見るとDNS解決ができていからなどのトラブルシューティングはあったが、そちらは問題ではなかった

よくよく確認すると、コンピューティング環境の設定値において、[必要な vCPU]が0になっており、コマンド実行に必要なマシンができていないという状態になっていた(インスタンスは立ち上がっていたが)

そのため、コンピューティング環境の編集で[必要な vCPU]を2に修正し、少し待つと(即時反映はされない)Runnable状態だったジョブがSUCCEEDEDに移行した

設定した数値が反映されない不安はあるがこれ以降は同様の事象は起きないため解決とする

一安心

参考ページ

AWS公式ドキュメント
AWS BatchのジョブがRUNNABLEのまま進まない
AWS Batchを利用してコンテナを定期実行する~前編~

91
68
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
91
68