Benchmarking Real-Time Database Synchronisation Architectures: REST Polling, WebSocket Push, and CockroachDB CDC
본 논문은 실시간 데이터베이스 동기화를 위한 REST 폴링, WebSocket 푸시, 그리고 CockroachDB CDC 아키텍처를 비교하는 통제된 벤치마크를 제시하며, WebSocket 푸시가 가장 낮은 중앙값을 제공하고 REST 폴링이 예측 가능한 제한된 지연 시간을 제공하는 반면, CDC는 경쟁력 있는 중앙값을 전달하지만 배칭과 특정 프로토콜 불일치로 인해 상당한 꼬리 지연 시간(tail latency)을 겪는다는 점을 밝히고 있습니다.
원본 논문은 CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
현대 소프트웨어의 세계에는 인터넷에 연결되어 있지 않을 때도 마치 기기에 직접 살고 있는 것처럼 느껴지는 애플리케이션에 대한 갈망이 커지고 있습니다. '로컬 퍼스트(local-first)'라고 불리는 이 접근 방식은 오프라인 상태에서도 문서를 편집하거나 목록을 업데이트할 수 있게 하며, 변경 사항은 연결이 복구될 때까지 중앙 서버로 전송되기를 기다립니다. 문제는 연결이 복구되는 순간입니다. 컴퓨터는 어떤 버전의 데이터가 올바른지 어떻게 결정하며, 사용자가 기다리지 않게 얼마나 빨리 중앙 서버를 업데이트할 수 있을까요? 이것이 원활하게 작동하려면 시스템은 새로운 정보를 감지하고 이를 즉시 전달할 수 있는 신뢰할 수 있는 방법을 갖추어야 합니다. 업데이트가 너무 느리면 사용자는 지연을 느끼고, 시스템이 너무 복잡하면 배터리를 소모하거나 충돌을 일으킵니다. 엔지니어들의 핵심 질문은 이 감지 메커니즘을 어떻게 구축할 것인가 하는 것입니다. 장치가 서버에 무언가 변경되었는지 계속 물어봐야 할까요, 서버가 변경 사항을 즉시 외쳐야 할까요, 아니면 데이터베이스 자체가 나중에 읽을 수 있도록 모든 작업의 실행 기록(log)을 계속 유지해야 할까요?
인도 공과대학교 카라그푸르(IIT Kharagpur)의 한 연구자는 이 세 가지 일반적인 전략을 통제된 환경에서 나란히 테스트하여 어떤 것이 실제로 가장 잘 작동하는지 확인하기로 했습니다. 이 연구는 클라이언트가 정해진 시간 간격으로 업데이트를 확인하는 방법, 서버가 영구적인 연결을 통해 변경 사항을 즉시 밀어내는(push) 방법, 그리고 데이터베이스가 구독자들에게 모든 변경 사항의 로그를 스트리밍하는 방법을 비교했습니다. 공정한 테스트를 보장하기 위해, 연구자는 사용자에게는 동일해 보이지만 내부 기어는 서로 다른 세 가지 별도의 시스템을 구축했습니다. 한 시스템은 단순한 "체크인" 루프를 가진 표준 데이터베이스를 사용했습니다. 다른 시스템은 동일한 데이터베이스를 사용하되, 변경이 발생하는 즉시 신호를 보내는 트리거를 추가했습니다. 세 번째 시스템은 자체 역사를 스트리밍하도록 설계된 다른 분산 데이터베이스를 사용했습니다. 목표는 사용자가 만든 변경 사항이 시스템을 거쳐 리스너의 화면에 나타나기까지 정확히 걸리는 시간을 측정하는 것이었으며, 단 한 명의 사용자부터 동시에 글을 쓰는 50명의 사용자까지 테스트 범위를 넓혔습니다.
결과는 각 방법이 압박 속에서 어떻게 작동하는지에 대한 명확한 그림을 보여주었습니다. 영구적인 연결을 통해 서버가 변경 사항을 즉시 외치는 방식에 의존하는 시스템이 가장 빠른 것으로 증명되었습니다. 가장 좋은 경우, 변경 사항은 단 2밀리초 만에 리스너의 화면에 나타났으며, 50명이 동시에 글을 쓸 때도 지연 시간은 좀처럼 63밀리초를 넘지 않았습니다. 이 방법은 놀라울 정도로 일정한 속도를 유지했으며, 가장 느린 업데이트조차 0.25초 미만으로 도착했습니다. 클라이언트가 업데이트를 요청하기 위해 100밀리초마다 확인하는 방식에 의존하는 방법은 예측 가능했지만 더 느렸습니다. 클라이언트가 자신의 차례를 기다려야 했기 때문에 평균 지연 시간은 약 60밀리초였지만, 체크 사이의 시간보다 빨라질 수는 없었습니다. 많은 사용자가 동시에 글을 쓸 때 이 대기 시간은 늘어나 평균 지연 시간이 100밀리초 이상으로 치솟았습니다. 데이터베이스의 내부 로그를 사용하는 시스템은 엇갈린 성능을 보였습니다. 일반적인 업데이트는 보통 1초 미만으로 빠르게 도착했지만, 이 시스템은 가장 느린 몇몇 업데이트에서 심각한 지연을 겪었습니다. 가끔씩 변경 사항이 도착하는 데 2초 이상이 걸렸고, 어떤 경우에는 지연 시간이 3.5초 이상으로 길어지기도 했습니다.
연구자는 로그 기반 시스템에서 가장 느린 업데이트가 변경 사항을 기록하는 아이디어 자체의 결함이 아니라, 특정 소프트웨어가 어떻게 연결되어 있는지의 결과라는 것을 발견했습니다. 이 시스템은 표준 연결 도구가 데이터베이스의 언어를 올바르게 구사하지 못했기 때문에 데이터베이스 로그를 읽기 위한 우회 방법을 사용했습니다. 이 우회 방식은 연결이 중단될 때마다 새로운 프로세스를 시작해야 했으며, 이는 지연 시간에 1초에서 4초 사이의 무거운 페널티를 추가했습니다. 이러한 특정 기술적 장애물이 없었다면 로그 기반 방식은 훨씬 더 잘 작동했을 수도 있지만, 이 테스트에서는 긴 지연 시간 때문에 대화형 사용에는 부적합한 것으로 나타났습니다. 연구는 또한 확인 절차 방식에 대한 간단한 규칙을 확인했습니다: 체크 사이의 간격을 길게 잡을수록 평균 지연 시간도 길어진다는 것입니다. 시스템이 50밀리초마다 확인하면 평균 대기 시간은 약 36밀리초이고, 500밀리초를 기다리면 평균 대기 시간은 300밀리초 이상으로 급증합니다.
이러한 발견은 동기화를 유지해야 하는 소프트웨어를 구축하기 위한 실질적인 가이드를 제공합니다. 사용자들이 실시간으로 함께 타이핑하는 협업 편집 도구와 같이 속도가 중요한 애플리념의 경우, 서버가 변경 사항을 즉시 밀어내는 방식이 명확한 선택입니다. 이 방식은 많은 사람이 동시에 시스템을 사용할 때도 가장 낮은 지연 시간과 가장 일관된 성능을 제공합니다. 클라이언트가 정기적인 간격으로 업데이트를 확인하는 방식은 수백 밀리초의 지연이 허용되거나, 모바일 기기처럼 배터리를 아끼기 위해 연결을 계속 열어두기 어려운 단순한 애플리케이션에 좋은 옵션입니다. 데이터베이스 로그를 스트리밍하는 방식은 대량의 데이터를 이동하거나 백업을 생성하는 데 강력하지만, 여기서 테스트된 특정 구현 방식은 대화형 사용에는 너무 느리고 예측 불가능했습니다. 연구는 세 가지 방법 모두 작동하지만, 최선의 선택은 전적으로 우선순위가 즉각적인 반응성인지 아니면 운영의 단순성인지에 달려 있다고 결론지었습니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.