リアルタイム共同編集ホワイトボードのハイレベル計画

1. 目標と仮定

• 1つのボードで50人以上の同時ユーザーをサポートする。
• 500ミリ秒未満のエンドツーエンドの更新可視性。
• 操作：フリーハンドストローク、テキストボックス、長方形/円、移動/リサイズ/削除。
• 全ユーザーのビューを最終的に整合させながら、強力な応答性を維持する。
• 厳密なグローバル順序付けよりも可用性と低遅延を優先する。

2. ハイレベルアーキテクチャ

クライアントアプリケーション

• Web/モバイルホワイトボードUI。
• Canvas/WebGL/SVGを使用したローカルレンダリングエンジン。
• ポインター/マウス/タッチイベント用の入力キャプチャレイヤー。
• ローカル操作バッファと楽観的な適用。
• WebSocket over のリアルタイム同期モジュール。
• 現在のボード状態のスナップショット/キャッシュストア。

APIおよびセッションレイヤー

• 認証、ボード検出、権限、初期ボードスナップショットのロード、ボードのエクスポート用のHTTPS API。
• リアルタイムセッショントラフィック用のWebSocketゲートウェイ。

コラボレーションバックエンド

• セッションコーディネーターサービス：ボードごとの接続ユーザー、プレゼンス、カーソル、ルーティングを追跡する。
• オペレーションプロセッサー：オペレーションを検証し、シーケンスメタデータを割り当て、イベントログを永続化し、参加者にブロードキャストする。
• 競合解決レイヤー：順序付け/冪等性ルールおよびオブジェクトレベルのマージポリシーを適用する。

ストレージレイヤー

• ボード操作の永続イベントログ。
• 高速ロード用の定期的なボードスナップショットストア。
• ユーザー、ボード、ACL、セッション情報用のメタデータDB。
• ホットセッション、プレゼンス、一時的なカーソル状態用のオプションのインメモリキャッシュ（例：Redis）。

3. クライアントサイド設計

レンダリングモデル

• ボードをオブジェクトのシーングラフとして表現する：
  • ストローク
  • テキストボックス
  • 図形
• 各オブジェクトは、安定したobject_id、z_index、スタイル、トランスフォーム、created_by、タイムスタンプ/バージョンを持つ。
• フリーフォーム描画の場合、クライアントはポイントをサンプリングし、即時フィードバックのためにローカルでスムージングする。

ローカルファースト動作

• ユーザーアクションは、低い知覚遅延のためにクライアントで即座に適用される。
• クライアントは非同期でサーバーに操作を送信する。
• サーバーの確認応答は、ローカルの保留中オペレーションと正規順序を調整する。

クライアントモジュール

• プレゼンス/カーソルモジュール：軽量のカーソル/選択範囲の更新を間隔を空けて送信する。
• 同期エンジン：再接続、再送信、重複排除、および最後の確認済みシーケンスからのキャッチアップを処理する。
• 状態マネージャー：確認済み状態+保留中のローカルオペレーションを維持する。

4. サーバーサイド設計

4.1 WebSocketゲートウェイ

• 永続的な双方向接続を維持する。
• ユーザー認証とボードアクセス権限の付与。
• ボード/セッションIDごとにメッセージをルーティングする。
• 水平方向にスケーリング可能。ステッキセッションは役立つが、セッション状態が外部化されていれば必須ではない。

4.2 セッションコーディネーター

• 各ボードセッションのメンバーシップを維持する。
• 参加/退出、カーソルプレゼンス、選択状態を公開する。
• Redis pub/subまたはメッセージバスを使用して、すべてのゲートウェイインスタンスが同じボードの参加者にブロードキャストできるようにする。

4.3 オペレーションプロセッサー

• クライアント操作を受信する。
• スキーマ、ボード権限、オブジェクトの存在、レート制限を検証する。
• ボードごとにサーバーシーケンス番号を割り当てる。
• 追記型イベントログに操作を書き込む。
• インメモリボード状態またはスナップショットキャッシュを更新する。
• 正規操作を接続されているすべてのユーザーにブロードキャストする。

4.4 スナップショットビルダー

• イベントログを定期的にボードスナップショットに圧縮する。
• N回の操作またはT秒ごとにスナップショット作成をトリガーする。
• ボードロード時、クライアントは最新のスナップショット+スナップショットバージョン以降のオペレーションのテールをフェッチする。

5. 通信プロトコル

WebSocketをリアルタイム更新に使用

• 低遅延双方向通信に最適。
• 頻繁な小メッセージをサポート：ストローク、トランスフォーム、カーソル移動、確認。
• HTTPポーリングへのフォールバックは必要に応じてのみ、WebSocketがプライマリ。

HTTPS/REST（またはGraphQL）を非リアルタイムフローに使用

• ログイン/認証。
• ボードメタデータの取得。
• 最新スナップショット/履歴の取得。
• ボード/セッションの作成。
• エクスポート/インポート。

WebSocketメッセージタイプの例

• join_board {board_id, last_seq_seen}
• op_create_object
• op_append_stroke_points
• op_update_object
• op_delete_object
• op_reorder_object
• cursor_update
• selection_update
• ack {server_seq}
• snapshot_required / resync

6. データモデルと永続化

6.1 論理ボードモデル
ボード

• board_id
• owner/team
• permissions
• latest_seq
• snapshot_version
• created_at, updated_at

描画可能オブジェクト

• object_id
• type: stroke | textbox | rectangle | circle
• version
• z_index
• style: color, width, fill, font, etc.
• geometry:
  • stroke: pointsのリストまたは圧縮されたパスセグメント
  • textbox: x, y, width, height, text content
  • shape: x, y, width, height, rotation
• deleted flag or tombstone

操作/イベント

• op_id (冪等性用のUUID)
• board_id
• actor_id
• client_id
• client_op_seq
• server_seq
• timestamp
• op_type
• payload
• base_version or dependency metadata

6.2 永続化戦略
イベントソーシング+スナップショット

• すべてのユーザーアクションを不変の操作としてイベントログに永続化する。
• 定期的にマテリアライズされたスナップショットを保存して、ボードの再構築を高速化する。
• 利点：
  • 再生と監査証跡が容易。
  • 同期とリカバリが簡素化される。
  • コラボレーティブなタイムラインに適している。

推奨されるストレージ分割

• メタデータはリレーショナルDBに。
• イベントログは耐久性のある追記フレンドリーなストレージに（SQLテーブル、Kafka + DBシンク、またはNoSQLログストア）。
• スナップショットはオブジェクトストレージまたはドキュメントストアに。
• Redisは一時的なプレゼンスとホットボード状態用。

7. リアルタイム同期戦略

7.1 オペレーションベースの同期

• クライアントは、完全なキャンバスビットマップではなく、セマンティックな操作を送信する。
• 例：
  • 長方形の作成
  • ストロークSにポイントを追加
  • テキストボックスTのテキストを更新
  • 図形Xをデルタで移動
  • オブジェクトYの削除
• これにより帯域幅が低く保たれ、マージが管理可能になる。

7.2 シーケンスモデル

• サーバーはボードごとに単調増加するserver_seqを割り当てる。
• 正規のブロードキャスト順序はserver_seqによる。
• クライアントはlast_seq_seenを追跡する。
• 再接続時、クライアントはlast_seq_seen以降の欠落しているオペレーションを要求する。

7.3 楽観的なUI

• クライアントは自身のオペレーションを即座に適用する。
• server_seqで確認されるまで保留中としてマークする。
• サーバーがオペレーションを変換/拒否した場合、クライアントは保留中のオペレーションを正規状態の上にリベースして解決する。

7.4 バッチ処理とスロットリング

• フリーハンド描画は多数のポイントを生成するため、20〜50ミリ秒ごとに、またはNポイント後にポイントをバッチ処理する。
• カーソル更新は一時的なものであり、約20〜30 Hzにスロットリングし、永続化しない。
• これにより、リアルタイム感を維持しながら負荷が軽減される。

8. 競合解決

ホワイトボードには多くの独立したオブジェクトが含まれているため、単一のグローバルロックではなく、オブジェクトレベルの競合処理を使用する。

8.1 推奨アプローチ
オブジェクトごとのバージョニングと、オブジェクトタイプに応じた単純なOT/CRDTインスパイアールールを使用したオペレーションベースのモデルを使用する。

A. 独立したオブジェクト作成

• 同時作成は決して競合しない。
• 各オブジェクトにはグローバルに一意なobject_idが割り当てられる。

B. ストローク

• 描画中は各ストロークを追記専用として扱う。
• ストロークは通常、アクティブな描画状態中は作成者が所有する。
• 他のユーザーは通常、同じ進行中のストロークを変更できない。
• 一度完了すると、編集は個別のオペレーション（移動、スタイル変更、削除）になる。
• これにより、競合の複雑さが大幅に軽減される。

C. 図形とテキストボックス

• オブジェクトごとのバージョンを使用する。
• 更新にはbase_versionが含まれる。
• base_versionが現在のバージョンと一致する場合、直接適用する。
• 一致しない場合は、フィールドレベルのマージで解決する：
  • 位置とサイズの編集：ラストライターウィンまたはオペレーションが可換であればトランスフォームの合成。
  • 異なるフィールドでのスタイル変更はマージ可能。
  • テキストコンテンツ：同じテキストボックス内での同時テキスト編集が必須の体験であれば、テキストCRDT/OTを使用する。
    • リッチな同時テキスト編集がコアでない場合、各テキストボックスのアクティブなエディタロックを1つ許可するように簡略化する。

D. 削除対更新

• 削除は古い更新よりも優先される（更新がより新しいserver_seqを持ち、オブジェクトが削除解除/バージョン復元をサポートする場合を除く）。
• 後続のオペレーションを安全に識別して無視できるように、一時停止を短時間保持する。

8.2 このシステムの実用的な競合ポリシー
中程度の複雑さのホワイトボードの場合、実用的なポリシーは次のとおりです：

• server_seqによるボードレベルの順序付け。
• オブジェクトレベルのバージョンチェック。
• 図形/テキストボックスのトランスフォームとスタイルに対するラストライターウィン（編集が衝突した場合）。
• アクティブなテキストボックスコンテンツ編集に対するソフトロックまたはシングルエディタリース。
• 描画中の作成者所有権を持つ追記専用ストローク作成。

これはフルボードOTよりもシンプルであり、ほとんどの編集が異なるオブジェクトを対象とするホワイトボードには適しています。

9. 50人の同時ユーザー/ボードのスケーリング処理

これが実現可能な理由

• メッセージがコンパクトで、一時的なトラフィックがスロットリングされていれば、50ユーザーは中程度。

テクニック

• 高速ファンアウトのためのメモリ/キャッシュ内のボードごとのセッションシャード。
• pub/subを介したWebSocketファンアウト。
• ストロークポイントのバッチ処理。
• 必要であればpermessage-deflateでメッセージを圧縮する。
• カーソル/プレゼンスノイズの永続化を避ける。
• 長い再生時間を避けるために十分な頻度でスナップショットを取得する。

容量の考慮事項

• メモリ内のホットボード状態：現在のオブジェクトマップ、最新のシーケンス、参加者リスト。
• ブロードキャストパスはO（ボード内のユーザー数）であるべきで、50ユーザーなら問題ない。
• 後でセッションが大きくなった場合、リージョンエッジゲートウェイを追加し、コラボレーションワーカー間でセッションをパーティション化する。

10. 障害処理と信頼性

• すべてのオペレーションには、再試行時の重複排除のためのop_idがある。
• クライアントはlast_seq_seenで再接続し、見逃したオペレーションを受信する。
• ギャップが大きすぎるかスナップショットが期限切れの場合、サーバーは最新スナップショットからの完全な再同期を指示する。
• コラボレーションワーカーがクラッシュした場合、イベントログが耐久性を提供する。
• プレゼンス状態は一時的なものであり、再接続時に再構築される。

11. 500ミリ秒未満を維持するための遅延戦略

• WebSocket永続接続はリクエストセットアップコストを回避する。
• クライアントサイドの楽観的なレンダリングは、ほぼ即時のローカル応答を提供する。
• コラボレーションサーバーは、メモリ内でホットセッション状態を維持する。
• リージョン展開により、ユーザーは最寄りのゲートウェイの近くに配置される。
• バッチ処理はスループットと遅延のバランスを取る。ストロークには短いフラッシュ間隔を使用する。
• データベースを各更新で再読み取りするのではなく、メモリ/キャッシュからブロードキャストする。

12. セキュリティとアクセス制御

• トークン/Cookieを使用した認証済みWebSocketアップグレード。
• ボードレベルのACL：所有者/エディタ/ビューアロール。
• サーバーは、すべての操作を権限に対して検証する。
• 乱用や偶発的なフラッドを防ぐためのクライアントごとのレート制限。

13. エンドツーエンドフローの例

• ユーザーがHTTPS経由でボードを開き、最新のスナップショット+テールオペレーションを取得する。
• クライアントはWebSocketを確立し、last_seq_seenとともにjoin_boardを送信する。
• ユーザーが線を描画する。クライアントは即座にレンダリングし、バッチ処理されたappend_stroke_pointsオペレーションを送信する。
• サーバーは検証し、server_seqを割り当て、イベントログに追記し、セッション状態を更新し、すべてのユーザーにブロードキャストする。
• 他のクライアントはオペレーションを受信し、ストロークを段階的にレンダリングする。
• クライアントの1つが切断された場合、再接続して最後のシーケンス以降のオペレーションを要求する。

14. 推奨最終設計選択

• クライアント：ローカルファーストキャンバスレンダラー+楽観的なオペレーションバッファ。
• サーバー：WebSocketゲートウェイ+コラボレーション/セッションサービス+追記型オペレーションログ+スナップショット。
• プロトコル：リアルタイムオペレーション/プレゼンスにはWebSocket、ボードロードおよび管理APIにはHTTPS。
• 一貫性モデル：オブジェクトレベルのバージョニングによるサーバー順序のオペレーション。
• 競合解決：追記専用ストローク、図形用の単純なマージ/LWW、テキストボックスコンテンツ用のオプションロックまたはCRDT。

この設計は構築が容易で、ニアリアルタイムの共同編集ニーズを満たし、同期と競合処理を管理可能に保ちながら、ホワイトボードあたり50人の同時ユーザーに快適にスケーリングします。

リアルタイム共同編集ホワイトボードシステム設計

ハイレベルアーキテクチャ概要

システムは、クライアントサイドレンダリングとインタラクション、リアルタイム通信インフラストラクチャ、サーバーサイドの状態管理と永続化の3つの主要なレイヤーで構成されています。

主要コンポーネント

クライアントサイドアーキテクチャ

1. キャンバスレンダリングエンジン: WebGLまたはCanvas 2D APIを使用して、すべてのホワイトボード要素の効率的な描画とレンダリングを行います。
2. ローカル状態マネージャー: 即時的な視覚的フィードバックのために、キャンバス状態のローカルコピーを維持します。
3. 入力ハンドラー: ユーザーインタラクション（マウス/タッチイベント）をキャプチャし、描画操作に変換します。
4. WebSocketクライアント: サーバーへの永続的な双方向接続を確立します。
5. 競合解決レイヤー: サーバーに送信する前に、ローカルでオペレーショナル・トランスフォーメーションまたはCRDTロジックを適用します。
6. 元に戻す/やり直しマネージャー: ローカルの元に戻す/やり直し機能のために操作履歴を維持します。

サーバーサイドアーキテクチャ

1. WebSocketサーバー: Node.jsとSocket.ioまたはネイティブWebSocketを使用して、複数の同時クライアント接続を処理します。
2. セッションマネージャー: アクティブなホワイトボードセッションとユーザーのプレゼンス情報を維持します。
3. 操作ログ: 受信順にすべての描画操作を格納します。
4. 状態調停エンジン: 標準的なキャンバス状態に操作を適用し、更新をブロードキャストします。
5. 競合解決サービス: オペレーショナル・トランスフォーメーションまたはCRDTを実装して、同時編集を処理します。
6. 永続化レイヤー: データベースにホワイトボードのスナップショットと操作ログを保存します。
7. キャッシュレイヤー: アクティブなセッション状態への高速アクセス用にRedisを使用します。

通信プロトコル

プロトコル: WebSocket（JSONメッセージ形式）

メッセージタイプ:

• draw_operation: {userId, operationId, type, coordinates, color, strokeWidth, timestamp}
• add_shape: {userId, operationId, shapeType, position, dimensions, style, timestamp}
• add_text: {userId, operationId, text, position, fontSize, color, timestamp}
• delete_element: {userId, operationId, elementId, timestamp}
• cursor_position: {userId, x, y}（認識用）
• ack: {operationId}（受信確認）
• sync_request: {userId, lastKnownVersion}
• full_state: {version, elements, operations}

レイテンシ最適化:

• バイナリプロトコル（MessagePack）を使用してペイロードサイズを小さくします。
• メッセージバッチングを実装します：50ms間操作を収集してから送信します。
• 状態更新にはデルタ圧縮を使用します。
• 目標：最適化されたサーバー処理とCDN分散WebSocketサーバーによるエンドツーエンドレイテンシ500ms未満

データモデリング

キャンバス要素スキーマ:

Element {
  id: UUID,
  type: 'line' | 'rectangle' | 'circle' | 'text',
  userId: string,
  createdAt: timestamp,
  updatedAt: timestamp,
  version: number,
  data: {
    // 線の場合: points 配列 [{x, y}, ...]
    // 図形の場合: {x, y, width, height, rotation}
    // テキストの場合: {x, y, content, fontSize, fontFamily, color}
  },
  style: {color, strokeWidth, opacity, ...}
}

操作スキーマ:

Operation {
  id: UUID,
  sessionId: string,
  userId: string,
  type: 'create' | 'update' | 'delete',
  elementId: string,
  timestamp: number,
  lamportClock: number,
  payload: {...},
  clientId: string
}

リアルタイム同期戦略

オペレーショナル・トランスフォーメーション（OT）アプローチ

1. 操作順序付け: LamportクロックとuserIdを組み合わせて、同時操作の全順序を確立します。
2. 変換関数: 2つの操作が競合する場合、それらを互いに変換します：
   • ユーザーAが線を描画し、ユーザーBが同時にテキストを追加した場合、両方の操作が保持されます。
   • 変換により、すべてのクライアントで最終状態が一貫していることが保証されます。
3. サーバーを権威とする: サーバーは操作を受信し、Lamportクロック値を割り当て、同時操作に対して変換し、標準バージョンをブロードキャストします。
4. クライアントサイド予測: クライアントは、一時的なIDで楽観的に操作を適用し、サーバーが確認したら調停します。

競合解決プロセス

1. 検出: サーバーは、同時操作（同じ時間枠内に受信された）を特定します。
2. 変換: OT変換ルールを適用します：
   • 位置ベースの競合（同じ場所にある2つの図形）：両方を保持し、位置をわずかに調整します。
   • テキストの競合：Lamportクロックに基づいて挿入順序を維持します。
   • 削除の競合：タイムスタンプのタイブレーカーによるラストライトウィン。
3. ブロードキャスト: 変換された操作を、標準バージョン番号とともにすべてのクライアントにブロードキャストします。
4. クライアント調停: クライアントはローカルバージョンとサーバーバージョンを比較します。一致しない場合は、完全な状態同期を要求します。

50人の同時ユーザーの処理

1. 水平スケーリング: ロードバランサーの後ろに複数のWebSocketサーバーをデプロイします。
2. セッションシャーディング: 各ホワイトボードセッションは特定のサーバーインスタンスに割り当てられます。
3. Redis Pub/Sub: セッションが複数のサーバーにまたがる場合のサーバー間通信用。
4. 操作バッチング: 処理前に10〜20件の操作をバッチにグループ化します。
5. 遅延評価: 表示されているキャンバス領域のみをレンダリングし、画面外のレンダリングを遅延させます。
6. 接続プーリング: 永続化書き込みのためにデータベース接続を再利用します。

永続化戦略

1. 操作ログ: データベースに保存されたすべての操作の追記専用ログ。
   • 任意の履歴状態の完全な再構築を可能にします。
   • 監査証跡と元に戻す機能に対応します。
2. 定期的なスナップショット: 1000回の操作または5分ごとに、キャンバスのスナップショットを作成します。
   • サーバー再起動時の復旧時間を短縮します。
   • バージョン番号とともにデータベースに保存します。
3. 非同期書き込み: クライアントにブロードキャストした後、操作をデータベースに永続化します。
   • 永続化がリアルタイム更新をブロックするのを防ぎます。
   • 永続化のためにライトアヘッドログを使用します。
4. データ構造: ドキュメントデータベース（MongoDB）または時系列データベースに効率的なクエリのために格納します。

スケーラビリティに関する考慮事項

• メモリ: アクティブなセッションをRedisにキャッシュします。30分後に非アクティブなセッションをエビクトします。
• ネットワーク: メッセージ圧縮を実装します。CDNを静的アセットに使用します。
• データベース: 高速クエリのためにsessionIdとtimestampでインデックスを作成します。古いセッションをアーカイブします。
• 監視: 操作レイテンシ、接続数、競合率を追跡します。

セキュリティ対策

• セッションアクセスを許可する前にユーザーを認証します。
• サーバーサイドですべての操作を検証します。
• ユーザーごとのレート制限を実装します（最大100操作/秒）。
• 通信中のデータ（WSS）と保存中のデータを暗号化します。
• セッション権限のためのアクセス制御を実装します。

この設計は、リアルタイムの応答性と一貫性およびスケーラビリティのバランスを取り、500ms未満のレイテンシで最大50人の同時ユーザーの円滑なコラボレーションを可能にします。