DropboxをNginxからEnvoyにマイグレーションする方法(第六章）

今回はDropboxをNginxからEnvoyにマイグレーションするやり方をご説明します。今回の記事は長いので6回に分けてお送ります。今回は６回目の最終章です。

Current state of our migration

半年以上前から Nginx と Envoy を並べて運用しており、徐々に DNS を使ってトラフィックを切り替えています。今では、様々なワークロードをEnvoyに移行しています。

• Ingressのハイスループットサービス。DropboxデスクトップクライアントからのファイルデータはすべてEnvoy経由でエンドツーエンドのgRPCで提供されています。Envoy に切り替えることで、エッジからの接続の再利用が改善され、ユーザーのパフォーマンスも若干向上しました。

• Ingressの高RPSのサービス。これはすべてDropboxデスクトップクライアント用のファイルメタデータです。エンドツーエンドの gRPC の利点に加えて、接続プールが削除されたことで、一度に 1 つの接続につき 1 つのリクエストに縛られなくなりました。

• 通知および遠隔測定サービス。ここでは、すべてのリアルタイム通知を処理しているので、これらのサーバには何百万ものHTTP接続（アクティブなクライアントごとに1つずつ）があります。

• 高スループット/高RPSサービスのミックス。API トラフィック (メタデータとデータそのものの両方) これにより、パブリックな gRPC API について考え始めることができるようになりました。既存のRESTベースのAPIをエッジ上ですぐにトランスコードするように切り替えることもできるかもしれません。

• Egressハイスループットプロキシ。私たちの場合、DropboxからAWSへの通信は、ほとんどがS3です。これにより、最終的には本番ネットワークからすべてのSquidプロキシを削除し、単一のL4/L7データプレーンを残すことができるようになります。

最後にマイグレーションするものの一つは、www.dropbox.com 自体です。このマイグレーションが終わったら、エッジのNginxデプロイメントの廃止をします。エポックがpassします。

Issues we encountered

もちろん、マイグレーションは完璧ではありませんでした。しかし、目立った障害は発生しませんでした。最も困難だったのは、API サービスでした。curl/wget で動くシェルスクリプトやカスタム HTTP/1.0 スタックを搭載したビルドインデバイスから、ありとあらゆる HTTP ライブラリまで、さまざまなデバイスが Dropbox とパブリック API を介して通信しています。Nginx…