デュアルオーケストレーターとパケットロスゼロの自動スケーリングRTSPストリーミングアーキテクチャ
ある監視プラットフォームでは、そのビデオストリーミングインフラストラクチャを動的にスケーリングする必要がありました。10台から200台以上のIPカメラを、数百人の同時視聴者とAI処理ワーカーで処理し、スケーリング操作中にパケットロスゼロを保証しつつ、決して変更されない安定したストリームURLを維持することが求められました。
プロジェクトを相談する
課題
固定のストリーミングインフラストラクチャでは、成長する監視プラットフォームの変動する要求に対応できませんでした。
- スケールの変動性 — カメラ数と視聴者需要は一日を通して劇的に変動しました（ピークから谷までの比率が10倍）
- 過剰プロビジョニングコスト — ピーク負荷に備えてプロビジョニングすると、オフピーク時に70%以上のリソースがアイドル状態になりました
- スケーリング中のパケットロス — ストリーミングサーバーの追加または削除はストリーム中断を引き起こし、AI処理ワーカーのフレームをドロップさせました
- URL の不安定性 — 特定のサーバーIPで構成されたカメラと視聴者は、インフラストラクチャが変更されるたびに再構成が必要でした
- 異なるスケーリング要件 — カメラのインジェストと視聴者のディストリビューションは、根本的に異なる負荷パターンを持ち、独立したスケーリングが必要でした
- AI ワーカーの機能停止 — ソースストリームサーバーがスケールダウンされると、AI処理パイプラインがクラッシュしました
私たちのソリューション
当社は、個別のインジェストクラスターとディストリビューションクラスター、パケットロスゼロを実現する5段階のグレースフルシャットダウン、安定したDNSベースのURL、および自動AIワーカー再接続を備えたデュアルオーケストレーターの自動スケーリングストリーミングアーキテクチャを設計しました。
アーキテクチャ
- ストリーミングサーバー: RTSP/WebRTC/HLS プロトコルをサポートするMediaMTX
- インジェストクラスター: カメラのRTSPストリームを受信する1～10台のサーバー
- ディストリビューションクラスター: 視聴者 (WebRTC/HLS) およびAIワーカー (RTSP) にサービスを提供する2～20台のサーバー
- デュアルオーケストレーター: インジェストとディストリビューションのための独立したスケーリングコントローラー
- ロードバランサー: プロトコルに適したアルゴリズムを備えたクラスターごとの個別のロードバランサー
- サービスレジストリ: サーバーの状態、ストリームマッピング、および連携のためのRedis
- ヘルスモニタリング: 自動復旧を伴うアクティブなヘルスチェック
- DNSレイヤー: ロードバランサーを指す安定したドメイン名 (URLは決して変更されません)
デュアルオーケストレーターの設計
なぜ2つのオーケストレーターが必要なのか
インジェストとディストリビューションは、根本的に異なるスケーリング特性を持っています。
- インジェストはカメラ数とインバウンド帯域幅によってスケールします（予測可能で、着実に増加します）
- ディストリビューションは視聴者数とAIワーカーの需要によってスケールします（バースト的で、予測不可能です）
個別のオーケストレーターを使用することで、各クラスターが独自のポリシー、メトリクス、しきい値を用いて独立してスケーリングでき、一方のクラスターのスケーリング決定がもう一方に影響を与えることはありません。
インジェストオーケストレーター
- プライマリメトリック: サーバーあたりのカメラ接続数
- セカンダリメトリック: インバウンド帯域幅利用率
- スケールアップ: CPUがしきい値を超えた場合、またはサーバーあたりのカメラ数が容量を超えた場合
- スケールダウン: 継続的な安定化期間中に利用率がしきい値を下回った場合
- サーバー範囲: 1～10台のサーバー
ディストリビューションオーケストレーター
- プライマリメトリック: サーバーあたりの視聴者 + AIワーカー接続数
- セカンダリメトリック: アウトバウンド帯域幅利用率
- スケールアップ: CPUがしきい値を超えた場合、またはサーバーあたりの接続数が容量を超えた場合
- スケールダウン: 継続的な期間（インジェストよりも長い安定化期間）中に利用率がしきい値を下回った場合
- サーバー範囲: 2～20台のサーバー（高可用性のために最低2台）
パケットロスゼロ：5段階のグレースフルシャットダウン
ディストリビューションサーバーが削除されるようにスケジュールされた場合、5段階のプロセスによりフレームが失われないことが保証されます。
フェーズ1：事前通知サーバーはサービスレジストリで「DRAINING」とマークされます。ロードバランサーの重みが減らされ、新しい接続は他の場所にルーティングされます。Redisのpub/sub通知とwebhookは、AIワーカーに移行の準備を促します。
フェーズ2：ロードバランサーの更新サーバーはロードバランサーのバックエンドプールから削除されます。ドレイニング中のサーバーには新しい接続は到達できません。既存の接続は中断されることなく継続されます。
フェーズ3：AIワーカーの移行AIワーカーはドレイニング中のサーバーから切断し、健全なディストリビューションサーバーに再接続します。チェックポイントベースの状態保存により、処理は中断した正確なフレームから再開されます。総ギャップは約3秒で、フレームの損失はゼロです。
フェーズ4：視聴者の排出残りの視聴者接続は、設定可能なウィンドウ内で自然に排出されます。最新のビデオプレーヤーは、同じ安定したURLに自動再接続し、これは健全なサーバーにルーティングされます。ほとんどの視聴者は中断を経験しません。
フェーズ5：クリーンアップすべての接続が閉じていることを確認します。サービスレジストリからサーバーを削除します。クラウドインスタンスを破棄します。スケーリングメトリクスを記録します。
安定したURL
URLアーキテクチャにより、カメラやクライアントは再構成の必要がありません。
- カメラの公開ターゲット: 安定したインジェストドメイン名
- 視聴者/AIのアクセスターゲット: 安定したディストリビューションドメイン名
- DNSレコードはロードバランサーのIP（永続的です）を指します
- ロードバランサーはバックエンドサーバーへのルーティングを透過的に処理します
- バックエンドサーバーは、URLを変更せずに、追加、削除、または交換できます
サービスレジストリ (Redis)
一元化されたRedisインスタンスがシステム全体を連携させます。
- サーバーの状態追跡（アクティブ、ドレイニング中、オフライン）
- ストリームとサーバーのマッピング（どのカメラがどのインジェストサーバー上にあるか）
- AIワーカーの状態とチェックポイントデータ
- スケーリング決定のためのサーバーごとの負荷メトリクス
- リアルタイムの連携イベントのためのpub/subチャネル
AIクライアントの再接続
AIクライアントライブラリはシームレスな再接続を提供します。
- Redisのpub/subを介してサーバー削除通知をリッスンします
- 定期的な間隔での自動フレームチェックポイント
- 通知があった場合の健全なディストリビューションサーバーへの再接続
- 最小限のギャップでチェックポイントから処理を再開します
- 再接続イベントのメトリクスレポート
ヘルスモニタリング
- すべてのサーバーで定期的にアクティブなヘルスチェック
- サーバー障害時のロードバランサーの自動更新
- 応答しないサーバーに対する自動復旧トリガー
- アップタイム追跡と可用性レポート
主要機能
- デュアルオーケストレーター — インジェストおよびディストリビューションクラスターの独立したスケーリング
- パケットロスゼロ — AIワーカーの移行を伴う5段階のグレースフルシャットダウン
- 安定したURL — DNSベースのルーティングにより、スケーリング中にURLが変更されることはありません
- AIワーカー再接続 — 約3秒のギャップとフレームロスゼロのチェックポイントベースの移行
- 独立したスケーリング — インジェストとディストリビューションは独自のメトリクスに基づいてスケーリング
- サービスレジストリ — サーバーの状態とストリームマッピングのためのRedisベースの連携
- ヘルスモニタリング — 自動復旧を伴うアクティブなチェック
- コスト最適化 — 低需要期間中の自動スケールダウン
成果
技術スタック
caseStudyDetail.more ケーススタディ
その他の技術実装事例をご覧ください
Catant HR & ワークフォース管理プラットフォーム
Catantは、企業が従業員、給与計算、勤怠、およびコンプライアンスを単一のダッシュボードから管理できるよう支援する、モジュラー型のHRおよびワークフォース管理プラットフォームです。
Kickly: AIを活用したスタートアップ向けプロジェクトプラットフォーム
Kicklyは、AIを活用したスタートアップ向けプロジェクト管理プラットフォームです。スマートなタスク自動化、チームコラボレーション、リアルタイムの進捗追跡を一つの製品に統合しています。
よくある質問
MicrocosmWorksは、アクティブ/アクティブなデュアルオーケストレーター設計を実装しました。この設計では、両方のオーケストレーターがストリーム割り当てとワーカーの健全性に関する同期された状態を維持し、一方が故障した場合、数秒以内にストリーム管理を生き残ったオーケストレーターに転送する自動フェイルオーバーを備えています。これにより、従来のシングルオーケストレーター設計が抱える単一障害点が解消され、オーケストレーターのメンテナンス中や予期せぬクラッシュ時でもパケット損失がゼロになります。
MicrocosmWorks は、終了するワーカーが割り当てられたストリームの提供を継続し、RTSP TEARDOWN および再SETUPシーケンスを介してすべての接続が新しいワーカーにクリーンに移行されるまで待機する、グレースフルドレインメカニズムを設計しました。新しいワーカーは、ストリームの割り当てを受ける前に完全に初期化され、ヘルスチェックが行われます。そして、この移行は、古いワーカーと新しいワーカーの両方が一時的に同じストリームを提供することで、いかなる中断も防ぐオーバーラッピングウィンドウ（重複期間）を使用します。
MicrocosmWorksはこのプロジェクトのためにMediaMTXを選定しました。それは、フル機能のメディアサーバーと比較して、ストリームごとのリソースオーバーヘッドが最小限に抑えられたRTSP再ストリーミングのために特別に設計された、軽量でオープンソースのサーバーだからです。APIを介した動的なストリーム作成をサポートし、Kubernetesベースのオートスケーリングのためにコンテナ内で効率的に動作し、大規模になるにつれて法外な費用となるWowzaのような商用代替製品のストリームごとのライセンス費用を回避できます。
MicrocosmWorksは、パケットロス率、ジッター、再接続数、エンドツーエンドのレイテンシなどを含むストリームごとのメトリクスを追跡し、エンドユーザーに劣化が可視化される前にアラートが発報される包括的なオブザーバビリティスタックを導入しました。監視システムは、スケーリングイベント、ストリーム移行時間、ワーカーの利用率の傾向など、オーケストレーターの意思決定に関するメトリクスも追跡し、プロアクティブなキャパシティプランニングを可能にします。
はい、MicrocosmWorksは、ライブビューア向けの同時RTSP出力と、オブジェクトストレージへのセグメント化された録画をサポートするようにワーカーノードを設計し、各ワークロードに独立したリソース割り当てを行っています。録画には、アップロード前にセグメントをローカルでバッファリングする個別の書き込みパスを使用するため、ストレージのI/Oスパイクがライブストリーム配信に影響を与えることはありません。また、オートスケーラーはスケーリングの決定時に両方のワークロードの合計リソース需要を考慮します。