13万台の監視カメラ-それらを機能させる方法は？

こんにちは、Habr！ 優れたフィードバックに感謝します。次のような多くの質問に詳細な回答を提供します。システムのインフラストラクチャについて詳しく説明します。 近い将来、このような投稿を行うことを考えましたが、このトピックにも関心を示していたため、プロセスを少し強制しました。









カットの下-ポイントに右。



システムアーキテクチャは 、この規模のシステムの標準であるモジュールベースで構築されています。 ただし、1つの重要な違いがあります。システム内のこれらのモジュールは、多数だけでなく非常に多くあります。 各モジュールは、都市および部門の情報システム（IS）からのビデオ画像と情報の受信、処理されたデータへのアクセスの制御、 ECSDのユーザーと都市の住民を含むさまざまな外部消費者への写真とビデオ画像の提供に関連する個別の高度に専門化されたタスクを実行します。



モジュールは、さまざまなテクノロジー（主にJSON、REST API、およびSOAP）に基づいて互いに密接に連携します。 モジュール自体は、フレームワーク（ASP.NET Web API、WCF、NLog、Entity Framework、MySQL ADO.NETマネージドドライバー、Unity 3、EPPlus、Json.NETなどを使用して、さまざまな言語（Java、C＃、Javaスクリプトなど）で実装されます。 EmitMapper、DotNetZip、jQuery、knockoutjs、Moment.js、underscore.jsなど）。



このソフトウェアの多様性はすべて、VMware vSphere 5仮想化環境のさまざまなオペレーティングシステム（Windows Server、SUSE Linux Enterprise Server、CentOSなど）で動作します。



システムアーキテクチャを図に示します。







すべてのモジュールには、独自のフォールトトレランスとバランシングメカニズムがあります。 このために、クラスターテクノロジー、nginxに基づいてHTTP要求のバランスをとるためのさまざまなオプション、およびアプリケーションレベルでのキューと優先度の管理が使用されます。 さらに、すべてのモジュールは弱い接続性の原則に従って結合され、システム全体の開発および変更の可能性を大幅に高めます。



このアプローチにより、システムをスケーラブルにするだけでなく、新しい技術プロセスを実装したり既存のプロセスを変更したりするという点でも非常に柔軟になります。各モジュールは独立して開発でき、モジュールの後方互換性のサポートは必須要件です。

システムの主要コンポーネントの説明

ビデオストリームの受信と処理を提供するビデオコアは、 Linuxを実行する専用仮想マシンのリソース上で実行される数百のビデオサーバーで構成され、145万台を超えるカメラ、エンコーダー、その他のビデオストリーム生成システムからのビデオトラフィックを提供します。 トラフィック受信はRTSPプロトコル（H.264形式のビデオ）に従って実行され、トラフィック受信スキームは異なる方法で使用できます-調整可能な記録深度（ストレージ期間）で継続的に、または単にビデオを見る必要がある場合はリクエストに応じて。 この柔軟なアプローチにより、両方のサーバーリソースを節約し、通信チャネルの負荷を軽減できます。



TCPは主にトランスポートレイヤープロトコルとして使用されますが、UDPも使用される場合があります。 ビデオサーバーはいくつかのタスクを実行します。



- 主なもの：ビデオストリームを受信し、記録してから、ストリーミングサーバーまたはアーカイブビデオを中継サーバーに発行するか、アーカイブビデオの一部を別の専用ストレージに長期保存します。

- 多数の追加機能：ビデオソースの可用性の監視、指定されたパラメーター（fps、ビットレート、パケット損失）によるビデオストリームの受信とコンプライアンスの監視、および特殊なデータ交換バスを介したビデオサーバーからの情報は、その後のアカウンティングおよびオペレーションサービスへの送信のためにサービス配信制御システムに入ります。



ビデオサーバーは専用のHTTP APIによって管理されます。これにより、制御システムを介して作業を完全に自動化できます。 ビデオサーバーの機能は、ビデオサーバーの追加の内部メカニズムを使用して、Zabbixを通じて制御されます。



Restrimming-リレーサーバー-ビデオコア（ビデオの主な受信とその記録を実行する）とユーザー（実際には、ビデオコンテンツの主な消費者）間の接続リンク。 ストリーミングビデオ用の組み込みの再カプセル化および配信メカニズムにより、ライブおよびアーカイブビデオコンテンツをPCおよびポータブルデバイス（タブレット、電話）に中継できます。 再ストリーミングは、RTSPを介して、ビデオ分析システムやトランスコーディング制御システムなどの追加システムにストリーミングビデオコンテンツを提供することもできます。スライドショーとして特別な表示モードを活用してください。 リレーサーバーはクラスターで動作し、動的バックアップモードをサポートします。また、ユーザーが生成する可能性のあるバーストからビデオコアを分離します。



ユーザーインターフェース -フロントエンドWebインターフェースは、数万人の登録ユーザーにビデオ監視システムへの許可されたアクセスを提供し、都市内ネットワークのどこからでも、場合によっては閉じられた専用インターネットリソースを通じて、さまざまな機能を利用できます。



すべての主要なブラウザー上のさまざまなオペレーティングシステム（Windows、MacOS、Linux）の環境で作業が提供されるため、職場の組織が大幅に簡素化されます。 また、たとえばiOSベースの多くのモバイルデバイスでの作業もサポートしています。



機能は非常に多様です-ストリーミングおよびアーカイブされたビデオの通常の表示（PCのフラッシュプレーヤー、iOSのネイティブツールを使用）、カメラのPTZ機能の制御、地図作成のさまざまなレイヤーへのリンクを備えた検索エンジン、都市システムのデータとの統合、柔軟なロールモデルを使用する前に、ユーザーインターフェイスのカスタマイズされたプレゼンテーションと組み込みのユーザートレーニングメカニズムを作成します。



フロントエンドは、RequireJS、ノックアウト、lodash、リーフレットなどのテクノロジーを使用します。 バックエンドは、モジュールの原理に基づいて構築されており、必要なレベルの冗長性とコンポーネントのスケーリングを提供でき、構成管理システムが使用されます。 ソフトウェアおよびテクノロジー：Java / Tomcat、MariaDB、RabbitMQおよびその他のいくつか。



統合ゲートウェイ -外部情報コンシューマをシステムのコアから分離するサブシステムモジュールのセット。 承認を通過し、指定された権限（つまり、利用可能なデータと機能）を考慮した後、外部システムにさまざまな情報を提供します。 3つの主要な論理コンポーネントがあります。

• サービスインタラクションコンポーネントは、指定された情報セット（カメラ名、住所と場所の座標、スクリーンショット、およびその他の付随情報）を提供するHTTP APIです。
  
  
  
  
• リレーコンポーネント -ビデオコアの負荷を最小限に抑え、ブロードキャストビデオストリームを外部システムに提供するように設計されています（iOSデバイスのHLSと同様、フラッシュへのブロードキャストがサポートされています）。 ビデオコアと再スリム化サーバーにはCDN機能があり、このコンポーネントはビデオコンテンツ配信用の追加のCDNリンクとして機能します。
  
  
  
  
• インターフェイスレンダリングコンポーネント -ストリーミングおよびアーカイブされたビデオ情報を再生するための既製のインターフェイスとして外部システムに埋め込まれるように設計されています。たとえば、iframeを介して埋め込み、簡単なカスタマイズ（視覚表示設定-色、必要な機能ボタンなど）をパラメーター化された呼び出しで埋め込みます。

これらのコンポーネントを使用すると、外部システムはデータにアクセスして情報を視覚化する独自のインターフェイスを作成できるだけでなく、準備済みのコンポーネントを可能な限り簡単に実装できます。







ユーザーにビデオ監視システムのカメラへのアクセスを提供するために、ユーザーの認証と承認、PTZ制御機能へのアクセスの優先順位付け、ユーザーアクションのログ記録、個々のモジュールの相互作用を提供する相互接続されたコンポーネントがすべてあります。



システムは2種類の認証をサポートしています。ECSDのユーザーアカウントの使用と、リソースへのアクセスを管理するための単一の都市システムの使用（実際、これは都市全体のIPのSSOの可能性です）。 同時に、1人の物理ユーザーに対して、異なるタイプの認証を共有することが可能です。 ECSDユーザーの主要な認証情報はActive Directoryに保存され、すべての追加情報はMicrosoft SQLデータベースに保存されます。



もちろん、すべてのパスワードは暗号化された形式でモジュール間で送信されます。 またはそれらはまったく送信されないので、私たちも方法を知っています:)



アクセス権限と優先順位の付与は、すべてのモジュールの単一のロールモデルに基づいて実装されます。これにより、ビデオ監視カメラだけでなく、個々のシステム機能にもアクセスできます。 現在、システムには100を超えるさまざまな権限があります。ライブブロードキャストへのアクセス、写真およびビデオ画像のアーカイブの表示とエクスポート、PTZコントロール、個々のシステムレジストリおよびディレクトリの変更、スナップショットの作成スケジュール、パトロールルートの作成、モバイルデバイスからアクセスする機能など。 システムは絶えず進化しており、新しいユーザーグループがそれぞれのタスクに接続しており、実際にはシステムに新しい機能が追加されています。



さらに、さまざまなユーザーグループとシステムサービスにはいくつかの優先度レベルがあり、異なるユーザーグループ間の競合を回避し、PTZカメラ制御を「透過的に」インターセプトし、パトロールモードで制御を提供し、スケジュールに従って表示領域を移動します。



数万人のユーザーにすばやく簡単にアクセス許可を提供および管理するために、システムはさまざまなメカニズムを使用します：ユーザーグループへのアクセス許可の割り当て、定義済みの標準アクセス許可を持つテンプレートの使用、スマートグループ（定義済みのルールに基づいて、新しいユーザーがグループ間で自動的に配布される場合） ） カメラのレジストリを管理するために同様のメカニズムが使用されますが、グループへの配布は主に地理的な原則、サービスの種類、または部門のビデオ監視システムとの提携によって実装されます。



アクセス制御はほぼリアルタイムで実行され、権限の構成の変更は即座にユーザーに影響を与えます。 さらに、トークンベースのセッション検証メカニズムを使用して、ライブビデオストリームへのリンクの有効期間を制御します。 ちなみに、ビデオストリームへの「期限切れ」リンクへのアクセスを可能にしたのは、市の住民向けのテストサービスにこのメカニズムがないことです。



システムは、すべてのレベルでのすべてのユーザーアクションとモジュールの相互作用を記録し、あらゆる状況の分析を可能にします。 ロギングシステムは、イベントの日時、ユーザーが実行したアクション（インターフェイスボタンを押すまで）、スケジューラーがシステムで実行したタスク、情報交換の終了方法などを記録します。 現在までに、システムは「テクノロジー」プロセスの実装に関して100億件以上の記録を記録しており、各プロセスはいくつかの別々のログに記録されたアクションで構成されています。 DITの従業員は、使用するポータル、ライブブロードキャストの表示回数、最もリクエストの多いカメラグループなど、さまざまなセクションでユーザーアクティビティを判断できる統計を毎日受け取ります。



「ケーキの上のチェリー」として、数字のビデオ監視システム：



カメラの数： 145千台以上。

ユーザー数： 1万人以上。

ネットワークビデオトラフィックの量：約120 Gb / s;

ストレージシステムの容量： 20 Pバイト。



システムの公式ページはこちらです。 カメラの技術的特性を確認し、レンズに侵入する可能性のあるイベントが発生した場合の対処方法を学習し、公共の場所でWindow to the Cityサービスを使用して複数のカメラを見ることができます 。



Habréのブログもご覧ください。

» モスクワの130,000台のカメラのHabraeffect

» 情報技術はモスクワで75万人以上の人々に供給されています

» ハブラハブルのモスクワ市の情報技術局のブログ



ご清聴ありがとうございました！