AI Surveillance公開日 June 22, 2026 · 更新日 June 22, 2026

デュアルオーケストレーターとパケットロスゼロの自動スケーリングRTSPストリーミングアーキテクチャ

ある監視プラットフォームでは、そのビデオストリーミングインフラストラクチャを動的にスケーリングする必要がありました。10台から200台以上のIPカメラを、数百人の同時視聴者とAI処理ワーカーで処理し、スケーリング操作中にパケットロスゼロを保証しつつ、決して変更されない安定したストリームURLを維持することが求められました。

プロジェクトを相談する

AI Surveillance

Domain

Technologies

Key Results

Delivered

Status

課題

固定のストリーミングインフラストラクチャでは、成長する監視プラットフォームの変動する要求に対応できませんでした。

スケールの変動性 — カメラ数と視聴者需要は一日を通して劇的に変動しました（ピークから谷までの比率が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ベースの連携
ヘルスモニタリング — 自動復旧を伴うアクティブなチェック
コスト最適化 — 低需要期間中の自動スケールダウン

成果

パケットロス: スケーリング操作中のAIワーカー向けに0.00%

AI再接続: チェックポイントベースの再開で約3秒

スケールアップ時間: トリガーからサービス提供まで約60秒

スケールダウン時間: 完全なグレースフルシャットダウンで約220秒

技術スタック

MediaMTXPythonFastAPIRedisDockerCloud VM APIsLoad BalancersDNSPrometheusGrafanaWebSocket

caseStudyDetail.more ケーススタディ

その他の技術実装事例をご覧ください

AI Accounting

AIを活用したOCRによる請求書処理とQuickBooks連携

毎月数百件の仕入先請求書を処理する中規模企業が、AI/OCRを使用して請求書データを自動抽出し、それを記帳と支払追跡のためにQuickBooksに直接同期させることで、手動データ入力を排除する必要がありました。

ケーススタディを読む

Video Encoding

SCTE-35マーカー解析とマルチプラットフォームプレイヤー統合によるクライアントサイド広告挿入 (CSAI)

あるビデオストリーミングプラットフォームは、ウェブ、モバイル、コネクテッドTVアプリ全体でクライアントサイド広告挿入 (CSAI) を実装する必要がありました。これにより、サーバーサイド挿入では提供できない、完全な広告インタラクションサポート（クリック可能なオーバーレイ、コンパニオンバナー、スキップボタン）を備えた、パーソナライズされたデバイスレベルの広告体験が可能になります。

ケーススタディを読む

よくある質問

MicrocosmWorksは、アクティブ/アクティブなデュアルオーケストレーター設計を実装しました。この設計では、両方のオーケストレーターがストリーム割り当てとワーカーの健全性に関する同期された状態を維持し、一方が故障した場合、数秒以内にストリーム管理を生き残ったオーケストレーターに転送する自動フェイルオーバーを備えています。これにより、従来のシングルオーケストレーター設計が抱える単一障害点が解消され、オーケストレーターのメンテナンス中や予期せぬクラッシュ時でもパケット損失がゼロになります。

MicrocosmWorks は、終了するワーカーが割り当てられたストリームの提供を継続し、RTSP TEARDOWN および再SETUPシーケンスを介してすべての接続が新しいワーカーにクリーンに移行されるまで待機する、グレースフルドレインメカニズムを設計しました。新しいワーカーは、ストリームの割り当てを受ける前に完全に初期化され、ヘルスチェックが行われます。そして、この移行は、古いワーカーと新しいワーカーの両方が一時的に同じストリームを提供することで、いかなる中断も防ぐオーバーラッピングウィンドウ（重複期間）を使用します。

MicrocosmWorksはこのプロジェクトのためにMediaMTXを選定しました。それは、フル機能のメディアサーバーと比較して、ストリームごとのリソースオーバーヘッドが最小限に抑えられたRTSP再ストリーミングのために特別に設計された、軽量でオープンソースのサーバーだからです。APIを介した動的なストリーム作成をサポートし、Kubernetesベースのオートスケーリングのためにコンテナ内で効率的に動作し、大規模になるにつれて法外な費用となるWowzaのような商用代替製品のストリームごとのライセンス費用を回避できます。

MicrocosmWorksは、パケットロス率、ジッター、再接続数、エンドツーエンドのレイテンシなどを含むストリームごとのメトリクスを追跡し、エンドユーザーに劣化が可視化される前にアラートが発報される包括的なオブザーバビリティスタックを導入しました。監視システムは、スケーリングイベント、ストリーム移行時間、ワーカーの利用率の傾向など、オーケストレーターの意思決定に関するメトリクスも追跡し、プロアクティブなキャパシティプランニングを可能にします。

はい、MicrocosmWorksは、ライブビューア向けの同時RTSP出力と、オブジェクトストレージへのセグメント化された録画をサポートするようにワーカーノードを設計し、各ワークロードに独立したリソース割り当てを行っています。録画には、アップロード前にセグメントをローカルでバッファリングする個別の書き込みパスを使用するため、ストレージのI/Oスパイクがライブストリーム配信に影響を与えることはありません。また、オートスケーラーはスケーリングの決定時に両方のワークロードの合計リソース需要を考慮します。

ビジネスの変革の準備はできていますか？

お客様の課題に類似のソリューションを適用する方法について話し合いましょう。

お問い合わせ caseStudyDetail.viewAllCaseStudies