VercelでホストされているNext.jsアプリケーションのレスポンス時間が600msに達していました。 特にローカル環境では遅い印象はなくて、なぜかvercel上で動かしているときだけ遅いという謎現象。
Edge Middlewareがロンドンで実行されていた
レスポンスが遅い原因を調べるためにVercelのログを漁っていたら、Edge Middlewareがロンドンで実行されていたことがわかりました…。
まず、Vercelのドキュメントを参照しました。
Functions using the Edge runtime execute in the data center is closest to the user, or in a region near your databases. This can result in a much lower latency and allows you to provide personalization at speed.
このように書かれているので、現状どう考えても東京リージョンで実行されるはずなんだけど、なぜかロンドンで実行されていました。
Cloudflare DNS Proxyモードが原因だった
ステージングではそこまで遅くなかったこともあり、本番環境との違いを潰していったら唯一設定が違ったのがCloudflareで設定したDNSだけでした。
本番環境は以前の環境のときにいろいろあったのでCloudflare DNS Proxyを利用していました。
そのためになぜかEdge Middlewareだけがロンドンで実行されていたようです。
Proxyモードをoffにしたら、150msぐらいでレスポンスしてくれるようになりました。
さらにEdge Middlewareも東京リージョンで実行されていました。
そもそもCloudfare DNS Proxyモードってなんだろう
- DNSリゾルバに対する名前解決の結果CloudflareのIPアドレスが応答される
- オリジンへのリクエストはCloudflare内部ネットワークを通ることになる
Cloudflare DNS Proxy モード と CNAME Flattening (ALIASレコード）について;
上記の記事に詳しく書いてあります。
おそらくですがCloudflare Edgeから出る際にロンドンあたりを経由したからVercel側のEdge Middlewareがロンドンで実行されたのかと思われます。 (なぜロンドンなんだろうか…)
Serverless Functionでちょっと混乱した
ちなみにmiddlewareのあとに実行されるServerlss Functionは東京で実行されていました。
なんでだろうって必死に考えてましたが、Edgeじゃないから設定で指定していただけでした。
調査時にちょっと混乱してしましました。
最後に
Vercel使うときはCloudflareのProxyモードはオフにしましょう。
実はVercelの公式ドキュメントにも「Disable the Cloudflare Proxy」と書かれていました…w
Vercel and Cloudflare Integration