컨테이너 데이터 복구

이 시나리오에서는 데이터 복구를 살펴봅합니다. 컨테이너가 추가 사용자 작업을 처리할 수 없는 잘못된 상태에 도달하면 데이터가 손상된 것으로 간주합니다. 손상된 상태의 결과는 컨테이너가 예기치 않게 닫히는 것입니다. 일시적인 상태인 경우가 많으며 다시 열면 컨테이너가 예상대로 동작할 수 있습니다. 여러 번의 재시도 후에도 컨테이너가 로드되지 않는 상황에서는 아래 설명된 대로 데이터를 복구하는 데 사용할 수 있는 API 및 흐름을 제공합니다.

Fluid Framework 및 Azure Fluid Relay가 상태를 저장하는 방법

Fluid 프레임워크는 사용자가 시작한 명시적 백업 작업 없이 요약이라는 상태를 주기적으로 저장합니다. 이 워크플로는 사용자 활동이 없는 경우 1분마다 발생하거나 보류 중인 작업이 1000개를 초과하는 경우 더 빨리 발생합니다. 보류 중인 각 작업은 대략적으로 아직 요약되지 않은 개별 사용자 작업(선택, 텍스트 입력 등)으로 변환됩니다.

Azure 클라이언트 API

개발자가 손상된 컨테이너에서 데이터를 복구할 수 있도록 AzureClient에 다음 메서드를 추가했습니다.

getContainerVersions(ID, options)

getContainerVersions를 통해 개발자는 이전에 생성된 컨테이너 버전을 볼 수 있습니다.

copyContainer(ID, containerSchema)

copyContainer를 통해 개발자는 다른 컨테이너의 특정 버전에서 새 분리된 컨테이너를 생성할 수 있습니다.

예제 복구 흐름

async function recoverDoc(
    client: AzureClient,
    orgContainerId: string,
    containerScema: ContainerSchema,
): Promise<string> {
    /* Collect doc versions */
    let versions: AzureContainerVersion[] = [];
    try {
        versions = await client.getContainerVersions(orgContainerId);
    } catch (e) {
        return Promise.reject(new Error("Unable to get container versions."));
    }

    for (const version of versions) {
        /* Versions are returned in chronological order.
        Attempt to copy doc from next available version */
        try {
            const { container: newContainer } = await client.copyContainer(
                orgContainerId,
                containerSchema,
                version,
            );
            return await newContainer.attach();
        } catch (e) {
            // Error. Keep going.
        }
    }

    return Promise.reject(new Error("Could not recreate document"));
}

주요 관찰

새 컨테이너를 만드는 중입니다.

기존 컨테이너를 복구(롤백)하지 않습니다. copyContainer는 원본 컨테이너에서 데이터가 복사되는 새 인스턴스를 제공합니다. 이 프로세스에서는 이전 컨테이너가 삭제되지 않습니다.

새 컨테이너가 분리됨

새 컨테이너는 처음에 detached 상태입니다. 분리된 컨테이너로 계속 작업하거나 즉시 연결할 수 있습니다. attach를 호출한 후 새로 만든 인스턴스를 나타내는 고유한 컨테이너 ID를 다시 가져옵니다.

복구 후 고려 사항

복구 후 시나리오를 중심으로 사용 사례를 빌드할 때 원격 협력자가 모두 동일한 컨테이너에서 다시 작업하도록 하기 위해 애플리케이션에서 수행할 수 있는 몇 가지 고려 사항은 다음과 같습니다.

유동 컨테이너만 사용하여 애플리케이션 데이터를 모델링하는 경우 컨테이너가 손상되면 통신 "링크"가 효과적으로 손상됩니다. 비슷한 실제 예제는 원래 작성자가 참가자와 링크를 공유하고 해당 링크가 더 이상 작동하지 않는 화상 통화일 수 있습니다. 이러한 관점에서 원래 컨테이너의 복사본을 복구한 후 복구 권한을 원래 작성자로 제한하고 원래 링크를 공유한 것과 동일한 방식으로 새 컨테이너 링크를 공유할 수 있도록 하는 옵션이 있습니다.

또는 일시적인 데이터에만 유동 프레임워크를 사용하는 경우 항상 고유한 원본 데이터 및 지원 서비스를 사용하여 보다 자율적인 복구 워크플로를 관리할 수 있습니다. 예를 들어 여러 클라이언트가 앱에 처음 복구된 복사본이 있을 때까지 복구 프로세스를 시작할 수 있습니다. 그러면 앱이 참여하는 모든 클라이언트에게 새 컨테이너로 전환하도록 알릴 수 있습니다. 이는 현재 활성 클라이언트가 참여 그룹의 차단을 해제하여 협업을 진행할 수 있으므로 유용할 수 있습니다. 여기서 고려해야 할 한 가지 고려 사항은 중복으로 인해 발생하는 비용입니다.