どうも，エンジニアのナカノです．
今回は，社内システムのバッチ運用の自動化の内容をご紹介致します．
社内では，クローリングデータを加工するために，ETLシステムが存在します．
このシステムのEC2インスタンスのAMI運用を，今回は自動化しました．
- 背景
- 作り方
- 所感
背景
今までのETLシステムはLAMPの様なステートフルなもので，サーバ自体の運用が必須でした．
また，同様なシステムが運用の都合で複数出てきたため，コスト面で問題になってきました．
そのため，コストダウンのために，API，バッチ，DBを全て切り分ける様に構成を見直しました．
以下の画像は，ETLシステムのサービスとCI／CDのインフラ構成図のサンプルです．
大半をステートレスな構成に変更することが出来たのですが，バッチサーバはそれが困難でした．
そのため，バッチサーバのAMIは既存のものをベースとして，構成管理の自動化を進めました．
作り方
色々と調べた結果，主に次の様な構成にしました．
GitHubと連携して，CircleCIをパイプラインとして使う
CodeBuildでPackerとAnsibleを実行し，AMIを作成する
CircleCIを選んだのは，パイプラインの設定が他のCI／CDサービスよりも細やかだからです．
他には，社内のCI／CDツールでこのサービスが使われているからというのもあります．
また，CodeBuildを利用したのは，CircleCIの無料プランの制限問題を回避するためです．
ビルドに時間がかかるため，CircleCIはあくまでGitHubとCodeBuildの間の仲介者と使っています．
CircleCIからCodeBuildの連携は，CodeBuildに関するAWS CLIを使って行っています．
また，CodeBuildでのコンテナ上では，Packerのコマンドを実行する様にしています．
ところで，バッチサーバには管理や利用の有無が不明やプログラムが多く存在します．
これらは，AMIの新規作成や更新の際にS3から必要な分のみをプルする様にしました．
この辺りは弊社の技術負債の1つであり，どこかで何とかしたいところですね...．
所感
開発と運用のそれぞれが楽になる案を探し，一旦の落としどころを見つけたという感じですね．
ステートレスな構成に出来ていないのが無念ですが，フローを何とか固められて良かったです．
あとは，Codeシリーズはとても便利ですが，慣れていないとハマり易い印象がありますね．
CodeBuildは，忘れた頃にはIAM関連の設定やネットワーク制約等でハマっってしまいますね...．
引き続き，チームで自動化を進めていき，社内外の困りごとを技術で解決していきます．
