🤖

IoT + AI/MLを考えた時にエッジ or クラウドどっちでAI/MLするのか

4 min read

こんにちは。okeeeです。
もう 2021 年も年の瀬、ということで個人的に今年よく話があったIoTとAI/MLを組み合わせる時にエッジでAI/MLするのか、クラウドでAI/MLするのか、というあたりを整理してみます。

以下で使う用語の定義

  • エッジ:IoTで言うデバイス、そのデバイスの周辺で動作するものを指します
  • クラウド:AWSやMicrosoft Azure、Google Cloudなどのクラウドサービス、もしくはオンプレミスのサーバなどを指します

そもそもAI/MLとは


AI/ML(DL)をザックリ説明したものが上の図です。点線より下が現在実用化されている部分になります。ML(機械学習)はAI(人工知能)の一種とみなされています

「AI/MLする」

タイトルにはあえて「AI/MLする」と入れてみましたが、「AI/MLする」の中もいくつかに分けることができます。大きく「学習」と「推論」があります。

「AI/MLする」というのはこの「学習」と「推論」を行うことになります
※ ちなみに学習しないMLもあります

IoTシステムが構築される場所で学習と推論を行う

IoTシステムはエッジおよびクラウドを活用して構築されます。例えば、どこかの温湿度を計測してデータを蓄積することを考えた時、温湿度を計測するのはエッジ、データを蓄積するのはクラウド、という形です。ということは学習と推論はエッジおよびクラウドのどちらかで行うことになります。
エッジおよびクラウドには以下の特性があります

  • エッジ
    • 現場に近い
    • ネットワークや電力、コンピュートリソースが限られている
  • クラウド
    • 現場から遠い
    • コンピュートリソースは自由に利用することができる

また学習と推論にも以下の特性があります

  • 学習
    • 大量の学習用データを必要とする
    • 大量のコンピュートリソースを必要とする
  • 推論
    • 入力を受け取って推論結果を出力する
    • コンピュートリソースにより推論にかかる時間が増減する

学習と推論にはコンピュートリソースが必要になります。と、いうことはコンピュートリソースが限られているエッジではなく、クラウドで学習と推論を行う形が良さそうに見えます。ただ、クラウドは現場から遠いため、推論が早く終わってもエッジに結果を届けるための時間が必要になります。そうなると推論はエッジで行い、学習はクラウドで行う形が見えてきます。どちらがよいのでしょうか。

IoTシステムの要件から考える

いくつかのIoTシステムの要件から考えてみます

どこかの温湿度を計測してクラウドにデータを蓄積し、その後1ヶ月先までの温湿度を予測し可視化する

このケースでは推論を行うのは「1ヶ月先までの温湿度の予測」になります。また1ヶ月分の予測を可視化することが目的のためリアルタイム性はそこまで必要にならないと思われます。推論結果もエッジ側で利用する必要がありません。この場合は蓄積したデータをクラウドで学習し、クラウドで推論を行い予測結果を可視化する、が良さそうです

高速で動くベルトコンベア上を流れる荷物の宛名をカメラで読み取り、地域ごと日ごとの荷物データを蓄積し、1週間の荷物数を予測し、必要となる配送車数を調整する

こちらで推論を行うのは「荷物の宛名の読み取り」「1週間の地域ごと日ごとの荷物数」になります。荷物数のような人が起因となる(人が荷物の発送を行う/注文する)数値の推論については、季節性(イベント、曜日など)を学習データとして利用すると精度が上がりそうです。推論の結果は1週間先の配送車の手配に利用されているため、リアルタイム性は重要ではありません。配送車の手配期限に間に合えば大丈夫そうです。この場合も蓄積したデータをクラウドで学習し、クラウドで推論を行い予測結果を可視化する、が良さそうです

高速で動くベルトコンベア上を流れる荷物の宛名をカメラで読み取り、地域ごとにベルトコンベアの経路を変更し、積み込むトラックを振り分ける。地域ごと日ごとの荷物データを蓄積し、1週間の荷物数を予測し、必要となる配送車数を調整する

こちらで推論を行うのは「荷物の宛名の読み取り」「1週間の地域ごと日ごとの荷物数」になります。「荷物の宛名の読み取り」の推論の結果は高速で動くベルトコンベアにリアルタイムで反映させる必要があります。この場合は「荷物の宛名の読み取り」の推論をエッジで行い、「1週間の地域ごと日ごとの荷物数」の推論はクラウド、「荷物の宛名の読み取り」「1週間の地域ごと日ごとの荷物数」の学習はクラウドで行う形が良さそうです

エッジとクラウドを使い分ける、その時の課題

先の通り、エッジとクラウド、どこで推論を行うのか、どこで学習を行うのか、は要件に応じて変化することがわかりました。開発フェーズはクラウドで行い本番フェーズはエッジで行う、という使い分けもあると思います。他にも様々な理由や切り口で使い分けが必要になります。その時に課題となるのが、エッジとクラウドの環境の差異です。エッジ側はデバイスの構成次第で環境が大きく変化します。環境が変わるとAI/MLモデルの出力形式を変更する必要があったり、性能(推論の精度、速度)が大きく変化する可能性があります。

課題を解決できる(かもしれない)サービス

そんな課題を解決できる(かもしれない)サービスやツールをいくつか紹介します

AWS / Amazon SageMaker Neo

https://aws.amazon.com/jp/sagemaker/neo/
SageMaker NeoはSageMakerで作成した推論モデルをデバイスに合わせて最適化するサービスです。同じ推論モデルをクラウドのリソース/エッジのリソースに合わせて最適化/出力できるため、手動で環境に合わせる手間が減り、性能も最適化できます

AWS / AWS IoT Greengrass

https://aws.amazon.com/jp/greengrass/
AWS IoT Greengrassはエッジランタイムで、デバイスソフトウェアを構築、デプロイ、管理するためのクラウドサービスです。Lambda FunctionをGreengrass上で動作させたり、推論を行うことができます

Google Cloud / Vertex AI Edge Manager

https://cloud.google.com/vertex-ai?hl=ja#section-12
2021年5月にリリースされた機械学習プラットフォームがVertex AIです。Vertex AI Edge Managerを利用することでエッジへのデプロイも可能です

Microsoft Azure / Azure IoT Edge

https://azure.microsoft.com/ja-jp/services/iot-edge/
Azure IoT EdgeとAzure IoT Hubを合わせて利用することでエッジへのデプロイが可能です。またMicrosoft以外のサードパーティからもエッジにデプロイできるモジュールが提供されています

他にもエッジのためのサービスは多くあるので、いずれかを利用することでエッジとクラウドの差異をカバーしつつ維持運用ができそうです

結局どっちなのか(まとめ)

色々と書いてきましたが、まとめると以下の感じになるのかな、と。

  • どちらが正解!ではなく様々な要件に合わせてエッジとクラウドを使い分ける
  • エッジとクラウドの差異をカバーするサービスを上手く活用する

中でも「様々な要件に合わせて使い分ける」は記載した以外にも色々と考える必要があると思います

  • 必要とされる推論のパフォーマンスを満たすためにクラウドが必要
  • 推論のリアルタイム性は必要だが、エッジ側のフローを変更することでリードタイムを稼ぐことができる
    ...etc

昔から「IoTはITの総合格闘技」と言われますが、デバイスもソフトもクラウドもエッジもシステムも現場運用も丸っと含めて考えていく必要がありますね。

ではまた。次回はデバイスを用意してエッジとクラウドでどれくらいの差が出るのかを検証してみます。

Discussion

ログインするとコメントできます