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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介 ● 名前: 岡本済 ● 所属: 合同会社DMM.com プラットフォーム事業本部 Developer Productivity Group ● 仕事: モノレポのメンテナンス

Slide 3

Slide 3 text

生産性とスケール可能性

Slide 4

Slide 4 text

「社長、人増やしたけど速度が遅くなってます」 - 組織が大きくなるにつれ、徐々に進みが緩やかになっていく感覚を感じたことはないか？話すこと - 組織のスケーラビリティにはソフトウェアのアーキテクチャが重要 - モノレポのスケーラビリティに何が必要か

Slide 5

Slide 5 text

人員が増えると、かえって遅くなる - コミュニケーションパスの急激な増加 - 5 人だった時は10通り - 10人だと45通り - 20人だと190通り!! - 種類 - オンボーディングコスト - 承認・コミュニケーションのオーバーヘッド - チーム化による分割統治は本質的解決にならない

Slide 6

Slide 6 text

横断的関心とエコシステムチーム間のコミュニケーションには一定のパターンがある - デプロイ - QA - 複数チームで開発組織のスケーラビリティにはエコシステムが重要である - 「組織規模が倍になっても通用するか？」

Slide 7

Slide 7 text

Main

Slide 8

Slide 8 text

DMM プラットフォーム事業本部とは主な扱う領域 - 認証認可・決済・不正対策・会員・ポイント・カスタマーサポート組織規模: 100人強フロントエンドプロダクト: 40個以上

Slide 9

Slide 9 text

DMM プラットフォームのエコシステムフロントエンドチームでは、プラットフォームのFEを集約したエコシステムを作っているフロントエンドチームにやっていること - モノレポ基盤 - デザインシステム - 静的アセット配信基盤 - 実装・アーキテクチャレビュー

Slide 10

Slide 10 text

今回扱う事例 - 事業部のフロントエンドAppを集約したモノレポ - Nx - 差分検知, 変更対象の自動テスト - GHAによる、すぐに使える CI - デザインシステムや破壊的変更を検知 - PRごとにStorybookなどが自動的にデプロイされ、 cloneせずとも動作検証できる仕組み - 自信を持ってマージできる仕組み - フロントエンド専任が少ないが、プロダクトは多いという組織特性にマッチ

Slide 11

Slide 11 text

課題の変遷新たに開発されるアプリケーションはReactで行うことが当たり前になった一方で、変化するニーズに機敏に対応しきれないところが見えてきた昔: メンテが難しくなったプロダクトのリプレース & React化現在: Reactでより効率よく開発を行いたい

Slide 12

Slide 12 text

抱えていた問題 1. CIの低速化と遅いフィードバック 2. CIの低い拡張性と多様化するニーズ 3. モノレポ管理ツール周辺の対応コスト

Slide 13

Slide 13 text

抱えていた問題 - CIの低速化と遅いフィードバック - CIの低い拡張性と多様化するニーズ - モノレポ管理ツール周辺の対応コスト　 - →律速、強制的なマルチタスク化 - →やりたいことができない - →新しい施策が行えない

Slide 14

Slide 14 text

具体例1: テストが遅い特定のチームでCIがかなり遅くなり、数ヶ月後にOOMで失敗するように実施からテスト失敗まで20分 →　辛い https://github.com/nodejs/node/pull/50682

Slide 15

Slide 15 text

具体例1: テストが遅い Jest のヒープサイズを調査したところ、他のアプリケーションでも増加していた → アプリケーション起因ではなさそう、Jest側の問題を調査根本原因は、Jestが使用しているvm.ScriptがGCできていない > vm: ﬁx V8 compilation cache support for vm.Script Node.js 20.10.0 で修正

Slide 16

Slide 16 text

具体例2: yarn installが遅い開発マシンでもクリーンインストールで5分かかっていた Nxの特性上、node_modulesのサイズが肥大化しやすい GitHub Actionsのキャッシュ制限からキャッシュミスが多発していた解決策: PNPMに移行し、Yarnのグローバルキャッシュ分の高速化 Docker buildも高速化し、デプロイが40分から20分に🎉

Slide 17

Slide 17 text

具体例3 最も大変なのはモノレポ管理ツール Nxのアップデート - 13 → 15のアップデート: 所要時間 2ヶ月 Nxは nx migrate latest で自動化できると言っている - 全然そんなことはない！！ - https://github.com/nrwl/nx/issues/13192 - 現象: Next.jsのカスタムサーバーが本番環境でもwatchモードになっていて、No space left on device でコンテナが立ち上がらない

Slide 18

Slide 18 text

Nxのつらみ - ExecutorがAdapterではなく、「いい感じのオプション」を追加してくる - ドキュメントに乏しい - 定期的にバグる - 問題の切り分けが面倒 NxでTypeScript, Nextなどを実行するためには、Nxが提供しているプラグインを使用する

Slide 19

Slide 19 text

Nxのつらみ例えば、 - nodeでスクリプトを実行するには @nx/js:node が必要

Slide 20

Slide 20 text

Nxのつらみ Executorは次の形で利用する

Slide 21

Slide 21 text

Nxのつらみ簡単に利用できるように見えるが、大きな落とし穴があるこの例だと、デフォルトで以下のオプションがオンになっている - デバッガー有効化、 - ファイルウォッチによる自動更新 →　本番環境でデバッガーを常に有効簡単さはあるが、あまり安心して使えない

Slide 22

Slide 22 text

Nxのつらみを解決する NxのメリットはExecutorが簡単に使用できるというメリットだったが、現状を考えると、Executor自体メリットが低い →Nxをやめることを決め、最適な方法を検討している

Slide 23

Slide 23 text

Monorepo in General

Slide 24

Slide 24 text

スケールするモノレポ - 疎結合性 - Sparse Checkoutとの相性の悪さ - モノレポ化はGoでいうサブパッケージレベルのモノだったり - 現時点のモノレポは分割実行のための作為的な分割 - 自動化 - One Version Policy

Slide 25

Slide 25 text

組織の課題に見合ったソリューション組織規模に見合った解決方法を考案しなければならない - Google, Facebook, … - DMMの組織規模やメンバー構成・スキルセット初期のDMMのモノレポ化は、レガシーなphpからの移行プロセスモノレポツールはBig Techから生まれた文化であり、そのプラクティスを実践することが正しいとは限らない