RePlaya: S2 ストリームストレージによるセッションリプレイの簡素化
セッションリプレイツールは、定性的なユーザーリサーチにおいて非常に価値があります。定量的な指標が統計的に有意なサンプルを提供する前に、開発者がユーザーが新しい機能のどこで苦労しているかを正確に把握することを可能にします。しかし、従来のセッションリプレイのバックエンドは、高ボリュームのDOM変異のストリームを処理するために、メッセージバス、リレーショナルデータベース、オブジェクトストア、検索インデックスの複雑なオーケストレーションを必要とする、アーキテクチャ上の悪夢であることが多いです。
RePlayaは異なるアプローチを取ります。S2の上に構築することで、各ユーザーセッションを単一の追記専用(append-only)ストリームとして扱います。このアーキテクチャの転換により、インフラストラクチャのフットプリントを劇的に削減しつつ、セルフホストの代替手段では欠落しがちな強力な機能、すなわちアクティブなセッションのライブテイル(live tailing)を実現します。
アーキテクチャ: 真実のソースとしてのストリーム
典型的なセッションリプレイのセットアップでは、サーバーが仲介役として機能し、イベントをバッファリングしてデータベースやブロブストアにフラッシュします。RePlayaはこの中間層を排除します。S2 Producer APIを使用することで、rrwebイベントはセッションのストリームの末尾に直接追記されます。
この設計は、いくつかの技術的な利点を提供します。
1. 統合されたストレージと取得
メタデータをデータベースに、実際の録画をオブジェクトストア(S3など)に分割する代わりに、RePlayaはS2ストリーム全体をバックエンドとして使用します。ストリームそのものが録画となります。大きなイベントは複数のS2レコードにまたがってフレーム化され、再生中に再構成されます。つまり、管理すべき個別のブロブストアは存在しません。
2. リアルタイムのライブテイル
S2ストリームは書き込み中にテイル(追跡)できるため、RePlayaはServer-Sent Events (SSE)を介して新しいレコードをブラウザに橋渡しできます。これにより、開発者は訪問者がまだページに滞在している間に、最終的に履歴録画として機能するのと同じストリームを使用して、セッションをライブで視聴することができます。
3. 簡素化されたリスティングと順序付け
セッションの順序を追跡するために個別のインデックスを維持する代わりに、RePlayaは反転タイムスタンプ(例: sessions/<inverted timestamp>)を使用してストリームに名前を付けます。S2はストリームを辞書順でリスト化するため、単純なプレフィックスリスト呼び出しによって最新のセッションを最初に取得でき、セッションの時系列を追跡するためのリレーショナルデータベースの必要性がなくなります。
比較: RePlaya vs. 従来のバックエンド
| 機能 | 典型的なリプレイバックエンド | RePlaya | | :--- | :--- | :--- | | | インフラストラクチャ | メッセージバス、アナリティクスストア、DB、オブジェクトストア、検索インデックス | One Node server + S2 | | ライブセッション | 取り込み/フラッシュの遅延後の再生 | 同じストリームを介したアクティブセッションのライブテイル | | 保存された録画 | オブジェクトストレージ内のブロブ; メタデータはDB内 | セッションごとに1つの順序付けられたS2ストリーム | | フットプリント | マルチサービス・クラスター(多くの場合Kubernetes) | Single process + S2 (または self-hosted s2-lite) |
実装とセキュリティ
RePlayaは「ドロップイン」形式のリコーダーとして設計されています。対象のサイトに小さなJavaScriptスニペットを追加するだけで、キャプチャを初期化し、RePlayaホストに向けてポイントします。
プライバシーとデータマスキング
セッション録画に固有のプライバシーの懸念に対処するため、RePlayaはデフォルトでマスキングを実装しています。rrwebのmaskAllInputsを使用して、パスワードやメールアドレスなどの入力、select、およびtextareaフィールド内のキーストロークがサーバーに送信されないようにします。開発者は、機密性の高いDOM領域をreplaya-blockまたはreplaya-ignoreクラスでラップすることで、それらを録画から完全に除外するように、さらに詳細に設定できます。
本番環境へのデイプロイメント
セキュリティの観点から、RePlayaは「コレクター」(公開されている書き込み面)と「dashboard」(プライベートな読み取り面)を分離しています。推奨される本番環境へのデイプロイメントは以下の通りです。
- Private Read APIs: dashboardとセッション取得APIをプライベートなインターフェースにバインドするか、SSO/VPN層の背後に保護します。
- Public Collector: リコーダー・スクリプトと書き込みエンドポイントのみを公開し、
REPLAYA_ALLOWED_CAPTURE_ORIGINSとプロジェクトキーによって制限をかけます。 - Ingest Authentication: セッション作成時に生成される短寿命の追記トークンを使用して、後続のイベント書き込みを承認します。
倫理的考慮事項
RePlayaの技術的な実装は合理化されていますが、セッションリプレイは重大な倫理的質問を投げかけます。コミュニティの議論で指摘されているように、多くのユーザーは、自分のカーソル移動やビューポートの変化が会社の拠点にライブ配信されていることに気づいていない場合があります。これは、定性的なUXデータへのニーズとユーザーのプライバシー権との間の緊張関係を浮き彫りにし、倫何的な展開のための透明な開示やオプトイン・メカニズムが必要であることを示唆しています。
はじめに
セルフホストを検討している方は、、RePlayaはDockerまたはNode.jsを介して直接デイプロイできます。S2 Cloudと、インフラ全体を自身の境界内に保持したい方向けのセルフホスト版s2-liteインスタンスの両方をサポートしています。