AWS Batchを自前でVPCを構築して動かす

AWS Batchはフルマネージドのバッチ処理環境を用意してくれるサービスです。

このスライドが概要をかなり分かりやすく説明してくれています。
ジョブを定義、キューイングしてスケーラブルに実行してくれるサービスのようですね。

バッチ処理でよく必要になるジョブスケジューリングまでは含んでないようなので、そこは他で工夫する必要がありそうです。

VPCを構築する

AWS Batchには実行環境となるためのVPCが必要なので、事前にVPCを構築します（デフォルトVPCを使ってもよい）。

まずは、VPCを作成します。
VPCのDNSホスト名を有効にしておきましょう。

次はサブネットを作ります。
IPv4の自動割り当てを有効にしておきましょう。

インターネットゲートウェイを作ってVPCにアタッチします。
サブネットのルートテーブルにインターネットゲートウェイをデフォルトゲートウェイとして設定します。
最後にセキュリティグループを作成します。
インバウンドのルールは、タイプをすべてでソースをセキュリティグループ自身に設定します。
これで、インターネットに出れるVPC環境ができました。
いよいよAWS Batchを設定します。

AWS Batchを設定する

ウィザードの流れに沿って進めていきます。
ここではジョブとジョブキュー、コンピューティング環境を一度に作成します。
VPCだけ、先ほど作ったものを設定し。
作成すれば、コンピューティング環境とジョブキューが定義され、ジョブが実行されます。

実行されたジョブを確認する

ダッシュボードを確認すると、先ほど作成したジョブがキューに投入されているのが分かります。
ジョブの状況に応じてステータスが遷移していきます。
RUNNABLEのまま止まってしまう場合は事前に作成したVPCの設定に問題があるかもしれません。

裏で、先ほど作ったVPCにEC2インスタンスが立ち上がります。
初回はこの立ち上がりがあるのでジョブの実行に少し時間がかかりますが、二回目以降は立ち上がっているのではすぐに実行されます。
裏を返せば立ち上がりっぱなしなので、必要がなければインスタンスは削除しましょう。

コンピューティング環境のリンクからそのEC2インスタンスで実行されているECSクラスタも確認できます。

AWS Batchは標準出力がCloudWatch Logに出力されます。
実行したジョブの出力結果が見れます。
以上、簡単にですがジョブが実行できました。

最初はフルマネージドのバッチサーバーみたいなものを想像していたのですが、まったく毛色が違うものでした。
バッチ処理をコンテナ化していることが前提条件なので、既存のバッチサーバーをそのまま置き換えるとかは難度が高そう。

では。
Docker/Kubernetes 実践コンテナ開発入門

使ってみたAWS, AWS Batch, CloudWatch Logs, EC2, ECS, VPC, コンテナ

Posted by danishi