Durable Objects との併用

グローバル一意性 を保つため、各 Durable Object は同時に 1 バージョンだけが動作します。そのため、Durable Objects では段階的デプロイの動きが少し異なります。

Durable Objects を使う Worker に新しい段階的デプロイを作ると、各 Durable Object には、デプロイ で設定した割合に基づいて Worker バージョンが割り当てられます。このバージョンは、新しいデプロイを作るまで変わりません。

この例では、名前が "foo"、"bar"、"baz" の Durable Object インスタンスを 3 つ、すでに作成しているとします。

Worker はいまバージョン "A" で動いており、新しいバージョン "B" を段階的にデプロイします。

段階的デプロイを進めると、Durable Objects のバージョンは次のように変わることがあります。

これは一例なので、実際に割り当てられるバージョンは異なる場合があります。ただし、次のことは保証されます。

• あるデプロイでは、各 Durable Object へのリクエストは常に同じ Worker バージョンを使います。
• 各バージョンを前回のデプロイと同じ順で指定し、あるバージョンの割合を上げた場合、以前そのバージョンが割り当てられていた Durable Object に別のバージョンは割り当てられません。この例では、Durable Object "foo" がバージョン "B" からバージョン "A" へ戻ることはありません。
• Durable Object が リセット されるのは、別のバージョンが割り当てられたときだけです。そのため、この例では各 Durable Object のリセットは 1 回だけです。

Durable Object クラスのライフサイクルを変える Worker バンドルのバージョンはアップロードできません。宣言的な exports フィールドと、レガシーな migrations 配列の両方に当てはまります。ライフサイクル変更はアトミックな操作だからです。一度デプロイすると、その変更を含むバージョンより前のバージョンへはロールバックできません。

Durable Object のライフサイクル変更は、次のコマンドでデプロイできます。

npx wrangler deploy

yarn wrangler deploy

pnpm wrangler deploy

こうしたデプロイの影響範囲を抑えるため、Durable Object のライフサイクル変更は、ほかのコード変更とは分けてデプロイしてください。

ライフサイクル変更がアトミックである理由は、クラス削除を段階的にデプロイする仮想例で分かります。削除を Durable Object インスタンスの 50% に適用すると、削除済みのインスタンスを要求する Worker は失敗します。

エラーを出さずに行うには、削除対象の Durable Objects に依存しない Worker バージョンを、あらかじめロールアウトしておく必要があります。そのうえでクラス削除をデプロイすればトラフィックに影響しません。段階的に行う理由もありません。