はじめに：本記事について
私の所属する部署では自動車にかかわる様々な開発をしています。その中でも私のチームでは、特に コネクテッドカー（Connected Car） にかかわるバックエンド開発を担当しています。 コネクテッドカー とは、インターネットやクラウドサービスと常時接続された自動車のことです。車両が車両外のデータセンタ/クラウド基盤とデータを送受信することで、ドライバー・運行管理者・メーカー・第三者のサービスと連携して多様な機能やサービスを提供します。具体的にはプローブデータ(CAN)やドライブレコーダの映像データなどが収集されています。
当部では上記基盤開発を長きにわたり取り組んでおり、その中でも本日は 映像データをクラウド基盤で行う際の検討事例 を紹介します。主にクラウドアーキテクトを目指す人/担っている人で、映像データを扱う/扱いたい方が対象となります。(もちろん興味ある方はぜひとも読んでください)
ちなみに：クラウドサービスはAmazon Web Services (AWS)を前提としています。
Part1:映像データについて
映像データをクラウド処理する事例
近年、映像データをクラウドで処理するユースケースが急速に増加しています。具体的には以下が挙げられますが、特に当部では自動車関連を担当していることもあり、ドライブレコーダのような移動体のカメラ映像を扱うことが多いです。
-
車のドライブレコーダ
事故分析や危険運転の検知、さらには自動運転のための周辺環境認識に利用される映像データが、クラウド上で解析されています。解析では多量のリソースを用いるため、クラウドへデータをアップロードし、車の外で処理がされます。 -
テレビ局の映像データ
放送素材の管理、編集、AIによるコンテンツ分析（例: スポーツのハイライト自動生成、不適切な表現の検出）など、膨大な映像資産の処理にクラウドが活用されています。 -
街の防犯カメラ
不審者の早期発見、特定の行動パターンの検知、人の流れの分析といったセキュリティやスマートシティ分野での利用が増加しています。 -
小売店舗の顧客行動分析
店内のカメラ映像から顧客の導線、商品の滞留時間、購買行動を分析し、店舗レイアウトや商品配置の改善に役立てられています。
映像データの特性
従来、よく扱われてきた構造化データ（データベースにきれいに格納されたテキストや数値データなど）と異なり、映像データは非構造化データ、つまり「塊」として扱われるため、処理で気にしなければならない観点がやや異なります。
-
データ容量の大きさ
映像は1ファイルで数MBから数GB、あるいはそれ以上の巨大なファイルサイズになることが一般的です。そのため、転送、保存、読み込みといった操作自体に時間がかかり、ネットワーク帯域やストレージ容量の制約を受けやすくなります。うまく分割する、必要に応じて圧縮することが重要になります。 -
多様なフォーマット
MP4, AVI, MOV, H.264, H.265など、映像には多種多様なエンコーディングやコンテナフォーマットが存在します。これらを扱うためには、それぞれに対応したデコーダーやライブラリが必要となり、処理パイプラインが複雑化します。 -
時間軸と空間軸の同時処理
映像は時間の経過とともに変化する情報（時間軸）と、フレーム内のピクセル情報（空間軸）を同時に持ちます。そのため、単一の静止画解析とは異なり、動きの検知や追跡、シーンの切り替わり判断など、時系列的な処理が求められます。 -
推論処理の負荷
AIや機械学習を用いて映像から特定の物体を認識したり、行動を分析したりする推論処理が昨今多くなっていますが、この場合膨大な計算リソースが必要となります。特にディープラーニングモデルを用いた推論は、GPUなどの高性能なハードウェアが不可欠となるケースが多く、処理の実行環境に高い要求が出ます。
Part2：映像処理×クラウドって具体的になにするの？
映像処理をクラウドで検討する際、大きく分けて「アプリケーションレイヤ（どのような処理ロジックを組むか）」と「基盤（クラウド）レイヤ（その処理をどこで動かすか）」の2つがありますが、 本記事では後者の「基盤（クラウド）レイヤ」に焦点を当てて解説します。
基盤（クラウド）レイヤの重要性
映像処理は、その性質上、非常に多くのハードウェアリソースを消費します。具体的には、大容量のメモリ、高速なCPU、GPUなどの高性能な計算リソースが不可欠となる場合が多いです。これにより、必然的に利用するサーバーのスペックが高くなり、オンプレミスで構築・運用しようとすると、莫大な初期投資とランニングコストが発生してしまいます。ここにクラウドを利用する大きな価値があります。
ただし、クラウド利用といっても魔法のようにコストは削減できません
結局のところ、高額なリソースを使うことは変わらず、要件によっては月額数百万円かかるケースもあります。そのため、 どのクラウドサービスを選び、どのように活用するかが、映像処理プロジェクトの成否やコスト効率に直結します。
映像処理×クラウドにおけるコスト支配項
ここで映像処理をクラウドで行う際のコスト要因について補足します。実態は多種にわたりますが、主に以下の2つの支配項によって決まることが多いです。
-
映像データの処理コスト
映像データをエンコード（圧縮）したり、AIによる推論処理を実行したりする際に発生するサーバーなどの計算リソースの利用コスト。 -
大量の映像データを保管する際のストレージコスト
処理対象となる映像データ、および処理結果の映像データなどを保存するストレージの利用コスト。
これらの支配項に対して、様々なコスト最適化の打ち手が考えられます。以下は実際のアプローチ例です。
本記事では、特に前者である「映像データの処理コスト に焦点を当て、その最適化に寄与するクラウドのマネージドサービスについて、次のセクションで詳しく比較検討していきます。
映像処理に適したクラウドマネージドサービスと特性
クラウド上で映像処理を行う際に利用される主要なマネージドサービスは以下で、それぞれ異なる特徴と適性があります。 実際には要件を踏まえて最適なものを選択していく必要があり、そこがアーキテクトの腕の見せ所です。 以下はあくまで一般例となります。
AWS Lambda
- メリット: コードを実行するだけでサーバーのプロビジョニングや管理が不要なサーバーレスサービス。イベント駆動型で、短時間の軽い処理（例: アップロードされた動画ファイルのメタデータ抽出、サムネイル生成）に適しており、利用した時間分の課金でコスト効率が良い。
- デメリット: 実行時間の制限（最大15分）、メモリやCPUリソースの制約があり、長時間かかる重い映像処理や、GPUを必要とする推論には不向き。CPUも明示的に指定ができず、メモリのみ指定のため、CPUを多用する映像処理において基盤最適が狙いづらい
Amazon ECS (Elastic Container Service) / Amazon EKS (Elastic Kubernetes Service)
-
メリット: コンテナ技術を利用することで、アプリケーションのポータビリティが高く、開発・テスト・本番環境の一貫性を保ちやすい。ECSはAWSが提供するマネージドなコンテナオーケストレーションサービス、EKSはKubernetesをマネージドで利用できるサービスであり、スケーラビリティと可用性に優れ、複雑なワークロードにも対応可能。GPUインスタンスの利用も容易。
-
デメリット: コンテナイメージの作成やオーケストレーションの理解が必要で、Lambdaに比べると学習コストや運用管理の複雑さが増す。
-
※ECSとEKSとで正確には学習コストや拡張機能が異なりますが、おおよそ同じことができるため、同じジャンルとして記載
AWS Batch
- メリット: 大規模なバッチ処理（例: 大量の動画ファイルの一括エンコード、オフラインでのAI推論）に特化しており、EC2やFargateを自動でプロビジョニング・管理可能。
- デメリット: インタラクティブな処理やリアルタイム性が求められるユースケースには不向き。
Amazon Kinesis Video Streams
- メリット: リアルタイムの動画ストリームを安全に収集、保存、処理、分析するための専用サービス。ライブストリーミング、監視カメラ映像のリアルタイム分析、機械学習への入力などに適しており、カメラデバイスから直でのデータ収集が容易。
- デメリット: リアルタイムストリーミングに特化しているため、バッチ処理やファイルベースの複雑な変換処理には不向き。
実際にはこれらのメリット/デメリットであったり、要件として重要なポイントをピックアップして表形式で整理するなどして、方式を決めていくケースが多いです。プラットフォームの決定根拠が残ることは自身の振り返り、並びに社外での説明で説得力を増すためです。
Part3:過去事例とGPU・推論アクセラレータの重要性
過去の当部での映像処理事例では、特にAmazon EKSやAmazon ECSが採用されるケースが多く見られました。これは映像データが持つ特性に起因します。
-
処理時間/種別
映像データは一般的にサイズが大きく、エンコード、デコード、分析といった処理には一定の時間を要します。これらの処理は、Lambdaのような短時間実行のサービスには向かず、コンテナで長時間安定して稼働できる環境が求められます。
また、要件としても、リアルタイムとバッチ処理が混在するケースが多く、どちらにも対応しやすいプラットフォームが好まれる傾向です。 -
スケール性
映像データの要件に依存しますが、例えば車は日中帯で多く走り、まちのカメラも動体検出を導入していれば、昼間の方が人が多く撮影されるため、時間帯で必要なサーバ量が変わりうるものとなります。そのため、基盤がスケール出来ることが望まれるケースが多いです。 -
GPU・推論アクセラレータの必要性
映像解析におけるAI/ML（機械学習）モデル、特にディープラーニングを用いた画像認識や物体検出、行動分析などでは、膨大な並列計算処理が必要です。CPUだけでは処理に時間がかかりすぎるため、GPUや、AWS Inferentiaのような推論アクセラレータといった特殊なリソースの利用が不可欠になります。EKSやECSは、これらのGPUインスタンスを柔軟に組み込み、スケールさせやすいという利点があります。これにより、処理性能とコストのバランスを取りやすくなります。
実際には映像処理といってもユースケースは多岐にわたるため、業務要件を理解したうえで最適なものを選択することが重要になりますので、これはあくまで参考です。どこまで応用できるかがアーキテクトとしての腕の見せ所です。
Part4:他のアプローチ例
Part3では映像処理の要件に合わせて、AWSのマネージドサービスを選択するアーキテクトの事例紹介をしました。さらに発展的な話になりますが、もちろん選んだマネージドサービスの中でコストを最小に抑える、性能をパワーアップさせる事例もあれば、異なるアプローチをする事例もあります。
例えば、リソースを効率よく使うために推論API化(サービング化)する手法などが挙げられます。
NVIDIA様 Triton Inference Server より
他社事例になりますが、実際に導入して性能/コスト削減を狙っている事例もあります。
株式会社ディー・エヌ・エー様 Triton Inference Serverを用いた機械学習モデル推論基盤の取り組み より
本手法は当部でも苦労しながら実用に向けて泥臭い取り組みをしてきましたので、次回以降の記事で上記含め紹介する予定です。
過去に登壇発表もしていますので、より具体を知りたい方は以下動画を見るとわかりやすいです！
Part5:おわりに
我々のチームでは自動車を軸に、R&Dから商用開発まで幅広に開発をしています。
** 興味がある方は **
** 自チームの取り組み紹介 **
** 本件に関するお問い合わせ先 **
株式会社NTTデータ
システムインテグレーション事業本部
ビジネスエンジニアリングサービス事業部
自動車開発統括部
E-mail：connected-car-cloud@hml.nttdata.co.jp
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。
Discussion