はじめに
Vercelを調査していて感じたメリット・デメリット
メリット
継続的にアプリケーションを運用していく上で必要なインフラ構築にかかる作業工数を削減できる
Next.jsで開発されているアプリケーションであれば、GitHubなどからコードを連携するだけで、インターネットからアクセス可能なアプリケーションとして動かすことが容易にできます。
一例ですが、一般的なWebアプリケーションであれば、
- サーバーの構築
- CI/CDの構築
- 監視の構築
などの手順を経て初めて、アプリケーションとして継続的に運用していく準備が整うと言えますが、Vercelではそれを自前で用意する必要はありません。
Next.jsを開発しているVercel社が運営している
Vercel社がNext.jsを開発している関係上、VercelでNext.jsのサポートが切られることはほぼ有り得ないと考えられます。
動かしたいアプリケーションの技術としてNext.jsを採用している場合、サポート切れによるリプレイスのリスクなどは極限まで減らすことができると考えられます。
リスク面だけでなく、Next.jsの新機能も積極的にサポートされていくであろうといったプラスの面も期待できます。
チーム開発に対するサポートが存在する
環境変数をVercelのプロジェクト上で管理し、各開発者はVercelのCLIツールを用いて常に最新の環境変数をpullすることができたりします。
また、featureブランチをpushした際に自動的に作成されるPreview環境では、動いているアプリケーションの画面にコメントをつけることができるため、コードのみのPRレビューより更に一歩進んだチーム開発体験を感じることができる可能性があります。
インフラ費用の最適化に工数を減らすことができる
たとえば、AWSではEC2のインスタンスそれ自体に課金されるため、インフラコストを下げようと思うとEC2のスペックを下げたり稼働時間を少なくするといった工夫が必要になります。
これに対して、（Proプランでは）Vercelは開発者アカウントに対しての課金になるため、サイジングに工数を割くといったことを行う必要がありません。
Vercel社提供のエコシステムを利用しやすい
たとえば、モノレポ構成をアプリケーションに採用する場合に、Turborepoを利用しやすいといったことはメリットです。
なお、デプロイ先に Vercel を利用している場合、このリモートキャッシュは自動的に有効化されます。
Next.jsアプリケーションのISRがVercelだと苦労せずに導入できるといった話も類似の話かと思います。
画像の最適化を利用できる
Image Optimization with Vercel
リサイズなどの処理を行ってくれ、それをVercelのEdgeの層でキャッシュしてくれます。
画像をたくさん使うアプリケーションでは画像の最適化が必要になる可能性が高いため、メリットになると思います。
Analyticsツールがある
プラットフォームに組み込まれた分析ツールであり、Cookieを利用しないといった記述があるため、昨今話題のサードパーティクッキーの問題などをおそらく気にしなくてよさそうです。
デメリット
APIの実行がServerless Functionになる
たとえば、Node.jsを通常のサーバーで動かす場合と比較して、OSのコマンドやファイルシステムにアクセスできません。
また、実行時間にも制限があります。（Proプランでは5分が上限にはなる）
アプリケーションログが1日しか保持されない
アプリケーションが出力するログは最大で1日しか遡ることができません。
業務で利用する本番環境アプリケーションで、1日しか残らないログで要件を満たすことができるケースはあまり多くないと考えるため、実質何らかの手段を用いてログを保存することは必須になると思われます。
Log Drainといった概念でログを保存することができますが、これを提供する別SaaSはVercel提供外のものになるため別途利用料がかかったり、セキュリティが担保されているかを別途確認したりする工数も発生します。
監査ログが残らない
Enterpriseプランのみ監査ログに対応しており、Proプランだと残らないようです。
個人情報といった秘匿性の高い情報を取り扱うアプリケーションを業務で作成する場合には、監査ログが必要になるケースが多いと思われるため、問題になる可能性があります。
マネージドなDBのリージョンに日本がない
DBのリージョンは、日本から一番近いリージョンでもシンガポールになります。
DBはAPI（Serverless Function）が配置されるリージョンと同一リージョンに作成することが推奨されています。
We recommend choosing the same region as your Serverless and Edge Functions for the fastest response times. After creating a database, you cannot change its region. Check your project's region before creating your database.
一部の追加機能には追加の課金が必要になる
いわゆる痒い所に手が届く機能で課金を促してくるため、本番アプリケーションとして運用する場合に欲しいものを全部求めているととんでもない金額になる可能性があります。
たとえば、DBのCompute Timeも課金対象です。
弊社では、社内で利用するアプリケーションでのVercel利用を検討しているため、毎日業務時間8時間中にずっと何らかのDBアクセスが発生すると制限である100時間を超過するような計算になります。
また、並列でビルドを走らせるのも課金対象であり、プロジェクトがスケールしていくにつれて問題が発生する可能性はあります。
Vercelの前にCDNを配置できない
• Vercel の前に追加の CDN を使用すると、Vercel が他のプロバイダーを制御できないため問題が発生し、古いコンテンツが提供されたり、404 エラーが返されたりする可能性があります。
弊社では社内利用を想定しているためあまりCDNの重要性は高くありませんが、一般的なアプリケーションでは問題になる可能性があります。
ただし、Vercel自体がインフラとしてエッジネットワークを構築しているため、それで満足できる場合は問題にならないかもしれません。
Vercelで提供されていないインフラを利用したい場合結局Vercel外で構築する必要がある
たとえば何らかの非同期処理のためにメッセージキューイングを利用したい、となった場合にAWS SQSを利用する、といった形になる可能性があります。
マルチクラウドな状態は管理が煩雑になるため、それであれば最初から全てAWSに寄せてしまった方がよいとなる可能性があります。
IaaCは実現できない
基本的にはVercelのダッシュボードから設定をぽちぽち変更することなるため、インフラ設定をコードで管理したい場合は向きません。
監査ログが残らないのも合わさって、「設定がいつの間にか変わっているがいつ変わったか、誰が変えたかわからない」といったことが起こる可能性もあります。
Discussion