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

Transcript

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

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

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

5. 開発言語 コミュニケーション・情報共有 開発支援 インフラ マイナビニュースを支える技術
6. 本日の内容
 • CodeBuildでCI環境を構築してみた
 • 速度改善方法の紹介
 • CI環境として使ってみて
 • まとめ 
 

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

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

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

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

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

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

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

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

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

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

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

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

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

20. というわけでやってみる

21. あれ...?

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

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

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

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

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

29. buildspec.yml(一例)

30. CodeBuild移行前

31. CodeBuild移行後

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

49. 参考 • 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/ 

50. 参考 • 速度改善を実施した時に見たもの
 ◦ “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 

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