RePlaya: S2 스트림 스토리지를 통한 세션 리플레이 간소화

세션 리플레이 도구는 정성적 사용자 연구에 매우 유용하며, 정량적 지표가 통계적으로 유의미한 샘플을 제공하기 전에 개발자가 사용자가 새로운 기능에서 정확히 어디에서 어려움을 겪는지 확인할 수 있게 해줍니다. 그러나 전통적인 세션 리플레이 백엔드는 종종 아키텍처 측면에서 악몽과 같으며, 대량의 DOM 변형 스트림을 처리하기 위해 메시지 버스, 관계형 데이터베이스, 오브젝트 스토어, 검색 인덱스의 복잡한 오케스트레이션이 필요합니다.

RePlaya는 다른 접근 방식을 취합니다. S2를 기반으로 구축함으로써, 각 사용자 세션을 단일한 추가 전용(append-only) 스트림으로 취급합니다. 이러한 아키텍처의 변화는 인프라 발자국을 획기적으로 줄이는 동시에, 셀프 호스팅 대안에서 종종 누락되는 강력한 기능인 활성 세션의 라이브 테일링(live tailing)을 가능하게 합니다.

아키텍처: 진실의 원천으로서의 스트림

전형적인 세션 리플레이 설정에서는 서버가 중간 매개체 역할을 하여 이벤트를 버퍼링하고 데이터베이스나 블롭 스토어(blob store)로 플러시(flush)합니다. RePlaya는 이러한 중간 계층을 제거합니다. S2 Producer API를 사용하여 rrweb 이벤트를 세션 스트림의 끝에 직접 추가합니다.

이 설계는 몇 가지 기술적 이점을 제공합니다:

1. 통합된 스토리지 및 검색

메타데이터를 데이터베이스에, 실제 녹화본을 오브젝트 스토어(S3와 같은)에 나누어 저장하는 대신, RePlaya는 S2 스트림을 전체 백엔드로 사용합니다. 스트림이 곧 녹화본입니다. 대규모 이벤트는 여러 S2 레코드를 통해 프레임화되고 재생 시 재구성되므로, 관리해야 할 별도의 블롭 스토어가 없습니다.

2. 실시간 라이브 테일링

S2 스트림은 기록되는 대로 테일링(tailing)할 수 있기 때문에, RePlaya는 Server-Sent Events (SSE)를 통해 새로운 레코드를 브라우저로 연결할 수 있습니다. 이를 통해 개발자는 방문자가 페이지에 머무는 동안 동일한 스트림을 사용하여 세션을 라이브로 시청할 수 있으며, 이 스트림은 결국 역사적 녹화본으로 사용됩니다.

3. 간소화된 목록 및 정렬

세션 순서를 추적하기 위해 별도의 인덱스를 유지하는 대신, RePlaya는 역순 타임스탬프(예: sessions/<inverted timestamp>)를 사용하여 스트림의 이름을 지정합니다. S2가 스트림을 사전식 순서로 나열하기 때문에, 간단한 접두사 목록 호출을 통해 가장 최신 세션을 먼저 반환하므로, 세션 연대기를 추적하기 위한 관계형 데이터베이스가 필요하지 않습니다.

비교: RePlaya vs. 전통적인 백엔드

| Feature | Typical Replay Backend | RePlaya | | :--- | :--- | :--- | :--- | | Infrastructure | Message bus, analytics store, DB, object store, search index | One Node server + S2 | | Live Sessions | Playback after ingest/flush delay | Live tail of active sessions via the same stream | | Stored Recording | Blobs in object storage; metadata in DBs | One ordered S2 stream per session | | Footprint | Multi-service cluster (often Kubernetes) | Single process + S2 (or self-hosted s2-lite) |

구현 및 보안

RePlaya는 "drop-in" 방식의 레코더로 설계되었습니다. 대상 사이트에 작은 JavaScript 스니펫을 추가하면 캡처를 초기화하고 RePlaya 호스트를 가리키도록 설정할 수 있습니다.

개인정보 보호 및 데이터 마스킹

세션 녹화의 내재적인 개인정보 보호 문제를 해결하기 위해, RePlaya는 기본적으로 마스킹을 구현합니다. rrweb의 maskAllInputs를 사용하여 input, select, textarea 필드에서의 키스트로크(예: 비밀번호 및 이메일)가 서버로 절대 전송되지 않도록 보합니다합니다. 개발자는 민감한 DOM 영역을 replaya-block 또는 replaya-ignore 클래스로 감싸서 녹화에서 완전히 제외할 수 있습니다.

프로덕션 배포포

보안 관점에서 RePlaya는 "collector"(공개용 쓰기 표면)와 "dashboard"(비공개용 읽기 표면)를 분합니다합니다. 권장되는 프로덕션 배포 방식은 다음과 같습니다:

  • Private Read APIs: Dashboard와 세션 검색 API를 프라이빗 인터페이스에 바인딩하거나 SSO/VPN 레이어를 통해 보호합니다.
  • Public Collector: Recorder 스니펫을 REPLAYA_ALLOWED_CAPTURE_ORIGINS와 프로젝트 키를 통해 잠금 처리하여, 레코더 스키립트와 쓰기 엔드포인트만 노출출합니다.
  • Ingest Authentication: 세션 생성 시 생성된 수명이 짧은 append tokens를 사용하여 이후의 이벤트 쓰기를 승인합니다.

윤리적 고려 사항

RePlaya의 기술적 구현은 간소화되었지만, 세션 리플레이는 중요한 윤리적 질문을 제기합니다. 커뮤니티 논의에서 언급되었듯이, 많은 사용자는 자신의 커서 이동과 뷰포트 변경 사항이 회사의 본사로 라이브 스트리밍되고 있다는 사실을을umentation of qualitative UX data and the user's right to privacy, suggesting that transparent disclosure or opt-in mechanisms may be necessary for ethical deployment.

시작하기

셀프 호스팅을 원하는 경우, RePlaya는 Docker 또는 Node.js를 통해 직접 배포포할 수 있습니다. S2 Cloud와 인프라 전체를 자체 경계 내에 유지하고자 하는 이들을 위한 셀프 호스팅 s2-lite 인스턴스를 모두 지원합니다.

Sources