【レポート】KYBにおけるAWSを活用したIoT-Platformの構築 ～予知保全システムにおけるAmazon SageMakerの活用～ #AWSSummit

DA事業本部の春田です。

AWS Summit Online絶賛開催中！ということで、本記事では「CUS-35：KYB における AWS を活用した IoT-Platform の構築 ～予知保全システムにおける Amazon SageMaker の活用～」の内容についてまとめていきます。

セッション情報

• KYB 株式会社 DX 推進部 内藤 孝昌 氏

設計・生産から製品使用時のデータに至るまで、社内のデータ活用を加速させる基盤として、AWS 上に IoT-Platform の構築を進めています。 本セッションでは、その一部である設備予知保全システムを例に、Amazon SageMaker 周辺のサービス活用について重点的に紹介します。

※セッション動画は以下リンク

はじめに

1. 話すこと
   1. KYBがどんなIoT-Platformを構築中なのか
      1. 「予知保全」中心
   2. AWSをどのように活用しているのか
      1. 「Amazon SageMaker」中心
   3. 話さないこと
      1. 予知保全の機械学習モデル

アジェンダ

1. About KYB
   1. 会社紹介
   2. KYBのITシステム開発
2. IoT-Platform
   1. 概要と課題
   2. 予知保全システム
3. Amazon SageMakerの活用
   1. Amazon SageMakerを使う上での工夫
   2. ML Workflows構築における工夫
4. 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の構築を進めている
  • 外注丸投げではなく、内製を中心に取り組んでいる
  • 製品領域への適用も進めている最中