Cloudflare D1・KV・Durable Objectsの違い｜Workersの保存先をどう選ぶか
Cloudflare Workersでアプリを作るとき、データの保存先としてD1、Workers KV、Durable Objectsなどが候補になります。どれもWorkersから利用できますが、データモデル、整合性、検索、同時更新、配置の考え方が異なります。
『データベースだからD1』『高速そうだからKV』と決めると、更新競合や検索不足、復旧困難が後から表面化します。まず業務上の正しさとアクセスパターンを整理し、必要なら複数を組み合わせます。
表形式・SQL検索・トランザクションを使う業務データはD1、設定やキャッシュなど読み取り中心のKey-ValueはKV、チャットルームや共同編集のように一つの主体へ更新を集約したい状態はDurable Objectsが基本候補です。
本記事のポイント
- D1はSQLとリレーショナルな問い合わせ、KVは読み取り中心のKey-Value、Durable Objectsはエンティティ単位の強く整合した状態に向きます。
- 製品名や無料枠から選ばず、更新競合、検索方法、データ量、復旧、監査を先に定義します。
- 一つに統一せず、設定はKV、業務データはD1、同時更新状態はDurable Objectsのように役割分担できます。
この記事で分かること
| 確認対象 | 見る内容 | 判断のポイント |
|---|---|---|
| D1 | リレーショナルSQL | 顧客・注文・コンテンツ等の問い合わせ |
| Workers KV | Key-Value、分散読み取り | 設定・フラグ・読み取り中心データ |
| Durable Objects | エンティティ単位の状態と調整 | ルーム・セッション・予約・同時更新 |
| R2 | 大きなオブジェクト | 画像・ファイル・バックアップ |
| 組み合わせ | 用途別に分離 | 一つの弱点を別の保存先で補う |
D1が向くデータ
D1はSQLiteのSQLセマンティクスを持つサーバーレスデータベースです。複数テーブルの関係、絞り込み、並べ替え、集計、トランザクションを使うデータに向きます。顧客、案件、記事、申請、設定台帳など、後から条件検索が増える業務データで検討できます。
スキーマ変更、インデックス、クエリ性能、バックアップ・復旧、書き込み集中を確認します。SQLが使えることと、既存の大規模RDBをそのまま置き換えられることは同じではありません。
Workers KVが向くデータ
KVはキーから値を読む単純なアクセスに向き、世界各地から読み取りやすい構成を作れます。機能フラグ、公開設定、ルーティング情報、参照用メタデータ、短いキャッシュなどが候補です。
更新直後にすべての場所で同じ値が必要な用途や、複数キーをまたぐ厳密な取引には向かない場合があります。書き込み後の可視性と競合を理解し、正本データとキャッシュを混同しません。
Durable Objectsが向く状態
Durable Objectsは、特定のIDに対応するインスタンスへ処理を集め、状態と調整を扱います。チャットルーム、共同編集、ゲームルーム、座席予約、レート制御、WebSocket接続など、同じ対象への更新順序が重要な用途で検討できます。
全データを一つのObjectへ集めるとボトルネックになるため、テナント、ルーム、アカウントなど自然な単位でIDを分けます。再起動、アラーム、WebSocket、ストレージ、障害時の再処理も設計します。
複数ストレージを組み合わせる
例えば、アプリ設定と公開フラグをKVへ置き、顧客・注文をD1へ保存し、同時接続中のルーム状態をDurable Objectsで調整し、添付ファイルをR2へ置く構成が考えられます。
役割を分ける場合は、どこが正本か、IDをどう共有するか、更新失敗時にどう整合させるかを決めます。複数サービスへの同時書き込みは途中失敗を想定し、再実行可能な処理にします。
選定前にPoCで確認する
代表的なデータ量と同時実行を用意し、読み取り、書き込み、検索、競合、遅延、失敗、復旧を測ります。平均速度だけでなく、更新直後の見え方と異常時の正しさを確認します。
料金・上限・対応機能は更新されるため、公式ドキュメントで最新条件を確認し、監視指標と出口戦略も設計します。
本番導入で必要な変更管理と評価方法
Cloudflareの設定は通信経路の手前で効くため、小さな変更でも複数ページや外部連携へ影響します。開発・検証環境で再現できるものは先に試し、本番では対象ホスト、パス、利用者、時間帯を限定して段階反映します。変更票には目的、変更前後、実施者、承認者、確認URL、期待結果、切り戻し条件を残します。
確認は「画面が開くか」だけで終えません。HTTPステータス、レスポンスヘッダー、認証、フォームやAPIの完了、オリジンログ、Cloudflareイベントを同じ時刻で照合します。正常系だけでなく、権限なし、期限切れ、過剰アクセス、外部API停止、再送などの異常系も試し、利用者へ返すエラーと運用担当者が見る証拠を分けます。
導入効果は、表示速度やブロック件数など一つの数値だけで評価しません。可用性、正常完了率、オリジン負荷、エラー率、誤検知、サポート問い合わせ、変更作業時間、月額・従量費を導入前後で比較します。性能が上がっても問い合わせやログインの失敗が増えていれば、事業成果としては改善していません。
料金と上限は利用プランや使用量で変わります。無料枠や小規模検証の結果をそのまま本番へ外挿せず、ピーク時のリクエスト、保存・操作、ログ量、利用者数、サポート、監査要件を公式料金ページと契約条件で確認します。上限へ近づいたときの通知と、機能を縮退させる順序も決めます。
設定の所有者と定期レビュー日を決め、不要なルール、トークン、例外、接続先を残しません。Cloudflare画面だけでなく、設定のエクスポート、コード、変更履歴、復旧手順をチームで参照できる場所へ保管します。担当者の退職や委託先変更があっても、誰が承認し、どこまで戻せるか分かる状態を維持します。
公開後は一週間程度の観測期間を設け、導入前と同じ時間帯・同じURL・同じ業務操作で比較します。異常がなくても、例外が増え続けていないか、想定外の回避策が現場で使われていないかを確認します。問題が見つかった場合は、影響を受けた利用者とデータを特定し、暫定回避と恒久修正を分けて記録します。
また、Cloudflare以外の構成要素を含む依存関係図を残します。DNS、レジストラ、オリジン、IdP、メール、外部API、監視、CI/CDのどこで設定が重複し、どこが単一障害点になるかを明示します。障害時に別サービスの担当者へ連絡すべき条件も決めておくと、Cloudflare側だけを調べ続ける時間を減らせます。
本番の設定変更は、可能ならAPIやInfrastructure as Codeで再現可能にし、画面で行った緊急変更も後から正本へ戻します。秘密情報は設定ファイルへ直接書かず、環境ごとのSecret管理へ分離します。手作業とコードの状態がずれると、次回デプロイで緊急修正が消えるため、復旧後の同期までをインシデント対応に含めます。
公開・変更前チェックリスト
- 必要な検索・集計・更新を列挙した
- 更新直後の整合性要件を決めた
- 同じ対象への同時更新を確認した
- 正本とキャッシュを分けた
- 添付ファイルはR2等へ分離した
- バックアップ・復旧・移行方法を確認した
- 代表負荷でPoCを行った
よくある質問
D1はPostgreSQLやMySQLの代わりになりますか？
SQLを使えますが、機能、互換性、スケール、運用は同一ではありません。既存DBが使う機能を具体的に比較します。
KVへ顧客マスタを置いてよいですか？
読み取り用途の複製には使えますが、厳密な更新・検索・取引が必要な正本には慎重な評価が必要です。
Durable Objectsはデータベースですか？
状態保存だけでなく、特定IDへ処理を集めて調整する実行モデルを含みます。同時更新の制御が重要な用途で使います。
一つのアプリで複数を使ってよいですか？
問題ありません。正本、ID、同期、失敗時の再処理を明確にし、用途ごとに選びます。
関連ページと関連記事
仕様確認に使った公式情報
Cloudflareの機能、プラン、上限、画面構成は更新されます。実装時は利用する機能の最新公式ドキュメントも確認してください。
まとめ
Workersアプリの保存先を、データモデル、整合性、アクセスパターン、検索、復旧要件で比較する設計ガイドです。 設定を有効にしただけで完了とせず、正常系・異常系・切り戻しを同じ手順で確認することが、安全な運用につながります。
