Boost Your Web Performance with Hyperdrive Cloudflare Workers Tech Talks in Osaka #2 2025.3.7 

目次 ● Cloudflare Workersのメリット ○ メリットのおさらい ○ メリットから発生する課題 ● Hyperdrive ○ Hyperdriveとは ○ 設定の解説 ○ 計測 ● 導入例 ○ 初期おすすめ設定 ○ 実例 ● まとめ 

Cloudflare Workersの メリット 

https://www.cloudflare.com/ja-jp/developer-platform/products/workers/ 

リージョン Earth 🌍 

Region:Earthとは？ ● Cloudflare Workersにリージョンの概念は存在しない ○ 全世界に125カ国335拠点すべてに配置される ● インターネット人口95%の人は最寄りの拠点まで50ms圏内に 接続される ● 小さい日本でもデータセンターが4拠点もある ○ 東京、大阪、福岡、那覇 https://www.cloudflare.com/ja-jp/network/ 

Cloudflare Workersの実行イメージ アクセス使用としたユーザの近い拠点で実行される 

発生する課題 💣 

アプリケーションすべてがRegion:Earth？ ● 作成したCloudflare Workersはどこに接続（通信）しますか？ ○ オリジンサーバー ○ データベースサーバー etc ● 接続（通信）先はCloudflare Workersの拠点から近いですか？ https://www.cloudflare.com/ja-jp/network/ 

Cloudflare Workersの実行イメージ 日本にあるデータベースサーバーを配置して日本からアクセスした場合の例 jp jp jp 50ms 50ms 日本からの接続速度 SQLを2回実行 通信速度合計としては 50ms + (50ms x 2) = 150ms 

Cloudflare Workersの実行イメージ 日本にあるデータベースサーバーを配置してUSからアクセスした場合の例 us jp us 50ms 500ms USからの接続速度 SQLを2回実行 通信速度合計としては 50ms + (500ms x 2) = 1050ms 

Cloudflare Workersを使用しない実行イメージ 日本にあるデータベースサーバーを配置してUSからアクセスした場合の例 jp jp us 500ms 50ms USからの接続速度 SQLを2回実行 通信速度合計としては 500ms + (50ms x 2) = 600ms 

Region:Earthが引き起こす課題 ● 通信経路によっては通信速度によるパフォーマンス低下が著しい ○ 通信先（DBなど）をRegion:Earthとする対応はコスト増 ● 地域（日本）限定のユーザしかいないので大丈夫と過信は良くない ○ Bot（GoogleBot）とかアクセスしてこないですか？ ○ Cronバッチなどのイベント処理はどこからアクセスしてきますか？ 

Hyperdrive 

Hyperdriveとは？ ● リージョナルDBを仮想Region:Earthにする ● データベースへのコネクションプーリングを提供する ● SQLの実行結果のキャッシュ機能を提供する https://developers.cloudflare.com/hyperdrive/ 

Hyperdriveの概念的イメージ（たぶん） リージョン間の通信を極力早くするためにCloudflare内部のネットワークを 使用しているのではないかと思われる us jp us Workers jp Hyperdrive Cloudflare private network 

実は、、、 ● Hyperdriveは2023年にリリースされている ● 2024年6月のアップデートでアジアリージョンでHyperdrive を使うと遅くなる不具合が発生していた ○ 暫定的に遅くならないようにCloudflareに対応してもらう必要があった ● 2025年2月のアップデートで上記の不具合が解消された 🎉 ○ 既存のHyperdriveは順次アップデートされていくらしい 

Hyperdriveの設定 ● キャッシュについては有効/無効が設定できる ● キャッシュを有効にした場合は以下の2つの設定を行う必要がある ○ max_age: キャッシュが有効な時間（デフォルト60秒） ○ stale_while_revalidate: max_ageが有効中のキャッシュを再取得するための時間 （デフォルト15秒） 

計測 ● 日本からCloudflare Workersにアクセス ● 1リクエストでSQLを10回発行 ● Supabaseの日本とアメリカのDBへの接続を比較 ● Neonのシンガポールへの接続を比較 

計測 import postgres from "postgres"; async function executeSqlQuery(sql: any) { for (let i = 0; i < 10; i++) { await sql`SELECT 1`; } } export default { async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise { … const client = await postgres(connectionString); await executeSqlQuery(client); return new Response('ok'); }, } satisfies ExportedHandler; コネクションだけを変更する 

計測 Service Region 1回目 2回目 3回目 Direct Supabase Japan 0.18 s 0.18 s 0.19 s Supabase Virginia 2.83 s 2.91 s 2.78 s Neon Singapore 1.66 s 1.67 s 1.68 s Hyperdrive Supabase Japan 0.25 s 0.26 s 0.22 s Supabase Virginia 2.13 s 2.20 s 2.08 s Neon Singapore 1.07 s 0.98 s 0.99 s 日本から大きく離れたリージョンへの速度は早くなるが、逆に近いリージョン は若干遅くなるという結果 

導入例 

初期のおすすめ設定 ● キャッシュをオフにして使用する ○ コネクションプーリングおよび接続速度の高速化のみを使用する ● キャッシュをオンに使用する ○ max_age: 1秒に設定して短い間だけキャッシュを使用する ○ stale_while_revalidate: 0秒に設定してキャッシュの更新を常に行う 

実例 GoogleBotのレスポンス速度 Hyperdrive有 　+ コード改善前 Hyperdrive無 + コード改善前 Hyperdrive無 　+ コード改善後 Hyperdrive有 　+ コード改善後 コードやSQL自体の実行回数に左右されるが、通信経路を変えるだけで 効果がかなりある 

実例 import postgres from "postgres"; export default { async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise { … const country = request.headers.get("CF-IPCountry"); const client = createClient( country === "JP" ? context.env.DIRECT_DATABASE_URL : context.env.YOUR_HYPERDRIVE.connectionString, ); … return new Response('ok'); }, } satisfies ExportedHandler; データベースへの接続をリクエスト毎に変更する - 接続元によって接続経路変える - 実行SQLによってHyperdrive を使用する etc DBクラスターやHypedriveのキャッシュを無効化した場合など 複数のHyperdriveを用意して制御するとよい 

まとめ ● Cloudflare Workersを使う場合はWorkers から接続する先も考慮した方がよい ● Hyperdriveが使える環境ならとりあえず 使っておいた方がよい ○ 有料版のCloudflare Workersでしか 使えないので注意 

Thanks! ● name: chimame / rito ● job: Webエンジニア ● field: Cloudflare, GCP, AWS, Ruby, Node.js, TypeScript, React, Next.js, Remix, Docker etc ● company: Goens株式会社( https://about.goen-s.com ) ● twitter: @chimame_rt ● GitHub: chimame