リアルタイム共同ホワイトボードシステムを設計する

# リアルタイム共同編集ホワイトボード — システム設計 ## 1. ハイレベルアーキテクチャ コンポーネントとリクエスト/データフロー: ``` ┌──────────────┐ Web/Mobile/Desktop │ Clients │ (Canvas rendering, local CRDT replica, Clients ─────► │ (100/board) │ WebSocket client, offline buffer) └──────┬───────┘ │ HTTPS (REST) + WSS (WebSocket) ┌──────▼───────┐ │ CDN │ (static assets, exported images) └──────┬───────┘ ┌──────▼───────────────┐ │ Global Load Balancer │ (L7, TLS termination, │ + API Gateway │ auth, rate limiting) └───┬───────────────┬───┘ REST traffic │ │ WS upgrade (sticky by sessionId) ┌──────────────▼──┐ ┌─────▼───────────────┐ │ Stateless App │ │ Realtime Collab │ │ Services │ │ Servers (WS) │ │ (auth, board │ │ - hold in-memory │ │ CRUD, sharing, │ │ board state │ │ exports) │ │ - merge ops (CRDT) │ └───┬────────┬─────┘ │ - broadcast deltas │ │ │ └───┬───────────┬──────┘ ┌───────▼──┐ ┌───▼─────┐ ┌────▼────┐ ┌───▼────────┐ │ Metadata │ │ Object/ │ │ Redis │ │ Session │ │ DB │ │ Blob │ │ Pub/Sub │ │ Routing │ │(Postgres)│ │ Store(S3)│ │+Presence│ │(Consistent │ └──────────┘ └─────────┘ └─────────┘ │ hashing) │ │ └────────────┘ ┌───────▼─────────────┐ ┌─────────────────────────────┐ │ Document/Op Store │ │ Async Workers (Kafka queue) │ │ (DynamoDB/Cassandra: │◄──│ - snapshotting │ │ ops log + snapshots) │ │ - thumbnail/export gen │ └─────────────────────┘ │ - analytics │ └─────────────────────────────┘ ``` **インタラクションの概要:** クライアントはAPI Gateway (REST) を介して認証を行い、その後 Realtime Collab サーバーへの永続的な WebSocket 接続を開きます。ゲートウェイは `sessionId` に対する一貫性ハッシュを使用して、1つのボードの全参加者が同じサーバー（または小規模なレプリカセット）に到達するようにし、権威あるライブ状態を1か所に保持します。App Services は、リアルタイムではないCRUD（ボードの作成、共有、一覧表示、エクスポート）を処理します。Redis Pub/Sub は Realtime サーバー間のブリッジとして機能し、参加者がインスタンス間で分割されていても、操作が確実に伝播するようにします。Async Workers は定期的にスナップショットと操作ログを耐久性のあるストレージに永続化します。 ## 2. リアルタイム通信 - **プロトコル:** WebSocket (WSS) は、全二重、低遅延の双方向メッセージングに使用されます。制限の厳しいネットワークでは、Socket.IO のようなライブラリを介した HTTP ロングポーリングにフォールバックします。カーソル/プレゼンスのピアツーピア通信には WebRTC データチャネルが検討されましたが、シンプルさと信頼性のためにサーバーリレーモデルが採用されました。 - **メッセージモデル:** クライアントは、ボード全体の状態ではなく、小さな**操作/デルタ**（例: `{type:'stroke_add', objId, points, color}`, `{type:'obj_move', objId, dx, dy}`）を送信します。サーバーは操作を検証し、シーケンス/バージョンを割り当て、マージし、そのデルタを他のすべてのセッションメンバーにブロードキャストします。 - **ファンアウト:** 各 Realtime サーバーは、ボードごとの接続セットをメモリ内に保持し、デルタを直接ブロードキャストします。メンバーが複数のサーバーにまたがるボードについては、送信元のサーバーが操作を `sessionId` をキーとする Redis Pub/Sub チャネルに発行します。購読しているサーバーは、ローカルの接続に再ブロードキャストします。 - **プレゼンスとカーソル:** 高頻度の低価値データ（ライブカーソル位置、選択範囲）は、スロットリング（約30〜60ms）され、ベストエフォートで送信され、永続化されることはありません。 - **遅延ターゲット（<200ms）:** 地域ごとの Realtime クラスター、スティッキー ルーティング（リージョン間ホップなし）、バイナリ/コンパクト JSON ペイロードの最小化、および楽観的なローカルレンダリング（クライアントは自身の操作を即座に適用し、その後調整する）によって達成されます。 ## 3. データモデル **ボードメタデータ (Postgres — リレーショナル、トランザクショナル):** - `boards(board_id, owner_id, title, created_at, updated_at, latest_snapshot_id)` - `users(user_id, name, email, ...)` - `board_permissions(board_id, user_id, role[owner|editor|viewer])` - `sessions(session_id, board_id, started_at, active_user_count)` **ボードコンテンツ (DynamoDB/Cassandra — 高い書き込みスループット、追記フレンドリー):** - **操作ログ:** パーティションキー `board_id`、ソートキー `version`（単調増加）。各行は1つの操作 `{op_type, object_id, payload, user_id, timestamp}` です。 - **スナップショット:** 定期的にマテリアライズされたフルステートブロブ `{board_id, snapshot_version, state_json/binary}` をオブジェクトストレージ (S3) に格納し、ポインタ行を付けます。ボードのロード = 最新のスナップショット + そのスナップショットバージョン以降の操作の再生。 **ボード内のオブジェクト構造:** ``` WhiteboardObject { id, type: "stroke" | "text" | "sticky", layer/zIndex, geometry: { x, y, width, height, rotation }, props: { // type-specific stroke: { points:[...], color, thickness }, text: { content, font, color }, sticky: { content, bgColor } }, createdBy, lastModified, version } ``` **競合解決:** オブジェクトセットには **CRDT** (例: Yjs/Automerge のようなリスト/マップ CRDT) または OT を使用し、同時編集（異なるオブジェクトまたは同じオブジェクトを移動/編集する2人のユーザー）が中央ロックなしで決定論的に収束するようにします。各オブジェクトには、競合するプロパティ更新に対する最終書き込み者勝ち（last-writer-wins）のための論理クロックが含まれます。 **大きな/バイナリのアセット**（アップロードされた画像、エクスポートされたPNG/PDF）は S3 スタイルのブロブストレージに配置され、オブジェクト内の URL で参照されます。 ## 4. スケーラビリティと信頼性の戦略 **1万セッション / 100万ユーザーへのスケーリング:** - **ステートレスアプリ層:** ロードバランサーの後ろで水平に自動スケーリングされ、ノードの追加が容易です。 - **リアルタイム層:** 一貫性ハッシュによる `sessionId` でシャーディングされます。ボードあたり最大100ユーザーの場合、1万セッション = 最大約100万同時 WebSocket 接続。1つのチューニングされたノードは約1万〜5万接続を処理します。ファンアウトは、各ボードのメンバーが1つのノードに集中するようにサイズ設定されています。接続数と CPU で自動スケーリングします。 - **Redis:** クラスター化され、Pub/Sub ファンアウトとプレゼンスに使用されます。セッションごとにパーティション化されます。 - **データベース:** メタデータには読み取りレプリカを持つ Postgres。高ボリュームの操作ログには水平スケーリング可能な DynamoDB/Cassandra。オブジェクトストレージは事実上無限にスケーリングします。 - **スナップショット:** Async Workers が、再生コストとストレージを制限するために、一定のペース（例: N 操作ごと、または T 秒ごと）で操作ログをスナップショットに圧縮します。 **高可用性 (99.9%):** - すべての層でマルチ AZ デプロイメント。ディザスタリカバリのためにマルチリージョン。 - Realtime サーバーは、ボードごとにウォームスタンバイ/レプリカで実行されます。ノード障害が発生した場合、クライアントは自動的に再接続し、新しいノードは最新のスナップショット + 操作ログから状態を再構築します（メモリ内の最後の数秒間の操作は、クライアントのローカルバッファから再送信される可能性があります）。 - ヘルスチェックとロードバランサーでの自動フェイルオーバー。 - オペレーションストームに対するバックプレッシャーとレート制限。 - 耐久性のある操作ログにより、サーバークラッシュ時でもコミットされた作業が失われないリカバリポイントが得られます。 ## 5. トレードオフ **選択されたトレードオフ: 強い一貫性 (CP) よりもレイテンシ/可用性 (AP)、CRDT を使用。** 200ms 未満の応答性とオフライン耐性を優先し、クライアントが操作を楽観的に適用し、CRDT/最終書き込み者勝ちで競合を解決することで、**結果整合性**を受け入れます。利点は、UI が即座に感じられ、ユーザーは短いネットワークパーティション中に編集でき、フェイルオーバー中にシステムが利用可能であることです。コストは、まれな同時編集ケースで、収束した結果が単一ユーザーの直感的な期待と一致しない可能性があること（例: 同じテキストへの同時編集）、および CRDT メタデータがメモリ/ストレージのオーバーヘッドを追加することです。ホワイトボードにとっては、トランザクショナル/ロッキング (CP) アプローチが課す厳密な直列化一貫性よりも、クリエイティブなコラボレーションでは流動性と可用性をはるかに重視するため、これは正しい判断です。これは、ラウンドトリップの遅延を追加し、パーティション中の可用性を低下させます。 **二次的なトレードオフ:** 各ボードの単一 Realtime ノードで権威あるライブ状態をメモリ内に保持すること（高速ブロードキャスト、シンプルなマージ）対、完全にステートレスな層（より回復力があるが高遅延）。スナップショット + 操作ログで軽減され、フェイルオーバー時にどのノードでも状態を再構築できます。

1. ハイレベルアーキテクチャ 優れた設計とは、ステートレスAPI、ステートフルなリアルタイムコラボレーションワーカー、永続ストレージ、イベントストリームのハイブリッドです。 主要コンポーネント: - Web/モバイルクライアント - 静的アセット用のCDN - APIゲートウェイ/ロードバランサー - 認証サービス - ホワイトボードメタデータサービス - リアルタイムコラボレーションサービス - セッションルーター/プレゼンスサービス - メッセージバス/イベントストリーム - パーシステンスパイプライン - メタデータ用のプライマリデータベース - ホワイトボードのスナップショットと要素の状態用のオブジェクト/ドキュメントストア - キャッシュ (Redis) - モニタリング、トレーシング、レート制限 テキスト図: クライアント -> アプリ資産用のCDN -> APIゲートウェイ/LB -> 認証サービス -> ホワイトボードAPIサービス -> セッションルーター -> リアルタイムコラボレーションノード (WebSocket) -> Redis / インメモリセッション状態 -> シャードごとのPub/SubまたはKafkaトピック -> パーシステンスワーカー -> スナップショットストア -> メタデータDB フロー: - ユーザーがアプリを開き、認証を行います。 - クライアントはREST/HTTP API経由でホワイトボードのメタデータと最新の永続状態を取得します。 - クライアントはその後、ボードセッションのためにWebSocketにアップグレードします。 - セッションルーターは、クライアントをそのホワイトボードを担当するコラボレーションノードに送信します。 - ユーザーは、描画ストロークセグメントの作成、テキストボックスの作成、オブジェクトの移動、付箋の編集などの操作を送信します。 - コラボレーションノードは操作を検証、シーケンス化し、セッション内のすべての参加者にブロードキャストします。 - 操作はイベントログに追加され、定期的にスナップショットにコンパイルされます。 - 再接続または再オープン時に、クライアントは最新のスナップショットと最近の操作をロードします。 実用的なパーティショニング: - 一貫性ハッシュまたはボード対ノードのマッピングサービスを使用して、1つのボードセッションが一度に1つのコラボレーションノードによって所有されるようにします。 - これにより、順序付けと競合処理が簡素化されます。 - 10,000の同時セッションとセッションあたり最大100ユーザーの場合、システムは大規模ですが、コラボレーションノードの水平スケーリングで管理可能です。 2. リアルタイム通信 プロトコル: - TLS over WebSocketが主な選択肢です。 - 理由: 低遅延の双方向通信、広範なブラウザ/モバイルサポート、ロングポーリングよりもシンプル、頻繁な小規模更新に効率的です。 更新モデル: - クライアントはボード全体の状態ではなく、操作を送信します。 - 操作の例: - start_stroke, append_stroke_points, end_stroke - create_text, edit_text - create_sticky, move_object, resize_object, delete_object - コラボレーションノードは操作にタイムスタンプを付け、シーケンス化し、そのボード内のすべてのクライアントにブロードキャストします。 順序付けとファンアウト: - 単一のボード内で、単調増加するシーケンス番号を維持します。 - そのボードからのすべての操作は、ボードごとの総順序を提供するその所有者コラボレーションノードを通過します。 - ローカルの接続済みクライアントにブロードキャストします。フェイルオーバーのためにレプリカまたは複数のノードが同じボードをサービスする場合、Redis Pub/SubまたはKafkaをレプリケーション/イベント処理に使用します。 遅延ターゲット200ms未満: - コラボレーションノードを、リージョン展開を使用してユーザーの地理的に近くに配置します。 - スティッキールーティングを使用して、ボードのすべてのユーザーができるだけリージョン内の同じノードにヒットするようにします。 - デルタのみをブロードキャストし、ペイロードを圧縮し、数ミリ秒ごとにペンポイントをバッチ処理します。 - フリーハンド描画の場合、サーバー確認前にローカルで即座に楽観的レンダリングを許可し、必要に応じて調整します。 競合処理: - テキストボックスの移動や付箋の編集などのオブジェクトベースの編集には、オブジェクトごとのバージョニングを使用します。 - 高度に同時実行される状態の場合、リッチなマルチユーザー編集が必要な場合は、オペレーショナルトランスフォームまたはCRDTに触発されたマージを使用します。 - ハイレベルなホワイトボードシステムの場合、よりシンプルなモデルで十分です: - ペンストロークは追記専用であり、自然にうまくマージされます。 - オブジェクト変換は、ラストライトウィンまたはサーバー順序付けを使用します。 - テキストコンテンツは、最初はよりシンプルなオブジェクト全体の編集ロックを使用するか、後で同時テキスト編集のためにOT/CRDTに進化させることができます。 3. データモデル 分割モデルを使用します: メタデータリレーショナルDB + ドキュメント/ブロブストレージ内のボードコンテンツ + 操作ログ。 A. ホワイトボードメタデータ テーブル: Whiteboard - board_id - owner_user_id - title - created_at - updated_at - last_snapshot_id - access_policy - region - status テーブル: WhiteboardMember - board_id - user_id - role (owner/editor/viewer) - invited_at テーブル: ActiveSession - session_id - board_id - user_id - connection_id - joined_at - last_heartbeat - presence_state B. ボードコンテンツモデル ボードを無限または境界付きキャンバス上の要素のコレクションとして表現します。 要素の基本フィールド: - element_id - board_id - type: stroke | text | sticky_note | shape - created_by - created_at - updated_at - z_index - position {x, y} - rotation - style object - version - deleted flag ストローク要素: - element_id - points: ポリラインまたはベジェ曲線圧縮ポイントリスト - color - width - opacity テキスト要素: - element_id - text_content - font_family - font_size - bounding_box 付箋要素: - element_id - text_content - background_color - bounding_box C. 操作ログ テーブルまたはストリーム: BoardOperation - op_id - board_id - seq_no - user_id - op_type - target_element_id - payload - client_timestamp - server_timestamp ペイロード例: - 初期プロパティを持つ要素の作成 - ストロークポイントの追加 - オブジェクトを古い位置から新しい位置に移動 - テキストのパッチ - 要素の削除 D. スナップショット ドキュメント/ブロブストアに保存されるスナップショットオブジェクト: - snapshot_id - board_id - base_seq_no - created_at - シリアライズされたボード状態またはチャンク化された空間パーティション スナップショット + 操作ログの理由: - 無限に履歴全体を再生するのは遅すぎます。 - スナップショットにより高速ロードが可能になります。 - スナップショット復元後の最近の操作により、最新の状態が復元されます。 大規模ボードのオプション最適化: - 空間チャンキング: キャンバスをタイル/領域にパーティション化して、クライアントが可視コンテンツのみをロードするようにします。 - ボードが非常に大きくなった場合に役立ちます。 4. スケーラビリティと信頼性戦略 スケーラビリティ A. コラボレーションノードの水平スケーリング - コラボレーションサービスはクリティカルパスです。 - 各ノードは、それに割り当てられたアクティブなボードセッションをインメモリで維持します。 - セッションはboard_idによってシャーディングされます。 - 平均セッションサイズが控えめな場合、多くのセッションをノードごとにホストできます。 - ロードバランサーとセッションルーターにより、ユーザーは正しいノードに参加できます。 B. イベント駆動型パーシステンス - 遅延を悪化させるため、すべてのペンポイントをプライマリDBに同期的に書き込まないでください。 - 代わりに: - コラボレーションノードが操作を受け入れます。 - 永続ログ/レプリケートキューに追加します。 - 即座にブロードキャストします。 - 非同期ワーカーが永続化し、スナップショットにコンパイルします。 - 耐久性のために、より強力な保証が必要な場合は、ACKの前にKafka/Pulsarまたはレプリケートされたライトアヘッドログを使用します。 C. 効率的な描画トラフィック - ペンツールは1秒あたりに多くのポイントを生成する可能性があります。 - 次の方法でボリュームを削減します: - クライアントサイドのポイント簡略化 - 10〜30ミリ秒ごとにポイントをバッチ処理します。 - 必要に応じて、冗長なJSONではなくバイナリエンコーディングを使用します。 - WebSocketでのgzip/permessage-deflate。 D. キャッシュ - ボードメタデータ、プレゼンス、ルーティングマップ、ホットスナップショット用のRedisキャッシュ。 - 最近のボードと権限は、DB負荷を軽減するためにキャッシュできます。 E. ストレージ戦略 - ユーザー、ボード、権限、共有メタデータ用のリレーショナルDB (PostgreSQL/MySQL)。 - スナップショット用のドキュメント/ブロブストア (S3/オブジェクトストレージまたはドキュメントDB)。 - 操作用のストリーム/ログシステム。 - これにより、すべてのアクセスパターンを1つのデータベースで処理することを回避できます。 信頼性/高可用性 A. マルチAZ展開 - API、コラボレーションノード、Redis、データベースを複数のアベイラビリティゾーンにまたがって実行します。 - ロードバランサーはインスタンスのヘルスチェックを行い、自動的にルーティングします。 - マルチAZとローリングデプロイにより、99.9%のアップタイムが達成可能です。 B. コラボレーションノードのフェイルオーバー - ボードの所有権はステートフルであるため、ノードの障害は重要です。 - 軽減策: - 操作は永続ログに継続的にレプリケートされます。 - 定期的なインメモリチェックポイントまたは高速スナップショット。 - セッションルーターはノードの損失を検出し、ボードを別のノードに再割り当てします。 - クライアントは自動的に再接続し、スナップショットとテール操作をロードします。 - 短い中断は許容範囲内であり、ユーザーは迅速に回復します。 C. プレゼンスとハートビート - WebSocketハートビートは切断を検出します。 - プレゼンスサービスは、RedisのTTLを使用してアクティブユーザーの状態を更新します。 D. バックプレッシャーと保護 - ユーザーごとおよびボードごとのレート制限。 - 過剰な移動/ドラッグイベントのドロップまたは統合。 - コントロールプレーントラフィックとデータプレーンを分離します。 - ノイジーなセッションがすべてのノードリソースを消費するのを防ぎます。 E. 耐久性の選択肢 2つのオプション: - 低遅延: 操作がメモリで受け入れられ、非同期にレプリケートされた後にACK。 - 高耐久性: レプリケートされたログへの追加後にのみACK。 信頼性と速度のバランスをとるために、オブジェクトの変更にはACK後のログ追加、ペンセグメントにはバッチ処理を選択します。 容量の根拠 - 10,000の同時セッションx平均10アクティブユーザー/セッションは平均100,000の同時接続です。最悪の場合、すべてのセッションが100ユーザーの場合1,000,000ですが、これはおそらく意図された定常状態ではありません。設計は、水平方向に数百千のWebSocketをサポートする必要があります。 - 各コラボレーションノードは、数万のアイドル/ライト接続、またはヘビーセッションの場合はそれより少ない接続をサポートできるため、オートスケーリングとアクティブボード数およびイベントレートによるシャーディングでスケールアウトします。 5. トレードオフ 主要なトレードオフ: 一貫性 vs. 遅延。 厳密なグローバル一貫性よりも、低遅延とスムーズなコラボレーションを優先します。 これは何を意味するか: - クライアントは自身の描画を即座に楽観的にレンダリングします。 - サーバーはボードごとの権威ある順序付けを提供しますが、一部の操作はサーバー順序またはラストライトウィンなどの単純なルールを使用してマージされる場合があります。 - パーシステンスは、データベーストランザクションですべての更新をブロックするのではなく、ほぼリアルタイムです。 このトレードオフが良い理由: - ホワイトボードのUXは非常にインタラクティブであり、ユーザーは時折発生する軽微な調整よりも遅延に気づきます。 - ペンストロークとオブジェクトの移動は、非常に短いウィンドウ内での最終的な一貫性に耐性があります。 - すべての編集に対する厳密なシリアライズ可能なトランザクションは、遅延を増加させ、スループットを低下させます。 この選択のコスト: - 同じオブジェクトに対する同時編集中に、ユーザーは小さなジャンプや上書きされた更新を目にする可能性があります。 - ノード障害からの回復には、短い操作履歴の再生が必要になる場合があります。 - リッチな同時テキスト編集には、後でより高度なOT/CRDTメカニズムが必要になる場合があります。 概要設計 - 認証、ボードメタデータ、スナップショット用のREST API。 - ライブコラボレーション用のWebSocket。 - シーケンス化とファンアウトのためのボードごとの論理的な所有者コラボレーションノード。 - ルーティングとプレゼンス用のRedis/キャッシュ。 - 永続的な操作ストリーミング用のKafka/PubSub/イベントログ。 - メタデータ/権限用のリレーショナルDB、スナップショットとボード状態用のオブジェクトストアまたはドキュメントストア。 - マルチAZ展開、オートスケーリング、再接続/フェイルオーバー、非同期スナップショット化による信頼性とスケーラビリティ。 このアーキテクチャは、ほぼリアルタイムの要件を満たし、永続性をサポートし、多くのアクティブセッションにスケーリングし、システムを運用上実用的に保ちます。