Edge データストア

Edge Computing における最大の技術的課題: データの配置と一貫性。「データをユーザーに近づけるほどレイテンシは下がるが、一貫性の維持コストが上がる」というジレンマが全ての設計判断の根底にある。

CAP 定理と Edge

Edge 環境はネットワーク分断が常態であるため P (分断耐性) は必須。設計上の選択肢は CP か AP の二択。

graph TD
    CAP["CAP 定理"] --> CP["CP (一貫性 + 分断耐性)<br/>書き込みレイテンシは上がるが<br/>常に最新値を返す"]
    CAP --> AP["AP (可用性 + 分断耐性)<br/>低レイテンシ・高可用性だが<br/>stale な値を返しうる"]
    CP --> DO["Durable Objects<br/>single-point-of-coordination"]
    AP --> KV["Workers KV<br/>eventually consistent"]
Strong Consistency (CP)Eventual Consistency (AP)
保証常に最新値を返す時間経過で収束。stale な値を返しうる
レイテンシ高い (合意に時間)低い (ローカルレプリカから即応答)
適用例決済、排他ロック、在庫確認設定情報、カウンター、CDN キャッシュ

KV ストア

Workers KV

グローバル分散 KV ストア。読み取り特化 (global read, regional write)。3層キャッシュ構造。

項目値
一貫性Eventually consistent (~60秒で伝播)
キーサイズ最大 512 bytes
値サイズ最大 25 MiB
同一キー書き込み1回/秒
名前空間アカウントあたり 1,000

料金 (Paid): 読み取り 10M/月含む ($0.50/M 超過)、書き込み 1M/月含む ($5.00/M 超過)、ストレージ 1GB 含む ($0.50/GB)。

ユースケース: 更新頻度が低い読み取り主体のデータ。設定情報、feature flags、i18n、URL リダイレクトマップ。

Deno KV

FoundationDB 上に構築。デフォルトで strongly consistent (プライマリ内で linearizable)。ACID トランザクション対応。

項目値
一貫性Strong (選択的に eventual も可)
キーサイズ最大 2 KiB
値サイズ最大 64 KiB
トランザクションACID (strict serializability)

KV 比較

特性Workers KVDeno KVFastly KV
一貫性Eventual (~60秒)StrongEventual
トランザクションなしACIDなし
値サイズ上限25 MiB64 KiB25 MB
強みグローバル読み取り、大きな値強一貫性、トランザクション大規模リスト

Durable Objects

Edge での最大の革新の一つ。「グローバルに一意なオブジェクト ID に対して、必ず単一のインスタンスが存在する」という保証で、分散合意プロトコル不要の強い一貫性を実現。

アーキテクチャ

graph LR
    A["Client A"] -->|WebSocket| DO["Durable Object<br/>(単一インスタンス)<br/>インメモリ調整"]
    B["Client B"] -->|WebSocket| DO
    C["Client C"] -->|WebSocket| DO
    DO --> SQLite["SQLite Storage<br/>10GB/オブジェクト<br/>5x フォロワーレプリケーション"]

SQLite バックエンド (2025年4月 GA)

Hibernation API

WebSocket 接続を維持したまま DO をスリープ。スリープ中は duration 課金なし。メッセージ到着で自動ウェイクアップ。まばらなメッセージングで劇的なコスト削減。

DO の本質

CRDT が「全ノードで独立に書き込み、後で収束」なら、DO は「全員が一箇所に集まることで競合を発生させない」。分散合意の複雑さを回避する single-point-of-coordination アプローチ。

料金

項目Paid (含む分)超過
リクエスト100万/月$0.15/百万
Duration400K GB-s/月$12.50/百万 GB-s
SQLite 読み取り250億行/月$0.001/百万
SQLite 書き込み5,000万行/月$1.00/百万
SQLite ストレージ5 GB$0.20/GB-月

制限

Edge Database

Cloudflare D1

SQLite ベースの Edge DB。Durable Objects 上に構築。

Global Read Replication (2025年4月ベータ): 全リージョンに自動リードレプリカ。Session ベースの sequential consistency で “read-your-own-writes” を保証。追加料金なし。

項目FreePaid
読み取り500万行/日250億行/月 ($0.001/M 超過)
書き込み10万行/日5,000万行/月 ($1.00/M 超過)
DB サイズ500 MB10 GB
DB 数1050,000

Time Travel: 過去 30日 (Paid) / 7日 (Free) の任意の時点に復元可能。

Turso (libSQL)

SQLite フォーク。ローカルファースト設計。

Neon (Serverless Postgres)

ストレージとコンピュートの分離。2025年5月に Databricks が約10億ドルで買収。

Edge DB 比較

特性D1TursoNeon
エンジンSQLitelibSQL (SQLite fork)PostgreSQL
Edge 読み取り自動 Read ReplicationEmbedded Replicas / SyncHTTP/WS ドライバー (データは Edge にない)
一貫性Sequential (Session)Eventual (sync)Strong (プライマリ)
ブランチングなしなしあり (O(1) CoW)
最大 DB サイズ10 GBプラン依存大容量対応
SQL 機能SQLite SQLSQLite SQL + 拡張完全な PostgreSQL
強みCF エコシステム統合、無料 Read Replicationローカルファースト、オフラインフル Postgres、ブランチング

Cloudflare R2

S3 互換オブジェクトストレージ。エグレス完全無料。

比較S3 エグレスR2 エグレス
10TB/月~$891$0

ストレージ $0.015/GB-月。Workers から直接アクセス (同一ネットワーク内で転送コストゼロ)。メディア配信、データレイク、マルチクラウドアーキテクチャに最適。

Cloudflare Queues

Edge ネイティブなメッセージキュー。Workers と直接統合。

Producer (Worker) → Queue → Consumer (Worker) のパイプライン。料金: 100万 ops/月含む、超過 $0.40/M。

用途: 非同期処理の Edge 化、バースト吸収、オリジンへのバッチ書き込み、イベント駆動アーキテクチャ。

CRDT (Conflict-free Replicated Data Types)

全レプリカが独立に書き込み可能で、アルゴリズム的に自動収束するデータ構造。中央コーディネーター不要。

データ型動作ユースケース
G-Counter各レプリカのカウントの max の和ビューカウント、いいね数
PN-Counter増加用 + 減少用の G-Counter ペア在庫数、リソースプール
LWW-Registerタイムスタンプが大きい値が勝つプロファイル、設定値
OR-Set要素にユニークタグ、同時追加は生存ショッピングカート、協調編集

DO vs CRDT: DO は「全員が一箇所に集まる」(single-point)。CRDT は「全員がバラバラに動いて後で合流する」(multi-writer)。

主要ライブラリ: Yjs (テキスト協調)、Automerge (JSON CRDT)、crdt-kit (Edge / リソース制約向け)。

採用事例: Figma (マルチプレイヤー)、Linear (オフライン同期)、Apple Notes (クロスデバイス)。

Edge データの設計パターン

Read-Heavy (KV + キャッシュ)

graph LR
    User["ユーザー"] --> Edge{"Edge キャッシュ"}
    Edge -->|Hit| Resp1["即応答 < 10ms"]
    Edge -->|Miss| KV["Workers KV"] --> Resp2["応答 + キャッシュ格納"]

適用: 商品カタログ、ブログ、i18n、A/B テスト設定。

Write-Heavy (Durable Objects)

全クライアントが同一 DO インスタンスに接続。インメモリで調整、非同期永続化。

適用: リアルタイムチャット、協調編集、ゲームセッション。

Edge-Origin ハイブリッド

graph TB
    subgraph Edge["Edge 層"]
        Auth["認証 (ステートレス)"]
        Session["セッション (KV)"]
        RT["リアルタイム (DO)"]
        Assets["静的アセット (R2)"]
        Async["非同期 (Queues)"]
    end
    subgraph Origin["Origin 層"]
        TX["トランザクション (Neon/RDB)"]
        Pay["決済 (strong consistency)"]
        Analytics["複雑なクエリ / 分析"]
    end
    Edge --> Origin

設計原則: 全てを Edge に移すのではなく、地理的分散の恩恵を受けるレイヤーを特定し、そのレイヤーが Origin から独立して動作できるよう構造化する。

選択フローチャート

graph TD
    Q["データの性質は?"]
    Q -->|"読み取り主体、stale 許容"| KV["Workers KV"]
    Q -->|"読み取り主体、SQL 必要"| D1["D1 + Read Replication"]
    Q -->|"強い一貫性、特定エンティティへの書き込み集中"| DO["Durable Objects"]
    Q -->|"オフラインファースト"| Turso["Turso Sync / CRDT"]
    Q -->|"フル SQL (JOIN, 複雑クエリ)"| Neon["Neon (HTTP/WS 経由)"]
    Q -->|"大きなバイナリデータ配信"| R2["R2 (エグレス無料)"]
    Q -->|"非同期処理 / バッチ化"| Queues["Queues"]

押さえどころ(カード化候補)

関連

Graph