すべての Durable Object でゼロレイテンシの SQLite ストレージ

 (simonwillison.net)
2 ポイント 投稿者 GN⁺ 2024-10-15 | 1件のコメント | WhatsAppで共有

  • Zero-latency SQLite storage in every Durable Object

    • Kenton Varda は、Cloudflare の Durable Object プラットフォームの次世代版を紹介している。このプラットフォームは最近、キー/バリューストアから SQLite ベースの完全なリレーショナルシステムへとアップグレードされた
    • Durable Objects の最初のバージョンについての有用な背景情報として、Paul Butler による Cloudflare の durable multiplayer moat を参照できる。これは WebSocket ベースのリアルタイム協調アプリケーションの構築で人気がある
    • 新しい SQLite ベースの Durable Objects は、大規模アプリケーションを設計するための興味深い方法を提案する、分散システム設計の魅力的な要素である

  • Durable Objects の中核アイデア

    • Durable Object は、データとアプリケーションロジックを同じ物理ホスト上に配置することで、非常に高速な読み書き性能を提供する
    • 単一のオブジェクトは単一マシンの単一スレッドで実行されるため、スループットには制限がある。より多くのトラフィックを処理するには、より多くのオブジェクトを作成する。各状態単位のトラフィックが単一オブジェクトで処理できるほど低い場合に最も容易である

  • 航空便予約システムの例

    • 各フライトは、独自の SQLite データベースを持つ専用 Durable Object にマッピングできる。航空会社ごとに毎日数千個の新しいデータベースが作成される
    • 各 DO は一意の名前を持ち、Cloudflare のネットワークは、そのオブジェクトが世界のどこにあってもリクエストをルーティングする

  • 技術的詳細

    • Litestream に着想を得て、各 DO は WAL エントリのシーケンスをオブジェクトストアへ継続的にストリーミングする。これは 16MB ごと、または 10 秒ごとにバッチ処理される
    • 10 秒のウィンドウ内で耐久性を保証するため、書き込みはコミットされるとすぐに近隣データセンターの 5 つのレプリカへ送られ、3 つが確認するとその書き込みが承認される

  • JavaScript API デザイン

    • 非同期ではなくブロッキング方式で設計されている。これは高速な単一スレッドの永続化処理を提供するためである
    • SQLite がうまく処理できる N+1 クエリパターンを意図的に示した例を含んでいる

  • Storage Relay Service

    • Durable Objects の基盤システムであり、Cloudflare の既存の D1 SQLite システムを 1 年以上にわたって支えてきた

  • Durable Objects の生成場所

    • Durable Objects は作成後に場所を変更しない。デフォルトでは、最初の get() リクエストが行われたデータセンターでインスタンス化される
    • 別の場所で Durable Objects を手動で作成するには、get() にオプションの locationHint パラメータを指定する

  • where.durableobjects.live サイト

    • Cloudflare ネットワーク上で DO が生成される場所を追跡するサイトである

GN⁺の要約

  • Cloudflare の Durable Objects は SQLite を基盤としており、大規模アプリケーション設計に新たな可能性を提示する。データとアプリケーションロジックを同じ物理ホストに配置することで高速な性能を提供する
  • このシステムは特にリアルタイム協調アプリケーションに有用で、さまざまな状態単位を処理できる柔軟性を提供する
  • Durable Objects はデータの耐久性を保証するために複数のデータセンターにレプリカを作成し、安定性と信頼性を高めている
  • この技術は大規模分散システム設計に関心のある開発者にとって興味深い可能性がある。類似機能を提供するシステムとしては Amazon の DynamoDB や Google の Firestore がある

関連記事

1件のコメント

 
GN⁺ 2024-10-15
Hacker Newsの意見

  • 書き込みAPIは同期式だが、隠れた非同期待機の仕組みがある。書き込みが失敗した場合、ランタイムが応答をHTTPエラーに置き換えるため、自動的に書き込みをバッチ処理し、成功を前提にできる

    • 読み取りトランザクションがないため、特定時点のスナップショットを取得しにくい
    • 各ランタイムインスタンスは128MB RAMに制限されている
    • WebSocketsは休止状態にでき、この間はコストが発生しない。これにより、DOがスリープしている間もクライアントは接続を維持できる
    • 自動RPC機能があり、他のDOやWorkerと通常のJS呼び出しのように通信できる。ランタイムがシリアライズとパースを処理する

  • 各DOはWALエントリのシーケンスをオブジェクトストレージにストリーミングし、これは16MBごと、または10秒ごとにバッチ処理される

    • グローバルには、書き込みが読み取りに反映されるまで10秒かかる可能性がある
    • 地理的に分散配置されたデータベースクラスタの代替にはしにくい

  • Durable Objectの設計は気に入っている。内部の動作を理解しやすい

    • DOは高速かつ低コストなリアルタイム体験の構築には向いているが、分析や集計は難しい
    • SQLiteにデータを入れると、多数の小さなSQLiteインスタンスをクエリし、結果をマージする必要がある

  • Durable Objectsの物理的な配置場所を理解しにくい

    • API呼び出しが発生した地域に配置されるのか気になる
    • DOが自動的に別の場所へ移動できるのか気になる

  • 新しいクラウド技術を理解するのは難しい

    • 15年以上のWeb開発経験があるが、こうした技術は自分には合わないと感じる

  • スキーママイグレーションをどう処理するのか気になる

    • データベースがテナントごとに存在する場合、スキーマ変更を各DOに適用するのは難しい

  • DOの設計は興味深いが、高負荷システムかおもちゃのプロジェクトにしか向かないと思う

    • 実務では実証済みのシステムが必要であり、DOはまだ成熟していない

  • DOの設計に感銘を受けた。複雑な作業を小さなスケールで処理する方法が、実際のプロダクト構造に似ていると思う

  • CFが開発者にDOの使用を勧めている点に注目している

    • WorkerのWebSocket接続は30秒後にタイムアウトし、DOの使用が推奨される

  • DOがMVCアーキテクチャの「モデル」に相当するのか気になる

    • DOをテナントごとに使い、すべてのDOをクエリしたり結合したりする方法が気になる