DropboxがコアサービスをRustで書き換えた背景とは

ファイルシェアサービス（クラウドストレージ）のDropboxが、コアとなるサービスの一つをPythonからRustで書き直したことをブログで公開した。これはクライアントとサーバー間でファイルを同期させる重要なコンポーネントである「Sync Engine」と呼ばれるソフトウェアを、PythonからRustに変えた背景を解説したものだ。

参考：Rewriting the heart of our sync engine

Rustは、Mozilla Foundationが開発をリードしているメモリーセーフなコードの生成を目指したオープンソースの低レベルプログラミング言語だ。ここで言う「低レベル」とは、アセンブラーやC言語と同様に抽象度が低いことを意味する。Rustは高速な実行速度と低い消費リソースという低レベルプログラミング言語と同じ特徴を持ちながらも、メモリーアクセスを安全にすることを最大の目的として開発されている。CやC++などとは異なる新しいパラダイムを導入し、セキュアなコードが書けることを勘案すれば、別の意味で「高レベルのプログラミング言語」と呼んでも良いだろう。

なぜメモリーセーフなコードが重要になるのかを示す一例が、Microsoftが行った調査の結果だ。その調査によれば、Microsoftが開発するソフトウェアに関する脆弱性の約70％がメモリーアクセス、メモリーセイフティに関するものであったという。メモリーリークや本来アクセスするべきでないデータがアクセスされてしまうというのは、ハッカーが攻撃を行う脆弱性の代表的なものだ。

メモリー関連の脆弱性が70％を占めるというMicrosoftの調査結果

なお、DropboxはPython 2を使って開発を始めたが、2018年にPython 3へのマイグレーションも実施しており、開発言語や環境については常に改善を行ってきた組織と言える。DropboxのPython 3へのマイグレーションに関しては、以下の記事を参照してほしい。

参考：How we rolled out one of the largest Python 3 migrations ever

ではDropboxはなぜPythonで書かれていたSync EngineをRustで書き換えたのか、その概要を見ていこう。

まずSync Engineについて解説をすると、ローカルのPC（Windows／macOS）において実行されるプロセスで、サーバー側と通信を行うことでファイルのコピー、同期などを行うものである。単純に書けばその通りだが、複雑になるのは複数のユーザーがサーバー側を操作することでファイルの共有ができるというところから始まる。

Sync Engineの概要

そして「PythonベースのSync Engine Classicがどういうチャレンジに晒されていたのか？」という部分では、大規模にスケールすること、複数のユーザーが利用する非同期かつ分散システムであること、異なるOSの下で動いても同じように動くこと、ファイルの同期をテストすることが難しいこと、同期の挙動をすべて網羅するのが困難であることなどを挙げて、PythonベースのSync Engine Classicでは対応できないことが明らかだったと解説する。

別々のユーザーが同じディレクトリーを操作

わかりやすい複雑さの例として、複数のユーザーが同じファイル構造に対して変更を行う操作を挙げて説明をしている。これはAとBのユーザーがディレクトリーの構造を変更した際にそれぞれがサーバー側に同期した時にオリジナルのSync Engineでは不具合が起こるが、時系列でちゃんと整合性を取っている新しいSync Engine（コードネーム：Nucleus）では不具合が起こらないというイラストだ。

新旧のSync Engineでの処理比較例

そして書き直したことの最も大きな理由は、Sync Engineが採用していたデータモデルが、共有や同期などの分散処理に向かないものだったこと、さらにもう一つの理由としてテストやデバッグに向かないコードだったことを解説している。さまざまなクライアントから多種多様な使い方でファイルが共有されるDropboxでは、テストの網羅性と自動化が必須であろうが、その両方ができていなかったという。

それらの問題点を解決するためにRustを採用して書き直し、マルチスレッドではなくシングルスレッドでシンプルにすることで複雑な並列処理を実装、擬似的にランダムな入出力をテストとして実施することができたというのが結論だ。

Rustの良さを表すもう一つの事例も紹介しよう。それはCNCFがIncubation ProjectとしてホストするキーバリューストアデータベースであるTiKVだ。TiKVは中国のPingCAPが開発をリードするオープンソースソフトウェアで、スケーラブルであることに加え、キーバリューストアでありながらACID^※1を保証するAPIを実装していることでも知られている。2018年にサンドボックスプロジェクトとしてCNCF配下になったTiKVは、2019年5月にIncubation Projectとして採用された。etcdも採用する分散合意アルゴリズムであるRaftをRustで実装しており、Clientとの通信にgRPCを使うという辺りも、最近のクラウドネイティブソフトウェアという印象だ。

※1：Atomicity（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（永続性）を表し、信頼性のあるデータベースシステムが備えるべき性質であるという概念。

TiKVのホームページ：https://github.com/tikv/tikv

ここで紹介したいのは、CNCFからの委託としてベルリンのCure53というサイバーセキュリティの企業が実施したTiKVのセキュリティに関するレポートだ。2020年3月に公開されているもので、コードの内容、ドキュメンテーション、コミュニティの活動など、ソフトウェアそのものに限定せず、そのソフトウェアとエコシステムが信用に足るものか？　を審査したものだ。

参考：Security-Review Report TiKV 02.2020

TiKVは4.0.0-alphaを利用し、5人のテスターが18人日を掛けて調査を行ったという。ここでの注目は、TiKVは当初からGoで開発をスタートしたものの、Goのガベージコレクションの制約やC言語へのBindingに関する不満などから、Rustに変更して開発を進めたという部分だろう。同じメモリーセーフを謳いながら、GoとRustで決定的に違いがある部分がこのガベージコレクションの有無だ。

Cure53のレポートから。C言語のstrcpyは使うなと明記

調査の結果は非常に良いもので、脆弱性もなく、ドキュメンテーションも豊富であるなどの賞賛を寄せている。この調査がPingCAPではなくCNCFの予算で実施されているという部分に、CNCFがホストするプロジェクトに対する客観的な視点を感じる。etcdに対して分散処理システムとしての妥当性をJepsenが調査した事例からも分かるように、CNCFの単にホストするだけではなく第3者からの評価を常に怠らない本質を見たと言えるだろう。

他にもCNCFがホストするサービスメッシュのソフトウェアLinkerdのモジュールであるLinkerd2-Proxyも、ゼロからRustで書かれたソフトウェアである。

Linkerd2-Proxy：https://github.com/linkerd/linkerd2-proxy

またLogDNAというログを管理するソリューションを開発するベンチャーは、最新のv2のエージェントをRustでゼロから開発したという。Rustで書くことで大量のログを処理する際の高速化が図れたというのは、Rustの特徴がメモリーセーフであるだけでなく、高速であるということも記憶にとどめておくべきだろう。

参考：https://logdna.com/introducing-agent-v2-beta-for-kubernetes/

Mozilla Foundationも、Rustの高速化については記事を書いている。

How to speed up the Rust compiler one last time in 2019

これらの例が示すように、Go言語も含めてメモリーセーフなプログラミング言語に大きな注目が集まっていることがわかる。Googleが開発したGoは、早い時期から多くのデベロッパーの支持を集めているが、Rustもメモリーセーフ、ガベージコレクションがないこと、高速な実行速度、少ないメモリー使用などの利点を評価するデベロッパーが増えていくだろう。これからもRustの将来を注視していきたい。