0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

なりかくんAdvent Calendar 2023

Day 4

[4日目] 学校の食堂をIT化させる話 混雑度カメラのサーバー構成を考える(案出し)

Last updated at Posted at 2023-12-03

こんにちは、なりかくんと申します。
この記事はなりかくん Advent Calender 2023の4日目の記事です。

この話は、1日目から始めた学校の食堂をIT化させる話の続きとなります。今回は、前回混雑度カメラの構成を考えたので、その中で出てきたサーバー構成を考えていきたいと思います。

前回のおさらい

前回(3日目)の記事で、最終的にRaspberry Pi上でYOLOv8で物体検出をしてクラウドに人数と画像をクラウドに送信するように決めました。

また、混雑度をWebページからリアルタイムの映像と人数・混雑度(パーセンテージ)を見れるようにすることも決めました。

image.png

Webページからリアルタイムで情報を見れるようにする

まず最初にWebページからリアルタイムに情報を見れるようにする方法を考えます。私が思いついたのは、以下の手順です。

  • WebSocketを使ってリアルタイムに情報を受信する
  • HTTPでポーリングしてリアルタイムのようにする
  • YouTubeライブなどを使って映像としてリアルタイム性を持たせる
  • Firebase Realtime Databaseでリアルタイムにデータを更新する

最終的には、現時点で「HTTPでポーリングしてリアルタイムのようにする」を採用します。これに至った理由(それぞれの特徴)をこれから長々と書いていきます。
お時間があれば、ぜひお読みいただければと思います。

WebSocketを使ってリアルタイムに情報を受信する

まず最初に思いついたのが、WebSocketを使ってリアルタイムに情報を送信する手段です。これが、一番いいと思ったのですが、一つデメリットがあって接続数が増えた際にサーバーが負荷に耐え切れるかが分かりません。

実はこの食堂IT化には予算があまりありません😭 そのため、今回はつよつよサーバーが使えないので、この方法は候補からなくなりました。

HTTPでポーリングしてリアルタイムのようにする

この方法が一番手軽で安定させれるのではないのかなと思いました。
また、値段についてもHTTP APIであればレンタルサーバーを使えば最悪無料でも構築できるわけです。

image.png

ただし、デメリットとして大きいのがWebサーバーに負荷がかかりやすい点です。不必要にリクエストを送ってしまう事があるためです。

そこで、キャッシュを利用して負荷を減らします。間にCDNを挟むことで最初のリクエストのみ元のオリジンサーバー(Webサーバー)にアクセスし、それ以降のリクエストはすべてCDNのキャッシュから返すようにします。

Cloudflareというサービスを利用すれば無料でキャッシュサーバーを利用することが出来ます。また、世界各地のサーバーから最も最適な経路・サーバーでのリクエストが可能なためレスポンスタイムの最適化にも期待が出来ます。

image.png

YouTubeライブなどを使って映像としてリアルタイム性を持たせる

この方法が一番リアルタイム性を持たせれるのではないかと考えましたが、今回は見送りました。理由としてはRaspberry PiでYOLOv8で重たい画像処理を常にしながらYouTubeライブを行う際にRaspberry Piが負荷に耐えきれないと考えたためです。(実際の実験は行えてないです。)

また、YouTubeライブにOBSを利用して行うと考えてましたがカメラはディスプレイが無くCUI環境での動作なのでどうすれば対応できるかを私の頭で思いつかせることが出来ませんでした。
(OBS以外でもRTMPで直接プログラムから配信すればもっと軽いのだろうが、私の技術力不足でコードを作れません。。)

また、学校のネットワークでの運用なので常にライブ配信をするとネットワークの負荷がすごいことになりそうです。

ですが、プログラムや負荷問題が解決したら一番コストも安く出来るのではないかと考えてます。(これは完全に技術力不足)

Firebase Realtime Databaseでリアルタイムにデータを更新する

最近FirebaseというGoogleが運営している(Firebase, Inc.がGoogleに買収された)サービスでサーバーレスを体験して感動していたので、Firebase Realtime Databaseでリアルタイムにデータを更新する方法も良いのかなと考えたのですが、以下の懸念点が出てきました。

  • 画像データなので転送量が凄いことになる = お金が凄いかかる
  • クライアントからのリクエストを処理すると凄いことになる = お金が凄いかかる
  • とにかくすごいことになる = お金が凄いかかる

ということですね。無料枠を超えて凄いお金がかかるかと思うので、高額請求が怖くこの案は一瞬で消え去りました。

最終的に

最終的に実際に開発を行っていくうえで、「HTTPでポーリングしてリアルタイムのようにする」を採用しました。

おっと、日付が超えそうだ。続きは5日目に書くこととします(許して)

最後までお読みいただきありがとうございました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?