いくつかの一般的なロスレス圧縮アルゴリズムをパフォーマンス分析した結果、Dropboxのエンジニアたちは、GoogleのBrotliエンコーダに少し手を加えることで、自社エンジンの同期パフォーマンス改善に成功した。同社エンジニアのRishabh Jain、Daniel Reiter Horn両氏の主張によれば、この変更により、中央値レイテンシ(median latency)とデータ転送が30パーセント以上改善された。
Dropboxでは、オリジナルの同期エンジンを自社開発しており、同期パフォーマンスを改善するために圧縮技術を使用している。しかしながら、昨今のロスレス圧縮分野における進歩によって、Dropboxのエンジニアたちは、当初より使用していた旧式のzlibアルゴリズムからの移行を検討するに至ったのだった。
Broccoliは基本的にはBrotliの拡張版で、複数のBrotliファイルを連結することができる。これにより、複数のコアを使ってファイルのチャンクを圧縮して最後に連結する、という方法を採用することで、Brotliのオリジナル実装に比較して3倍という、高い圧縮率が可能になった。Jain、Reiter Horn両氏は、Brotliを選択したおもな理由として、実行時にHuffmanテーブルの動的選択が可能であること、安全なRustベースの実装であること、HTTPの標準であること、などを挙げている。
マルチスレッドによる圧縮(と連結)を可能にするには、ファイルのチャンクを圧縮して有効なBrotliをアウトプットできることが必要ですが、設計プロセスの中で、オリジナルのBrotliプロトコルのサブセットに少し手を加えれば、圧縮後のファイルをひとつにまとめられることが分かりました。
Dropboxのエンジニアたちが考慮しなければならなかったことのひとつは、クライアント上でチャンクを圧縮中にデータを毀損する可能性であった。これに対しては、圧縮結果の展開(解凍)を行って、圧縮されたファイルが実際にオリジナルをエンコードしたものであることを確認する、という方法によって対処することにした。このアプローチは結果としてコアあたり約300MiBのコストを発生させるが、レイテンシやストレージコストの全体的な改善を考えれば受容する価値がある、とDropboxのエンジニアたちは判断したのだった。
展開時においても同様に、障害発生の可能性を考慮しなくてはならない。このケースにおいては、ユーザにエラーを報告したり、もっと悪く、クライアントがクラッシュしたりすることはなく、サーバが単に非圧縮データを再送することによって対処する。圧縮の不可能なデータに対しても同じアプローチを採用する。この場合、圧縮データを送り返すのは、単にクライアントのパフォーマンスを無駄にするだけだからだ。
前述のように、この対応はDropboxとそのユーザにとって、ファイルのダウンロードとアップロード両方において大きなメリットをもたらした。
アップロードパスに関しては、1日の帯域使用量を平均33パーセント削減できることが分かりました。日々の使用量を集計して正規化すると、50パーセントのユーザが約13パーセント、25パーセントのユーザが約40パーセント、10パーセントのユーザは最も多いおよそ70パーセントを、ファイルのアップロードにおいて削減できています。
ダウンロード時の圧縮に関しては、すべてのリクエストに対して1日平均で15パーセントの削減という結果になりました。これを時間で正規化すると、50パーセントのユーザが8パーセントの削減、25パーセントのユーザが20パーセントの削減、ダウンロード圧縮によるメリットが最も大きい10パーセントのユーザについては約50パーセントの削減を実現できています。
Jain、Reiter Horn両氏の記事には、プロトコルの低レベルに関する概要など、詳細な情報が数多く提供されている。リモートファイル同期の最適化に関心があるのであれば、ぜひ見ておくべきだろう。