델타 패턴이란?
상태 전체를 가끔만 보내고, 평소에는 변경분(델타)만 이벤트로 전송하는 식으로 메시지를 관리하는 전략
이번에 TableMaster 프로젝트를 진행하면서 테이블 상태에 대한 관리를 어떻게 해야할지 고민하고 있었다. 먼저 fetch 해온 데이터를 실시간성 있게 관리를 하려면 어떻게 해야할까 생각해보았는데 현재 구현해놓은 STOMP 메시지 프로토콜 + RabbitMQ 메시지 브로커를 사용해서 이벤트마다 메시지를 pub 하고 이를 가져다가 새로운 페이지로 렌더링 하는 전략을 택하게 되었다.
메시지를 렌더링 하는 과정에서 전체 테이블 데이터를 가져오려고 하다보면 이미 중복되는 데이터들이 대부분인 상태가 되는데, 이런 과정에서 변경점이 있는 테이블만 fresh 한 데이터로 전환시켜주면 된다.
지금 진행하는 Tablemaster 프로젝트의 경우에는 소규모의 매장관리 시스템이기 때문에 일단 수평확장성에도 무게를 두되 스코프 자체를 아주 미세한 필드값 변화 재설정 보다는 테이블 하나를 최소 스코프로 보기 때문에 검색 리소스 절약, 데이터 일관성 면에서 이득을 본다. 트레이드 오프의 부분에서는 데이터 크기가 증가한다는 면이 있지만 현재 테이블 데이터 객체 자체가 큰 편이 아니라서 이정도의 트레이드 오프는 합리적이라는 생각을 하였다.
정리하자면,
-
스냅샷을 초기 연결, 특정 주기마다 전송하여서 클라이언트의 기본 베이스라인을 설정해주고
-
데이터 변경 이벤트가 발생하면 현재값 - 이전값을 계산하여 변경된 데이터 (델타) 만듦 (현재 프로젝트에서는 아예 변경이 있는 테이블 자체를 id 값으로 셀렉트해옴 )
-
클라이언트는 이미 가지고 있는 이전 상태 데이터에 수신한 델타값을 더하거나 덮어씌워 최신 상태를 스스로 갱신함.
이런 델타 패턴의 장점으로는
- 대역폭 절약 : 수백 ~ 수천의 테이블에서 단 한 줄만 수정되었을 때 전체 데이터를 보내는 대신 변경분만 보내므로 네트워크 부하가 줄어듦
- 실시간성 향상 : 데이터 패킷의 크기가 작아 전송 속도가 빠르며, 브라우저가 처리해야할 데티어의 양이 적어 렌더링 성능이 최적화됨
- 데이터 정합성 유지 : 각 델타에 버전을 부여함으로 메시지의 누락이나 순서 바뀜을 감지하고 대응할 수 있음 (현 패턴에서는 미사용)
등이 있다.
결론
데이터 동기화 관리라고 하면 제일 먼저 생각나는 패턴이 델타 패턴인데 또 다른 데이터 동기화 패턴이 있는지 더 공부해봐야할 것 같다 일단, 이번 프로젝트에서는 델타 패턴을 사용할 것 같다.
(이벤트 소싱 패턴, CQRS 패턴, 낙관적 UI 업데이트 패턴)
| 패턴 | 핵심 아이디어 | 적합한 상황 |
|---|---|---|
| 델타 패턴 | 차이점만 전송 | 대용량 데이터의 실시간 동기화 |
| 이벤트 소싱 | 모든 행위의 기록 | 데이터 이력 추적이 중요할 때 |
| CQRS | 읽기/쓰기 분리 | 읽기 요청이 쓰기보다 압도적으로 많을 때 |
| 낙관적 UI | 선 반영 후 검증 | 느린 네트워크에서도 부드러운 UI가 필요할 때 |
