CircleCI のデータ活用 - Insights と Insights API - Qiita
こんにちは。CircleCI カスタマーサクセスチームの Chisato です。最近個人的に幸せを感じた出来事は、育てているレモンの花が咲いたことです。今年2回目の開花で、とても良い香りがします。今回は、インサイト(以下 Insights)についてご紹介します...
https://qiita.com/chisato-ygc/items/fc727faf72195029801c
この記事は、CircleCI Advent Calendar 2023 の 25 日目の記事です。
こんにちは、ウォンテッドリー株式会社の @fohte です。普段は Infra Squad でインフラのコストを管理していたりします。
今回は、CircleCI の費用増が起きた話と、それの対策を行った話をします。
Infra Squad では、利用しているインフラや SaaS の利用料金を月次でチェックしています。
そこで CircleCI の費用を普段どおりチェックしていると、ある月で前月の 1.5 倍ほどまで増加していました。
下図は、そのある月で増加している様子です。縦軸は費用を、横軸は年月を示しています。
このまま増加し続けた場合、事前に確保している年次予算を超えてしまいます。少なくともこれは防ぎたく、まず増加している要因を調査しました。
CircleCI には Insights という利用状況を可視化する機能が備わっており、ここからざっくりとクレジット利用数の内訳などが確認できます。
参考:
ただ、今回は Insight では具体的なコスト増の要因が特定できなかったため、「誰が」CircleCI のジョブを多く走らせているのかを調査しました。
具体的な調査方法としては、CircleCI API v2 で pipeline の実行履歴を取得しました。(https://circleci.com/docs/api/v2/index.html#operation/listPipelines)
実行例 (過去の pipeline 実行履歴を一気に取得するコマンド):
for i in `seq 500`; do echo $i; curl -sH "Circle-Token: $CIRCLECI_API_TOKEN" "<https://circleci.com/api/v2/pipeline?org-slug=$ORG_SLUG&page-token=$>(jq -r .next_page_token pipeline-$((i - 1)).json)" > pipeline-$i.json; sleep 1; done
その上で、実行ユーザーをチーム (Squad) ごとにグルーピングして集計したグラフが下記です。
これを見ると、pipeline 実行が多い月は Bot による実行が多いことが判明しました。
Bot の内訳を見てみると、Renovate が 9 割以上を占めていました。
つまり、Renovate が大量に PR を生成したり、base branch の更新を取り込むために各 PR で rebase が実行されることが、CircleCI の費用増の要因であると推測しました。
とはいえ、Renovate はパッケージのバージョンアップ等のために価値が高い Bot であり、Renovate の利用自体はやめられません。
さらに詳細に調査していくと、以下のようなことが起きて Renovate が大量にリポジトリへ push していることがわかりました。
特に利用が急激に増加した月は、人の手による merge も大量に行われていることも要因のひとつでした。
そこで、以下の対策を実施しました。
これらは開発生産性を落とす対策ではありますが、手動で rebase や merge を実施しても開発生産性を大きくは損なわないと考え、費用とのバランスでこの対策をとりました。
結果として、この対策を取り入れた以降は Bot での CircleCI 利用が減り、効果があることがわかりました。
さて、ここまでで Bot での CircleCI 利用が減りました。
しかし、Bot を抑制できても、以下のようにそれまでの月よりも費用は増加していました。(最も右側の棒グラフは月途中で算出されたもののため、低く表示されています)
再掲ですが、チームごとの pipeline 実行数は下図のとおりで、DX Squad による実行が増加傾向にありました。
これに関しては、結論から書くと費用増を受け入れるという選択を取りました。
現在のウォンテッドリーでは、組織の拡大に伴いプロダクト開発も盛んとなっています。
特に DX Squad では CircleCI を利用しているリポジトリでの活動が盛んになっていました。ウォンテッドリーの開発組織では、細かく commit や push を積み重ねる文化もあり、それも CI の利用増の要因のひとつでした。
commit や push を粒度を細かくすることで、CI によるフィードバックもその分頻繁に受けられ、効率よく開発が進められます。そこで「CI の費用を減らすために commit や push の粒度を大きくしてほしい」という手もありますが、これは開発生産性を損なってしまいます。
そのため、ここは開発生産性に投資するべきであると判断し、費用増を受け入れるという選択をしました。
なお、テスト高速化などの CI のチューニングをするという手も考えられます。これに関しては挑戦を試みたのですが、CircleCI を利用しているリポジトリではすでにパッとできるようなチューニングは行われていました。
費用を抑えられるほど効果のあるチューニングをするには一筋縄ではいかないことがわかったため、今後長期的に対策していきたいと考えています。
CircleCI の利用が増えていることと、その対策について書きました。
この記事で伝えたかったことをまとめると、以下の通りです。
費用についての考え方や原因調査など、読者の皆さんの一助となれば幸いです。