この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
DA事業本部の春田です。
AWS Summit Online絶賛開催中！ということで、本記事では「CUS-35：KYB における AWS を活用した IoT-Platform の構築 ～予知保全システムにおける Amazon SageMaker の活用～」の内容についてまとめていきます。
セッション情報
- KYB 株式会社 DX 推進部 内藤 孝昌 氏
設計・生産から製品使用時のデータに至るまで、社内のデータ活用を加速させる基盤として、AWS 上に IoT-Platform の構築を進めています。 本セッションでは、その一部である設備予知保全システムを例に、Amazon SageMaker 周辺のサービス活用について重点的に紹介します。
※セッション動画は以下リンク
はじめに
- 話すこと
- KYBがどんなIoT-Platformを構築中なのか
- 「予知保全」中心
- AWSをどのように活用しているのか
- 「Amazon SageMaker」中心
- 話さないこと
- 予知保全の機械学習モデル
- KYBがどんなIoT-Platformを構築中なのか
アジェンダ
- About KYB
- 会社紹介
- KYBのITシステム開発
- IoT-Platform
- 概要と課題
- 予知保全システム
- Amazon SageMakerの活用
- Amazon SageMakerを使う上での工夫
- ML Workflows構築における工夫
- Conclusion
About KYB
会社紹介
- 創立: 1935年3月
- 創業者: 萱場 資郎
- 代表取締役社長執行役員: 大野 雅生
- 売上高: 4,122億円（2018年度実績・連結）
- 従業員: 15,426名（2018年度・連結）
- 人々の暮らしを安全・快適にする技術や製品の提供
- 自動車や新幹線などにもKYB社の技術が使われている
製品図で赤色で示した部品がKYB社製
KYBのITシステム開発
- 1996年: POPICS
- MESのシステムで、生産計画の提供や可動率などのKPIの自動計算を担っている中核システム
- 2000年: 品番チェックシステム
- ハンディターミナルを用いた部品庫・製品庫などで使用するシステム
- 2002年: トレサビシステム
- 製品のシリアルNoと各種情報を紐付けた、トレーサビリティのシステム
- 2008年: 作業・検査支援システム
- 手順の提示、計測値の自動収集や判定を行う、組立作業や検査作業を支援するシステム
- 2013年: QTS
- 鋳造工場における品質情報を全て収集し、各種分析を行えるようにしたシステム
- 2014年: 溶接不良検知
- 機械学習を活用し、時系列データのみで溶接品質をリアルタイムに判定するシステム
- 2019年: 予知保全
- クラウドと機械学習をフル活用した、IoT-Platformの一部機能 → 今回の中心
※KYB技報No.60の特集記事にて近年の取り組みを紹介
- 創立80年以上の老舗油圧技術メーカーだが、ITにも取り組んでいる
- 内藤氏のいるチームの実績では、ほぼ内製
- チーム内で新規開発・運用しているシステムは数十個
IoT-Platform
概要と課題
- なぜIoT-Platformか
- 既存システムの連携状態がスパゲティ
- そこにIoTデータが増えると破綻
- IoT-Platformが目指す姿
- 左側がKYB、右側がユーザー、中央がIoT-Platform
- ユーザー側の車両データ、KYB側の生産・設計・開発のデータをIoT-Platformに集約
- IoT-Platform上で、処理・分析・可視化を行うことで以下を実現
- ①生産性の向上 → KYB
- ②品質の向上 → KYB
- ③製品付加価値の向上 → KYB
- ④新しい価値の提供 → ユーザー
- 従来はオンプレかクラウドの仮想マシンでPlatformを構築していた
- オンプレやIaaS
- 開発コスト ≦ 運用コスト になってしまう
- ビジネスに注力したい
- クラスタ管理などに注力したくない
- スモールスタートができない or 難しい
- 最初から全てはうまくいかない
- 素早く構築し、繰り返し改善したい
- 開発コスト ≦ 運用コスト になってしまう
よりマネージドなサーバレス（FaaS）を中心に採用
予知保全システム
- 保全の種類は3つ
- 壊れたら保全する、事後保全
- 計画的に保全する、予防保全
- 故障を予知して壊れる前に保全する、予知保全
- 予知保全は複雑な仕組みになるが、近年のAI・IoTの発展に伴い、多くの製造業で取り組まれている
- 予知保全システムの全体像
- 左上がKYBの工場で、設備、センサー、エッジコンピューターがある
- 工場で収集されたデータは、右側のAWS上に転送され、処理・分析を行う
- 最終的に故障が予測される場合は、左下オフィスの保全担当者にアラートメールを送る
- データ収集
- AWS IoT Coreを中心に、デバイス管理
- 予知保全用センサデータ例
- 種類: 振動データ
- 収集頻度: 30分毎、10秒間
- データ量: 40MB/ファイル = MQTTでストリーミングできる量ではない
- 大容量データは得意ではないため、エッジデバイスから直接S3にアップロードして対応
- 入口にはAWS IoT Coreを使用
- S3の特定のバケットにアクセスできるRoleを、一時クレデンシャルとして取得
- トークンを使用してエッジデバイスからS3へデータをアップロード
- 故障判定
- エッジとクラウドの2段階で行っているのが特徴
- 左側がエッジで行う短期故障判定
- 特徴抽出
- 短期故障モデルを事前にAmazon SageMakerで学習
- 学習済みモデルを、GreengrassのML Inferenceの機能を通してEdge側にデプロイ
- リアルタイムの推論を実現する
- 生波形は10秒間で40MBといった、非常に大きな容量のファイル
- リアルタイムの推論によって、サイズの小さな短期故障度ファイルに変換する
- 右側がクラウド上で行う長期交渉判定
- 短期故障度ファイルをAWSに転送
- 10秒のファイルを何個かにまとめて長期的なトレンドを把握し、長期故障判定を行う
- 故障が予測される場合は、SNSを通してユーザーへ通知
- 見える化
- 使い方とコストを考慮し、まずはAmazon Athena採用
- S3上のデータをAthenaを使って直接クエリ
- EC2上のTableauサーバーを経由して、ダッシュボードの形で保全担当者へ提供
Amazon SageMakerの活用
Amazon SageMakerを使う上での工夫
- Amazon SageMakerとは
- 機械学習のあらゆるワークフローをサポートする、フルマネージド型サービス
- ラベリング
- ラベリング支援
- 開発
- マネージドJupyter Notebook
- 主要フレームワークのサポート
- 学習
- APIで学習ジョブ
- 分散学習、チューニングに対応
- 推論
- API で推論エンドポイントをデプロイ
- バッチ推論サポート
- 使ってみたらかなり便利だったが、最初はうまく行かなくて色々と工夫した
- 課題1: 使い慣れたエディタで開発したい
- Notebookインスタンスが提供されているので、普通はそれを使う
- 学習するときにはコンテナを起動する
- 開発の序盤、探索的なデータ分析（EDA）を行うときにはNotebookを使用
- プロダクションのMLコードを開発するときは、使い慣れたエディタで開発したい
- 解決1: 開発マシンにSageMaker Python SDKを導入
- オフィスにある自分のパソコンでコーディングが可能
- 学習したいときは、fitメソッドでクラウド上のSageMakerでトレーニングジョブが起動
- 課題2: 開発のイテレーションを高速化したい
- 開発初期はコーディングミスが発生
- コンテナ起動に数分時間がかかった後にエラーが確認され、効率が悪い
- 解決2: Localモードの活用
- トレーニングのジョブをローカルのコンテナで起動できる
- 開発初期は少量データでローカル開発、高速で開発イテレーションを回す
- 後半は大量データを使い、AWS上の大規模なインスタンスでで学習
roleとtrain_instance_typeを変更するだけ- データもローカルを利用可能
# 通常モード
role = get_execution_role()
train_input = "s3://foo-bar/train_aws.csv"
estimator = PyTorch(entry_point='mnint.py',
role=role,
train_instance_count=1,
train_instance_type='ml.p2.xlarge',
framework_version='1.4.0')
##################################################
# Localモード
role = 'arn:aws:iam::xxxxx:role/SageMakerExecutionRole'
train_input = 'file://foo-bar/train_local.csv'
estimator = PyTorch(entry_point='mnint.py',
role=role,
train_instance_count=1,
train_instance_type='local_gpu',
framework_version='1.4.0')- 課題3: 低頻度の推論を低コストで実現したい
- 予知保全のような機械学習は、一つのモデルで全ての推論ができることはありえない
- 似たような設備ごとに個別のモデルが作られることが一般的
- 30分に1回データを収集している場合は、最速でも30分に1回しか推論を行わない
- 予知保全で欲しい情報は、10分後でなく、2週間後や1ヶ月後の推論
- 昨日のデータで1日1回推論したとしても機能する
- 低頻度の利用では、エンドポイントはリソースの無駄が多い
- プロビジョンニングの対して、実際に使われているリソースが非常に少ない
- 解決3: Batch Transform の活用
- 低頻度かつ非リアルタイムで良いならBatch Transform
- バッチで推論を行うので、無駄なリソースを削減できる
- その他: Managed Spot Trainingの活用
- スポットインスタンスを使ってトレーニングを行う
- A. スポットの使用フラグと時間を設定するだけ
- B. 中断対策としてcheckpointを利用可
- コストが最大で9割減、平均６割〜7割減
estimator = PyTorch(entry_point='mnint.py',
role=role,
train_instance_count=1,
train_instance_type='ml.p2.xlarge',
train_max_run=6000, # A
train_use_spot_instances=True, # A
train_max_wait=7200, # A
checkpoint_s3_uri='s3://example-bucket/checkpoints', # B
checkpoint_local_path='/opt/ml/checkpoint', # B
framework_version='1.4.0')- モデルの学習は出来たし、推論の確認もした
- あとは実行して故障通知するだけ？
- むしろここからが重要
ML Workflows構築における工夫
- ML Workflowsの実現
- 機械学習花形のモデリングは全体のごく一部
- データの収集やリアルタイム推論をどう実現するか、などの管理も必要
- KYB社は学習のワークフローと、推論のワークフローをどう実現したか？
AWS Step Functionsでお手軽Workflow化
- 学習Workflow
- 現在は未実装（あえて人間のオペレーションを挟む）
- モデル1とモデル2があり、２の方が新しいが、１の方が性能が良い
- 推論では自動的にモデルを選択したい → タグを活用
- 任意のタイミングで開発者が学習をかけ、モデル3が生成
- タグのデフォルトは
dev - 予知保全ではABテストによる全自動化が難しいため、開発者が評価してタグを切り替えている
- 推論Workflow
- モデルごとに動的並列処理
- 時代に応じてモデルが増える
- 定期的に推論を行うので、毎回対象が変わってくる可能性がある
- データの前処理もSageMaker内で実施
- 前処理（正規化など）も学習データの情報を含んでいる
- パイプライン化し、バッチジョブで実行している
- モデルごとに動的並列処理
- 並列処理のエラーハンドリング
- Task2がエラーとなった時、CatchしてFailのステートに落としたくなる
- Failにすると、他の全並列処理が強制終了してしまう
- → 並列内ではPassで一旦無視する
- → 並列処理後、エラーのフラグをチェックする
Conclusion
- Amazon SageMakerまとめ
- 既に我々にとって必須のサービス
- 今後は 他部署にも展開していく計画
- まだまだ進化しており、今後も非常に楽しみ
- KYBの取り組みまとめ
- KYBではIoT-Platformの構築を進めている
- 外注丸投げではなく、内製を中心に取り組んでいる
- 製品領域への適用も進めている最中
18
