レンタルサーバーからCloudflareへ
個人サイトの運用にはレンタルサーバーがとっても便利です。ドメイン管理もメール機能もWordPress自動インストール機能もあります。個人サイト運用者の強い味方ですね。 私も昔はレンタルサーバーを使っていました。
ですが、紆余曲折経て、今はCloudflareで個人サイトをホスティングしています。
- 当初、Nuxt.jsで静的生成 → XサーバーにSFTPでアップロードしていた。（CI/CDに移行したい気持ちが高まっていた）
- その後、フレームワークをNext.jsに変更するタイミングでVercelへ移行。ようやくGitからデプロイできるようになった。
- ドメインはXサーバーのまま運用していたが、SSL証明書の更新で問題が起き、Cloudflareにドメインを移行。
- 2024年ごろ、フレームワークをAstroに切り替え、サイトもCloudflare Pagesへ。ようやく一本化できた。
こんな流れで移行していきました。
Xサーバー時代に遭遇したSSL更新のエラーを解消するために、ドメインレジストラの移管先として選んだだけだったCloudflareですが、徐々にその魅力に気づいていきました。
今回は、レンタルサーバーからCloudflareに移行して良かったことについて書きたいと思います。
Cloudflareの良かったこと
フリープランの制限が緩い
フリープランという前提で、Cloudflare、Netlify、Vercelを比較してみます。
Cloudflareはビルド回数・ファイル数・ファイルサイズなどの上限がありますが、いずれも個人Webサイトの範疇なら十分な余裕があります。静的な軽いWebサイトなら帯域幅や転送量は無制限です。
NetlifyはCloudFlareに比べて各制限が強め。Vercelは規約上、商用利用する場合は有料プラン必須となっています。
どんな機能が必要なのか、どう運用するのか、有料プランはどうか、いろいろ検討事項はあるのですが、ひとまずCloudflareは始めやすい、という印象です。
CI/CDがとても簡単だった
CloudflareでGitHubのリポジトリを連携すると、pushするたびに自動でビルド・デプロイされるようになります。かなり簡単にできて驚きました。
ブランチごとに自動でプレビューURLが発行されます。サブドメインとしてdevやstgを設定し、プレビューURLを割り当てると、Stg環境やDev環境を簡単に作れます。その環境にパスワード保護を付ける設定もあります。
SFTPで個別の環境にファイルをアップロードしていた頃のことを思うと、隔世の感があります。
SSLの更新エラーから解放
Xサーバーで管理しているドメインに他のホスティングサービスを割り当てるとSSL証明書の更新時にエラーが発生して更新ができなくなるという事象が発生しました。
具体的に何が原因なのかはわかりませんが、Xサーバー側のインフラの都合だろうと想像はつきます。解決方法を探るよりもCloudflareにドメイン移管してしまう方を選び解決しました。これは間接的な恩恵ですが、一元管理はやはり強いですね。
エッジ配信でサイトが速い
世界中にエッジサーバーがあり、ユーザーの近くのサーバーから配信されます。日本国内なら大阪、東京、福岡、那覇と4箇所。後述で考察を書きますが、CDNとエッジサーバーの組み合わせがCloudflareの大きな魅力だと考えています。
考察: SSG とCDNとエッジ配信
Cloudflareはデフォルト設定ではSSG, SSRを問わずhtmlをキャッシュしないそうです。（画像やJSなどのアセットはキャッシュします）
Default Cache Behavior · Cloudflare Cache (CDN) docs
CloudflareといえばCDNでキャッシュ、というイメージが強いので意外でした。
なぜhtmlをデフォルトでキャッシュしないのか、その理由を考察してみました。観点は2つ。
- エッジ配信：ユーザーに地理的に近いサーバーからコンテンツを返す
- キャッシュ：一度処理した結果を保存しておき、次のリクエストから使い回す
キャッシュが特に威力を発揮するのは、オリジンサーバーの処理が重い場合です。SSRでDBクエリや外部APIの呼び出しが走るような場合、初回の処理結果をキャッシュしておくことで、2回目以降は処理を丸ごとスキップできます。数百msかかる処理が一瞬になる、という効果です。
ではSSGの場合はどうでしょう。SSGはビルド時にすべてのHTMLを生成します。つまり「サーバーサイドの処理」はありません。キャッシュで省くべき処理が最初から存在しないので、HTMLをキャッシュしてもあまり速度は変わらないのかもしれません。むしろエッジサーバーの数、つまりユーザーに地理的に近い場所に配信サーバーを多く設置することの方が重要なのでは？と思いました。
加えて、キャッシュにはデメリットもあります。 コンテンツが更新されたとき、古いキャッシュをいつ・どうやって削除するかの設計や運用を誤ると、ユーザーに古い情報を表示し続けることになります。
CloudflareがデフォルトでHTMLをキャッシュしないのは、こうしたリスクを避けつつ、エッジ配信だけで十分な速度を実現できる、という判断なのだと思います。SSGサイトとは相性が良さそうです。
ちょっと面倒なこと
レンタルサーバーであれば、ドメインに紐づいたメールアドレスを作って運用することができますが、Cloudflareにはメールサーバーやメール管理機能がありません。ここが国内のレンタルサーバーと考え方が違うところですね。
独自ドメインのメールアドレスを使いたい場合は、別途用立てする必要があり、私はさくらのメールとZoho Mailを試しています。
自分で使う分には用途に合ったものを選べばよいのですが、クライアントワークの場合はドメインを移管するか、メールアドレスとサイトを分けて運用するか、なんらか検討が必要です。
Cloudflareへの移行でよかったことまとめ
- フリープランの制限が緩い 転送量・ビルド回数など個人サイトには十分な上限で、商用利用もOK
- CI/CDがとても簡単 GitHubと連携するだけで自動デプロイできる
- Stg/Dev環境を手軽に構築できる プレビューURLをサブドメインに割り当てるだけで環境が作れる
- SSLの管理が楽になった ドメインをCloudflareに一元化したことでSSL更新エラーから解放された
- エッジ配信でサイトが速い 世界中のエッジサーバーからユーザーに近い場所で配信される
CI/CDに関して言えば、レンタルサーバーでもGitHub ActionsからSSH経由でrsyncするという手がありますが、自前で実装する必要があるので、最初から環境があるCloudflareはやっぱり楽ですね。
AstroなどでSSGで個人サイトを作成しているなら、Cloudflareは有力な選択肢だと思います。
補足
今回の記事ではCloudflare PagesとCloudflare Workersの違いについては触れませんでした。 今の段階では私はCloudflare Pagesを使用していますが、ゆくゆくはCloudflare Workersに統合されます。これについてはまた別の記事を書きたいと思います。