CI環境としてのAWS CodeBuild / AWS CodeBuild as a CI software

Slide 1

Slide 1 text

CI環境としての  AWS CodeBuild  〜構築して得たこと・速度改善を色々やってみた話〜  岡部恭平 / Mynavi Corporation  2019.9.25 シス担ミートアップ#3 

Slide 2

Slide 2 text

IT戦略事業部 IT開発統括部  ITマネジメント2部開発1課(マイナビニュース)  岡部恭平 @okabeeeat  Webアプリケーションエンジニア 

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

マイナビニュース  ・ビジネスパーソンのON/OFF、男女を問わず、幅広いジャンルの情報を提供する総合ニュースメディア  ・ニュースに限らず、役立つノウハウや体験レポート、まじめなレビュー、柔らかい記事から硬派な記事まで網羅  その先を伝える総合情報サイト 

Slide 5

Slide 5 text

開発言語コミュニケーション・情報共有開発支援インフラマイナビニュースを支える技術

Slide 6

Slide 6 text

本日の内容  ● CodeBuildでCI環境を構築してみた  ● 速度改善方法の紹介  ● CI環境として使ってみて  ● まとめ    

Slide 7

Slide 7 text

本日の内容  ● CodeBuildでCI環境を構築してみた  ● 速度改善方法の紹介  ● CI環境として使ってみて  ● まとめ    

Slide 8

Slide 8 text

背景  ● マイナビではCIサービスとしてCircleCIを利用している  ○ BitBucket Pipelinesを使っているチームもある  ● CircleCIはマイナビニュースだけではなく、他のチームも利用している 

Slide 9

Slide 9 text

● 継続的インテグレーション(Continuous Integration)を提供するサービスの総称  ● 定期的(git push時やブランチのマージなど)にビルドやテストを自動で実行してくれる  ● TravisCI, Jenkins, Drone CIなど様々なCIサービスがある  お!テストやっておきますね  CIサービスとは  CI導入前  手動で50パターンのテストしてエビデンスを残すの辛い!  あ!10パターン目のテストの手順間違ってた!  やり直しだ〜やだ〜   CI導入後  git push  (ソースコードを保存) 

Slide 10

Slide 10 text

CIでのテスト実行の様子  ● マイナビニュースの場合、約1400パターンのテストが定期的に実行される  ● 人間が手動で都度都度テストをしなくて済む  ● テストがOKにならないと本番リリースできない     うおお〜1400パターンのテストを漏れなく実行〜   記事タイトルは必須であること  メールアドレスは二重登録できないこと 

Slide 11

Slide 11 text

Slide 12

Slide 12 text

つまり...  ● 他チームもCircleCIを利用しているため、テストが実行待ち(渋滞)になり、他チームの開発業務の進捗が遅延する問題が発生した 

Slide 13

Slide 13 text

目的  他チームの開発業務に支障が無いようなCI環境を作る 

Slide 14

Slide 14 text

対策案を考えてみた  ● CircleCIの契約コンテナ数を増やす  ● IaaS上にOSSのCI環境を構築  ● マイナビニュース側が他のCIサービスへ移行  

Slide 15

Slide 15 text

CircleCIの契約コンテナ数を増やす  ● 一番簡単で作業工数が少ない方法  ● 1コンテナあたり、目安50$(約5,509円)/月かかる(当時)  ● どれくらいコンテナ数を増やすか・月額料金をどのように事業部毎に分割して支払うかなどの調整コストが掛かると予見したため断念 

Slide 16

Slide 16 text

IaaS上にOSSのCI環境を構築  ● OSS(オープンソース)のためIaaSの月額料金のみで済む   ● Drone CIならGitHub Enterprise(以下、GHE)にも対応   ● CIを構築するための学習コストとの兼ね合いとなるべく早めに解決するよう要望が来ていたため断念 

Slide 17

Slide 17 text

マイナビニュースが他のCIサービスへ移行  ● 他のCIサービスを比較した結果AWS CodeBuildを選定  AWS CodeBuildとは  ● AWSの完全フルマネージドのビルドサービス  ● ビルド環境の構築が主な利用例だが、テスト実行も可能  ● 並列でのテスト実行が可能  ● 従量課金制  

Slide 18

Slide 18 text

CodeBuild良さそう!!  ● 他チームを気にせずテストを実行できそう  ● 最大で見積もった月額の概算費用が約9,252円  ○ 予算内に収まるレベル  ● GHEにも対応  ● 普段からAWSを利用しているため請求先がまとまる  ● テストを実行するビルド数(CircleCIのコンテナに相当)が最低でも20  ○ 開発メンバーが数人増えてもテストの実行待ちがほぼ発生しないと判断  

Slide 19

Slide 19 text

CircleCIとの主な違い  ● AWS CodeBuildではbuildspec.ymlにテストで実行したいコマンドを書いていく  ○ buildspec.ymlはCircleCIで言うconfig.yml  ○ 「buildspec」というファイル名は変更可能  ● Dockerイメージの選択はAWS CodeBuild側で設定  ● IAMの設定も必要  ● CIの実行ログはS3またはCloud Watch Logsで保存  ○ マイナビニュースではCloud Watch Logsを選定  ○ ログローテートは2週間で設定 

Slide 20

Slide 20 text

というわけでやってみる 

Slide 21

Slide 21 text

あれ...? 

Slide 22

Slide 22 text

Dockerイメージが1個しか選べない!? 

Slide 23

Slide 23 text

CodeBuildはDockerイメージを一つしか選択できない  ● CircleCI利用時はconfig.ymlでAmazon ECRにある複数の Dockerイメージを設定し、テストを実行していた  ○ 逆に、単一のDockerイメージで済むRailsプロジェクトなら直ぐにビルドプロジェクトが作成できる  ● 複数のDockerイメージを選択できるビルドプロジェクトは作れないだろうか? 

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

コンテナの中に複数のコンテナを配置すれば良いのでは?  ・・・

Slide 26

Slide 26 text

dindでコンテナ内にさらに複数コンテナを配置  ● dind(Docker in Docker)とは?  ○ Dockerコンテナの中でさらにDockerコンテナを配置する手法  ● dind対応のDockerイメージはDocker HubのDocker Official Imagesで配布  ○ https://hub.docker.com/_/docker?tab=tags  ● ビルドプロジェクトのDockerイメージはdind対応のDockerイメージを指定する  ● 特権付与にチェックを入れる必要がある     

Slide 27

Slide 27 text

dind対応のDockerイメージを指定(一例)  特権付与にチェックを入れる 

Slide 28

Slide 28 text

これを踏まえて大まかな作業手順  ● CodeBuildで使うdocker-compose.ymlを用意  ○ ローカル開発環境で利用しているdocker-compose.ymlをベースに作成  ■ 例  ● Dockerイメージの取得先をECRを指定  ● working_dirをRailsプロジェクト直下に指定  ● buildspec.ymlをRailsプロジェクト直下に作成  ● AWS Console上でビルドプロジェクトを作成 

Slide 29

Slide 29 text

buildspec.yml(一例) 

Slide 30

Slide 30 text

CodeBuild移行前 

Slide 31

Slide 31 text

CodeBuild移行後 

Slide 32

Slide 32 text

導入した結果  ● 他チームの開発業務の進捗の遅延が解消し、目的は達成した   ● マイナビニュース側の開発効率が上がった  ○ 他チームのCIの利用状況を気にしなくて良くなった  ○ テストの待機が無くなった  ● GHEに対応  ● 月額料金が想定よりも安く済んだ  ○ 約1,534円/月(想定よりも約7,718円⬇)  ● テスト実行時間が5分増えた(25分に...)  

Slide 33

Slide 33 text

Slide 34

Slide 34 text

本日の内容  ● CodeBuildでCI環境を構築してみた  ● 速度改善方法の紹介  ● CI環境として使ってみて  ● まとめ    

Slide 35

Slide 35 text

現状の確認  buildspec.ymlで各フェーズの実行時間は以下の通り  ● install(docker-composeやaws-cliのインストール)  ○ 約2分  ● pre_build(各コンテナのイメージをpull)  ○ 約1分  ● build(テストの実行)  ○ 約22分 

Slide 36

Slide 36 text

試してみた速度改善  ● ローカルキャッシュ機能を使う  ○ DockerLayerCacheをオン  ○ SourceCacheをオン  ○ CustomCacheをオン  ● コンピューティングタイプを上げる 

Slide 37

Slide 37 text

DockerLayerCacheをオン  ● Dockerイメージのレイヤーをキャッシュする  ● buildの実行時間が約9分間短縮した⬇  ● キャッシュが原因でテストが落ちるようになった場合は「docker-compose down -v」などのコマンドをテストの実行コマンドの前に追加しておく  ○ 例: minioなどのバケットを作成するコマンドがbuildspec.yml にあるなど 

Slide 38

Slide 38 text

SourceCacheをオン  ● コミット間の変更のみのソースコードがpullされる  ● 設定はしてみたが、あまり速度改善は見込めなかった  ※あくまでマイナビニュースの場合 

Slide 39

Slide 39 text

CustomCacheをオン  ● buildspec.ymlで指定したディレクトリをキャッシュする  ● 今回は以下のライブラリをキャッシュした  ○ vender/bundle  ○ node_modules  ● buildの実行時間が約2分間短縮した⬇ 

Slide 40

Slide 40 text

コンピューティングタイプを上げる  ● ビルドプロジェクトで使用可能なメモリ、vCPU、およびディスクスペースを上げる  ● buildの実行時間が2分間短縮した⬇ 

Slide 41

Slide 41 text

速度改善の結果  約25分→約13分代と約半分になった  ● install(docker-composeやaws-cliのインストール)  ○ 2分  ● pre_build(各コンテナのpull、前回キャッシュしたライブラリを利用)  ○ 1分  ● build(テストの実行)  ○ 10分  ● post_build(利用したライブラリをキャッシュのディレクトリに戻す)  ○ 数秒 

Slide 42

Slide 42 text

その他速度改善ができそうなところ  ● コンピューティングタイプをさらに上げる  ● Rails(アプリケーション)周り  ○ アプリケーションプリローダー(Spring)でのテストの実行  ○ slow testをひたすら改善...etc 

Slide 43

Slide 43 text

しかし...  ● ローカルキャッシュはビルドホスト内に保持するキャッシュのため、以下の場合は効かない場合がある  ○ ビルドの(テストを実行する)間隔が空いた場合  ○ ビルド用のDockerコンテナが別のホストで実行される場合 (ビルドの並列度が高いなど)   ● 恒久的にキャッシュしたい場合は従来通りのS3キャッシュモードを検討する必要がある 

Slide 44

Slide 44 text

本日の内容  ● CodeBuildでCI環境を構築してみた  ● 速度改善方法の紹介  ● CI環境として使ってみて  ● まとめ    

Slide 45

Slide 45 text

CI環境として使ってみて  当初の目的は達成したが、導入するかどうかは現状の開発環境によってよく検討した方が良い  ● 単一のDockerイメージで済む場合  ○ ビルドプロジェクトで対象のDockerイメージを選択し、 buildspec.ymlを作成すれば、すぐに構築できそうではある  ● 複数のDockerイメージが必要な場合(大抵はこっち)  ○ 今回はローカル開発環境としてdocker-composeを使っていたなど材料が既にあったため、そこまで苦労なくビルドプロジェクトが作れたという点がある  ○ 無い場合は「CodeBuild用にdocker-composeを1から作る必要がある or 別のCIサービスを利用する」になりそう  

Slide 46

Slide 46 text

今後  ● 引き続き速度改善は少しずつ進めていく  ● これからプロジェクトが増える場合はDrone CIなどのOSSのCI環境の構築や他のCIサービスの導入も検討する  ○ CodeBuildで各プロジェクト専用のCI環境を確かに作ることができる  ○ 逆に、各プロジェクト用にdocker-composeを作る必要があり、プロジェクト共通のCI環境(テストを並列実行できる)を構築する方がコストが掛からずに済む場合がありそう  ○ CircleCIにPERFORMANCEプランがいつの間にかできていたため再度検討してみても良い 

Slide 47

Slide 47 text

本日の内容  ● CodeBuildでCI環境を構築してみた  ● 速度改善方法の紹介  ● CI環境として使ってみて  ● まとめ 

Slide 48

Slide 48 text

まとめ  ● CodeBuildでCI環境を構築した  ○ 他チームの開発業務の進捗の遅延が解消し、テストの待機状態も解消した  ● ローカルキャッシュ機能を使い、約半分のテスト実行時間になった  ○ ローカルキャッシュ機能は効かない場合がある  ○ アプリケーション周りでの速度改善もまだまだできる  ● CodeBuildによるCI環境の構築は、現状の開発環境の状態と課題を整理してから検討する 

Slide 49

Slide 49 text

参考 ● CodeBuildでCI環境を構築時に見たもの  ○ “AWS CodeBuild とは”. AWS CodeBuild. https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/welcome.html   ○ “CodeBuild の Docker サンプル”. AWS CodeBuild. https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/sample-docker.html   ○ “Using Docker-in-Docker for your CI or testing environment? Think twice.”. ~jpetazzo. https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/   ○ “CircleCI 2.0の処理をAWS CodeBuildで実行する”. MMMブログ. https://blog.mmmcorp.co.jp/blog/2018/04/14/circleci2codebuild/   ○ “CodeBuild における DockerInDocker(dind) の活用”. ビジネス on IT. https://www.business-on-it.com/2004-aws-codebuild-dind/  

Slide 50

Slide 50 text

参考 ● 速度改善を実施した時に見たもの  ○ “CodeBuild でキャッシングをビルドする”. AWS CodeBuild. https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-caching.html   ○ “docker buildを高速化！CodeBuildのローカルキャッシュ機能を試してみる”. DevelopersIO. https://dev.classmethod.jp/cloud/aws/codebuild-local-cache/   ○ “AWS CodeBuildのローカルキャッシュのCustom cacheでnode_modulesやvendorをキャッシュする”. moyashidaisuke's diary. https://www.moyashidaisuke.com/entry/2019/03/19/205243  

Slide 51

Slide 51 text

ご清聴ありがとうございました