Dropboxが毎秒数百万のアクセスをさばくトラフィック制御基盤をNGINXからEnvoyへ移行中

クラウドストレージサービスを提供するDropboxは、自社トラフィック制御基盤をNGINXからEnvoy Proxyへと移行しました。なぜNGINXからEnvoyへと移行したのか、その理由や問題点などについて、Dropboxがブログ上で公開しています。

How we migrated Dropbox from Nginx to Envoy - Dropbox
https://dropbox.tech/infrastructure/how-we-migrated-dropbox-from-nginx-to-envoy

NGINXはDropboxのトラフィック制御基盤として過去10年ほど問題なく稼働していましたが、サービス間通信のREST APIからgRPCへの移行、Bazelによるビルド管理など、モダンなシステム導入が進むにつれて、Dropboxのアプリケーションデプロイに関するベストプラクティスに合わなくなったとのこと。また、NGINXによるトラフィック制御基盤はYAMLやJinja2、Pythonなど、複数の要素によって構築されており、運用コストが高い点も問題でした。NGINXの移行先としてGoで開発されたBandaidを検討していましたが、GoはCやC++よりもオーバーヘッドが大きいため、移行先をEnvoyに決定したそうです。

NGINXは「ワーカープロセス」と呼ばれる複数のプロセスによってトラフィック制御を行いますが、Envoyは複数のスレッドによる制御を行います。NGINXからEnvoyに移行した結果、Dropboxの環境では、NGINXが占有していたサーバーリソースを60％まで解放することができたとのこと。また、NGINXによるトラフィック基盤では、DropboxがLuaを用いて独自実装したログ収集システムを利用していましたが、EnvoyにはPrometheusのExporter形式で多様なメトリクスを出力する機能が備わっており、かつgRPCでアクセスログをストリームする機能もあるので、監視が容易になったと説明されています。

NGINXは静的な設定ファイルやsyslogなどの広く普及しているプロトコルを利用しており、シンプルで高い互換性を持っているとのこと。こうした性質は小規模な環境では優位性がありますが、システムの規模が大きくなると、テストのしやすさと標準化がより重要になってくるとDropboxは説明。EnvoyはxDSと呼ばれる安定したAPIを提供するとともに、gRPCなどの利用を推奨しており、gRPCでサービス間通信を行っているDropboxのシステムと非常に親和性が高かったとのこと。Envoyは拡張性やセキュリティにも優れており、開発状況もオープンで透明性が高いとのこと。

NGINXからEnvoyへの移行における最大の問題点は、APIサービス動作の不整合であったとのこと。NGINXは業界標準としての実績があるため、ほとんどのライブラリはNGINXの動作を前提としており、APIの動作について、NGINXとEnvoyの間で多くの不整合があったそうです。また、Envoy自体にもバグがありましたが、Envoyコミュニティとの協力により、すでに解決済みだとのこと。

記事作成時点では、NGINXとEnvoyを両方利用している状態であり、DNSを操作して徐々に切り替えを行っているとのこと。今後はHTTP/3への対応や、社内で利用しているBandaidのEnvoy移行などを計画していると語られています。