Dropbox、GitHubと協力してモノレポのサイズを87GBから20GBに削減
本文の状態
日本語全文を表示中
詳細モードで約5分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
InfoQ
DropboxはGitHubと協力し、Gitのデルタ圧縮を最適化することでバックエンドモノレポのサイズを87GBから20GBに削減し、クローン時間やCIパフォーマンス、開発速度を向上させた。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るSource Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Dropboxのエンジニアは、Gitのストレージおよびデルタ圧縮（delta compression）モデルにおける非効率な問題を解決することで、バックエンドのモノレポ（monorepo）のサイズを87GBから20GBに削減し、開発者の生産性と継続的インテグレーション（CI）のパフォーマンスを向上させました。この取り組みは、Dropbox内の各チーム間でバックエンドサービスや共有ライブラリの統合ポイントとして機能するリポジトリのスケールアップに伴う課題がきっかけとなりました。
モノレポが大きくなるにつれて、エンジニアリングチームは1時間以上かかる遅いクローン操作（clone operations）や、繰り返されるフェッチとビルドのオーバーヘッドによるCIパイプライン（CI pipeline）のパフォーマンス低下を経験し始めました。また、リポジトリの拡張はホスティング制限に達するリスクも高めました。Dropboxエンジニアリングチームの調査によると、この問題は主に大きなバイナリや誤ってコミットされたファイルによるものではなく、Gitの内部圧縮ヒューリスティック（compression heuristics）が大量の関連ファイルをどのように処理していたかに起因していました。
Gitはファイル間の類似性を特定し、差分を効率的に保存することでストレージを削減するデルタ圧縮（delta compression）を使用しています。大規模なスケールで運用する際、Dropboxのエンジニアはこれらのヒューリスティックが最適ではないパックファイル（packfiles）を生成し、実際のコード変更に対して不釣り合いに大きなリポジトリの成長を引き起こしていることを観察しました。期待される成長と実際に観測された成長の不一致は、リポジトリの内容だけでなく、ストレージ動作そのものに対するより深い調査を促しました。
DropboxシニアソフトウェアエンジニアのIshan Mishraは次のように指摘しています：
成長率は、Dropbox規模での通常の開発活動から予想されるものとは一致しませんでした。これは、私たちが保存している内容だけでなく、どのように保存されているかが問題だったことを示唆しています。
チームはモノレポを生産環境のインフラとして扱い、ストレージパターンを詳細に分析しました。最適化されたリパッキング戦略（repacking strategies）を実装し、Gitがオブジェクトデルタ（object deltas）を構造化する方法を調整して、デルタウィンドウとディプス（delta window and depth behavior）の動作を改善することに焦点を当てました。クローンやフェッチ操作のためのサーバーサイドパッキングはGitHubインフラを通じて管理されているため、Dropboxのエンジニアはこれらのパラメータを調整するためにGitHubチームと連携しました。運用リスクを軽減するため、本番環境への展開前にミラーリングされた環境で変更が検証されました。
Shailesh MishraはLinkedInの投稿で次のように述べています：「これは、ツールの前提条件が大規模なリポジトリ構造と衝突した結果でした。
これは、ツールの前提条件が大規模なリポジトリ構造と衝突した結果でした。
これらの最適化の後、リポジトリのサイズは87GBから20GBに減少し、約77％の削減となりました。クローン時間は1時間以上から15分未満に短縮され、データ転送と処理のオーバーヘッド削減によりCIパイプラインの実行も高速化しました。この改善はリポジトリのサイズ制限に達する可能性を低減し、開発者のオンボーディング期間の短縮にもつながりました。
Dropbox Gitデータサイズの削減（出典：Dropboxブログ記事）
Dropboxのエンジニアたちは、主要な教訓はバージョン管理システム（version control systems）を重要インフラ（critical infrastructure）として扱うことの重要性にあり、ストレージの動作がエンジニアリング速度（engineering velocity）に直接影響を与えるという点だと強調しました。この取り組みでは、ツールレベルの最適化（tooling-level optimization）、GitHubとの組織横断的な連携（cross-organizational collaboration）、そして段階的検証（staged validation）を組み合わせ、開発者のワークフローを混乱させることなく安全なロールアウトを実現しました。
著者について
Leela Kumili
Leelaはスターバックスのリードソフトウェアエンジニアであり、スケーラブルなクラウドネイティブシステム（cloud-native systems）や分散プラットフォーム（distributed platforms）の構築において深い専門知識を有しています。リワードプラットフォーム全体においてアーキテクチャ、デリバリー、運用の卓越性（operational excellence）を牽引し、システムの近代化、スケーラビリティの向上、信頼性の強化に向けた取り組みを主導しています。
技術的なリーダーシップに加え、Leelaは組織内のAIチャンピオン（AI Champion）としても活動し、LLMベースのツール（LLM-based tools）を活用して開発者の生産性やワークフローを改善する機会を特定し、AI導入のベストプラクティスを確立しています。本番環境対応システム（production-ready systems）の構築、開発者体験の向上、そしてエンジニアが技術的・戦略的な影響力を両立して成長できるようメンターとして指導することに情熱を注いでいます。彼女の興味関心はプラットフォームエンジニアリング（platform engineering）、分散システム、開発者生産性、そして技術的ソリューションとビジネス・プロダクトの目標を結びつけることにあります。
続きを読む / 表示を閉じる
原文を表示
Dropbox engineers have reduced the size of their backend monorepo from 87GB to 20GB by addressing inefficiencies in Git’s storage and delta compression model, improving developer productivity and continuous integration performance. The effort was driven by scaling challenges in a repository that serves as a central integration point for backend services and shared libraries across teams at Dropbox.
As the monorepo grew, engineering teams began experiencing slow clone operations that could take over an hour, along with degraded CI pipeline performance due to repeated fetch and build overhead. The expansion also increased the risk of reaching repository hosting limits. According to Dropbox engineering findings, the issue was not primarily caused by large binaries or accidental commits, but by how Git’s internal compression heuristics handled large sets of related files.
Git uses delta compression to reduce storage by identifying similarities between files and storing differences efficiently. At scale, Dropbox engineers observed that these heuristics produced suboptimal packfiles, resulting in disproportionately large repository growth compared to actual code changes. The mismatch between expected and observed growth prompted a deeper investigation into storage behavior rather than repository content alone.
As Ishan Mishra, Senior Software Engineer at Dropbox, noted:
The growth rate didn’t match what we would expect from normal development activity, even at Dropbox’s scale. That suggested the problem wasn’t just what we were storing, but how it was being stored.
The team treated the monorepo as production infrastructure and conducted a detailed analysis of storage patterns. They implemented optimized repacking strategies and adjusted how Git structures object deltas, focusing on improving delta window and depth behavior. Since server-side packing for clone and fetch operations is managed through GitHub infrastructure, Dropbox engineers collaborated with GitHub teams to tune these parameters. Changes were validated in mirrored environments before production rollout to reduce operational risk.
As Shailesh Mishra noted in a LinkedIn post: ‘This was a tooling assumption colliding with repo structure at scale.
This was a tooling assumption colliding with repo structure at scale.
Following these optimizations, the repository size decreased from 87GB to 20GB, representing an approximate 77 percent reduction. Clone times dropped from over an hour to under 15 minutes, while CI pipelines saw faster execution due to reduced data transfer and processing overhead. The improvements also reduced the likelihood of hitting repository size limits and shortened developer onboarding times.
Dropbox Git data size reduction (Source: Dropbox Blog Post)
Dropbox engineers emphasized that the primary learning was the importance of treating version control systems as critical infrastructure, where storage behavior directly impacts engineering velocity. The work combined tooling-level optimization, cross-organizational collaboration with GitHub, and staged validation to ensure safe rollout without disrupting developer workflows.
About the Author
Leela Kumili
Leela is a Lead Software Engineer at Starbucks with deep expertise in building scalable, cloud-native systems and distributed platforms. She drives architecture, delivery, and operational excellence across the Rewards Platform, leading efforts to modernize systems, improve scalability, and enhance reliability.
In addition to her technical leadership, Leela serves as an AI Champion for the organization, identifying opportunities to improve developer productivity and workflows using LLM-based tools and establishing best practices for AI adoption. She is passionate about building production-ready systems, enhancing developer experience, and mentoring engineers to grow in both technical and strategic impact. Her interests include platform engineering, distributed systems, developer productivity, and bridging technical solutions with business and product goals.
Show moreShow less
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み