복제 캐시 큰 그림

Replicache

Local First Software 를 구현하는 데 도움을 주는 프레임워크이다. Git가 유사하게 push, pull 을 통해서 싱크를 맞추는 작업을 구성하는데 도움을 준다.

Replicache 는 서버 데이터의 동기화를 뒤에서 비동기적으로 수행하여 Server의 Round trip을 없애고 즉각적인 UI변경을 가능하게 한다.

Replicache Parts

Replicache는 여러개의 요소로 구성된다.

Replicache

Replicache는 내부에 git 같은 동작을 포함하는 In browser Key-Value 스토어라고 볼 수 있다. 메모리에 먼저쓰고 나중에 동기화한다.

Your application

웹 어플리케이션 같은 우리가 만든 응용프로그램이다. Replicache에 상태를 저장하는 주체이다. Mutator 와 Subscription를 구현해서 상태의 변경과 대응을 한다.

Your server

가장 신뢰할 수 있는 데이터를 저장하기 위해 존재한다. 서버에 연결된 데이터베이스에 저장된 상태는 어플리케이션에 있는 상태보다 우선시 된다.

서버는 push(upstream)와 pull(downstream)을 구현해서 클라이언트의 Replicache와 소통해야한다.

• push(upstream): Replicache 는 변경 사항을 push endpoint로 보낸다. 서버에도 어플리케이션과 같이 Mutator를 구현하는데 이 push endpoint는 이 mutator를 실행시켜서 database의 상태를 변경한다.

• pull(downstream): 주기적으로 혹은 명시적으로 요청할 때, Replicache는 서버에 Pull 요청을 날린다. 서버는 클라이언트가 서버의 상태와 동일해지기 위해 필요한 변경사항을 반환한다.

• poke: 주기적으로 클라이언트가 pull요청을 보내긴 하지만, 좀 더 realtime으로 보여주기 위해서 서버에 변경이 있을때, 서버가 클라이언트에게 pull 요청을 하라고 힌트를 주는 신호이다. 아무런 데이터를 수반하지 않는다.

Sync

어플리케이션과 서버가 최신의 상태로 동기화 한다. 아래 그림이 이 과정을 잘 보여준다. 서버에서 주기적으로 상태변화를 pull 받아서 UI를 업데이트하는 과정, 클라이언트에서의 상태변경이 먼저 UI를 업데이트하고 서버에 push 되는 과정을 보여준다.

출처

Clients, ClientGroups, Caches

메모리에 있는 Replicache를 Client 라고 한다.

import {Replicache} from "replicache";

const rep = new Replicache({
  name: userID,
  ...
});

console.log(rep.clientID);

클라이언트는 보통 한탭 당 하나 존재한다. 클라이언트는 휘발성이고 탭의 생명주기와 함께한다. 유일한 clientID를 가진다.

Client Group은 Local data를 공유하는 클라이언트의 집합이다. 이 클라이언트 그룹 안에 있는 클라이언트들은 오프라인 상태라도 상태를 공유한다.

Client Group은 Replicache의 생성자의 name parameter에 의해 구별되는 on-disk persistent cache를 사용한다. 같은 name을 가지는 Client Group에 속하는 모든 클라이언트는 같은 캐시를 공유한다.

The Client View

Client는 ordered map of key value pair 를 persistent cache에 가지고 있는데 이를 Client View 라고 부른다. Client View는 어플리케이션의 데이터이고 서버의 데이터와 싱크된다. Client View라고 부르는 이유는 서로 다른 클라이언트 마다 서버의 데이터를 다른 Client View로 가지고 있을 수 있기 때문이다. 각 클라이언트가 서버의 상태를 보는 게 다르다는 의미다.

Client View에 접근하는 것은 매우 빠르다. Read latency 는 1ms 미만이고 대부분의 장치에서 500MB/s 의 Throughput을 가진다.

React 같은 곳에서 useState로 따로 Client View를 카피해서 메모리에 올려서 사용하지말고, Client View에서 바로 읽어서 사용하길 권장한다. Client View에 mutator가 변경을 가하면 subscription이 발동되어 UI가 업데이트 되도록 하면 된다.

Subscriptions

Subscribe 함수는 ReadTransaction 인자를 받아서 Replicache에서 읽는 것을 구현한다. Replicache의 데이터가 변해서 이 subscription이 out of date 될때마다 subscribe 함수가 다시 수행된다. 만약 이 결과가 바뀐다면, 값이 업데이트되고 UI도 업데이트 된다.

Subscription을 통해 UI를 구성하면, 항상 최신의 상태로 유지할 수 있다.

import {Replicache} from "replicache";

const rep = new Replicache({
  name: userID,
  ...
});

console.log(rep.clientID);

Mutations

Mutation은 Replicache의 데이터를 변화시키는 작업을 뜻한다. Mutation을 받아서 실제로 데이터를 변화시키는 주체를 Mutator 라고 한다.

시작할 때 Replicache에 여러 Mutator를 등록하는데, 사실 그냥 named function이다. 아래 createTodo와 markTodoComplete는 모두 mutator로 WriteTransaction을 통해서 Replicache의 데이터를 변화시킨다.

const todos = useSubscribe(rep, async tx => {
  return await tx.scan({prefix: 'todo/'}).toArray();
});
return (
  <ul>
    {todos.map(todo => (
      <li key={todo.id}>{todo.text}</li>
    ))}
  </ul>
);

Mutator는 아래와 같이 작동 시킨다. Mutator가 작동하면 데이터가 변경되고, 그와 연관된 subscription들이 트리거 되면서 UI 또한 변경된다.

const rep = new Replicache({
  ...
  mutators: {
    createTodo,
    markTodoComplete,
  },
});

async function createTodo(tx: WriteTransaction, todo: Todo) {
  await tx.set(`/todo/${todo.id}`, todo);
}

async function markTodoComplete(tx: WriteTransaction,
    {id, complete}: {id: string, complete: boolean}) {
  const key = `/todo/${id}`;
  const todo = await tx.get(key);
  if (!todo) {
    return;
  }
  todo.complete = complete;
  await tx.set(key, todo);
}

내부적으로 Mutator는 mutation이라는 것을 만든다. 수행 기록 같은건데, Replicache는 아래와 같은 mutation을 생성한다.

await rep.mutate.createTodo({id: nanoid(), text: "take out the trash"});

이 mutation들이 서버에 push 되어 완전히 sync되기 전까지 이 mutation들은 pending 상태로 표기된다.

Sync Details

이제 Replicache의 핵심이라고 할 수 있는 Sync의 자세한 내용이다. Sync는 서버에서 이루어진다.

The Replicache Sync Model

(이제부터 '상태'라는 표현은 여러 key과 value 쌍으로 된 데이터(key value space)의 상태를 뜻 한다.)

Replicache가 풀려고 하는 Sync 문제는 여러 클라이언트가 동시에 같은 상태를 변화시키는 상황이고 아래와 같은 조건을 가질 때 발생한다.

1. 서버가 가지고 있는 상태가 source of truth이다. canonical(표준)이라고 표현한다.
2. 클라이언트의 로컬 상태의 변화는 즉각적으로 반영된다. 이를 speculative(추측)라고 부른다.
3. 서버는 변경사항을 정확히 한번만 적용해야하고 그 결과가 예측 가능해야한다. 서버에 적용된 변경사항이 클라이언트의 로컬 change와 합리적으로 병합될 수 있어야한다.

이 중에 마지막 항목에서 서버의 변화를 로컬 상태와 '합리적으로 병합'이라는 것은 흥미로운 주제이다. '합리적 병합'을 위해서 다음과 같은 상황들을 고려해야한다.

• 로컬의 변화가 아직 서버에 적용되지 않은 경우. 이 경우는 서버로부터 새로운 상태를 가져오더라도 로컬에서의 변경 사항이 앱의 UI에서 사라지지 않도록 해야 한다. 서버로부터 새로운 상태를 수신한 후, 기존의 로컬 변경 사항을 서버 상태 위에 다시 실행해야 한다.

• 클라이언트에서 발생한 로컬 변경 사항이 이미 서버에 전송되고, 서버 상태에 반영된 경우. 이 경우는 로컬 변경 사항을 중복 적용하는 것을 주의 해야한다. 로컬 변경 사항을 다시 적용하지 않아야한다.

• 동일한 상태에 대해 서버 상태를 변경한 다른 클라이언트가 존재하는 경우. 이 경우에도 첫번째 경우 처럼 서버에서 수신한 상태를 기준으로 로컬 변경 사항을 재 실행해야 한다. 하지만 같은 리소스에 대해서 충돌이 발생할 수 있기 때문에 병합 논리를 잘 짜야한다. Mutator 내부에 이 로직을 작성한다.

Mutator의 동작 과정을 따라가보자.

Local execution

로컬에서 Mutator 가 동작하고 mutator로직에 따라서 replicache의 값이 변경된다. 동시에 이 클라이언트에서 sequential하게 증가하는 mutationId를 가진 mutation을 생성한다. mutation은 pending mutation으로 queuing된다.

Push

Pending mutations은 server에 구현된 push endpoint(replicache-push)로 보내진다.

mutation은 서버에 구현된 mutator를 실행시켜서 canonical 상태를 변경한다. Mutation을 적용하면서 이 클라이언트의 last mutation id를 업데이트하고, 이 클라언트가 다음 pull을 할 때 어느 mutation부터 재 적용할지 알 수 있는 값이 된다.

로컬에 적용된 pending mutation은 speculative result를 생성하고, 서버에 적용된 mutation은 canonical result를 생성한다. 서버에 적용된 mutation은 confirmed 되어 다시 로컬에서 실행되지 않는다. 만약 같은 mutation이 다른 결과를 반환하더라도 server의 canonical result가 우선되므로 클라이언트의 결과는 바뀌게 된다.

Pull

Replicache는 최신 상태를 가져와 UI를 업데이트하기 위해서 주기적으로 pull endpoint(replicache-pull)로 요청을 보낸다.

Pull request는 cookie, clientGroupId를 담아서 요청하고, new cookie, patch, lastMutationIDChanges를 반환받는다.

cookie는 클라이언트가 가지고 있는 서버 상태를 구별하는데 사용한다. 서버와 클라이언트 상태가 얼마나 차이나는 지 추적할 수 있는 값이면 된다. 데이터베이스의 상태가 바뀔때마다 변경되는 global 'version'이라고 생각해도 된다. 아니면 좀 더 특정 범위의 데이터를 추적하는 쿠키 전략을 사용해도 된다.

lastMutationIdChanges는 각 클라이언트의 마지막으로 서버에서 적용된 mutation ID를 나타내는 값이다. 이 값보다 작은 mutationID를 가진 mutation은 모두 더 이상 pending이 아닌 confirmed로 간주해야한다.

Rebase

클라이언트가 pull을 받으면 로컬의 상태에 patch를 적용해야한다. 하지만 pending mutation이 현재 로컬 상태 영향을 줬을 것이기에 로컬 상태에 바로 patch를 적용할 수는 없다. 대신에 로컬의 pending mutation을 되돌리고 pull로 받은 patch를 먼저 적용한 후에 다시 로컬 pending mutation을 적용한다.

이런 되돌리기와 재적용을 가능하게 하기 위해서 Replicache는 깃과 유사하게 설계되었다. 서버의 상태가 main branch, 로컬에 팬딩된 mutation으로 변경된 상태를 develop 브랜치라고 생각하고 서버로 부터 main에 pull을 받고 develop을 main으로 rebase한다고 생각하면 된다.

리베이스하면서 발생할 수 있는 컨플릭트는 아래에서 따로 알아본다.

Poke

Poke는 위에서 설명했듯이 서버가 클라이언트에게 pull을 하라고 알려주는 힌트 메세지이다.

Conflict Resolution

Replicache과 같은 분산시스템에서 Merge conflict는 피할 수 없다. pull과 push과정에서 병합이 필요하다. 병합은 병합 결과가 예측 가능해야하고 앱의 목적에 맞는 방식으로 진행되어야한다.

만약 회의실 예약 앱 이라면, 컨플릭이 발생했을때 하나의 요청만 승인되어야 한다. 그렇기 때문에 먼저 예약한 클라이언트만 승인하는 병합 방법을 채택해야한다.

반대로 Todo 앱이라면, 투두리스트는 동시에 추가가 일어나더라도, 두 변경 모두 승인되는 것이 목적에 맞다.

Merge Conflict는 다음 두 상황에서 발생한다.

1. 로컬 변경 사항이 서버에 적용될 시점. 로컬에서 적용할 때의 상태와 서버에서 적용할 때의 상태가 다를 수 있기 때문이다.

2. Rebase할 때. 역시 적용할때 상태가 다를 수 있기 때문이다.

Replicache는 앱의 목적에 따라 병합 방법을 다르게 구현해야 함을 인지하기 때문에, 개발자가 이를 구현할 수 있도록 한다. 개발자는 Mutator를 통해 이 로직을 구현하면 된다.

위 내용은 복제 캐시 큰 그림의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!