Dropbox社のエンジニアは、Gitのストレージとデルタ圧縮モデルの非効率性を改善することで、バックエンドのモノレポのサイズを87GBから20GBに削減し、開発者の生産性と継続的インテグレーションのパフォーマンスを向上させた。 この取り組みは、Dropbox社内の複数のチームにまたがるバックエンドサービスおよび共有ライブラリの中央統合拠点として機能するリポジトリにおけるスケーリング上の課題によって推進されたものだ。
モノレポが拡大するにつれて、技術チームの人は1時間以上かかる場合があるクローン操作の遅延を経験し始め、さらに繰り返されるフェッチおよびビルドのオーバーヘッドによりCIパイプラインの性能低下も発生。拡大はまた、リポジトリホスティングの上限に到達するリスクを増加させた。Dropbox社の技術調査によると、問題は主として大容量のバイナリや誤って行われたコミットによるものではなく、Gitの内部圧縮ヒューリスティクスが関連する大規模なファイル群をどのように扱うかに起因するものであると明らかになった。
Gitは、ファイル間の類似性を特定し差分を効率的に保存することで、ストレージを削減するためにデルタ圧縮を用いる。大規模な環境において、Dropbox社の技術担当の人は、これらのヒューリスティクスが最適ではないパックファイルを生成し、実際のコード変更と比較して不均衡に大きいリポジトリの増加をもたらしていることを確認した。 予想された増加と観測された増加の不一致は、リポジトリの内容のみにとどまらず、ストレージの挙動に対するより深い調査を促す要因となった。
Dropbox社のシニアソフトウェアエンジニアであるIshan Mishra氏は、次のように述べた。
その増加率は、Dropbox社の規模においても、通常の開発活動から予想されるものと一致しなかったとIshan Mishra氏は述べました。これは、問題が単に保存しているものにあるのではなく、それがどのように保存されているかにあることを示唆しています。
チームは、モノレポを本番インフラとして扱い、ストレージのパターンに関する詳細な分析を実施した。Gitがオブジェクトのデルタをどのように構造化するかを調整し、デルタウィンドウおよび深さの挙動の改善に焦点を当て、最適化されたリパッキング戦略を実装した。 クローンおよびフェッチ操作のためのサーバー側のパッキングはGitHub社のインフラを通じて管理されているため、Dropbox社の技術担当の人はGitHub社のチームと協力し、これらのパラメータの調整した。変更は、本番展開前にミラー環境で検証され、運用リスクの低減が図られた。
Shailesh Mishra氏はLinkedInの投稿で次のように述べた。
これはツールの前提が大規模なリポジトリ構造と衝突したものです。
これらの最適化に続き、リポジトリのサイズは87GBから20GBへと減少し、およそ77%の削減となった。クローン作成時間は1時間以上から15分未満へと短縮され、データ転送および処理のオーバーヘッドの削減により、CIパイプラインの実行も高速化。 これらの改善はまた、リポジトリのサイズ上限に到達する可能性を低減し、エンジニアのオンボーディングに要する時間の短縮にもつながった。
Dropbox社のGitデータサイズ削減(出典:Dropbox社ブログ投稿)
Dropbox社のエンジニアは、今回の取り組みで得られたもっとも重要な教訓は、バージョン管理システムを重要なインフラとして捉えることの重要性であり、ストレージの動作が開発速度に直接影響を与えることを強調した。 この取り組みは、ツールレベルでの最適化、GitHub社との組織横断的な協力、ならびに段階的な検証を組み合わせたものであり、開発者の作業の流れを妨げることなく、安全な本番展開を実現した。