エッジデバイスでディープラーニング！ AWSを活用したエッジデバイスマネジメント JAWS DAYS 2018 #jd2018_c #jawsdays ABEJA, Inc Toshiya Kawasaki

河崎 敏弥 @toshitanian ABEJA, Inc. Platform Division Software Engineer • Development on cloud • IoT devices • Containers • Edge computing

ABEJA Platform 1):4*$ "-803-% $ :#&3803-% *P5،ؙثُؒ٦ة٦ *P5إٝ؟٦ 傀㶷ךر٦ة ➭ךفٓحز ؿؓ٦ي #JH%BUB رفٗ؎ 湊鋔 ؒحآ"* 䱿锷 ؙٓؐس"* 㷕统ה䱿锷 ♳׶ך*P5 ♴׶ך*P5 取得 蓄積 学習 デプロイ 推論・再学習

Object detection on an edge device

Edge features % *P5،ؙثُؒ٦ة٦ *P5إٝ؟٦ ךر٦ة ➭ךفٓحز ؿؓ٦ي #JH%BUB رفٗ؎ 湊鋔 ؒحآ"* 䱿锷 ؙٓؐس"* 㷕统ה䱿锷 ♳׶ך*P5 ♴׶ך*P5 •クラウドからエッジデバイスへデプロイ • アプリケーション • 学習したモデル •クラウドからエッジデバイスの監視 • メトリクス • システムログ

Edge use cases 自動検品 危険検知 商品仕分け

アジェンダ •エッジデバイスでのディープラーニングの必要性 •デバイスマネジメントに使えるAWSサービスの紹介 •AWS Greengrassでのディープラーニング利用を考える

ディープラーニング運用のプロセス 取得 蓄積 学習 デプロイ 推論・再学習

取得 蓄積 学習 デプロイ 推論・再学習 •データの収集 •学習データセットの作成 •データの前処理 •教師あり学習の場合はアノテーション作業 ディープラーニング運用のプロセス

•次のプロセスを繰り返す •モデルの設計・構築 •ハイパーパラメータの設定 •GPUを使ったモデルの学習 •学習済みモデルとパラメータのバージョン管理 取得 蓄積 学習 デプロイ 推論・再学習 ディープラーニング運用のプロセス

•学習したモデルを推論環境にデプロイ・利用 •実環境でのモデルの状況を確認・再学習 •データを蓄積して精度の改善 •適用対象別にモデルを個別に最適化 取得 蓄積 学習 デプロイ 推論・再学習 ディープラーニング運用のプロセス

IoTセッション?

取得 蓄積 学習 デプロイ 推論・再学習 クラウド クラウド or エッジ 要件によって使い分け ディープラーニング運用のプロセス

IoT での推論環境 エッジを使うべき状況 Cloud Edge （エッジと比較すると）高レイテンシ Latency 低レイテンシ 常時インターネット接続が必要 Connectivity オフラインでも実行可能 データ量が多い場合はクラウドに送れない Bandwidth 処理済みの少量データのみクラウドに送れる 全てのデータをクラウドに送る *Privacy ローカル環境からデータが出ない *学習データはクラウドに蓄積が必要 取得 蓄積 学習 デプロイ 推論・再学習

エッジデバイス上での推論に必要な事 •デバイスに対する定期的なモデルの更新 •デバイスへの直接接続はできない(NAT超え) •モデル毎のライフサイクルに依存 •デバイスの状態の把握 •モデルの実環境での稼働状況は重要（精度/パフォーマンス） •デバイスの故障 = システム停止 = 業務の停止 •セキュア・シンプルなデバイス管理 •プロビジョニング時に必要なデバイス固有の情報は減らしたい •個別のデバイスから情報が抜かれても全体としてはセキュアに

AWSサービスを使って解決

AWSサービスを使った機能 Device ShadowとECRでモデルをデプロイ Parameter Storeで共通設定を管理 証明書ベースでセキュアにAWSサービスを利用 MQTTとIoT Ruleでログ収集

Device ShadowとECRでモデルをデプロイ •デバイス上でAWS IoTと接続するエージェントを動かしている •モデルをデプロイする時はupdateShadowでデバイスに通知 •NAT配下のデバイスへも更新をPushできる •デバイスがオフラインの時は通知されないので、復帰時にデバイスが取りに行く •エージェントがECRからイメージを引っ張ってくる Device Amazon ECR AWS IoT updateShadow updateShadow docker images pull

MQTTとIoT Ruleでログ収集 ・・・ Device Kinesis Data Streams publish AWS IoT Rules •デバイス上のfluentdがDockerコンテナのログを収集 •デバイス毎に決められたMQTT TopicへPublish •IoT Policyでデバイスごとに特定のTopicしかPub/Subできないように制御 •IoT Rulesを使ってKinesis Data Streamsへ流し込む •その後はよしなに… AWS IoT MQTT Broker

Parameter Storeで共通設定を管理 Device AWS System Manager Parameter Store putParameter getParameter •全デバイスに適用したい共通パラメータがある •デバイス管理で使うAPIサーバのURLやAPIキー •Device Shadow → 一つの設定を全デバイスで共有するのには向かない •Thing Groups attributes → AWS APIのリクエスト数制限がある •Parameter StoreにKV形式で設定を保存 •全デバイスが定期的にチェック

証明書ベースでセキュアAWSサービスを利用 Device AWS IoT credential provider IAM Role assumeRole IAM Policy •デバイス上のエージェントからAWSサービスへのアクセスが必要 •ECR / SSM / KMS •AWS IoT credential providerを使えばassumeRoleする事が可能 •AWS IoTで利用している証明書付きでHTTPエンドポイントにリクエスト •指定したのIAM Roleの権限を持つ一時クレデンシャルをもらえる •証明書以外の個別情報無し

AWS Greengrass ?

"84(SFFOHSBTTͱ͸ wσόΠε্ͰͷίϯϐϡʔςΟϯά؀ڥΛఏڙ wσόΠε্Ͱ"84-BNCEBΛಈ͔ͤΔ w.-*OGFSFODFͰΫϥ΢υ͔ΒϞσϧΛಉظ wFUD wSF*OWFOUͰൃද w೥݄ʹ(" w.-ؔ࿈ػೳ͸SF*OWFOUͰൃද wݱ࣌఺Ͱ͸1SFWJFX

AWS Greengrass 使わないの? 使いたい。

AWS Greengrass 僕らが使えない理由 •ローカルリソースアクセス機能が無かった •DL用途だと、GPUやカメラへのアクセスにアクセスしたい •re:Invent 2017後から使えるようになった •フレームワークまで含めた管理・デプロイをするのが難しい •DLフレームワーク・依存ライブラリも含めてデプロイしたい •DLフレームワークは依存するライブラリが多い(OpenCV/Boost/cuda/etc.) •それぞれバージョンアップが頻繁→アップデートにより環境がしばしば壊れる •Lambdaでデプロイできる最大容量は50MB •デプロイパッケージにライブラリ類を含めるのは現実的では無い

まとめ •エッジデバイス上で推論をするにはそれなりのツラミがある •AWSのサービスを組み合わせる事で管理を実現できる •AWS IoT •Amazon ECR •etc. •AWS Greengrassは多くのユースケースで有効 •今後のアップデートに期待

ABEJA Wantedly