GCPからAWSへ移行しKuroko2はAWS Batchにした

2017/07/15にGCPからAWSへ移行した理由を記載しました

数週間かけて少しづつやってきた自宅サービスのGCPからのAWS移行がすべて完了した

まずGCPからAWSへ移行した理由としてはいくつかあるのですが、一番は会社で使用するインフラ環境がGCPからAWSに移ったので
個人も変えようという理由です

今まではアプリケーションはRailsで作成されており定期的なバッチ処理はKuroko2でスケージューリングして処理していた

これを下記のようなインフラ構成に変更した

f:id:hatappi1225:20170706235035p:plain

Railsに関してはDocker上で動かせるようにして動作環境でAWS Elastic Beanstalkを使用している
リクエストにはAWS Certificate Managerで証明書を無料で発行してhttpsでリクエストを出来るようにしている
またコストを抑えるためにEBやRDSは自動停止・自動起動が出来るようにしています
自動起動・自動停止については以前書いた記事を参考にしてみてください

hatappi.hateblo.jp

バッチ処理に関しては今までKuroko2を利用していましたが、Dockerで動かす際にRailsアプリケーションの中にKuroko2のworkerをいれないといけないなど、少々面倒になりそうだったので他の方法を考えていた時に下記のリリースが最近あったのを思い出しました

AWS Batch が東京で利用可能に

AWS BatchはEC2やスポットインスタンスを使用してECS上で指定されたDocker Imageを元に処理をしてくれます
開発者はDocker Imageと環境変数やコマンド、コンピューティングリソースなどの要件さえ指定すればAWS Batch側で環境を用意して実行してくれます
AWS Batchはキューイングなどもしてくれリトライもしてくれますが、現状(※ 2017/07/08)はスケジューリング機能などはついていないのでLambdaからCloudWatch Eventsで発火させて起動するようにしました

Kuroko2からAWS Batchに変えてよかった点

今まではKuroko2で動作させるためにはwokerとRailsのアプリケーションがあるインスタンスはたてておく必要がありました
そのため今回の場合のような自動停止・自動起動を使用した時は起動している時にバッチが起動するようにスケジューリングする必要があります

これがAWS Batchを使うことでDocker Imageさえあればいつでも好きな時間に起動させることが出来ます
またスポットインスタンスの管理もAWS Batch側で行ってくれるので、こちらはDocker上で何のコマンドをいつ実行するかなど考えることが減りました