Hyperdrive

Hyperdrive は、Cloudflare Workers のようなエッジで動く実行環境と、既存の PostgreSQL や MySQL 互換データベースとの間に立つ接続高速化サービスです。データベース接続をプールして再利用し、よく使われるクエリの結果をキャッシュすることで、遠隔地にあるデータベースへ都度接続する場合に比べてレイテンシを大きく下げます。既存のデータベースをそのまま使い続けられ、アプリ側は接続文字列を Hyperdrive のものに変更するだけで導入できます。

解決する課題

Workers はエッジの多数のロケーションで実行されるため、リクエストごとにデータベースへ新規接続を確立すると、TCP のハンドシェイクや認証のやり取りが往復し、データベースが遠いリージョンにある場合はレイテンシが顕著に増えます。加えて、サーバーレスの実行環境は同時実行数が急増しやすく、短命な接続を大量に開閉するとデータベース側の接続数上限を圧迫しやすいという問題もあります。

Hyperdrive はこの間に入り、確立済みの接続をプールして使い回すことで接続確立のオーバーヘッドを吸収します。さらに、Hyperdrive はデータベースに近い場所でクエリ結果をキャッシュする仕組みを持ち、繰り返し実行される読み取りクエリについては、データベースへ往復せずに応答を返せる場合があります。これにより、既存のデータベースの構成を変えずに、エッジからの体感速度と安定性を引き上げられます。

主要概念と用語

• 接続プーリング: 確立済みのデータベース接続をまとめて保持し、複数のリクエストで使い回す仕組み。接続確立のたびに生じるオーバーヘッドを削減する。
• クエリキャッシュ: 一部の読み取りクエリの結果を Hyperdrive 側で一時的に保持し、同じクエリが再度実行された際にデータベースへ問い合わせずに返す仕組み。
• コンフィグ（Hyperdrive 設定）: 接続先データベースのホスト・ポート・認証情報などをまとめた設定単位。Workers からはこの設定に対応する識別子を通じて接続する。
• ドライバー / クライアントライブラリ: PostgreSQL や MySQL 用の標準的なクライアントライブラリを、Hyperdrive 向けの接続情報でそのまま利用できる。
• オリジンデータベース: Hyperdrive が接続を仲介する対象の、既存の PostgreSQL または MySQL 互換データベース本体。
• プライベート接続: VPC など非公開ネットワークにあるデータベースへ、トンネル経由で到達するための接続経路。

仕様・制限・クォータ

Hyperdrive は PostgreSQL 互換および MySQL 互換のデータベースに対応しており、クラウド事業者が提供するマネージドデータベースや、自前で運用するデータベースのいずれも接続先にできます。データベースが非公開ネットワークにある場合は、トンネル機構と組み合わせてプライベートに到達させる構成が取れます。

クエリキャッシュは、パラメータや実行内容から安全にキャッシュできると判断される読み取りクエリが対象で、書き込みを伴うクエリや一部の複雑なクエリはキャッシュされません。キャッシュの保持時間や対象範囲は設定で調整でき、常に最新のデータが必須な参照には適さない点に注意が必要です。同時接続数やコンフィグ数などの上限は変更され得るため、最新の値は公式ドキュメントで確認してください。

内部の仕組み

Workers からのデータベース接続要求は、通常のドライバーを使ったコードのまま Hyperdrive 経由に向けられます。Hyperdrive はこれを受け、既に確立済みの接続がプールにあればそれを再利用し、なければ新規に接続を確立してオリジンデータベースへ橋渡しします。これにより、リクエストのたびに新しい接続を一から張る必要がなくなり、接続確立にかかる往復時間を大幅に削減できます。

読み取りクエリについては、Hyperdrive がクエリの内容をもとにキャッシュ可否を判断し、キャッシュ可能なものはエッジに近い場所で結果を保持します。同じクエリが再実行された際にキャッシュがヒットすれば、オリジンデータベースへ問い合わせることなく応答を返せます。書き込みクエリや、キャッシュ対象外と判断されたクエリは、通常どおりプールされた接続を通じてオリジンデータベースへ届けられます。

設計パターン / ベストプラクティス

最も効果が出やすいのは、Workers のようにエッジの多数の場所で実行され、かつ既存のリレーショナルデータベースをそのまま使い続けたいケースです。データベースを移行せずに、接続文字列を Hyperdrive 向けに切り替えるだけでレイテンシ改善の恩恵を受けられます。

データベースが非公開ネットワークにある場合は、トンネル機構と組み合わせてプライベートに接続する構成を検討します。また、キャッシュを有効にする場合は、データの鮮度要件に応じて保持時間を調整し、必要であれば特定のクエリだけキャッシュを無効化する運用も選択肢になります。

運用・監視

Hyperdrive を経由する接続やクエリの状況は、ダッシュボードやログを通じて確認できます。接続プールの利用状況やキャッシュのヒット状況を把握し、期待した効果が出ているかを継続的に確認することが運用の基本です。応答が遅い場合は、キャッシュ対象になっていないクエリが多くないか、オリジンデータベース側の負荷が高くないかを切り分けて調査します。

オリジンデータベース側の認証情報を変更した場合は、Hyperdrive の設定側も合わせて更新する必要があります。データベースのメンテナンスやフェイルオーバーが発生した際に接続がどう振る舞うかも、事前に確認しておくとよい観点です。

コスト

Hyperdrive 自体の利用に対する課金は、リクエスト数や利用量に基づく体系が取られています。オリジンデータベースの利用料は従来どおり別途発生するため、Hyperdrive の費用はデータベース本体のコストに追加される形になります。

クエリキャッシュによってオリジンデータベースへの問い合わせ回数を減らせれば、データベース側の負荷や、データベースサービスによっては読み取りに応じた課金を抑えられる場合があります。具体的な料金体系や無料枠は変更され得るため、見積もりは公式の料金ページで確認してください。

セキュリティ

Hyperdrive の設定にはオリジンデータベースへの認証情報が含まれるため、これらはシークレットとして安全に管理し、必要最小限の権限を持つデータベースユーザーを使うことが基本です。Workers から Hyperdrive、Hyperdrive からオリジンデータベースへの通信は暗号化された経路を使う構成が推奨されます。

非公開ネットワークにあるデータベースへ接続する場合は、トンネル機構を使ってインターネットへの露出を避け、接続元を必要な範囲に限定します。

関連サービス・比較

接続のプールとレイテンシ改善という点では、AWS の RDS Proxy と似た役割を持ちますが、Hyperdrive はエッジ実行環境からの利用を前提とし、クエリ結果のキャッシュも合わせて提供する点が特徴です。RDS Proxy は主に接続プーリングとフェイルオーバー対応に重点を置き、クエリ結果自体のキャッシュは行いません。

ハンズオン / CLI例

以下は wrangler CLI を使って Hyperdrive の設定を作成し、Workers のプロジェクトに紐づける例です。接続文字列やデータベースの認証情報は環境に合わせて置き換えてください。

# Hyperdrive の設定を作成(接続文字列はオリジンデータベースのものを指定)
npx wrangler hyperdrive create my-hyperdrive-config \
  --connection-string="postgres://user:password@db.example.com:5432/mydb"

# 作成済みの Hyperdrive 設定一覧を確認
npx wrangler hyperdrive list

# 設定の詳細を確認
npx wrangler hyperdrive get <HYPERDRIVE_ID>