利用者の生産性をどう上げるか 中規模モノレポの苦しみ

Think! FrontEnd第6回の発表で使用したスライドです。

Transcript

1. 利用者の生産性 をどう上げるか 中規模モノレポの苦しみ
2. 自己紹介 • 名前: 岡本 済 • 所属: 合同会社DMM.com プラットフォーム事業本部 Developer Productivity Group • 仕事: モノレポのメンテナンス
3. 生産性とスケール可能性
4. 「社長、人増やしたけど速度が遅くなってます」 - 組織が大きくなるにつれ、徐々に進みが緩やかになっていく感覚を感じたことはな いか？ 話すこと - 組織のスケーラビリティにはソフトウェアのアーキテクチャが重要 - モノレポのスケーラビリティに何が必要か
5. 人員が増えると、かえって遅くなる - コミュニケーションパスの急激な増加 - 5 人だった時は10通り - 10人だと45通り - 20人だと190通り!! - 種類 - オンボーディングコスト - 承認・コミュニケーションのオーバーヘッド - チーム化による分割統治は本質的解決にならない
6. 横断的関心とエコシステム チーム間のコミュニケーションには一定のパターンがある - デプロイ - QA - 複数チームで開発 組織のスケーラビリティにはエコシステムが重要である - 「組織規模が倍になっても通用するか？」
7. Main
8. DMM プラットフォーム事業本部とは 主な扱う領域 - 認証認可 ・ 決済・不正対策・会員・ポイント・カスタマーサポート 組織規模: 100人強 フロントエンドプロダクト: 40個以上
9. DMM プラットフォームのエコシステム フロントエンドチームでは、プラットフォームのFEを集約したエコシステムを作っている フロントエンドチームにやっていること - モノレポ基盤 - デザインシステム - 静的アセット配信基盤 - 実装・アーキテクチャレビュー
10. 今回扱う事例 - 事業部のフロントエンドAppを集約したモノレポ - Nx - 差分検知, 変更対象の自動テスト - GHAによる、すぐに使える CI - デザインシステムや破壊的変更を検知 - PRごとにStorybookなどが自動的にデプロイされ、 cloneせずとも動作検証できる仕組み - 自信を持ってマージできる仕組み - フロントエンド専任が少ないが、プロダクトは多いという組織特性にマッチ
11. 課題の変遷 新たに開発されるアプリケーションはReactで行うことが当たり前になった一方で、変化 するニーズに機敏に対応しきれないところが見えてきた 昔: メンテが難しくなったプロダクトのリプレース & React化 現在: Reactでより効率よく開発を行いたい
12. 抱えていた問題 1. CIの低速化と遅いフィードバック 2. CIの低い拡張性と多様化するニーズ 3. モノレポ管理ツール周辺の対応コスト
13. 抱えていた問題 - CIの低速化と遅いフィードバック - CIの低い拡張性と多様化するニーズ - モノレポ管理ツール周辺の対応コスト　 - →律速、強制的なマルチタスク化 - →やりたいことができない - →新しい施策が行えない
14. 具体例1: テストが遅い 特定のチームでCIがかなり遅くなり、数ヶ月後にOOMで失敗するように 実施からテスト失敗まで20分 →　辛い https://github.com/nodejs/node/pull/50682
15. 具体例1: テストが遅い Jest のヒープサイズを調査したところ、他のアプリケーションでも増加していた → アプリケーション起因ではなさそう、Jest側の問題を調査 根本原因は、Jestが使用しているvm.ScriptがGCできていない > vm: fix V8 compilation cache support for vm.Script Node.js 20.10.0 で修正
16. 具体例2: yarn installが遅い 開発マシンでもクリーンインストールで5分かかっていた Nxの特性上、node_modulesのサイズが肥大化しやすい GitHub Actionsのキャッシュ制限からキャッシュミスが多発していた 解決策: PNPMに移行し、Yarnのグローバルキャッシュ分の高速化 Docker buildも高速化し、デプロイが40分から20分に🎉
17. 具体例3 最も大変なのはモノレポ管理ツール Nxのアップデート - 13 → 15のアップデート: 所要時間 2ヶ月 Nxは nx migrate latest で自動化できると言っている - 全然そんなことはない！！ - https://github.com/nrwl/nx/issues/13192 - 現象: Next.jsのカスタムサーバーが本番環境でもwatchモードになっていて、No space left on device でコンテナが立ち上がらない
18. Nxのつらみ - ExecutorがAdapterではなく、「いい感じのオプション」を追加してくる - ドキュメントに乏しい - 定期的にバグる - 問題の切り分けが面倒 NxでTypeScript, Nextなどを実行するためには、Nxが提供しているプラグインを使用す る
19. Nxのつらみ 例えば、 - nodeでスクリプトを実行するには @nx/js:node が必要
20. Nxのつらみ Executorは次の形で利用する
21. Nxのつらみ 簡単に利用できるように見えるが、大きな落とし穴がある この例だと、デフォルトで以下のオプションがオンになっている - デバッガー有効化、 - ファイルウォッチによる自動更新 →　本番環境でデバッガーを常に有効 簡単さはあるが、あまり安心して使えない
22. Nxのつらみを解決する NxのメリットはExecutorが簡単に使用できるというメリットだったが、 現状を考えると、Executor自体メリットが低い →Nxをやめることを決め、最適な方法を検討している
23. Monorepo in General
24. スケールするモノレポ - 疎結合性 - Sparse Checkoutとの相性の悪さ - モノレポ化はGoでいうサブパッケージレベルのモノだったり - 現時点のモノレポは分割実行のための作為的な分割 - 自動化 - One Version Policy
25. 組織の課題に見合ったソリューション 組織規模に見合った解決方法を考案しなければならない - Google, Facebook, … - DMMの組織規模やメンバー構成・スキルセット 初期のDMMのモノレポ化は、レガシーなphpからの移行プロセス モノレポツールはBig Techから生まれた文化であり、そのプラクティスを実践することが 正しいとは限らない