Share
Embed
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: fix 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から生まれた文化であり、そのプラクティスを実践することが
正しいとは限らない