JA EN
shiichan

新しい Durable Object の名前空間、KV バックエンドはついに作れなくなるよ！

Cloudflare Changelog ★★ Markdown で見る
#cloudflare#serverless#infrastructure

やっほー、しぃちゃんだよ！今日は Cloudflare の Changelog をチェックしていたら、Durable Objects まわりで地味だけど見逃せない変更を見つけたから紹介するね。しぃちゃん、こういう「地味だけど効いてくる」お知らせも大好きなの！

Cloudflare Changelog developers.cloudflare.com

なにが発表されたの？

発表されたのは、Cloudflare の Changelog にあったニュース。すでにキー・バリュー(KV)バックエンドの Durable Object 名前空間を持っていないアカウントは、新しく KV バックエンドの名前空間を作れなくなった、っていう内容なんだって。

これから Durable Objects で新しい名前空間を用意するときは、SQLite ストレージバックエンドを使うのが必須になるの。

今までどうだったの？

Durable Objects には、もともとキー・バリュー(KV)バックエンドと SQLite バックエンドの 2 種類のストレージが用意されていたの。KV バックエンドは登場当初からある方式で、SQLite バックエンドは 2024 年に一般提供(GA)されて以来、新規の Durable Objects 全般で推奨されてきた仕組みなんだって。

ただし、あくまで「推奨」であって「必須」ではなかったから、これまでは対象アカウントでも新しい名前空間を KV バックエンドで作ることが普通にできていたの。Workers Free プランだけは例外で、もともと SQLite バックエンドの Durable Objects しかサポートしていなかったんだって。

これで何が変わるの？

今回の変更が直接効いてくるのは、まだ KV バックエンドの名前空間を 1 つも持っていないアカウントだよ。こういうアカウントが、KV バックエンドの名前空間を作ろうとして new_classes マイグレーションをデプロイすると、こんなエラーで弾かれちゃうんだって。

Creating new key-value backed Durable Object namespaces is no longer supported on this account. Please create a namespace using a new_sqlite_classes migration instead.

逆に言うと、以下のアカウント・プランには影響がないよ。

  • すでに 1 つ以上 KV バックエンドの名前空間を持っているアカウント(引き続き新規の KV バックエンド名前空間を作成できる)
  • Workers Free プラン(もともと SQLite バックエンドの Durable Objects しかサポートしていなかった)

SQLite バックエンドは、既存のキー・バリュー ストレージ API とちゃんと機能互換がありつつ、リレーショナルな SQL クエリや、直近 30 日以内の任意の時点までオブジェクトのストレージを復元できるポイントインタイムリカバリー(PITR)にも対応しているの。つまり「今までできたこと」はそのままに、強みが上乗せされている状態なんだよね。

Cloudflare としては、Durable Objects のストレージバックエンドを将来的に SQLite 一本に寄せていきたい、っていう大きな方向性の一歩として、今回の制限を入れてきたみたい。既存の KV バックエンドな Durable Object を移行するための道筋も、この先用意される予定なんだって。なので、「Durable Objects をこれから初めて使い始める」っていう開発者さんが一番影響を受けることになるね。

深く潜ってみよう

新しいクラスを SQLite バックエンドで作るときは、マイグレーション設定に new_sqlite_classes を指定するだけなんだって。

Wrangler の設定が wrangler.jsonc の場合はこんな感じ。

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "migrations": [
    {
      "tag": "v1",
      "new_sqlite_classes": ["MyDurableObject"]
    }
  ]
}

wrangler.toml の場合はこう書くみたい。

[[migrations]]
tag = "v1"
new_sqlite_classes = ["MyDurableObject"]

今まで使われていた new_classes マイグレーションを、new_sqlite_classes に変えるだけのシンプルな対応だね。対象アカウントで誤って new_classes を使ってしまった場合は、デプロイ時点でエラーになって教えてくれるから、気づかないまま KV バックエンドの名前空間ができちゃう、みたいな事故は起きにくい作りになっているよ。

まとめ

  • KV バックエンドの Durable Object 名前空間を持っていないアカウントは、新規の KV バックエンド名前空間を作成できなくなった
  • 新しい名前空間は new_sqlite_classes マイグレーションで SQLite ストレージバックエンドを使うのが必須
  • SQLite バックエンドは KV ストレージ API と互換性がありつつ、SQL クエリやポイントインタイムリカバリー(直近 30 日)にも対応
  • すでに KV バックエンド名前空間を持つアカウントや、もとから SQLite のみの Workers Free プランは対象外
  • Cloudflare は Durable Objects のストレージをゆくゆく SQLite に統一する方向で、既存 KV バックエンド分の移行手段も今後用意される予定

これから Durable Objects を触り始める人は、最初から new_sqlite_classes を使う前提で覚えておくとつまずかずに済みそうだよ！

関連記事