Denoが放つ「celld」：分散システムを再定義するセルフホスト型Durable Objectsの衝撃

我々エンジニアがクラウドネイティブな開発において最も頭を悩ませるのは、特定のプラットフォームに対する「ベンダーロックイン」という名の見えない鎖だ。特にCloudflare WorkersのDurable Objectsのような強力なステートフル・コンピューティング環境は、一度そのエコシステムに足を踏み入れると、他のインフラへの移行は極めて困難になる。そんな中、Deno Landがオープンソースとして公開した「celld」は、この状況を根本から覆そうとする野心的な試みである。celldは、Cloudflare WorkersとDurable Objectsの実行環境を、自前のインフラ上でセルフホスト可能にする分散デーモンだ。

celldの設計において最も特筆すべきは、その「極端なまでのシンプルさ」にある。一般的な分散システムが抱える「コントロールプレーンの複雑さ」や「コンセンサスアルゴリズム（RaftやPaxosなど）の運用負荷」を、celldは一切排除した。代わりに採用したのは、S3互換のオブジェクトストレージを唯一の真実のソース（Source of Truth）とするアプローチだ。各オブジェクトは個別のSQLiteデータベースとして管理され、ノード間での調整はすべてS3バケットを介して行われる。これは、複雑な分散合意プロトコルを実装する代わりに、ストレージの「Compare-and-Swap（CAS）」というプリミティブな機能に依存することで、ノードのステートレス性を担保するという、極めてエンジニアリング的な割り切りである。我々が深夜の障害対応で頭を抱える原因の多くは、分散システムにおける「合意形成の不整合」や「ネットワークパーティション時の挙動」にあるが、celldはそもそもそれらを発生させないアーキテクチャを選択している。

また、celldは「アプリケーションのシャーディング」を設計レベルで強制する。各オブジェクトが独立したSQLiteデータベースであるため、特定の巨大なデータベースがボトルネックになることはない。これは、モノリシックなデータベースを抱えてデッドロックやクエリの遅延に苦しむ現場のエンジニアにとって、非常に魅力的な解決策だ。アイドル状態のセルは自動的にハイバネーション（休止）し、リソース消費を最小限に抑える。この「必要な時に必要な分だけリソースを確保する」という設計は、クラウドのコスト最適化を突き詰めた結果と言えるだろう。

celldを実際に運用する際、我々が直面するのは「インフラの責任範囲」の再定義だ。celldは、Dockerコンテナとしてデプロイ可能であり、Linux x86-64およびARM64環境をサポートしている。運用者は、S3互換のバケット（Cloudflare R2やAWS S3など）を用意し、各ノードに環境変数を渡すだけでクラスタを構築できる。特筆すべきは、その診断機能だ。celld diagnoseコマンドを実行することで、各ノードのリース状況、CPU使用率、メモリ（RSS）、ファイルディスクリプタ、さらには圧力（Pressure）状況までを詳細に可視化できる。これは、ブラックボックス化しがちなマネージドサービスとは対照的であり、エンジニアが「何が起きているか」を完全に把握できる透明性を備えている。

運用上の重要なパラメータとして、以下の設定が挙げられる。これらは、システムの安定稼働を左右する重要なチューニング項目である。

しかし、この自由度には代償がある。celldはTLS終端を行わない。つまり、ノード間の通信は信頼できるプライベートネットワーク内で行うか、WireGuardやTailscaleのような暗号化オーバーレイネットワークを構築することが必須となる。これは、マネージドサービスが提供する「安全なデフォルト」を、自ら構築しなければならないことを意味する。また、デプロイにはesbuildが必要であり、Wranglerの構成を一部サポートする形をとっている。この「セルフホストの自由」と「セキュリティ運用の責任」のバランスをどう取るか。これは、DevOpsのスキルセットが問われる部分であり、単にツールを導入すれば解決する問題ではない。

celldの登場は、我々に一つの重要な問いを突きつけている。「我々は本当に、巨大なクラウドベンダーの管理下に置かれたブラックボックスを使い続ける必要があるのか？」という問いだ。celldは、特定の企業に依存せず、オープンなプロトコルと標準的なストレージさえあれば、高度な分散コンピューティング環境を自前で構築できることを証明した。これは、技術の民主化という側面において非常に大きな一歩である。しかし、同時に我々は「運用の複雑さ」という代償を支払う覚悟があるのかという点も考えなければならない。

明日から我々が取るべき実践的な対策は、まず「ステートフルなアプリケーションの設計」を再考することだ。celldのようなアーキテクチャを前提とするならば、アプリケーションを小さな単位（セル）に分割し、それらが独立して動作するように設計するスキルがこれまで以上に求められる。また、インフラのコード化（IaC）だけでなく、インフラの「可観測性（Observability）」を自前で担保する能力も不可欠だ。celldのソースコードを読み込み、プロトコルを理解し、必要であれば自らパッチを当てる。そんな「エンジニアとしての原点」に立ち返ることが、これからの分散システム時代を生き抜くための唯一の処方箋ではないだろうか。

最後に、読者諸君に問いたい。あなたが今構築しているシステムは、ベンダーのAPIが明日停止したとしても、自力で復旧させることができるだろうか？celldのようなツールを使いこなすことは、単なる技術的選択ではなく、エンジニアとしての「技術的自立」を勝ち取るための闘いである。このツールを単なる「便利なライブラリ」として消費するのか、それとも「インフラを支配するための武器」として使いこなすのか。その選択は、あなた自身のキャリアの方向性を決定づけることになるだろう。