この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
2020年9月8日から30日まで開催されるAWS Summit Onlineのレポートです。
本記事で取り上げるセッションは下記となります。
セッション情報
スピーカー
ウミトロン株式会社 CTO 岡本 拓磨 氏
概要
ウミトロンは世界の水産養殖の課題解決に取り組んでいるスタートアップです。水産養殖の現実の課題を解決するには、ソフトウェアだけでなくハードウェアも含めて実際の洋上にプロダクトとして提供する必要があります。本セッションでは、海という過酷な環境にスタートアップというリソースが限られた組織で、どのようにプロダクトを開発・運用してきたか、AWS 上に構築してきたかをIoTと機械学習といった技術を中心にお話します。
動画と資料はこちら
セッションレポート
まずは、水産養殖について
- 水産養殖は、アジアを中心として急成長を続けている
- 通常の漁業は、魚の生産量と漁獲量が均衡しつつある
- 一部の魚は乱獲によって絶滅危惧種にもなっている
- 増加する需要を満たすため、水産養殖は発展を続けている
- 水産養殖は、最も将来性の高い食料生産方法のひとつ
- 沿岸海域を活用することで、現在の世界の水産物消費量の100倍を生産可能
水産養殖の課題
- 飼料コストは、総生産コストの50％を占める
- 餌の原料（魚粉）の価格は15年で3倍に高騰
- 種類によっても変わるが、多いと総生産コストの70〜80％にもなる
給餌効率をテクノロジーで改善する
- 魚の摂餌行動から無駄餌の検知と削減
- 機械学習で魚の摂餌行動を定量化
- 人手の制約を受けない魚の生育に最適な給餌
- 日々変わる魚の食欲に対して、最適な量・タイミングでの給餌を実現
- 人の都合で給餌が難しい時間帯がある（早朝・深夜）
- 天候などの都合で給餌が難しいときがある
- 日々変わる魚の食欲に対して、最適な量・タイミングでの給餌を実現
UMITRON CELL（IoTと機械学習を用いた自動給餌器）
- 中のタンクには400キログラム以上の餌が入る
- タンクから餌を送り出すモーターとスクリューを搭載
- 魚の様子を常時撮影するカメラ
- これらを管理する基板
- 天板にはソーラーパネルを設置
- SORACOMを利用してネットワーク接続
- モバイルアプリやWebブラウザで遠隔操作可能
- モニタリング
- 遠隔給餌制御
- 生育管理（どれだけの餌を魚に与えたか）
- データ蓄積
- 魚の食欲を解析し、給餌の最適化を行っている
- 魚は餌を食べている？ これ以上の餌を与えると無駄になる？
- 魚は餌を食べなくなると、行動が目に見えて少なくなる
- 給餌中でも魚の活性が落ちた場合、給餌をやめる
給餌の最適化を実現させるために必要なこと
- IoTを用いた遠隔操作とデータ収集
- 遠隔での給餌器制御
- 安定したデータ取得
- 制御ソフトウェアの継続的アップデート
- 機械学習を用いた魚の食欲解析
- 取得したデータについて、リアルタイムで機械学習で処理する
- 日々取得できるデータから、継続的な機械学習モデルの改善
IoTシステムを用いて実現したい機能
- リアルタイムな双方向通信
- IoTデバイスからデータ取得
- 遠隔からデバイス操作
- 養生での独立・安定した稼働
- 電源は太陽光のみ
- ユーザはIoTデバイスの近くに常にいない、すぐ行けるわけではない
- ネットワークも常に万全とは限らない
- デバイスを設置してからも容易に改善を続けられる
- 設置してから初めて分かる課題にも対応したい
- さまざまな自然環境
- 魚の生育データ
- 設置してから初めて分かる課題にも対応したい
AWS IoTによるIoT基盤
- IoTデバイス・Webサーバ・ネイティブアプリの3者とのリアルタイム双方向通信
- MQTT over WebSocket
- 安定稼働
- インフラ運用がほぼいらない
- AWSの各種サービス連携
- ログ保存といった「IoTデバイスからWebサーバのリクエスト」を一部肩代わり
- サービス全体の中で大部分のリクエストが該当
- ほとんどは自前でビジネスロジックを持たないため、開発者は事業ドメイン固有のビジネスロジックに集中できる
- ログ保存といった「IoTデバイスからWebサーバのリクエスト」を一部肩代わり
IoTデバイスの構成
- Raspberry Pi + Raspbian + Go
- あとからソフトウェア変更が簡単なアーキテクチャ
- IoTデバイス設置後でも大幅な変更が可能
- 電力消費はモーターが大きいため、省電力マイコンにこだわらない
- 汎用品を使う
- Linuxの既存資産を利用
- 広く使われているので、情報が多い
- sshでトラブルシューティングが可能
- あとからソフトウェア変更が簡単なアーキテクチャ
- Go
- 高い生産性とパフォーマンス
- バイナリ配布だけで動く
- 簡単にアップデートできる
AWS構成
- 食欲判定の推論結果などを管理する機械学習サービス
- ユーザに提供するアプリケーション（Webサービス）
- Webサービス・IoTデバイス・モバイルアプリがAWS IoTを中心に双方向通信している
- Webサーバー・WorkerサーバーはDocker（ECS）を利用
- ストレージはデータ特性によってRDS、ElastiCache、DynamoDB、S3を使い分ける
AWS IoTによるリアルタイム双方向通信
- AWS IoTを利用した双方向通信を行っている
- 主にデバイスシャドウを利用している
- desired：WebサーバやモバイルアプリからIoTデバイスへのリクエスト
- 給餌開始・停止の命令
- リアルタイムモニタリング開始・停止の命令
- reported：IoTデバイスの状態を反映
- 給餌の進捗状況
- desired：WebサーバやモバイルアプリからIoTデバイスへのリクエスト
- 現在のIoTデバイスの状態を確認するとき、デバイスシャドウだけ見れば良い
- 非同期で命令をIoTデバイスに送れる
- 常に万全なネットワーク状態ではない
- ユーザが一時的にデバイスの電源を落としている場合もある
IoTデバイスからのデータ取得
- カメラから得られる動画や画像のメディアファイル
- 直接S3に置く
- PreSigned URLを利用
- 大容量ファイルのアップロードがWebサーバを経由しないというメリット
- デバイスで計算した数値やテキストデータ
- AWS IoTからIoT Ruleを経由し、DynamoDBやS3に置く
- 一番多いリクエストがWebサーバーを経由しないというメリット
- AWS IoTからIoT Ruleを経由し、DynamoDBやS3に置く
ソフトウェアのアップデート
- パッケージはS3に置き、CloudFront経由で配信している
- アップデート命令は、AWS IoT Jobsで行う
- jobを作ったときにデバイスがオフラインでも、オンラインになった際にアップデートできる
- ネットワーク不調のとき
- 台風対策でデバイスを陸に上げて電源Offしているとき
- など
- jobを作ったときにデバイスがオフラインでも、オンラインになった際にアップデートできる
機械学習システムの構築における課題
課題だったこと
- 開発速度
- 継続的に機械学習サービスを改善するための開発環境
- 属人化によるキャッチアップコストの高さ
- 機械学習サービスのインフラパフォーマンス
- 限られた人数での運用
- Webエンジニアと機械学習エンジニアのスキルセット差異
取り組んでみて、課題ではなかったこと
- 実際に動くものを作るのはできたが、それを継続して安定運用することが難しかった
- 継続的なデータ収集
- 実用に耐えうる精度のモデル生成
- 推論結果のアプリケーションでの利用
最初に構築した機械学習システム
- デバイスからリアルタイムで取得したデータを解析し、推論結果をアプリケーションで利用することを検証するために構築した
- デバイスからのデータをWebサーバーで受け取り、MLサービスに渡す
- 受け取ったデータをgRPCを使ってTensorflowに渡し、推論結果を受け取り、Webサーバに返す
- Tensorflowで動くモデルは、EC2スポットインスタンス上、またはローカルMac上で学習する
- 学習に使うデータは、S3やRDSから都度取得していた
初期の機械学習システムの課題
- 複雑な環境による開発の難しさ
- 学習環境が統一されていない
- EC2スポットインスタンス
- ローカルPC（Mac）
- 訓練データの管理方法が統一されていない
- デファクトな構成でないため学習コストが高い
- Webエンジニア
- 新入社員のキャッチアップ
- 学習環境が統一されていない
- 機械学習サービスのインフラ運用の難しさ
- Webサービスの負荷を機械学習サービスが裁けない
- 機械学習サービスのパフォーマンスがユーザに影響を与える
- 機械学習エンジニアだけインフラ運用できない
- Webサービスの負荷を機械学習サービスが裁けない
Amazon SageMakerを機械学習システムの基盤に採用した
- フレームワークとしてのAmazon SageMaker
- 統一された構成
- 学習環境のばらつき等が無い
- 学習コストをAmazon SageMakerのみに集約
- Webエンジニア、新入社員がキャッチアップしやすい
- 統一された構成
- フルマネージドなインフラ
- インフラ運用コストの削減
- 機械学習エンジニアでも運用できる
- Webサービスと機械学習サービスを疎結合にできる
- Amazon SageMakerのendpointで2つのサービスを結合
- Amazon SageMakerの知識だけで互いを運用できる
実際の機械学習サービスの構成
- デバイスからリアルタイムに来たデータは、IoT RuleによってDynamoDBやS3に保存される
- 推論リクエストは、AWS IoT RuleからSQSに渡り、Webサービス上でリアルタイムに必要な情報を付与して、SageMakerのendpointに渡す
- 推論結果は、AWS IoTを経由してデバイスに給餌命令として渡される
- 学習はSageMakerのノートブックインスタンス上で行う
- 学習したモデルはStepFunctionsでSageMakerのendpointにデプロイされる
Amazon SageMakerを採用した効果
- 開発環境の簡素化
- 学習環境が統一された
- 必要なインフラ知識をAmazon SageMakerに集約できた
- Amazon SageMakerさえ分かれば誰でも分かる
- 開発環境で社内特有の知識が少ない
- スケールが容易
- インフラ運用コストが少ない
- Webサービスが受ける影響が、Amazon SageMakerのパフォーマンスのみに限定される
- 機械学習エンジニアだけでインフラをスケールできる
今後の機械学習システムの発展
- 継続的に収集できる訓練データで、モデルの改善イテレーションを高速化
- 訓練データ作成の自動化
- Athenaやnotebookでのくれんデータ作成
- アノテーションの自動化
- Amazon SageMaker Ground Truth
- レポーティングの自動化
- 学習したモデルの評価
- 訓練データ作成の自動化
感想
機械学習システムの構築について、「実際に動くものを作るのはできたが、それを継続して安定運用することが難しかった」旨の発言があり、システムは作って終わりではなく育てていくことが大事だと再認識しました。 そして、機械学習サービスの活用について最初の構成と課題の紹介があり、その課題をどのように解決したのかという現在の構成紹介がとても参考になりました。
14
