Vercelで配信していた静的ページをVite + Cloudflare Pagesに置き換えた

カウンターワークスで主にDevOpsなところでお手伝いしている@tchikubaです。ベンチャー企業のTech支援やアジャイルコーチ、エンジニア向け研修など複数社に関わってます。

この記事では、HTML・CSS主体の静的ページをVercelを使って配信していた構成を、Cloudflare Pages（以下Pages）で配信するように変更した話をお届けします。

歴史的経緯

そもそもなんで静的ページをVercelで配信してたん？ってところです。

課題感

もともと、動的なアプリケーションの構成が、フロントエンド　=　Next.js（Vercel）、バックエンド = Ruby on Rails（AWS）で、特にバックエンドとのAPI通信を必要としないページもフロントエンド環境に組み込まれていました。
1枚もののLPやよくあるフッター系のページ（ex. プライバシーポリシー）くらいならそのままでも良かったんですが、以下のような課題感がありました。

• エンタープライズ向けSaaSであり、要件的にページ数が増えやすい（導入企業 x ページ種類）。
• 導入企業ごとに静的ページのプレビュー環境が必要。
• デザイナーが手軽に触れる環境が欲しい。

旧構成

そこで、以下のような構成で運用していました。

• 静的ページを別リポジトリに切り出して、別のVercelプロジェクトとして定義。
• 事前確認用にVercelのPreviewを利用。
• Cloudflare Workers（以下Workers）でリクエストを受けて、静的ページのパスルールに合致するものを静的ページにプロキシ。
  • 合致しないリクエストはそのままVercelにて処理される。

課題

この運用を継続する中で以下の課題が出てきました。

• 「（GitHubリポジトリ + Vercelプロジェクト x 2（staging / production）） x 導入企業数」となるのでGitHubリポジトリ・Vercelプロジェクトが乱立して管理が煩雑。
  • そもそもVercelプロジェクトはstagingとproduction用で1つにまとめられたけど歴史的経緯で2つ立てる運用になってしまっていた😅
• Webpackのビルドがイマイチ。
  • ローカルでビルドしたものをコミットする運用。
  • ローカルでのビルドが手間。
• 将来的にはそもそも動的アプリケーションも含めてVercelをヤメたい。
  • Vercelの障害に依存したくない。
• Workersスクリプト（JavaScriptで記述）が顧客ごとに違いパスルールの管理が煩雑。
  • 現状Terraformで管理しており特殊なパスルール追加のたびにterraform applyが必要。
  • この作業はデザイナーに依頼できないのでエンジニアが手を動かす必要あり。

移行

これらの課題を解決するため、タイトルの通りVite + Pagesでの配信を採用することにしました。

https://ja.vitejs.dev/
https://developers.cloudflare.com/pages/

採用理由

採用理由は以下の通りです。

• 1つの静的ページ用リポジトリ、1つのPagesプロジェクトで配信することで管理を楽にできる。
• Vite + Pagesのビルド・デプロイが良さそう。
  • Webpackよりモダンで開発体験が良い（ハズ）。
  • ローカルでビルドせずPages上でビルドしてローカルでのビルドの手間を省く。
  • Pages上のデプロイ全体で25秒程度で終わる。
• とりあえず手始めに乱立していた静的ページ用のVercelプロジェクトを撲滅できる。
• 既に採用しているWorkersと相性が良さそう。

Pagesの利便性

デプロイが高速であること以外にも、以下のように色々とメリットがあります。

• Preview環境がコミット・ブランチごとに作られるので過去の経緯追いやすい。
  • GitHub統合されていてPreview環境へのURLもGitHub上から辿れる。
  • 以下のようにデプロイ後にPRコメントされる。
    
  • 上記例だとコミットハッシュがbdd721b3、ブランチがfeature/remove_basic_auth。
  • たまにPRコメントされないことがあるけど、その場合はPRのChecksタブから辿れる。
• デプロイ時にフレームワーク・ビルドコマンドを指定できる。
  • see. https://developers.cloudflare.com/pages/configuration/build-configuration/
  • Viteは上記にないのでフレームワークは選択せずnpm run buildでビルドコマンドを設定。
    
• リアルタイムログはwebコンソールの他、wrangler pages deployment tailコマンドでも見ることができる。
  • webコンソールはちょっと分かりづらいけど、Workers & Pages > プロジェクト選択 > デプロイ対象のView detail > FunctionsのReal-time LogsでBegin log streamボタンを押下すると参照できる。
    
  • 他にもwrangler pagesコマンドが諸々用意されている。
    • see. https://developers.cloudflare.com/workers/wrangler/commands/#pages
• basic認証を入れたりするのにfunctionsという機能が使える。
  • 静的ページへのアクセス前に実行されるサーバーレス関数。
  • JavaScriptで記述する。

Cloudflareのログを永続的に残すことを考えるとEnterpriseプランの課金が必要だけど😅

移行後の所感

実際に移行をやってみて感じたことを最後に紹介します。

静的ページ配信ならVite + Pagesオススメ！

とくかく静的ページ配信ならVite + Pages一択！というくらいにはすごい便利＆簡単！
多分、設定だけなら3分クッキングくらいのスピード感で静的ページ配信できます。
Cloudflareすごいなぁ…！

ちなみにViteって 「ヴィート」 って発音するんですね。綴り見ると未だについつい「バイト」って読んじゃうｗ

vite.config.jsはやはり職人芸になりがち？

ViteにするとWebpackで苦戦してたwebpack.config.jsの職人芸から開放されるのかな？とちょっと期待していたけど、ビルド設定を工夫しようとするとvite.config.jsを入れる必要があり、これもまた職人芸になりやすいかも？と思いました。

Viteの設定項目についてもそうだけど、モジュールハンドラーのRollupについての理解も結構たいへんですね。私は「完全に理解した（※）」領域にすら到達してないです😅

※要は全くわかってないｗ

https://rollupjs.org/

Workersスクリプトの課題

Vite + Pagesと直接的な関係がない、静的ページへのプロキシルールを記述しているWorkersスクリプトがごちゃごちゃしていた課題は、これを機にリファクタリングすることで多少解決しました。

ただ、静的ページのパスルール（例えば/static配下のリクエストは静的ページにプロキシするなど）に沿わないリクエストについては、依然Workersスクリプトにパスルールを追加する必要があるので、これは運用上の手間として残っています。

また、かねてより「WorkersスクリプトはTerraformではなく、Wrangler + GitHub Actionsでデプロイする方が管理効率が良いね」と社内で機運が高まっており、そちらも別課題として取り組んでいく予定です。