ジモティーでインフラとバックエンドを担当している鈴木です。最近は貝出汁ラーメンをよく食べてます。美味しい。
ジモティーにCodeBuildを導入しましたので、背景や工夫した点などを紹介します。
CodeBuildとは
AWS CodeBuildは、AWSが提供するフルマネージド型のビルドサービスです。このサービスを利用することで、ソースコードのビルド、テストの実行など、ビルドプロセスを自動化することができます。 サーバーレスなサービスであり、ビルド実行の度に新たな環境が自動的に作成されるため、ユーザーは事前にビルドサーバーを準備しておく必要がありません。
背景
ジモティーでは、Rails、Next.jsといったアプリケーションサーバーがECS Fargate上で稼働しており、FargateにデプロイするDockerイメージは、元々はJenkinsを使用してビルドしていました。
しかし、Jenkins上で同時に複数のビルドを行うと、メモリ不足に陥るケースがありました。
さらに、新たな問題として、RailsやNext.jsのコンテナをARMアーキテクチャに置き換えることを計画していました。これにはARM向けのイメージをビルドする必要がありますが、イメージのビルドは一般的にホスト環境のCPUアーキテクチャに依存します（※）。弊社のJenkinsサーバーはx86アーキテクチャのインスタンスで構築されているため、ARM向けのイメージをビルドすることができませんでした。
こういった一連の課題を解決するため、ジモティーではCodeBuildの導入を決定しました。これにより、ホスト環境に依存せずに、各アーキテクチャのイメージをビルドできるようになります。また、CodeBuildはビルドごとに独立した環境で実行されるため、ビルドの同時実行によるメモリ不足といったリソースの問題も解決できます。
※ Docker Buildxプラグインを使うことでマルチアーキテクチャでのビルドが可能ですが、今回はリソース問題も解決できるCodeBuildの導入を選択しました。
工夫した点
Jenkins環境でDockerイメージをビルドしていた際には、Dockerビルドの結果がキャッシュとしてローカルに保存され、次に同じイメージをビルドする際にビルド時間を短縮することができていました。
一方、AWS CodeBuildはビルドごとに新しい環境を作成し、ビルドが完了するとその環境は破棄されます。そのため、ビルド間でイメージキャッシュを共有することができません。
キャッシュによるビルド時間の短縮はデプロイプロセスの効率において重要だったため、ECRに保存している前回のイメージを --cache-from オプションで指定することでキャッシュを有効にしました。
# 前回のイメージをECRからpull
- docker pull XXXXXXXXXXXX.dkr.ecr.ap-northeast-1.amazonaws.com/${REPOSITORY_NAME}:latest
# 前回のイメージを --cache-from オプションで指定
- docker build -t ${REPOSITORY_NAME} . --cache-from XXXXXXXXXXXX.dkr.ecr.ap-northeast-1.amazonaws.com/${REPOSITORY_NAME}:latest
この方法では、前回のイメージをECRからpullするため、通信のオーバーヘッドは発生しますが、このユースケースではビルド時間の短縮幅に比べるとはるかに小さいものだっため許容しました。
まとめ
- ジモティーのアプリケーションサーバーはFargateで構築されており、デプロイするDockerイメージをJenkins上でビルドしていた
- 以下の課題をCodeBuild導入により解決した
- ビルドの同時実行によるリソースの枯渇
- ビルドがホスト環境のCPUアーキテクチャに依存するためARM用のイメージビルドが難しい
- CodeBuildではローカルのイメージキャッシュを使えないというデメリットがあるがECRからpullしたイメージをキャッシュ指定することで解決できた（pullの通信によるオーバーヘッドは発生する）
この記事では、ジモティーにおけるCodeBuild導入の背景やそのメリット、そして工夫した点について解説しました。CodeBuildを活用することで、様々なアーキテクチャに対応したビルド環境を効率的に構築することができます。今後もテックブログでジモティーの開発事例や取り組みをご紹介していきますので、どうぞお楽しみに！
弊社では一緒にプロダクトを改善していただける仲間を探しています！
こちらでお気軽にお声がけください！
