イントロダクション
Surveillance BridgeのExtension機能を使用してクラウドストレージに拡張した場合、録画データの一部をローカルストレージに保存し、それ以外のデータはクラウドストレージ上に保存します。
例えば下図の場合は、ローカルストレージに3日間、クラウドストレージに87日間、合計90日間録画するシステムです。この図では3日間になっているローカルストレージの保存容量の最適値は何日分か？についてこの記事で説明したいと思います。
Tiger Surveillance社のSurveillance Bridge Administration Guide Version 2.0 Revision: April 2023（以下ガイドとします）の50ページに最適容量に関する考え方を説明しています。以下に紹介をします。
ローカルストレージの2つの役割 キャッシュとバッファ
Surveillance Bridgeのガイドによるとローカルストレージは以下の2つの役割を持たせると説明しています。
- キャッシュとして： ほとんどのクラウドストレージの場合、データ書き込みのための（アップロード）通信が多くても少なくても料金は変わりません。しかしながら再生する際のデータの読出しのための（ダウンロード）通信についてはデータ通信量に対して課金されるサービスがあります。監視カメラシステムの場合、直近の映像は頻繁に見る可能性がありますが、過去の映像については直近の映像よりは見る機会が少ないです。頻繁に見る期間をキャッシュに残しておくと、クラウドから映像をダウンロードする頻度が減り、ダウンロード通信に課金される料金も抑えることができます。
- バッファとして：他の記事（Full Cloud vs. On-Premise Cloud Hybrid）でも説明しましたが、多くの監視カメラシステムではベストエフォート型の回線が使われます。これらの回線は回線品質の保証がないので、回線が不安定になったり、切断されることがあります。回線、または、回線に接続される機器に障害が生じている間はローカルストレージにバッファとして映像データが保存されます。
ガイドではこのキャッシュとして、そして、バッファとしての容量を合計した容量をソースストレージ上に確保することを推奨しています。
キャッシュとしてのソースストレージ
キャッシュとしてのソースストレージの容量を試算するためには以下の2つの情報が必要です。
- カメラから流れ込む1日当たりのデータ容量（1日の録画容量）の総和
- 頻繁に録画データを再生して見る期間
1日当たりの録画容量は、カメラ1台当たりの１秒当たりの平均ビットレートを８で割って、86400を掛けた値になります。ビットレートは1bit当たりの通信速度なので容量計算に必要なバイト（＝8bit)に変換するために８で割ります。また１日は２４時間、１時間は６０分、１分は６０秒なので１秒当たりの１日当たりの録画容量を計算するために86,400（24時間/分 x 60分/秒 x 60秒)を掛けます。
頻繁に録画データを再生してみる期間については監視カメラシステムを設定している場所や目的によって異なります。その現場に適した期間を検討し、決める必要があります。
これまで、監視カメラシステムを導入していた施設におけるシステムにおける置き換えであれば、これまでの仕様方法を考えれば決めることができる可能性は高いと思います。
バッファとしてのソースストレージ
回線の不具合や故障が起きた場合であってもソースストレージにバッファとして録画されている期間であれば、映像の乱れや欠落がなく、クラウドストレージに映像を保存することができます。
また、回線に接続されている機器類の障害についても、バッファできている期間に機器の障害復旧ができれば同じく映像の乱れや欠落がなく、クラウドストレージに映像を保存することができます。
悪いパターンとして、金曜の夜間に障害が発生し、それが継続した場合は月曜日の朝から復旧対応が始まることが考えられます。
例えばバッファとしての容量を3日分確保しておけば、金曜の夜に障害が発生したとしても月曜日の業務時間中に復旧できれば事なきを得ます。
重要
ここで説明してきた内容が上記で紹介したガイドに書かれています。その説明の最後に「重要」という形で再度、短い説明を加えています。
非常に小さいローカルストレージ（例えば80台のカメラに対して200GB）でSurveillance Bridgeを設定、運用することはできます。ただし、Surveillance Bridgeの機能、性能を効率よく引き出すためにはローカルストレージがキャッシュとバッファの役割を果たしていることを忘れずに、かつ、これらの機能を十分に果たす容量をローカルストレージに割り当ててください。
