巨大モジュラーモノリスのテスト戦略.pdf

Transcript

1. 巨大モジュラーモノリスのテスト戦略 2025 / 10 / 23 Ubie株式会社 Shinobu Hayashi/Shinyaigeek Nihonbashi.js #10
2. 2 whoami • Shinobu Hayashi/Shinyaigeek ◦ X: https://x.com/Shinyaigeek ◦ GitHub: https://github.com/Shinyaigeek • Software Engineer@Ubie(25/08~) ◦ プロダクトの技術基盤の開発運用やら • Interest: HTTP, Frontend Toolchain, Platform Engineering
3. 3 Agenda • Ubie におけるモジュラーモノリス ◦ なぜモジュラーモノリスか ◦ プロダクト開発を支える設計 • 自動テスト実行における課題とその解消アプローチの紹介 ◦ なぜ自動テストがボトルネックになっていたか ◦ 自動テスト実行数を削ってしまうアプローチ
4. 4 ubie.app の システムアーキテクチャ
5. 5 ubie.app のフロントエンド • Full “JavaScript” & “React” Stack ◦ Web アプリケーション: Next.js ◦ モバイルアプリケーション: React Native • 複数の機能を内包しており , ストリームアラインドチーム的に独立して開発されてい る ◦ 問診サービス ◦ 医療情報サービス ◦ オンライン診療サービス ◦ etc…
6. 6 ubie.app のバックエンド • Nest.js 製バックエンドアプリケーション ◦ フロントエンドと同じく TypeScript で記述できるため機能開発をシームレスに行 える • プロダクトの諸機能に密なロジックとデータ永続化層を持っている ◦ ≠ JUST マイクロサービスの Gateway • 機能開発を行う際には , フロントエンドだけでなくバックエンドも併せて触ることにな る • モジュラーモノリスアーキテクチャの採用
7. 7 モジュラーモノリスの恩恵 • それぞれの機能開発の独立性を担保しつつ分散システムの複雑さを回避できる ◦ 機能ごとにモジュールとして独立している eg) 問診(qa), オンライン診療(telemedicine) ◦ アプリケーション境界を担う controller 層と、モジュール境界を担う service 層それぞれを提供してい る • マイクロサービスとの通信などロジックを共有できる • 機能ごとのコラボレーションも容易に • 全員が同じリポジトリで開発を行うため、共有知を形成できる ◦ coding agent 向けのドキュメント ◦ シンプルに参考にできるコードが身近に • パッケージなどのバージョン管理を一元化でき運用がシンプルに
8. 8 モジュラーモノリス運用で見 ててきた課題
9. 9 モジュラーモノリスの課題 • エラー監視時のオーナーシップの線引きの難しさ • コードベースの巨大さ ◦ lint, fmt, tsc の遅さ ◦ 自動テスト実行ケースの多さ ←ｺｺ • モジュール間依存の複雑性による負債
10. 10 モジュラーモノリスにおける自動テストの課題 • 数多くのロジックを抱えるためそれに比例してテストケースの数が膨大に ◦ テストファイル数だけで 314⋯！ • 自動テストの出力もテストケースの数に比例して膨大に ◦ coding agent のコンテキストを逼迫する原因に • 自動テスト実行時間もテストケースに比例して伸びることに ◦ CI 上においては 2並列で走らせても 9min の実行時間がかかる規模 ◦ テスト用の DB を立て永続化層込みでテストをしているためデッドロック問題により並行実行にも難点 が⋯
11. 11 自動テストの実行数を減らす戦略 • まずは手軽に行える、自動テストの実行数自体を減らしていく戦略をとっていくことに ◦ 併せて coding agent のコンテキスト問題も緩和できる ◦ 並行実行可能な状態にするのもよいが Invest が大きいと予見されたため後回し • モジュラーモノリスであるが故に取りやすい戦略でもある ◦ 複数のビジネスロジック、機能がモジュールとして独立して存在している状況にある ◦ モジュール間の依存についてある程度クリーンな状況が実装上担保される ◦ テストにおいて、他モジュールへの依存に関してはインターフェースと Mock によってその実装にまで は踏み込まない状況が担保されている ◦ → あるモジュールを変更した際に、実行されるべきテストを絞り込むことを機械的に行いやすい且 つ効果的に絞り込める土壌と言える
12. 12 自動テストの実行数を減らす戦術 • jest においては `--changedSince=${git commit-ish}`, vitest においては `vitest related` によって, 「ある地 点」から今に至るまでの差分を元に実行されるべきテストを絞り込むためのオプションがすでに存在している ◦ git レベルで diff を読んで差分ファイルを検出 ◦ その差分を元に, 変更のあったファイルに依存している実装とそのテストを算出している • For 手元での実行時向け : ◦ `npm run test:diff` という形で, 差分実行だけを行うオプションを提供 • For CI での実行時向け: ◦ PR 上では差分のみを実行 , trunk (=main branch) においては全てのテストケースを実行 , という形に ◦ リリースパイプラインにおいては安全に倒す形に
13. 13 差分ファイルと依存関係ベースでのテスト実行の注意点 • git の差分レベルを足掛かりに実行すべきテストを絞り込んでいるため、差分に検知されないものへの依 存は検知されない ◦ node_modules 配下のパッケージ ◦ gitignore されるような自動生成されるようなファイル • また設定ファイルの変化など、 ESM レベルでの依存関係は存在していないが挙動に変更を及ぼすような変 化にも注意が必要になる ◦ また tsconfig の paths alias を利用してるケースなども jest/vitest 側に設定ファイルで明示的にそれ を伝える必要がある • 本来実行されてほしいテストケースまで意図せず絞り込まれていないかは注意が必要
14. 14 差分ファイルと依存関係ベースでのテスト実行の注意点 • node_modules 配下のパッケージ、設定系のファイルについては CI 上でアドホックに検知しテストケースを 全実行する • 自動生成されたコードに依存しているケースについては、アプリケーションごとに判断を行う ◦ 大抵のアプリケーション大抵の自動生成されたコードに依存するケースとしては、 DB や RPC(grpc, graphql, REST API)、CSS など JavaScript から見た際の副作用の取り扱いを行うケースがほとんど ◦ 外部環境との副作用を取り扱う以上、自動生成されたファイルによって挙動に破壊的な影響が出る際 には、"型" レベルに影響が出るはずで型検査ででも影響を検知できるはず
15. 15 得られたもの • CI/ローカル環境 でのテスト実行時間の減少 🎉 ◦ 改善の性質上 PR の種類に依存するが ... ◦ 開発の中で変更の流量が多くなりがちな、具体機能にまつわる (=依存関係の末尾にいる )モジュール の変更に対して特に実行時間の改善が顕著に現れる ◦ 多くのモジュールで利用されるようなモジュールの変更時でも実行数はおよそ ⅔ にまで • coding agent がテストを実行した際のコンテキスト逼迫問題も改善