ハクソク

世界を動かす技術を、日本語で。

CloudflareからBunny.netへの移行

33日前原文(jola.dev)

概要

  • Cloudflare から bunny.net へのブログ移行理由と経験の共有
  • 集中依存 や 障害時のリスク に対する懸念
  • bunny.net の特長とヨーロッパ企業としての魅力
  • 移行手順 と 設定ポイント の詳細解説
  • bunny.net の今後への期待と利用推奨

Cloudflareからbunny.netへ移行した理由と背景

  • 長年Cloudflareユーザー として無料かつ高機能なサービスを利用
  • 単一企業依存 によるリスク、障害時の影響範囲の大きさへの不安
  • 米国企業への集中 やスキャンダルの存在も懸念材料
  • ヨーロッパ発の競合サービス への関心と分散化志向

bunny.netの特徴と選定理由

  • bunny.net はスロベニア（EU）発のCDNサービス
  • パフォーマンスと速度 でCloudflareに匹敵する実力
  • PoPネットワーク はCloudflareより小規模だが世界中で高評価
  • ヨーロッパ企業支援 の観点からも選択
  • 無料トライアル やシンプルな従量課金制、手厚いサポート体制

Cloudflareからの具体的な移行内容

  • ドメインレジストラ はCloudflareからPorkbunへ変更
    • INWXはWHOISプライバシー非対応のため除外
    • PorkbunはCloudflareインフラ利用だがサポートが優秀
  • Cloudflareの オレンジクラウド （自動キャッシュ・オリジン隠蔽・保護機能）からの脱却

bunny.net CDNの導入手順

  • bunny.netアカウント作成 （無料クレジット付与、メール認証必須）
  • 従量課金制 （月額最低1ドル）、無料トライアル後は低コスト運用
  • Pull Zoneの作成
    • 名前設定、Origin URL入力（サーバーの直接アドレス）
    • 必要に応じてHostヘッダー設定（複数アプリ運用時）
    • Standard Tier選択、利用ゾーンの選択（コスト最適化）
  • カスタムホスト名追加 とDNS設定（CNAMEレコード追加）
  • SSL有効化 （Verify & Activate SSL）でHTTPS運用開始

キャッシュ設定と最適化

  • キャッシュ制御ヘッダー に従う設定がデフォルト
    • サーバー側で適切なcache-controlヘッダーを返すことが推奨
  • Smart Cache の活用で静的リソースのみ自動キャッシュも可能
  • HTMLページもキャッシュ する場合は、記事公開時にPull Zoneのパージが必要
  • Phoenixフレームワーク でのキャッシュヘッダー追加例
    • cache-control: public, s-maxage=86400, max-age=0で高速化実現

推奨する追加設定

  • Force SSL を有効化し全通信を暗号化
  • Origin Shield の有効化でサーバー負荷軽減
    • オリジンに近いロケーションを選択
  • Stale Cache 設定でオリジン障害時もキャッシュ配信継続
  • Edge Rule で自動生成ドメインから本ドメインへのリダイレクト設定
    • 例：https://<slug>.b-cdn.netへのアクセスはhttps://jola.devへ301リダイレクト

bunny.netの今後とおすすめポイント

  • エッジルール、キャッシュ設定、セキュリティ機能 など多彩なオプション
  • ダッシュボードでの詳細な統計・ログ・メトリクス の提供
  • S3互換ストレージの今後の展開 にも期待
  • Cloudflare依存からの脱却 と ヨーロッパ企業支援 の両立
  • bunny.netの導入を強く推奨

Hackerたちの意見

一年前に切り替えたんだけど、めっちゃ気に入ってるよ。EUベースのCDNをサポートできるだけじゃなくて、Magic Containersがすごいんだ。グローバルに瞬時にスケールできるAPIが、使うまで月に1ドルもかからないんだよね。

└

うん、Magic Containersは素晴らしいよ。大きな負荷にスケールするかは分からないけど、コストがかかるかもしれないし、軽い趣味プロジェクトにはほぼ無料で使えるくらいスケールダウンは得意だね。ここにいる何人かは無料プランがないことを不満に思ってるけど、Magic ContainersはCloudflareのDurable Objectsと同じようなことができるから、確か月5ドル以上かかるはずだよ。

残念ながら、趣味で使う人には無料ホスティングを提供してないんだ。ちょっとしたトラフィックでも、月に1ユーロ（VAT別）払わなきゃいけない。CNAMEフラッティングをサポートしてるDNS管理プロバイダーはあまり知らないけど、教えてくれたら嬉しいな。プルゾーンキャッシュをクリアするたびに、2回やってるんだ。CIから1回じゃ足りないからね。CIはデプロイ中に個別のページキャッシュを無効化するけど、アセットが配信される時に何らかの遅延（フィードバックなし）が必要なんだよね。

└

えっ、サービスに月1ユーロだって？どうやって経済的に回復するの？

└

いやいや、月1.20ユーロだよ。

└

価格で笑われてるコメントもあるけど… 価格の問題じゃなくて、ハードルの問題なんだよね。どんなにサービスが好きでも、クレジットカードを入力しなきゃいけないとなると、あまり多くの人に試してもらえないんだ。

└

残念ながら、趣味のための無料ホスティングは提供していないんだ。表面的なトラフィックでも、月に1ユーロ（VAT別）払わなきゃいけない。え、月1ユーロが高いの？すごいね。1ユーロ払うか、GitHubに行けば無料だけど、ほぼ毎週ダウンするよ。

いくつかのことに使ってるけど、すごく満足してるよ。サービスの堅牢性以外で一番の理由はサポートかな。CloudFlareは良いけど、ダメな時もあるし、エンタープライズサポートにお金をかける必要もないからね。あまり知られてないけど、信頼できるインフラサービスに切り替える理由として、これが一番過小評価されてると思う。UpCloudも素晴らしいサポートだよ！

こんなポジティブなブログ記事で透明性を持たせるために言っておくと、ページ内のリンクは全部Bunnyのアフィリエイトプログラムにリンクされてるみたいだよ。

└

俺は法律の専門家じゃないけど、報酬が開示されてないこの手の推薦はFTCのガイドラインに違反する可能性があるから、「Amazonアソシエイトとして、適格な購入から収入を得ています」みたいな免責事項がどこにでもあるんだよね。著者はイギリスに住んでるみたいだけど、調べた感じでは、そっちにも似たようなものがあるっぽい。

└

ごめん、アフィリエイトリンクをやりすぎちゃったみたいで、リンクを外して他のもいくつか削除したよ。アフィリエイトプログラムがあるのはいいなと思っただけなんだ。怪しいことは全く考えてないからね！

CDNとDNSにはbunny.netを使ってるよ。無料のサービスはあんまり好きじゃないんだ。だって、いつかお金を取ることになったらどうするの？「無料は無理だから、今から1インスタンスにつき20ドル取るよ」って誰かが言い出したら困るじゃん。今、低料金で使える方がいいな。2ドルから3ドルに変わるのは全然ありだけど、無料から有料になるのはリスクが高い。だから、開発者に本当に気を使ってくれるような小さめの独立系の会社が好きなんだ。だからbunny.netやtransistor.fm、Plausible Analyticsを使ってるよ。

└

無料のサービスはあんまり好きじゃないんだ。いつかお金を取ることになったらどうするの？「無料は無理だから、今から1インスタンスにつき20ドル取るよ」って誰かが言い出したら、その時は別のプロバイダーに移ればいいじゃん。CDNとDNSに関しては、実際にロックインされることはないから。DNSレコードをエクスポートしてCSVにして、他のところに簡単にインポートできるし、CDNはただのファイルサーバーだから、ファイルを他の誰かに渡すのも簡単だよ。

└

もし市場全体が20ドルに移行したら、他の業者が同時に2ドルから3ドルに移行する経済的な理由は何だろう？

└

論理的には、CloudFlareがやることは無料利用枠を減らすか、なくすことだけだと思う。例えば、X百万の操作が現在無料なら、X/2の操作を無料にするみたいな感じ。彼らがそうするとは思わないけど、もしそうなったとしても、どんな企業にとっても致命的にはならないと思う。実際、メーター制のサプライヤーはビジネスを潰すことができるからね。通常は、破壊が相互確約されているからそんなことは起こらないけど。いずれにせよ、小さくて独立した企業を使うのは+1だね！

今、Cloudflare WorkersとPagesでSaaSを運営してるんだけど、開発者体験は本当に良いよ。サーバーレス関数と静的サイトを同じリポジトリからデプロイするのもスムーズだしね。でも最近、実際の問題にぶつかったんだ。CDNのエッジキャッシュがデプロイ後に古いHTMLを返して、サービスワーカーがその悪いレスポンスをキャッシュしちゃった。ダッシュボードからCDNをパージすることで解決したけど、エッジで問題が起きたときのデバッグ体験は辛いね。どのキャッシュレイヤーが問題なのか、いつも推測しなきゃいけないから。でも、始めるには無料プランが最高なのは間違いないよ。Workers、Pages、KV、R2 — スケールに達するまでほぼゼロコストでフルプロダクションアプリを運営できるからね。Bunnyがそれを提供してるかは分からないけど。

└

それにぶつかったこともあるよ、他にスクリプトを書いてくれた人を見つけたから、私たちだけじゃないね。https://bash.cyberciti.biz/web-server/linuxunix-bash-shell-s...

└

Cloudflareの最大の利点はwrangler cliだね。claude codeと組み合わせると、セットアップやデバッグ、分析を完全に任せられるんだ。これに懐疑的な人もいるかもしれないけど、複数のSaaSや趣味のプロジェクト、個人ツールを扱うときに、管理がずっと楽になるよ。

└

DBは彼らにとって主な欠点のようだね。D1の制限には関わりたくないな。NeonやSupabaseみたいなサーバーレスのPostgresセットアップがあれば、完璧だと思う。

└

Bunnyには無料プランがないけど、最大の利点は前払いの請求があることだね。攻撃されたり、デプロイでミスしたり、突然のリソース使用があっても、驚きの六桁の請求が来るリスクがゼロなんだ。何百万も請求されるくらいなら、サイトがダウンした方がマシだよ。多くのプロジェクトは、突然のトラフィックのスパイクからそんな収益を上げる見込みもないしね。高可用性の価値にはコストの上限があるけど、CloudFlareみたいな業者はそれを無視することが多い。

└

Bunnyはその辺りが結構あるよ（sqlite互換のAPIやエッジファンクションも持ってるけど、名前が違うとかね）。とはいえ、BunnyとCFのデバッグで地域を跨いで問題が多かったから、リモートHTTPとTCPトレースルートを両方できる無料ツールを作ったんだ：https://dnsisbeautiful.com/global-http-availability

質問があるんだけど、MITMせずにTLSを剥がして再暗号化しないCDNを設定することって可能なのかな？それとも、どの管轄がトラフィックを検査するかを選んでるだけなの？編集：CDNをAPIやキャッシュできないコンテンツのプロキシとして使うケースを考えてるんだけど、トランジットやDDoS保護のためのリバースプロキシとして使う場合ね。

└

CDNの目的の一つは、レスポンスをキャッシュできることだし、他にも色々変更できるはずだよね。リクエストの中身を見ずにそれができるとは思えないな。

└

おそらく無理だね。それだと、世界中にあるロードバランサーが自分のバックエンドにアクセスしてるように見える。ウェブデータをキャッシュするには、通常、キャッシュ内でそれを復号化する必要があるよ。

ちょっとした注意点だけど、教育関連の多くの場所では、マルウェアやプロキシツール、その他のトラブルのせいで*.b-cdn.netが禁止されてるんだよね。

└

面白いね！うちもCDNの解決策としてCloudflare R2に移行したんだけど、いくつかのヨーロッパの政府機関から、資産が読み込まれないって報告があったんだ。君が言ってるのと同じ理由だと思う。だから、選択肢を探しながら元に戻したんだ。最終的にはBunnyに移行したら、みんな問題なくなったよ。

CloudflareはもうCDNじゃなくて、ワーカーズエッジプラットフォームになっちゃったね。もしbunny.netに移れるなら、実際にはCloudflareを使ってなかったってことだよ。代替案がWinterTCを本当に取り入れないのが理解できない。もしこんな恐ろしいことを見たら：import * as BunnySDK from "@bunny.net/edgescript-sdk" BunnySDK.net.http.serve(async (request: Request) => これは置き換えようとしてるものよりもひどい独自ロックインだよ！

これ、https://www.goodboydigital.com/pixijs/bunnymark/を使ったキャプチャだと思ってたんだけど、ほとんどのボットはGPUがついてないだろうね :)