50台のスクリーン、1つのURL：リアルタイム同期の仕組み

私が個人的に立ち会った中で最大規模のデプロイメントは、コンベンションセンターの3フロアに分散した47台のスクリーンで構成されていました。すべてのブレイクアウトルームにコンフィデンスモニター、廊下にカウントダウンディスプレイ、メインボールルームにマスターコントロールルームのマスタークロック、各入口にアジェンダボード、そしてプロダクションデスクのタブレットにコントロールサーフェス。これらすべてのスクリーンが同一のタイマー状態を表示し、同一のアニメーションフレーム内で更新され、単一のブラウザURLから供給されていました。 これは、ほとんどのウェブベースタイマーツールが破綻するシナリオです。2台や5台ではなく、47台が、同時に2,000人の参加者がストリーミング、メールチェック、プレゼンテーションファイルのダウンロードを行っている会場WiFiネットワーク上で接続されているのです。Timers Studioがこのシナリオを安定して処理できる理由を理解するには、その基盤となるアーキテクチャを理解する必要があります。 システムはデータ同期にデュアルパスアプローチを使用しています。第一のパスはステートデータを処理します。タイマー構成、テーマ設定、ランダウンメタデータ、スピーカー名、セグメント時間などです。このデータは変更頻度が低く、中程度のレイテンシを許容します。SupabaseのリアルタイムサブスクリプションレイヤーがPostgreSQLのlisten/notifyメカニズムを使用して接続クライアントに変更を伝播します。タイマーの名前変更やテーマカラーの変更を行うと、数百ミリ秒以内にすべての接続スクリーンがその更新を受信します。ステートデータにとって、この速度は十分以上です。 第二のパスはトランスポートコマンドを処理します。再生、一時停止、停止、次へ、前へ、巻き戻し、時間調整などです。これらのコマンドは聴衆やスピーカーがリアルタイムで目にするものに影響するため、物理的に可能な限り速く到達する必要があります。トランスポートコマンドはデータベースを完全にバイパスし、サーバーがすべての接続クライアントに同時にリレーする専用のWebSocketブロードキャストチャネルを通じて伝送されます。サーバーはこれらのコマンドを保存しません。受信して即座にファンアウトします。このため、データベース負荷やステートチャネルのネットワーク輻輳、接続スクリーンの数に関係なく、トランスポートレイテンシは10ミリ秒未満に維持されます。 初期同期はもう一つの重要な要素です。新しいPlayerスクリーンがセッションに接続する際、単にインクリメンタルアップデートの受信を開始することはできません。どのタイマーがアクティブか、残り時間はどれくらいか、ディスプレイ構成はどうなっているか、メッセージが現在表示されているかなど、完全な現在の状態が必要です。Timers Studioはこの完全な状態スナップショットを50ミリ秒未満で配信します。サーバーはメモリ内にセッション状態の圧縮された表現を維持し、新しいクライアントが接続すると、インクリメンタルアップデートが始まる前にこのスナップショットを最初のWebSocketメッセージとして送信します。 高速な初期同期の実用的重要性は、プロダクション環境に身を置くまで過小評価されがちです。スクリーンはショーの間中、切断と再接続を繰り返します。会場の技術者が解像度の問題を修正するためにディスプレイを電源リサイクルします。誰かが誤ってブラウザタブを閉じ、再び開きます。WiFiアクセスポイントが再起動します。これらすべてのケースで、再接続するスクリーンは即座に正しい状態を表示する必要があります。ローディングスピナーの後でも、プログレスバーの後でも、5秒のポーリング間隔の後でもなく。50ミリ秒未満ということは、スクリーンが空白から正しい表示に移行する速度が速すぎて、観察者には一度も切断されたことがわかりません。 50台の同時接続スクリーンへのスケーリングには、ほとんどのWebSocketチュートリアルが簡略化する課題があります。素朴なアプローチではサーバーが各クライアントに個別のメッセージを送信するため、トランスポートコマンドごとに50のメッセージが必要になります。これは線形にスケールし、サーバーのネットワークバッファを圧倒する可能性のある送信トラフィックのバーストを生みます。Timers Studioはブロードキャストパターンを使用し、サーバーがメッセージをチャネルに一度書き込み、WebSocketインフラストラクチャがトランスポート層でファンアウトを処理します。10台でも50台でも、サーバーのCPUコストは意味のある増加をしません。 再接続ストームの問題もあります。会場のWiFiが30秒間ダウンしてから復旧した場合、50台のスクリーンすべてが同時に再接続を試みます。慎重なエンジニアリングがなければ、この急増がWebSocketサーバーをクラッシュさせたり、その後数分間パフォーマンスを低下させるサンダリングハードを引き起こしたりする可能性があります。Timers Studioの再接続ロジックはジッター付きの指数バックオフを使用しており、各クライアントがわずかに異なるランダムな間隔で再接続を待ちます。これにより、再接続負荷が単一の瞬間に集中するのではなく、数秒間にわたって分散されます。 プロダクションチームがよく尋ねる質問にお答えしましょう。インターネット接続が完全に失敗した場合はどうなるのか。Playerスクリーンは最後の既知の状態を表示し続けます。実行中だったカウントダウンは、Playerが最後に受信したサーバータイムスタンプに基づく独自のアニメーションループを維持しているため、ローカルでカウントダウンを継続します。つまり、ネットワーク中断中でも、聴衆はまだカウントしている、短期間の単一デバイスのドリフト許容範囲内で正確なタイマーを目にします。接続が回復すると、Playerは自動的に再同期し、目に見えるジャンプなしに蓄積されたドリフトを修正します。 実際の会場では、すべてのスクリーンが同じネットワークパスを持つわけではないという異種ネットワーク条件にも、アーキテクチャは適切に対応します。一部はイーサネット、一部は5GHz WiFi、一部は2.4GHzです。高速接続のスクリーンは低速接続のスクリーンより数ミリ秒早く更新を受信しますが、すべてのパスの絶対レイテンシが人間の知覚閾値を大幅に下回っているため、その差は知覚されません。 ウェブベースツールが自分たちの規模を処理できるかどうかを評価するイベントプロデューサーにとって、関連する問いは抽象的な「何台のスクリーンをサポートできるか」ではありません。そのアーキテクチャが同時リアルタイム配信のために設計されたのか、それとも単一ユーザー向けに設計され後からポーリングとキャッシュで拡張されたのかということです。[コンソールを見る] 複数のブラウザタブでPlayer URLを同時に開くことで、Timers Studioのマルチスクリーン動作をご自身でテストできます。各タブは個別の物理スクリーンとまったく同じように動作し、それらの間の同期は即座で一貫しています。 冒頭で述べたコンベンションセンターのデプロイメントは、3日間問題なく稼働しました。手動での再同期は一度も必要ありませんでした。不正確な状態を表示したスクリーンはありませんでした。プロダクションチームはタイマーインフラストラクチャの存在を完全に忘れていました。それこそまさに、ショーコーラーが求めるインフラストラクチャの姿です。[今すぐ体験する] [スタジオを開く]