ユーザーがLumisにライブデータソースを接続すると、ダッシュボードが即座に更新されることを期待します。私たちは、数百万のデータポイントを処理しながら、企業グレードの信頼性を保ちながら、魔法のように感じるリアルタイムの更新を提供するシステムをどのように構築したのかを説明します。
技術的な課題
従来のBIツールは、ダッシュボードを数分または数時間ごとに更新し、ビジネス運用のリアルタイム性とデータビジュアライゼーションの静的な印象との間にフラストレーションを感じさせるギャップを作り出しています。私たちは、数千の同時ダッシュボード接続においてサブ秒の遅延更新を提供しながら、膨大な同時負荷を処理できるシステムを構築する必要がありました。
最大の課題は技術ではなく、コスト効果を保ちながらユーザーに瞬時の感覚を与えるシステムを設計することでした。
当初のアプローチでは、単純なポーリングメカニズムを使用しており、膨大な計算リソースを消費し、顕著な遅延を生み出していました。ユーザーは、新しい販売データをアップロードしたり、自分の`Salesforce`インスタンスに接続したりすると、数分待ってからダッシュボードが変更を反映するのを見ることになりました。これにより、ビジネス運用のリアルタイム性とデータビジュアライゼーションの静的な印象との間に不快なギャップが生じました。
技術要件は厳しく、50,000を超える同時WebSocket接続を処理し、毎分数百万のデータポイントを処理し、サブ200msの更新遅延を維持し、分散システム間でデータの整合性を確保し、パフォーマンスの劣化なしに水平スケーリングを行う必要がありました。また、`PostgreSQL`、`MySQL`、`MongoDB`、リアルタイムAPI、およびストリーミングデータフィードを含む複数のデータソースタイプをサポートする必要がありました。
アーキテクチャ設計とトレードオフ
私たちは、現在のハイブリッドシステムに落ち着く前に、いくつかのアーキテクチャアプローチを評価しました。それぞれのアプローチには、遅延、スケーラビリティ、コスト効率、実装の複雑さの間に重要なトレードオフがありました。
アーキテクチャアプローチ | 平均遅延 | コスト効率 |
|---|---|---|
単純なHTTPポーリング | 30-60秒 | 低 |
WebSocketストリーミング | 200-500ms | 中 |
サーバー送信イベント | 150-400ms | 中 |
ハイブリッドWebSocket + SSE | 100-200ms | 高 |
最終的に、リアルタイムの双方向通信のために`WebSockets`を使用し、メッセージキューイングと永続化のために`Redis Streams`を使用し、関連する更新をグループ化するためのインテリジェントバッチアルゴリズムを使用した洗練されたストリーミングアーキテクチャを構築しました。重要な洞察は、ユーザーは200ms以内に到着する更新を「リアルタイム」と認識するため、短い時間ウィンドウ内でのバッチ更新が可能であり、ユーザー体験を損なうことなく更新をバッチ処理できるということでした。
私たちのシステムは、メッセージブローカーとセッションストアの両方として`Redis`を使用し、長期データの永続化には`PostgreSQL`を使用しています。データ変更が発生すると、更新をトリガーするカスタム`EventProcessor`サービスを通じて、どのダッシュボードに更新が必要か、効率的にそれらをバッチ処理する方法、ユーザーの権限やサブスクリプションに基づいてどのユーザーがどのデータを受け取るべきかを決定するための複雑なロジックを実装します。
実装の詳細
リアルタイム更新システムは、シームレスなユーザー体験を提供するために連携するいくつかのコンポーネントで構成されています。`ConnectionManager`サービスはすべてのアクティブなWebSocket接続を追跡し、ユーザーセッションの状態を維持しています。また、`UpdateDispatcher`は、更新を正しい受信者にルーティングする複雑なロジックを処理します。
パフォーマンス最適化
サブ200msの目標遅延を達成するためには、いくつかの重要なパフォーマンス最適化を実装する必要がありました。これらの最適化は、ネットワークオーバーヘッドを最小限に抑え、サーバー処理時間を短縮し、全体的なシステムスループットを改善するために協力します。
インテリジェントな更新バッチ処理:個々のデータポイントの更新を送信するのではなく、ダッシュボードごとに関連する変更を時間ウィンドウでグループ化します。100msウィンドウ内で到着する更新は自動的にバッチ処理され、ネットワークリクエストの数を削減しつつ、リアルタイム更新の感覚を維持します。このアプローチにより、ピーク使用期間中のネットワークトラフィックが最大85%削減されました。
差分データ送信:各更新時に完全なデータセットを送信するのではなく、システムは現在の状態と前の状態の差分のみを計算して送信します。この差分アプローチにより、通常のビジネスデータに対して最大95%のペイロードサイズ削減を実現します。私たちは、ビジネスインテリジェンスアプリケーションで一般的な数値データに最適化された効率的なバイナリ差分アルゴリズムを使用します。
接続プーリングとマルチプレクシング:持続的なWebSocket接続を維持し、可能な限りデータベース接続を再利用します。私たちのConnectionPoolサービスは、効率的に数千の同時データベース接続を管理し、WebSocketManagerは接続ライフサイクルイベント、自動再接続ロジック、クライアントがネットワークの問題を経験したときの優雅な劣化を処理します。
マルチティアキャッシング戦略:Redisをホットデータ(頻繁にアクセスされるダッシュボードの状態)、Memcachedをウォームデータ(最近のクエリ結果)、予測されるユーザーアクションのためのインテリジェントなプリロードに使用して、洗練されたキャッシング階層を実装しています。キャッシュの無効化は、データ整合性を確保しながらキャッシュミスを最小限に抑えるイベント駆動パターンを通じて処理されます。
接続管理
システムの安定性を保持しながら数千の同時接続を管理するには、堅牢なフォールトトレランスメカニズムの構築が必要でした。ユーザーは、複数のブラウザタブを開いたり、モバイルアプリケーションに接続したり、チームメンバーによって共有されたダッシュボードを表示したり、さまざまな統合クライアントが同じデータストリームにアクセスしたりすることがあります。
私たちのConnectionManagerサービスは、これらすべての接続を追跡し、更新がネットワークを圧迫したり、重複処理のオーバーヘッドを生じさせたりすることなく、関連するすべてのエンドポイントに届けられるようにする複雑なロジックを実装しています。各接続には、ユーザーの権限、ダッシュボードのサブスクリプション、データソースへのアクセス権、クライアントの能力を含むメタデータがタグ付けされています。
ネットワークの問題により接続が失われた場合、システムは急激な集中による問題を防ぐためにジッターを伴う指数バックオフ再試行ロジックを実装します。接続が切断された期間中に失われた更新はキューに蓄えられ、接続が再確立されると配信され、ユーザーは一時的なネットワークの中断中でも重要なデータ変更を失うことがありません。
監視と可観測性
スケールでリアルタイムシステムを運営するには、包括的な監視と可観測性が必要です。私たちは、更新遅延のパーセンタイル、地理的地域別の接続数、データ処理スループット、コンポーネント別のエラー率、キャッシュヒット率、ユーザーエンゲージメントパターンなど、数十のメトリックを追跡します。
私たちの監視スタックは、メトリック収集のためにPrometheusを、視覚化のためにGrafanaを使用し、システムのパフォーマンスが許可された閾値を下回るときにエンジニアリングチームに通知するカスタムアラートロジックを実装しています。私たちは、リアルタイムのシステム健康を示す詳細なダッシュボードを維持し、ユーザー体験に影響を与える前に、パフォーマンスの問題を特定して解決します。
結果
6ヶ月の最適化と生産強化の後、私たちのリアルタイム更新システムは、すべての主要なメトリックにわたって一貫して優れたパフォーマンスを提供しています。ダッシュボードの更新は、平均145msの遅延で到着し、99%の更新がピークトラフィック期間中でも300ms以内に配信されます。
システムは、最小限のパフォーマンス劣化で50,000の同時WebSocket接続のピーク負荷を成功裏に処理します。接続あたりのメモリ使用量は2.3KBに最適化され、数千の同時ユーザーをサポートするためにコスト効率を維持しながらスケーリングできます。データベースクエリパフォーマンスは、毎分数百万のデータポイントを処理しても一貫しています。
おそらく最も重要なことは、ダッシュボードの応答性に対するユーザーの満足度が、リアルタイム更新システムを実装して以来、78%向上したことです。ユーザーは、Lumisが「魔法のように」および「瞬時に応答する」と報告し、私たちが提供しようとしたシームレスな体験を作り出しています。システムの信頼性は卓越しており、過去6ヶ月間で99.97%の稼働時間を達成し、ユーザーから報告されたデータ整合性問題はゼロです。







