はじめに
とある日のメール。
「何か100％いって従量課金始まっているなぁ…」と不思議に思い調べていたところ、VercelのProプランの新料金体系の発表が4月にあり、そこから約2ヶ月後の6月分（5/25〜6/25）から新料金体系になっていたことが分かりました。
今回の新料金体系で、「帯域幅（bandwidth）」と「機能（functions）」が細分化され、より具体的な項目に料金がかかるようになりました。
以下はVercelからのお知らせに書いてある２文です。
- We're reducing pricing on Vercel fundamentals like bandwidth and functions
- For the majority of customers, monthly bills will remain the same or decrease
「帯域幅と機能の料金が改善され、大半の人たちは料金が減る」と書いてあります。
ですが、担当しているプロジェクトでは、先ほどのメールの通り、Edge Requestが100％になり従量課金が発生していて、以前の料金より増えていました。
「大半の人たち」の中に入っていなかったみたいですね…。残念。
急にEdge Requestという項目に料金がかかるようになったので寝耳に水状態でした。
正確には、事前にお知らせがあったので把握できはしましたが、いざ新料金が適用されてから、どれくらいリクエストがあったかが可視化されたので、びっくりという感じです。
なので、今回はそのEdge Requestのことについてのみ取り上げます。
その他の「帯域幅（bandwidth）」と「機能（functions）」が細分化された項目一覧
Edge Request以外について知りたい方は以下を参考にしてください。
Edge Requestとは
リソース使用量の計算ガイドを見てみる
まず、先にVercelの使用リソースがどう計算されているかのガイドです。
このガイドはEコマースサイトの例で、ジャーニーとして以下の５段階に分けられて説明されています。
Edge Request以外にもどこにリソースがかかっているかが分かるので参考にしてみても良いかもしれません。
- User enters the site （サイトにアクセスする）
- Product browsing （商品一覧を閲覧する）
- Viewing updated product details （最新の情報が載っている商品詳細を閲覧する）
- Dynamic interactions (Cart) （動的に商品をカートに追加する）
- Engaging with A/B testing for personalized content （パーソナライズされたコンテンツの表示）
この中で「Edge Request」はどこに該当するか見てみます。
- User enters the site
Edge Requests: Charged per network request to the Edge Network
エッジネットワークへのネットワークリクエストごとに課金されます
- Product browsing
Edge Requests: Charged for network requests to fetch product images/details
商品画像/詳細を取得するためのネットワークリクエストに課金
- Viewing updated product details
Edge Requests: Network request charges for fetching updated product information
更新された製品情報を取得するためのネットワークリクエスト料金
- Dynamic interactions (Cart)
Edge Requests: Network request charges for cart updates
カート更新のためのネットワーク・リクエスト料金
- Engaging with A/B testing for personalized content
Edge Middleware Invocations: Charges per invocation for A/B testing logic
テストバリアントを提供するためのネットワーク要求料金
上記の通り、ガイドの例だと全ての工程にEdge Requestがかかっていることが分かります。
Edge Requestの説明を見てみる
次に、Edge Requestについてです。
Requests to Edge Network regions are not only for Functions using the edge runtime. Edge Requests are for all requests made to your site, including static assets and functions.
エッジ ネットワーク リージョンへのリクエストは、エッジ ランタイムを使用する関数のみを対象としているわけではありません。エッジ リクエストは、静的アセットや関数を含む、サイトに対して行われたすべてのリクエストを対象としています。
上記の通り、Edge RequestはEdge Functionsのみにかかるリクエストではありません。
画像の読み込みだったり、jsの読み込みだったり、レンダリングだったり、APIリクエストだったり、サイトに対して行われたすべてのリクエストを対象としています。
先ほどのジャーニーのガイドで全ての工程でEdge Requestがかかっていることも頷けます。
つまり、サイトに対して行われた全てのリクエストを対象としているので、サイトのPV数が多ければ多いほど、Edge Requestにかかるリクエストが増えていくわけです。
どうすれば良い？
上記を踏まえて、どうしたらEdge Requestを減らせるかを考えます。
結論から言うと、PV数多いプロジェクトに関してはEdge Requestが増えてしまうのでEdge Requestそのものを減らすことは難しいです。
ただし、それでも、最適化することはできます。
最適化の手段は以下に書いてあります。
策としては以下が挙げられています。
- 再レンダリングを防ぐ。
- 過度なfetchを減らす。
- Linkコンポーネントのprefetchをなくす。
こちらで挙げられている策はEdge Request以外にも単純なパフォーマンスにも関わる部分だと思うので、知らず知らずのうちに最適化できているプロジェクトもあるかもしれません。
また、その他にも、１回のリクエストで多くのデータを取得することも考えられますが、こちらはパフォーマンスそのものが悪くなってしまう可能性もあるので、まずは上記を見直してみると良いかもしれません。
とはいえ、そもそものPV数が多ければ最適化してもEdge Requestが増えてしまいます。
PV数に関しては減らすことはほぼ不可能に近いので、PV数が多いプロジェクトに関してはもはや対策する術がありません。
おわり
最後に今回の新料金体系ですが、Edge Requestに限らず、Regionごとに料金が異なります。
担当しているプロジェクトでは、約60％がTokyo、約35％がOsakaと日本からのリクエストがほとんどでした。日本のサイトであればほとんど同じようになるかと思います。
Edge Requestに関しては、Proプランでは1,000万リクエストを超えたら、100万リクエストごとに従量課金が発生します。
2024/7時点でTokyo Regionだと$2.6です。
詳しくは以下を参考にしてください。
担当しているプロジェクトでは、約300万PVを見込んでいた少し画像が多めな単純なサイトで、約3500万リクエストほどでした。
今VercelのProプランを使用しているプロジェクトがある方、これからVercelのProプランを使用する予定があるプロジェクトがある方、他のホスティングサービスと比較したい方、参考にしてください。
おわりのおわり
ちょっと社はどうやらアジア初のパートナーらしいです。
今回記事にした、Edge Requestについてやその他の項目について、なぜ料金が上がったのか？などの質問をMTGで直接Vercelの方にすることができます。
パートナーのちからってすげー。
ちょっと株式会社（chot-inc.com）のエンジニアブログです。 フロントエンドエンジニア募集中！ カジュアル面接申し込みはこちらから chot-inc.com/recruit/iuj62owig
Discussion