サービス成長と共に 肥大化するモノレポ、 長くなるCI時間 @kohbis SRE観点での技術負債 懺悔会 2024

About Me Kohei SUGIMOTO 株式会社MIXI 2022/04 ~『家族アルバム みてね』 SRE X/GitHub : @kohbis

Agenda 1. Introduction 2. 『家族アルバム みてね』のリポジトリ構成 3. サービス成長に伴うモノレポの課題 4. CI時間の増加の原因 5. 改善のためにやったこと 6. まとめ

『家族アルバム みてね』とは スマホで撮ったお子さまの写真・動画を家族で共有し コミュニケーションして楽しむ家族アルバムサービス 「世界中の家族の”こころのインフラ”を作る」 ● 2015年4月リリース ● 現在7言語・175の国と地域でサービスを提供 ● 2023年11月に利用者数が2,000万人を突破 ※1 ※1 iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計

『家族アルバム みてね』の リポジトリ構成

『家族アルバム みてね』のリポジトリ構成 今回はサーバー側のみ ● ほとんどの機能が巨大なモノリシックリ ポジトリに実装されている ● いくつかサブシステムが切り出されたリ ポジトリもある （基本的に）Ruby on Rails CI環境は ● 主にCircleCI ● 新規ではGitHub Actions API Web Task Worker 海外 配送 画像 解析 1秒 動画 DVD etc.

サービス成長に伴うモノレポの課題

サービス成長に伴うモノレポの課題 サービス成長 → 機能の追加 → リポジトリの肥大化 ● 依存関係の複雑化 ○ 変更の影響範囲調査、エラー特定の難化 ● コードベースの管理難易度の増加 ○ 新たな開発者のキャッチアップ負荷 etc. ● CI時間の増加 今回はこちらの話 ○ （後述）

CI時間の増加の影響 Four Keys ソフトウェア開発チームのパフォーマンスを示す 4 つの指標 ● デプロイの頻度 … 組織による正常な本番環境へのリリースの頻度 ● 変更のリードタイム … commit から本番環境稼働までの所要時間 ● 変更障害率 … デプロイが原因で本番環境で障害が発生する割合（%） ● サービス復元時間 … 組織が本番環境での障害から回復するのにかかる時間 ref: https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance CI実行リソースの従量課金も増加

CI時間の増加の原因

CI時間の増加の原因 ● リポジトリサイズの肥大化 → チェックアウト時間の増加 ● 使用するライブラリの増加 → インストール時間の増加 ● 機能、コードの増加 → テスト実行時間の増加 ● コンテナイメージサイズの増加 → イメージのPull/Build/Push時間の増加 『家族アルバム みてね』のモノレポにおけるCI時間（2024/03現在） ● Rspecのテスト数 … 約23,000 ● CircleCI（並列数: 32） ● CI実行時間 … 約11分

改善のためにやったこと

やったこと ● （ライブラリのキャッシュ設定は有効） ● CI用イメージ（ECR）を東京リージョンからバージニア北部リージョンに移行 > AWS ECR イメージを使用する場合は、us-east-1 リージョンを使用することをお勧めします。 CircleCI のジョブ 実行インフラストラクチャは us-east-1 リージョンにあるので、同じリージョンにイメージを配置すると、イメー ジのダウンロードにかかる時間が短縮されます。 ref: https://circleci.com/docs/ja/using-docker/#docker-image-best-practices → イメージ取得時間を1/3に短縮（ECRのコスト減にも） ● 静的コンテンツの取得元を東京リージョンからバージニア北部リージョンに移行 → DL時間を1/2に短縮（S3のコスト減にも） ● 不要なチェックアウトを削除（Commit Hash値を取得するためだけ、など） → 約1分間の短縮

やった/やろうとしたけどだめだったこと ● CircleCIのマシンサイズと並列数の調整 ○ サイズを小さくしてジョブの並列数をあげる → リソースが足りずテストが終わらなくなってしまう ○ サイズを大きくしてジョブごとのテストを並列実行（paralles testsなど） → 多少早くなるがリソース時間にかかるコストとのバランスが悪い ● CircleCIでソースコードのキャッシュ → リポジトリサイズが大きいためsave/restoreに時間がかかってしまう ● 同時実行数の制限を緩和するためDependabotによるPR起票時間を深夜帯にする → 大量のPRが同時に起票されCircleCIの同時実行数制限に達してしまう

やった/やろうとしたけどだめだったこと ● GitHub Actionsの検証 ○ 実行時間はCircleCIと同等 ○ Initialize containersステップの実行時間が安定しない ref: https://github.com/orgs/community/discussions/25975 → 変更のリードタイムが長期化してしまう ● GitHub Actions Self-hosted Runnersの検証 ○ ノード起動済みの場合、実行時間はCircleCIと同等 ○ ノードスケールを伴う場合、実行時間が安定しない ※ CircleCIにもSelf-hosted Runnerがあるが未検証 ref: https://circleci.com/docs/runner-overview/

（おまけ）やれてないこと ● Dockerイメージサイズの削減 ● ソースコードのチェックアウトをShallow Cloneで行う ○ CircleCIのIdeasでは提案されている ref: https://circleci.canny.io/cloud-feature-requests/p/allow-for-shallow-clone-command-in-20 ● CircleCIで動かす必要のないものはGitHub Actionsへ移行 ○ 開発者はGitHub Actionsの方が馴染みがある ○ GitHub Actions Self-hosted Runnersも有効活用していきたい ● テストの見直し ○ 不要なテストやイテレーションがないか ○ 修正内容によって必要なテストのみにできないか ○ Flaky Testの撲滅、影響緩和

まとめ

まとめ ● サービス成長にともなってモノレポが肥大化し、CI時間の増加などの問題が発生する ● CI時間増加の要因は、大量のテストケースやコンテナイメージのビルド時間増加など さまざま ● 改善策はたくさんあるが、自分のプロジェクトで効果があるかは要検証 ○ 並列化、キャッシュ戦略、リソース最適化など ● CIのパイプライン環境の改善ではどこかで限界がくる ○ （おそらく）行き着くところはテストの見直し 　　「パフォーマンス最大化できなくてごめんなさい」 　　「すぐに価値を提供できなくてごめんなさい」

No content