[WebDev] Patterns for building realtime features

https://zknill.io/posts/patterns-for-building-realtime/?utm_source=tldrwebdev

Patterns for building realtime features

---

실시간 기능은 앱을 더 현대적이고, 협업적이며, 최신 상태로 유지되도록 해준다. 이 기능은 주로 한 사용자가 발생시킨 변경을 다른 사용자들에게 실시간으로 공유하는 것을 필요로한다.

이것은 일반적으로 서버가 특정 클라이언트들에게 데이터를 보내야 하는데, 그 클라이언트들은 자신들이 데이터를 놓치고 있다는 사실을 알지 못하는 상황을 의미한다.

이 패턴들은 서버가 클라이언트에게 데이터를 알릴 수 있는 connection에 의존한다. 이 connection은 웹소켓, sse, 이벤트 스트림 또는 polling일 수 있다. 이 connection은 단순히 클라이언트가 새로운 데이터가 있다는 것을 알지 못하는 상황에서 서버가 클라이언트에게 데이터를 보낼 수 있는 있도록 하면 된다.

 

Patterns

Poke / Pull

`poke/pull` 은 기존 앱과 호환될 수 있는 가장 쉬운 방법이다. 서버에서 update가 일어났을 때, 이를 subscribe하고 있는 모든 클라이언트에게 새로운 변경을 반영하라고 알리는 `poke`가 전송된다.

클라이언트가 이 알림을 받으면, 새로운 상태를 `pull`하기 위한 요청을 서버에 보낸다. poke/pull 은 새로운 상태를 가져가기 위한 엔드 포인트를 기존에 있는 것으로 활용할 수 있기 때문에 기존 앱과의 호환에 유리하다. 이미 존재하는 `pull API`를 사용하면 되기 때문에 `poke`만 구현하면 된다.

이 패턴의 문제점은 fan-out이다. 서버에 하나의 변경ㅇ만 일어나도, 다수의 클라이언트에 대해 fan-out이 일어난다. 이는 다수의 클라이언트들이 동시에 서버에 pull 요청을 보낸다는 것을 의미한다.

모든 클라이언트들이 동시에 요청하기 때문에, 캐싱은 매우 효과적인 방법이다. 따라서, 응답을 캐싱하고 모든 클라이언트에게 동일한 응답을 주는 것은 비교적 쉽다. 클라이언트들은 거의 동시에 pulll 요청을 보내기 때문에, 캐싱된 응답은 충분히 최신 상태를 유지할 수 있다.

서버는 또한 이러한 `poke`를 더 긴 시간을 두고 분산시킬 수 있는데, 이렇게 하면 동시에 `pull` 요청을 보내는 클라이언트 수를 줄일 수 있다.

 

Push state

두번째 패턴은 `push state`이다. 이 패턴에서 서버는 이미 클라이언트가 받아야할 최신 상태를 알고 있기 때문에, 그 상태를 클라이언트에 푸시한다. `poke`를 보내는 대신, 새로운 상태를 즉시 서버에서 보내는 것이다.

이것은 모든 클라이언트가 `pull`을 할 필요 없이 즉시 업데이트된 상태를 받기 때문에 fan-out 문제를 완화시킨다. 상태를 푸싱하는 것은 클라이언트가 상태와 동기화되지 않을 가능성이 적기 때문에 다루기가 쉽다. 매번 업데이트될 때마다 클라이언트는 사용해야 할 전체 상태의 사본을 받게 되므로, 클라이언트에서 발생한 버그로 인해 상태가 엇갈리는 문제가 빠르게 해결될 수 있다.

그러나 전체 상태를 푸싱하는 것은 클라이언트가 변경된 부분을 파악하기 어려울 수 있다. 또한 작은 변경이 일어나도 전체 상태를 재 전송해야하기 때문에, 대규모 상태를 처리 하는데에는 적합하지 않다. 예를 들어, “walk the dog”가 완료되어서 true로 변경되는 경우에도, 모든 “todos”를 다시 전송해야 한다.

 

Push ops

push ops는 클라이언트가 어느 부분이 변경되었는지 쉽게 파악할 수 있도록 도와주며, 전송되는 데이터의 사이즈도 줄여준다.

일반적응로 서버는 상태 변경을 발생시키는 작업에 대해 이해하고 있으며, 이를 연결된 클라이언트들에게 전송할 수 있다. 즉, 서버는 전체 상태를 보내는 대신 클라이언트의 상태를 서버의 상태와 일치하도록 업데이트할 수 있는 작업(operation)을 전송한다.

예제에서와 같이, 이 작업(operation)은 id가 2인 todo 항목의 상태가 `completed: true` 로 변경되었음을 나타낸다.

각 클라이언트는 이 작업을 기존 상태에 병합한다. `push state` 에서 언급한 것 처럼, 이것은 서버가 클라이언트의 상태를 정확히 이해하고 있다는 것에 의존한다. 그렇지 않으면 서버가 생성한 작업(operation)만으로는 클라이언트의 상태를 서버와 동기화 시킬 수 없다.

마지막으로 `push ops` 는 클라이언트가 작업을 적용할 수 있는 초기 상태를 얻는 매커니즘을 제공해야한다. 이것은 일반적으로 초기 상태를 설정하는 `initial` 작업을 먼저 제공하고, 이후의 작업이 그 위에 적용되는 식으로 모델링된다.

 

Event Sourcing

`event sourcing` 에서는 변경을 나타내는 작업 혹은 업데이트된 상태를 전송하는 대신 변경을 유발한 ‘이벤트’ 자체를 클라이언트에 전송한다.

이 예제에서 볼 수 있듯이, 이벤트는 업데이트 된 상태를 포함하는 대신 발생한 ‘이벤트’를 포함한다. 그렇기 때문에, 이 이벤트가 무엇인지 아는 것은 클라이언트의 책임이다. purists 들은 이것이 더 나은 데이터 표현 방식이라고 주장하지만, 실제로는 각 클라이언트들이 동일한 비즈니스 로직을 구현해야한다는 부담이 생긴다. 즉, 이 이벤트가 completed 필드를 true로 변경해야 한다는 의미임을 이해하는 로직을 각 클라이언트에서 구현해야 한다는 것이다.

아마도 만약 클라이언트가 단순히 업데이트된 상태를 표시하는 것 이상의 복잡한 로직을 갖는 경우라면, 이벤트를 보내는 것이 유용할 수 있다. 이렇게 하면 클라이언트가 completed 필드가 true로 변경되었음을 역으로 해석할 필요 없이, 그저 “todo was completed”라는 이벤트를 직접 받아서 처리할 수 있기 때문이다.

 

Transports

서버와 클라이언트를 연결된 상태로 유지하기 위해 사용할 수 있는 웹소켓, sse, 이벤트 스트림, 코멧, 폴링 등의 다양한 전송방식이 있다. 각 방식에는 장단점이 있지만, 전반적으로 동일한 기능을 제공한다.

나열한 모든 전송 방식은 HTTP위에서 동작한다. 즉, 이들은 모두 서버와 클라이언트 간의 1:1 연결 방식이다. 즉, 하나의 클라이언트는 하나의 서버에 연결된다. 이제 서버가 여러개의 `replicas` 로 수평 확장된 시스템을 생각해보자. 이 경우, 상태 변경을 유발한 최초 요청을 처리한 서버가 모든 클라이언트 연결을 관리하는 서버와 다를 가능성이 있다.

위 이미지에는 두 대의 서버 `replica`가 있다. 녹색 클라이언트가 변경을 수행하고, 웹소켓 연결을 통해 해당 변경 사항을 server A와 공유하면, server A가 파란색 클라이언트와 이 업데이트를 공유하는 것은 비교적 쉽다. 하지만, server A가 주황색 클라이언트 두 명과 이 업데이트를 공유하는 것은 상당히 어렵다. 왜냐하면 이 클라이언트들은 server B에 연결되어 있기 때문이다.

이것은 매우 번거로운 문제이다. 일반적으로 수평 확장된 서버들 간의 동기화는 데이터베이스를 통해 이루어진다. 하지만, 각 서버 `replica`가 변경 사항을 감지하기 위해 데이터베이스를 지속적으로 폴링하는 것은 비효율 적이다. `LISTEN/NOTIFY` 같은 데이터베이스 알림 방식을 사용하는 것도 이상적인 해결책이 아니다.

이런 상황에서 Pub/Sub은 꽤 유용하다. Pub/Sub 시스템은 웹소켓 인프라와 팬아운을 대신 처리해주기 때문이다.