Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
利用者の生産性をどう上げるか 中規模モノレポの苦しみ
Search
noyan
February 09, 2024
0
310
利用者の生産性をどう上げるか 中規模モノレポの苦しみ
Think! FrontEnd第6回の発表で使用したスライドです。
noyan
February 09, 2024
Tweet
Share
More Decks by noyan
See All by noyan
Goで書いて学ぶ HTTP Server / Write and learn HTTP Server in Go
noyan_
0
11
React Fiber Architectureとレスポンス性の向上 / React fiber architecture and responsiveness
noyan_
0
9
React Server Componentsは誰のためのものか?
noyan_
0
380
Featured
See All Featured
A Tale of Four Properties
chriscoyier
156
23k
Being A Developer After 40
akosma
86
590k
Scaling GitHub
holman
458
140k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Imperfection Machines: The Place of Print at Facebook
scottboms
264
13k
Bash Introduction
62gerente
608
210k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
YesSQL, Process and Tooling at Scale
rocio
167
14k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
330
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Transcript
利用者の生産性 をどう上げるか 中規模モノレポの苦しみ
自己紹介 • 名前: 岡本 済 • 所属: 合同会社DMM.com プラットフォーム事業本部 Developer
Productivity Group • 仕事: モノレポのメンテナンス
生産性とスケール可能性
「社長、人増やしたけど速度が遅くなってます」 - 組織が大きくなるにつれ、徐々に進みが緩やかになっていく感覚を感じたことはな いか? 話すこと - 組織のスケーラビリティにはソフトウェアのアーキテクチャが重要 - モノレポのスケーラビリティに何が必要か
人員が増えると、かえって遅くなる - コミュニケーションパスの急激な増加 - 5 人だった時は10通り - 10人だと45通り - 20人だと190通り!!
- 種類 - オンボーディングコスト - 承認・コミュニケーションのオーバーヘッド - チーム化による分割統治は本質的解決にならない
横断的関心とエコシステム チーム間のコミュニケーションには一定のパターンがある - デプロイ - QA - 複数チームで開発 組織のスケーラビリティにはエコシステムが重要である -
「組織規模が倍になっても通用するか?」
Main
DMM プラットフォーム事業本部とは 主な扱う領域 - 認証認可 ・ 決済・不正対策・会員・ポイント・カスタマーサポート 組織規模: 100人強 フロントエンドプロダクト:
40個以上
DMM プラットフォームのエコシステム フロントエンドチームでは、プラットフォームのFEを集約したエコシステムを作っている フロントエンドチームにやっていること - モノレポ基盤 - デザインシステム - 静的アセット配信基盤
- 実装・アーキテクチャレビュー
今回扱う事例 - 事業部のフロントエンドAppを集約したモノレポ - Nx - 差分検知, 変更対象の自動テスト - GHAによる、すぐに使える
CI - デザインシステムや破壊的変更を検知 - PRごとにStorybookなどが自動的にデプロイされ、 cloneせずとも動作検証できる仕組み - 自信を持ってマージできる仕組み - フロントエンド専任が少ないが、プロダクトは多いという組織特性にマッチ
課題の変遷 新たに開発されるアプリケーションはReactで行うことが当たり前になった一方で、変化 するニーズに機敏に対応しきれないところが見えてきた 昔: メンテが難しくなったプロダクトのリプレース & React化 現在: Reactでより効率よく開発を行いたい
抱えていた問題 1. CIの低速化と遅いフィードバック 2. CIの低い拡張性と多様化するニーズ 3. モノレポ管理ツール周辺の対応コスト
抱えていた問題 - CIの低速化と遅いフィードバック - CIの低い拡張性と多様化するニーズ - モノレポ管理ツール周辺の対応コスト - →律速、強制的なマルチタスク化 -
→やりたいことができない - →新しい施策が行えない
具体例1: テストが遅い 特定のチームでCIがかなり遅くなり、数ヶ月後にOOMで失敗するように 実施からテスト失敗まで20分 → 辛い https://github.com/nodejs/node/pull/50682
具体例1: テストが遅い Jest のヒープサイズを調査したところ、他のアプリケーションでも増加していた → アプリケーション起因ではなさそう、Jest側の問題を調査 根本原因は、Jestが使用しているvm.ScriptがGCできていない > vm: fix
V8 compilation cache support for vm.Script Node.js 20.10.0 で修正
具体例2: yarn installが遅い 開発マシンでもクリーンインストールで5分かかっていた Nxの特性上、node_modulesのサイズが肥大化しやすい GitHub Actionsのキャッシュ制限からキャッシュミスが多発していた 解決策: PNPMに移行し、Yarnのグローバルキャッシュ分の高速化 Docker
buildも高速化し、デプロイが40分から20分に🎉
具体例3 最も大変なのはモノレポ管理ツール Nxのアップデート - 13 → 15のアップデート: 所要時間 2ヶ月 Nxは
nx migrate latest で自動化できると言っている - 全然そんなことはない!! - https://github.com/nrwl/nx/issues/13192 - 現象: Next.jsのカスタムサーバーが本番環境でもwatchモードになっていて、No space left on device でコンテナが立ち上がらない
Nxのつらみ - ExecutorがAdapterではなく、「いい感じのオプション」を追加してくる - ドキュメントに乏しい - 定期的にバグる - 問題の切り分けが面倒 NxでTypeScript,
Nextなどを実行するためには、Nxが提供しているプラグインを使用す る
Nxのつらみ 例えば、 - nodeでスクリプトを実行するには @nx/js:node が必要
Nxのつらみ Executorは次の形で利用する
Nxのつらみ 簡単に利用できるように見えるが、大きな落とし穴がある この例だと、デフォルトで以下のオプションがオンになっている - デバッガー有効化、 - ファイルウォッチによる自動更新 → 本番環境でデバッガーを常に有効 簡単さはあるが、あまり安心して使えない
Nxのつらみを解決する NxのメリットはExecutorが簡単に使用できるというメリットだったが、 現状を考えると、Executor自体メリットが低い →Nxをやめることを決め、最適な方法を検討している
Monorepo in General
スケールするモノレポ - 疎結合性 - Sparse Checkoutとの相性の悪さ - モノレポ化はGoでいうサブパッケージレベルのモノだったり - 現時点のモノレポは分割実行のための作為的な分割
- 自動化 - One Version Policy
組織の課題に見合ったソリューション 組織規模に見合った解決方法を考案しなければならない - Google, Facebook, … - DMMの組織規模やメンバー構成・スキルセット 初期のDMMのモノレポ化は、レガシーなphpからの移行プロセス モノレポツールはBig
Techから生まれた文化であり、そのプラクティスを実践することが 正しいとは限らない