Amazon ECRを利用してCIを高速化する

ツール導入前の課題

もともとECRは、CDパイプラインでビルドしたDockerイメージを保存し、本番環境ECSコンテナの起動に利用する目的で導入されていました。 一方で、GitHub Actionsを利用したCIにおいては、実行ごとにDockerイメージを0からビルドすることによるオーバーヘッドが発生していました。

どのような状態を目指していたか

CIにおいても、デプロイ同様にあらかじめビルドしておいたDockerイメージをECRに保存して利用するようにすることで、生産性の向上を図りました。

• GitHub ActionsのCaches

前述の通り、CDパイプラインでECRを利用していたため、一貫性を重視してCIでも同等の仕組みを取り入れることにしました。

フロントエンド・バックエンドリポジトリともに同様の改善を行い、それぞれ1回あたりのCI所要時間の短縮について、以下の成果を達成しました。

当初は関連するIAMロールなども含め本番環境のリソースとして作成していましたが、ユースケースがCIであることを考慮し、後に開発環境のリソースとして作り直しました。 本番環境には直接的に関係のないリソースとなるため、AWS環境が分かれているのであれば最初から開発環境用のリソースとして作成することをお勧めします。

対応時、workflow_runを利用し、初めにDockerイメージの build & push ワークフローを実行し、それが完了してから後続のワークフローを行うように、実行順序を保証しようとしたのですがうまく機能しませんでした。 そこで、Dockerイメージの更新を伴う変更はそれ単体で行うというルールを決め、非同期でのワークフロー実行を許容しました。 現在の開発規模においては特に運用上の問題は発生していませんが、今後プロダクトやチーム規模の拡大に伴い、適宜見直していければと思います。