コンテナー データの復旧

このシナリオでは、データ復旧について説明します。 コンテナーが無効な状態に達し、それ以上のユーザー アクションを処理できない場合、データが破損していると見なします。 破損した状態の結果は、コンテナーが予期せず閉じられている状態です。 多くの場合、一時的な状態であり、再度開くと、コンテナーが期待どおりに動作する場合があります。 複数回の再試行の後でもコンテナーの読み込みに失敗する状況では、以下で説明するように、データの復旧に使用できる API とフローを提供しています。

Fluid Framework と Azure Fluid Relay での状態の保存方法

流動フレームワーク、コンテナー内のデータのスナップショットを定期的に保存します。これにより、その時点までのデータに加えられたすべての変更が要約されます。 通常の読み込み中に最新のスナップショットが取得され、その状態の上に後続の変更が適用されます。

最新のスナップショットまたはその後の変更が破損している場合、Fluid は通常どおりに読み込むことができない可能性があります。 この場合、Fluid には、保存されているスナップショット バージョンを表示し、それ以降の変更を適用しないビュー専用モードで読み込む API のコレクションが用意されています。 これにより、データを抽出し、必要に応じて新しいコンテナーに挿入してコラボレーションを再開できます。

Azure クライアント API

コンテナー バージョンを表示および読み込むための API

AzureClient には、このシナリオをサポートするための次の方法があります。

コンテナーのバージョンを取得する

getContainerVersions(id, options?)

読み込み元の使用可能なバージョンの一覧を取得します。

Parameters:

• id: コンテナー ID。 これは、 getContainerを呼び出すときに使用されるのと同じ ID です。
• options?: 必要に応じて、指定する options オブジェクト。
  • maxCount: 取得するバージョンの最大数。 使用できるバージョンが要求よりも多い場合は、最新のバージョンが取得されます。 既定:5

Returns: 使用可能なバージョンを表すオブジェクトの配列に解決される promise (最新から最も古いものに並べ替えられます)。 オブジェクトには、次のプロパティがあります。

• id: バージョン ID。
  • 注: これはコンテナー ID とは異なり、具体的にはコンテナーではなくスナップショット バージョンを参照します。
• date: バージョンが生成されたときのタイムスタンプ。

コンテナー バージョンの表示

viewContainerVersion(id, containerSchema, version, compatibilityMode)

表示専用のコンテナーの特定のバージョンを読み込みます。 getContainerVersionsから取得したバージョンはすべて使用できますが、破損したデータを回復する目的で、最新のバージョンから始めて、最新の修正されていないバージョンを見つけるために戻って作業することをお勧めします。

コンテナーは一時停止状態で読み込まれます。つまり、そのスナップショットの生成後に発生したデータに後続の変更は適用されません。 この状態で読み込まれると、コンテナー データは読み取られる可能性がありますが、編集することはできません。

Parameters:

• id: コンテナー ID。 これは、 getContainerを呼び出すときに使用されるのと同じ ID です。
• containerSchema: コンテナー スキーマ。 これは、 getContainerを呼び出すときに使用されるスキーマと同じです。
• version: 読み込み元のバージョンを参照する version オブジェクト。 バージョン オブジェクトは、 getContainerVersionsを使用して取得できます。
• compatibilityMode: 互換モード。 これは、 getContainerを呼び出すときに使用されるのと同じ互換モードです。

Returns: 1 つのプロパティを持つ読み込まれたコンテナーを表すオブジェクトに解決される promise:

• container: コンテナー オブジェクト。 これは、 getContainerによって返されるコンテナー オブジェクトと同じ種類のオブジェクトですが、選択したバージョンから以前の状態で一時停止されます。

例

const azureClient = new AzureClient(/* ... */);
const versions = await azureClient.getContainerVersions(id);
// Since the versions are sorted in order from newest to oldest, versions[0] will attempt to load the most recent version.
// If the most recent version is corrupted, we could try again with versions[1] and so on to find the most-recent uncorrupted version.
const { container } = await azureClient.viewContainerVersion(id, containerSchema, versions[0], "2");

// We can now start reading the data from the container.
const someData = container.initialObjects.someSharedMap.get("hello");

// With the data extracted, we can inject it into a new uncorrupted container and attach it to start collaborating again.
const { container: newContainer } = await azureClient.createContainer(containerSchema, "2");
newContainer.initialObjects.someSharedMap.set("hello", someData);
const newId = await newContainer.attach();

主な見解

新しいコンテナーを作成する

既存のコンテナーを復旧 (ロールバック) していません。 copyContainer は、元のコンテナーからデータがコピーされる新しいインスタンスを提供します。 このプロセスでは、古いコンテナーは削除されません。

新しいコンテナーがデタッチされます

新しいコンテナーは、最初は detached 状態です。 デタッチされたコンテナーの操作を続行することも、すぐにアタッチすることもできます。 attach を呼び出した後、新しく作成されたインスタンスを表す一意のコンテナー ID が返されます。

復旧後の考慮事項

復旧後のシナリオに関するユース ケースの構築について、リモート コラボレーター全員が同じコンテナーで再び作業できるようにするためにアプリケーションで行えることに関するいくつかの考慮事項を次に示します。

流体コンテナーのみを使用してアプリケーション データをモデル化している場合、コンテナーが破損すると、通信 "リンク" が効果的に切断されます。 実際の例と同様に、元の作成者が参加者とリンクを共有し、そのリンクが機能しなくなったビデオ通話があります。 その点に留意して、1 つのオプションとして、復旧アクセス許可を元の作成者に制限し、元のコンテナーのコピーを復旧した後に、元のリンクを共有したのと同じ方法で新しいコンテナー リンクを共有できるようにすることが考えられます。

または、一時的なデータのみに流体フレームワークを使用している場合は、独自の信頼できるソース データとサポート サービスを常に使用して、より自律的な復旧ワークフローを管理できます。 たとえば、アプリで最初の復旧されたコピーが作成されるまで、複数のクライアントで復旧プロセスを開始できます。 その後、アプリは、参加しているすべてのクライアントに新しいコンテナーに移行するように通知できます。 これは、現在アクティブな任意のクライアントで参加しているグループのブロックを解除してコラボレーションを再開できるため便利です。 ここでの考慮事項の 1 つとして、冗長化によってコストが生じることが挙げられます。