Durable Objectsを自分のサーバーで動かせる「celld」

複数台のサーバーで動くチャットアプリを作ると、サーバーごとに参加者リストが食い違うことがある。Cloudflare WorkersのDurable Objectsは、1つの部屋を必ず1つのインスタンスだけに担当させることで、この食い違いを防ぐ仕組みだ。便利そうだとは思いつつ、Cloudflareの中でしか動かないなら手が出しにくい、とも感じていた。

2026年10月9日、その手の届きにくさを変える発表があった。JavaScriptランタイム「Deno」を作ったチームがCloudflareに合流した。Durable Objects互換の仕組みを自分のサーバー群でも動かす取り組みを、本格化させるという(Deno公式ブログ)。鍵を握るのは、同チームが先に公開していたオープンソースソフト「celld」だ。何が自己ホストを阻んでいて、celldがどう解決し、どれだけ頼れるのか。確かめた。

なぜ自己ホストが難しいか

Durable Objectsは、WebSocketの接続やゲームのロビーのように、複数人が同時にアクセスしてもずっと1つの場所で状態を覚えておきたい処理に使う。Denoの作者Ryan Dahl氏は、公式ブログでこれを「分散シングルトン」と呼ぶ。1つのオブジェクトにつき、同時に動くインスタンスは必ず1つだけという約束だ。チャンネルごとに1つのDurable Objectsを割り当てれば、データと接続を自然に分散できるという(Deno公式ブログ)。

この約束は、Cloudflareの中でなら守れる。だが自分のサーバー群で同じことをやろうとすると、「いまどのサーバーがこの部屋を担当しているか」を全員が同じ答えで知る仕組みが要る。Cloudflare自身、この部分の自己ホスト向け実装がうまくいっていなかったと認めている。Workersランタイムの実装workerdは、すでにオープンソース化していた。だがDurable Objects部分は単一インスタンスの実装にとどまり、スケールしなかった。本番で使えるルーティングの実装は自己ホストに向かず、以前の試作も失敗に終わったという(Cloudflare公式ブログ)。

だからこそ、Deno Land社が別につくっていたcelldが注目された。celldは、その担当権をどうやって1つに決めているのか。

担当権をどう決めるか

celldは、Durable Objectsをそのまま自分のサーバーで動かすための、Rust製の単一バイナリだ。各オブジェクトは「セル」と呼ばれ、専用のSQLiteデータベースを持つ。長期的な状態は、自分で用意したオブジェクトストレージのバケットに保存する。対応するのはAmazon S3やGoogle Cloud Storageなどだ(celld公式サイト)。

celldが対応している範囲は、Durable Objectsだけにとどまらない。Cloudflareの開発者向けサービスのほとんどを、ほぼそのまま動かせる(celld公式サイト)。

• 対応(Supported): Workers、Durable Objects、KV、Queues、D1、R2、Workflows、Cron、静的アセット
• 実験的(Experimental): Containers

担当権の決め方が、celldの核心になる。各セルは同時に1台のノードだけが担当する。担当ノードは、オブジェクトストレージへの「条件付き書き込み」でセルの所有権を取得し、更新が一定時間止まると所有権は自動的に期限切れで解放される。リーダーを選ぶ投票も、メンバー一覧を管理する専用サービスも使わない(celld公式ドキュメント)。

担当ノードが落ちると、別のノードが引き継ぐ。その際、停止したノードがまだアップロードしていなかったデータを先に回収してから、担当を再開する(celld公式ドキュメント)。つまり担当権の管理を、サーバー同士の相談ではなく、全員が見られる1つのストレージへの書き込み競争に置き換えたことになる。調整役のサーバーを増やさずに済むのは、このためだ。

この仕組みが実際にどれだけ頼れるのかは、celld自身が公開している障害試験の数字から見えてくる。

10ノードでの障害試験

celldは自前の障害試験の結果を、公式ドキュメントの「Testing」ページで公開している。通常のアプリに近い規模の状態を保ったまま、ノードを意図的に停止させる試験だ(celld公式ドキュメント「Testing」)。

• ノード: 4 vCPU・8GBを10台
• 保持していた状態: 常駐セル10,000個、同時WebSocket接続20,000本
• 停止させた台数: 10台のうち2台
• 全セルが別のノードで利用可能に戻るまでの時間: ピーク時でも約11秒
• 全シナリオの全実行を通じたメッセージ損失: ゼロ

10台中2台を落としても、11秒で全部戻った。

別の試験では、書き込みの途中でノードを強制終了し、ローカルのデータベースも削除して、復旧をオブジェクトストレージからのみ行わせている。ここでも、書き込みの損失は確認されていない(celld公式ドキュメント「Testing」)。

自分は、Cloudflareが「以前の試作は失敗した」と認めていた直後にこの数字を読んだので、もっと控えめな結果を予想していた。実際の数字を見て、話が本当に動いているのだと感じた。ただし、この数値はcelldの開発元自身による計測で、第三者が独立に検証した結果ではない。

では、この仕組みを今日から試すには何が要るのか。

今日から試すには

celldは2026年10月7日公開のv0.6.2が最新で、まだベータ版の段階にある(celld公式GitHubリリース、celld公式サイト)。ライセンスはApache-2.0のオープンソースだ(celld公式GitHubリポジトリ)。

手元で試すだけならcelld devを実行するだけで、クラウドのバケットもDockerも要らない。本番で動かす場合は、celld deploy . --bucket s3://my-cells-bucketでアプリをデプロイする。同じバケットを指定してcelldを起動すればよい。設定は、Cloudflare Workers用のwrangler.jsonをそのまま使える(celld公式サイト)。

ただし、どのオブジェクトストレージでもよいわけではない。条件付き書き込みと書き込み直後の整合性が必要なためで、celld公式ドキュメントは対応状況を次のように整理している(celld公式ドキュメント)。

• 対応: Amazon S3、Cloudflare R2、Google Cloud Storage、Tigris、Azure Blob Storage
• 非対応(API互換性が足りない): Backblaze B2、Hetzner、DigitalOcean Spaces
• 本番向けには未認定: MinIO(コミュニティ版)

Workerプロジェクトのデプロイには、PATH上にesbuildも必要になる(celld公式GitHubリポジトリ)。

celldを生んだDeno Land社自身は、この先どうなるのか。

Denoランタイムの行方

celldを作ったDeno Land社は、2026年10月9日の発表で、開発チーム全体がCloudflareに合流することも明らかにした(Deno公式ブログ)。Denoランタイムは今後1年間、月次でバグ修正とセキュリティ更新を続けたあと開発を終了する。ソースコードはオープンソースのまま残り、引き継いで開発したい人は歓迎するとしている。開発者向けホスティング「Deno Deploy」は6か月間の運用を経て終了し、有料顧客にはCloudflare Workersへの移行支援が提供される。パッケージレジストリの「JSR」は運用を続け、インフラをCloudflareへ移す(Deno公式ブログ)。

終わるのはDenoという単体のランタイムとそのホスティングの方で、celldが実現する自己ホストの話はむしろここから本格化する側にある。Ryan Dahl氏とBert Belder氏が、workerd自体の自己ホストを正式にサポートされた手段にする取り組みを主導する。celldのコードとアイデアを、workerdへ統合する計画だ。詳細は数か月以内に発表予定で、それまではcelldかworkerdを使って今すぐ自己ホストできるとされている(Cloudflare公式ブログ)。

まとめ

Cloudflare WorkersのDurable Objectsは、celldを使えば今日から自分のサーバー群とオブジェクトストレージで動かせる。担当権をオブジェクトストレージへの書き込み競争で決める設計のおかげで、専用の調整サーバーを増やさずに済む。10ノード・10,000セル・20,000WebSocket接続という規模で2台を落としても、約11秒で全セルが復旧した。メッセージ損失はゼロだったという公式の試験結果もある。

celldはまだv0.6.2のベータ版で、対応するオブジェクトストレージも限られる。それでも、Durable Objectsのような状態を持つサーバーレスの書き方を、Cloudflareの外でも試せる選択肢が増えたことに変わりはない。wrangler.jsonがそのまま使えるぶん、すでにCloudflare Workersでアプリを書いている人ほど、試すハードルは低い。