長大な施設の点検や管理を効率化するサービスであるてんかく忍者。
今回は、2024年現在の最もメジャーなクラウドサービスであるAWSに、てんかく忍者の環境を構築してみました。
本題に移る前に、まずはてんかく忍者を構成するGNSS-BeatBox、GV-Sync、4D-dbについて、ざっくりおさらいしておきます。
GNSS-BeatBox:ビデオカメラに特殊な音を流し込む装置。
GV-Sync:GNSS-BeatBoxにより動画に録音された特殊な音から、各コマと座標が関連付いた情報に加工する装置。
4D-db:GV-Syncが加工した情報を便利に閲覧できるWebサービス。現場点検や管理の代わりに。
構成は、このような感じになっています。
「説明がざっくりすぎだよ!詳しく知りたいよ」という方は、それぞれ個別に詳しく書かれている記事があるので、そちらも読んでみて下さい。
今回はこのうちGV-Syncと4D-dbの環境をAWSに構築してみます。
GNSS-BeatBoxは現場に持ち出す"エッジデバイス"として構成されているので、AWSへは組み込みません。
インフラ環境に左右されず安定してソフトウェアを動作させるのにうってつけの技術が、仮想化です。
現在のトレンドはコンテナ化ですが、特に有名なのはDockerですね。
実は、今回AWS上に構築したGV-Syncや4D-dbは、コンテナ化してDocker上で動作させています。
開発用PCなどで環境一式を構築し、テストや検証などに使用してきました。
`docker compose up -d`として環境を作成し、`docker compose down`として環境一式が削除されるように設計していて、気軽に"作って"と"壊して"をできることから、コードネーム4ddb-sandbox(4ddbの砂場)としています。
これをAmazon EC2上で動かせば、難なく今回の試みを達成できる楽な仕事なのでは!?
と期待していましたが、うまくいきませんでした。
Amazon EC2のインスタンスというのは、基本的にそれ自体が仮想サーバーです。そのため、その中でさらに仮想化技術を使うということはできないようです。
つまりEC2では、基本的にDockerなどの仮想化技術が動作しません。
ただし、ハードウェアを占有するインスタンスタイプのEC2にすれば、Dockerを動作させることが可能らしいです。
ただこのタイプのインスタンスは料金が高く、運用の現実性なしと整理したので、検証はしていません。
AWSでのコンテナ運用は、Amazon ECS(Amazon Elastic Container Service)か、Amazon EKS(Amazon Elastic Kubernetes Service)を使うのが一般的です。
私はKubernetesは使ったことがないので、ECSを選択しました。
ECSを使う場合の流れは、次のようになります。
4D-dbとGV-SyncはDockerコンテナ化していましたが、AWS環境用に調整したコンテナイメージを作成し、登録し、タスクを作成し、サービスを起動しました。
4D-dbとGV-Syncからは、共通のAmazon EFS(Elastic File System)をマウントするようにして、GV-Syncからデータを書き込み、4D-dbでそれを読み取るようにしています。
あとはデータベースも必要です。
PaaS(Platform as a Service)型であるAmazon RDS(Amazon Relational Database Service)を活用しました。
こんな感じで、トライアンドエラーを繰り返しながら1つずつ構築した検証用AWS環境は、最終的に次図のような構成になりました。
実際に公開運用する場合には冗長化、セキュリティ、ドメイン名設定、自動スケール、なども考慮する必要がありますが、今後の課題という整理にしています。
てんかく忍者の既存運用環境は、ストレージサービスとしてBoxを活用していますが、先ほどさりげなく、4D-dbとGV-Syncから共通のAmazon EFSをマウントしたと書きました。つまり今回の環境では、Boxは使用していません。
Boxはユーザー数ごとの課金で、保管容量上限なし(通信制限はある)のストレージであり便利なのですが、Amazon ECSからBoxをマウントしようとするとSELinuxのセキュリティに阻まれてしまい一筋縄ではいきません。
さらにAWSは外部とのデータ通信に課金が発生することや、AWS内部のストレージのほうが応答早そうということで、Amazon EFSを活用しています。
BOX | Amazon EFS |
|
|
Amazon EFSの課金額は主にデータ量で決まるので、やたらとデータを多く入れてしまうと"とてつもない運用コストになってしまったりする"ので気をつける必要があるのですが、この辺りのお話は別の機会に記事にするので、楽しみに待っていてください。
接続先データベースやストレージをAWS環境対応に変更したりと苦労した部分も多かったですが、最終的に4D-dbはAWS上でも問題なく動作しました。
変な挙動は無く、安定もしています。となると次に気になるのが性能です。
今回構築したAWS環境は既存運用環境と比べ、地図全件検索のレスポンス時間が1秒程度短くなりました。
その一方で、同じ品質の画像、つまり同サイズの画像をビューアで表示した場合の表示速度は、ほぼ同じでした。(図の右側2つ)
図の左側2つの2K品質80や4K品質70のように、画質を下げるとビューア表示速度改善するといった確認もしているのですが、AWS環境の性能検証という本筋からは外れた部分なので割愛します。
BoxではなくAmazon EFSを使ったのに表示速度が同じとは、少しガックリ。
しかしよくよく考えると、Boxを活用している既存運用環境では、(RCloneによるBOXへの接続を高速化する目的で)膨大な時間をかけてファイル構造のキャッシュを事前取得しているというので、これが不要になるというアドバンテージがあったりします。
・・・その上で同じ表示速度ということは、AWS環境、優秀なのでは?
先述した4D-dbの動作検証は、AWS環境に構築したGV-Syncから登録したデータに対して実施しています。
GV-Syncは当社内の専用のマシン上に構築されたシステムなわけですが、それもAWS上で問題なく動作することが確認できました。
当社内では5台のGV-Syncマシン(MiniPCで構成されたUbuntuLinuxの専用機)が稼働しています。繁忙期にも並行稼働して対応できるようにするためです。
AWS環境なら必要な時に、必要な数だけ、GV-Syncインスタンスを立てて運用することも可能なのでは!?と考えると、コスパなどをはじめとして、かなり可能性が広がります。
今回の検証はAWS環境にGV-Syncインスタンスを1つだけ稼働させ、その登録時間やそれに伴う課金額などを確認しています。
この記事に含めると長くなってしまうので、別記事で詳しく紹介する予定です。
ということで、てんかく忍者の環境をAWSに構築し、動作確認しました。
実際にAWS環境でサービス提供するためには個別対応が必要になるため、ご興味持たれた方は、お問い合わせ下さい。
動画データの登録からデータの活用までをAWS上で一気通貫できるワークフローを確立できれば、将来的にはデータ加工を当社に委託することなく、お客様自身がてんかく忍者による点検DXをすべて運用できるようになります。
当社では、お客様にとって"スピーディ"に"ローコスト"な点検DXを提供できるよう、今後も技術開発を進めていきます。
※本記事中の、Docker、BOX、AWS、Amazon EFS、Amazon ECR、Amazon ECSなどは各社、各団体の登録商標です。
▼この記事を書いたひと
R&Dセンター 長尾 賢志
Pythonistaですが、Java、C#、Rubyなども経験があり、オブジェクト指向を得意とします。Djangoを使用したWeb開発をしたことがあるほか、データ解析・可視化なども行なっています。R&Dセンターではエッジコンピューティング、IoT関連を担当しています。保有資格:ソフトウェア開発技術者
●富士見事務所 TEL : 052-228-8744(交通部営業課) FAX : 052-323-3337(交通部共通)
〒460-0014 愛知県名古屋市中区富士見町13−22 ファミール富士見711 地図
PoCのお問い合わせ:交通部営業課
技術的なお問い合わせ:R&Dセンター