Python をフル活⽤した⼯場への AI 導⼊ & データ活⽤基盤構築 事例 2021.10.16 PyCon JP 2021

誰︖︖︖ • ソフトウェアエンジニア • ちゅらデータ株式会社 VPoE • 沖縄に移住して4年 • JavaScript / Python / Docker / AWS あたりをよく触っている • PyCon Kyushu in Okinawa 2019 コアスタッフ & スピーカー • ISUCON 10 & 11 スタッフ (Python 実装担当) Yuki Ishikawa @hoto17296

• 沖縄に『最⾼に⾯⽩い仕事』を作りたい︕という想いで 2017 年に創業した会社 • 受託データ分析・データ基盤構築・アプリケーション開発・技術研修などなど、 お客様の課題をあらゆる技術を使って解決する技術集団 • 急拡⼤中につき⼿が全然⾜りない、技術者を積極採⽤中 沖縄で︕⼀緒に Python を書きましょう︕︕

今⽇の話 ❌「最新の⼿法で︕ババっと課題解決︕」 「Python 最⾼︕︕︕」 ⭕「特に新しくない⼿法を積み上げてシステムを作った」 「各所に Python を使ってみたら割とうまく動いた」

AGENDA 1. プロジェクトの概要 2. 構築したシステムの概要 3. 設計の勘所 4. まとめ

1. プロジェクトの概要

プロジェクトの背景と課題 とある⼯業製品の製造⼯程にて、加⼯機器のパラメータ設定が職⼈技となり 属⼈化してしまっているという課題が発⽣していた 加⼯機器 原料 (品質にバラツキがある) 制御システム (職⼈がパラメータを設定) 製品 原料の品質に応じて適切なパラメータを設定しないと、 「製品の品質にバラツキが⽣じる」「⽣産効率が落ちる」 「加⼯機器が故障する」などの問題が発⽣する

プロジェクトの⽬的 職⼈技を AI で置き換えることで属⼈化を解消したい + 職⼈と同等以上の製造効率と品質を維持したい 加⼯機器 原料 (品質にバラツキがある) 制御システム (AI がパラメータを設定) 製品

実施した取り組み 1. AI の学習と評価 (PoC) ※ 今回は AI についての詳しい説明は割愛する • 機械学習モデルを学習し、評価を⾏った • 「原料の品質情報」や「センサから取得したデータ」などを⽤いた • 「(最適と思われる) 機器パラメータ」を出⼒するものができた • 複数回の PoC で試⾏錯誤し、最終的に良好な結果が得られた • しかしまだまだ性能改善していきたい 2. システム構築 ※ 今回はこの部分の話 • 制御システムと AI が連携する仕組みの構築 • データを蓄積する仕組みの構築 • 定期的に AI を再学習する仕組みの構築 まず PoC を実施し、良好な結果が得られたためシステムへの組み込みを⾏った PoC で判明した課題 • データの質が良くない • PoC を実施しながら改善した • データ量が不⼗分 • データ連携と前処理の⼿間

2. 構築したシステムの概要

システムの全体像 ⼯場内のサーバ機と AWS を組み合わせて以下のようなシステムを構築した AWS ロギング・監視・通知 CI / CD ⼯場 制御システム センサー システム Linux サーバ機 推論 API (HTTP サーバ) ⽣データ (Amazon S3) データベース (Amazon Aurora) ⽇次の集計処理 (Amazon ECS) モデル再学習処理 (Amazon ECS) 前処理済みデータ (Amazon S3) 専⽤線 (AWS Direct Connect) 製造ライン センサデータ前処理 (AWS Lambda) ログ/メトリクス基盤 (Amazon CloudWatch) アラート通知 (Amazon SNS) アラートメール配信 (Amazon SES) コンテナリポジトリ (AWS ECR) コードリポジトリ (AWS CodeCommit) ビルドパイプライン (AWS CodeBuild) アドホック分析⽤ Jupyter (Amazon EC2) データ転送 Worker

AWS ロギング・監視・通知 CI / CD ⼯場 制御システム センサー システム Linux サーバ機 推論 API (HTTP サーバ) ⽣データ (Amazon S3) データベース (Amazon Aurora) ⽇次の集計処理 (Amazon ECS) モデル再学習処理 (Amazon ECS) 前処理済みデータ (Amazon S3) 専⽤線 (AWS Direct Connect) 製造ライン センサデータ前処理 (AWS Lambda) ログ/メトリクス基盤 (Amazon CloudWatch) アラート通知 (Amazon SNS) アラートメール配信 (Amazon SES) コンテナリポジトリ (AWS ECR) コードリポジトリ (AWS CodeCommit) ビルドパイプライン (AWS CodeBuild) アドホック分析⽤ Jupyter (Amazon EC2) データ転送 Worker このシステムで実現したかったポイント このシステムにはいくつものコンポーネントがあるが、 それらはすべて以下の3点を実現するためである AI が制御システムに 最適なパラメータを 設定する センサデータを 今後のデータ分析に 活⽤しやすいかたちで 蓄積する 蓄積した最新データで AI を定期的に再学習する

AWS ロギング・監視・通知 CI / CD ⼯場 制御システム センサー システム Linux サーバ機 推論 API (HTTP サーバ) ⽣データ (Amazon S3) データベース (Amazon Aurora) ⽇次の集計処理 (Amazon ECS) モデル再学習処理 (Amazon ECS) 前処理済みデータ (Amazon S3) 専⽤線 (AWS Direct Connect) 製造ライン センサデータ前処理 (AWS Lambda) ログ/メトリクス基盤 (Amazon CloudWatch) アラート通知 (Amazon SNS) アラートメール配信 (Amazon SES) コンテナリポジトリ (AWS ECR) コードリポジトリ (AWS CodeCommit) ビルドパイプライン (AWS CodeBuild) アドホック分析⽤ Jupyter (Amazon EC2) データ転送 Worker Python 利⽤箇所 このプロジェクトでは多くの場所で Python を採⽤した 以降のスライドでそれぞれどのように技術選定していったかを説明する

センサデータの取得 (1/3) ⼯場のセンサシステムにアクセスしてセンサデータを取得する箇所 AWS ロギング・監視・通知 CI / CD ⼯場 制御システム センサー システム Linux サーバ機 推論 API (HTTP サーバ) ⽣データ (Amazon S3) データベース (Amazon Aurora) ⽇次の集計処理 (Amazon ECS) モデル再学習処理 (Amazon ECS) 前処理済みデータ (Amazon S3) 専⽤線 (AWS Direct Connect) 製造ライン センサデータ前処理 (AWS Lambda) ログ/メトリクス基盤 (Amazon CloudWatch) アラート通知 (Amazon SNS) アラートメール配信 (Amazon SES) コンテナリポジトリ (AWS ECR) コードリポジトリ (AWS CodeCommit) ビルドパイプライン (AWS CodeBuild) アドホック分析⽤ Jupyter (Amazon EC2) データ転送 Worker

センサデータの取得 (2/3) • センサーシステムは機器に対して TCP ベースの独⾃プロトコルでアクセスすると、 直近10分間のセンサデータを取得することができるという仕様 • 取得しに⾏かなければセンサデータは破棄されていく • もちろん Python ⽤のライブラリなどない (他の⾔語でもない) センサからデータを取得するには独⾃のプロトコルを喋る必要があった センサー システム データ転送 Worker 温度 位置・⾓度 電流値 温度センサ1のデータをくれ はいよ (直近10分データ) 定期的にデータを取得して Amazon S3 に保存する

センサデータの取得 (3/3) Python に独⾃プロトコルを喋らせた TCP 通信は asyncio で実装した (socket でも書けるが、通信処理はノンブロッキング IO で書きたい) バイナリデータの取り扱いも書いてみれば意外と短い 独⾃プロトコル実装、意外とできる ※ マトモな仕様書があれば Request Response Usage

補⾜︓ データをロストしない⼯夫 • ⽣データは無加⼯で Amazon S3 に送る • 加⼯処理に失敗してエラー吐いたらロストする • 「受け取って」「送る」以外のことは極⼒やらない • 実際は gzip 圧縮だけやった • まず HDD に保存する • ただ転送するだけでは、ネットワーク障害や AWS 障害でデータがロストしてしまう • データを受け取ったらまず HDD に書き出して、Amazon S3 への保存が完了したら消す • 障害の際は HDD にデータが残るのでロストしない センサデータは⼀度取りこぼすと再取得が不可能なため、 取りこぼさない⼯夫をした

データ処理 (1/3) 保存したセンサデータに対して前処理・集計処理を⾏う箇所 AWS ロギング・監視・通知 CI / CD ⼯場 制御システム センサー システム Linux サーバ機 推論 API (HTTP サーバ) ⽣データ (Amazon S3) データベース (Amazon Aurora) ⽇次の集計処理 (Amazon ECS) モデル再学習処理 (Amazon ECS) 前処理済みデータ (Amazon S3) 専⽤線 (AWS Direct Connect) 製造ライン センサデータ前処理 (AWS Lambda) ログ/メトリクス基盤 (Amazon CloudWatch) アラート通知 (Amazon SNS) アラートメール配信 (Amazon SES) コンテナリポジトリ (AWS ECR) コードリポジトリ (AWS CodeCommit) ビルドパイプライン (AWS CodeBuild) アドホック分析⽤ Jupyter (Amazon EC2) データ転送 Worker

データ処理 (2/3) 10分間の時系列データから「1回の⽣産」単位のデータを抽出する ⽣産 ⽣産 ⽣産 ⽣産 ⽣産 ⽣産 ⽣データ1 ⽣データ2 ⽣データ3 ⽣データ4 ⽣データ6 ⽣データ5 ⽣データ7 10分 ⽣産 ⽣データ (Amazon S3) 前処理済みデータ (Amazon S3) AWS Lambda s3:ObjectCreated イベントを トリガーにして Lambda 起動 「1⽣産」単位で データを抽出 (その他様々な 前処理をして) 保存

データ処理 (3/3) 1⽇1回、⽣産データを集計してデータベースに格納する ⽣産 ⽣産 ⽣産 前処理済みデータ (Amazon S3) データベース (Amazon Aurora) Amazon ECS 集計結果 1⽇分の ⽣産データを集計 ECS のスケジューラを設定して毎⽇タスク実⾏

モデル再学習 (1/2) データが貯まったら (3ヶ⽉に1回) モデルを再学習する箇所 AWS ロギング・監視・通知 CI / CD ⼯場 制御システム センサー システム Linux サーバ機 推論 API (HTTP サーバ) ⽣データ (Amazon S3) データベース (Amazon Aurora) ⽇次の集計処理 (Amazon ECS) モデル再学習処理 (Amazon ECS) 前処理済みデータ (Amazon S3) 専⽤線 (AWS Direct Connect) 製造ライン センサデータ前処理 (AWS Lambda) ログ/メトリクス基盤 (Amazon CloudWatch) アラート通知 (Amazon SNS) アラートメール配信 (Amazon SES) コンテナリポジトリ (AWS ECR) コードリポジトリ (AWS CodeCommit) ビルドパイプライン (AWS CodeBuild) アドホック分析⽤ Jupyter (Amazon EC2) データ転送 Worker

モデル再学習 (2/2) 3ヶ⽉に1回、溜めたデータをもとに機械学習モデルを再学習する (詳細は割愛) ⽣産 ⽣産 ⽣産 前処理済みデータ (Amazon S3) データベース (Amazon Aurora) Amazon ECS 学習済み モデル モデル学習 ECS のスケジューラを設定して3ヶ⽉に1回タスク実⾏ データベース (Amazon Aurora) 集計データ

推論 API (1/3) 制御システムと連携してパラメータを⾃動設定する箇所 AWS ロギング・監視・通知 CI / CD ⼯場 制御システム センサー システム Linux サーバ機 推論 API (HTTP サーバ) ⽣データ (Amazon S3) データベース (Amazon Aurora) ⽇次の集計処理 (Amazon ECS) モデル再学習処理 (Amazon ECS) 前処理済みデータ (Amazon S3) 専⽤線 (AWS Direct Connect) 製造ライン センサデータ前処理 (AWS Lambda) ログ/メトリクス基盤 (Amazon CloudWatch) アラート通知 (Amazon SNS) アラートメール配信 (Amazon SES) コンテナリポジトリ (AWS ECR) コードリポジトリ (AWS CodeCommit) ビルドパイプライン (AWS CodeBuild) アドホック分析⽤ Jupyter (Amazon EC2) データ転送 Worker

推論 API (2/3) 制御システムが HTTP をしゃべることができたため、パラメータの連携は 普通の HTTP サーバを実装するだけで事⾜りた 制御システム 推論 API (HTTP サーバ) データベース (Amazon Aurora) aiohttp 学習済み モデル 原料の品質情報 パラメータ 取得したモデルはメモリ内に保持しておく → ネットワーク障害が発⽣しても オフライン動作が可能に

推論 API (3/3) 何らかの理由でレスポンスを返せないままでいると⼯場の⽣産に遅れが⽣じて しまう恐れがあるため、サーバ側でもタイムアウトは適切に設定する こういうデコレータを 作っておくと ※ aiohttp Server の場合 こんな⾵に使えて便利

システムの全体像 ⼯場内のサーバ機と AWS を組み合わせて以下のようなシステムを構築した AWS ロギング・監視・通知 CI / CD ⼯場 制御システム センサー システム Linux サーバ機 推論 API (HTTP サーバ) ⽣データ (Amazon S3) データベース (Amazon Aurora) ⽇次の集計処理 (Amazon ECS) モデル再学習処理 (Amazon ECS) 前処理済みデータ (Amazon S3) 専⽤線 (AWS Direct Connect) 製造ライン センサデータ前処理 (AWS Lambda) ログ/メトリクス基盤 (Amazon CloudWatch) アラート通知 (Amazon SNS) アラートメール配信 (Amazon SES) コンテナリポジトリ (AWS ECR) コードリポジトリ (AWS CodeCommit) ビルドパイプライン (AWS CodeBuild) アドホック分析⽤ Jupyter (Amazon EC2) データ転送 Worker 再掲

3. 設計の勘所

AWS ロギング・監視・通知 CI / CD ⼯場 制御システム センサー システム Linux サーバ機 推論 API (HTTP サーバ) ⽣データ (Amazon S3) データベース (Amazon Aurora) ⽇次の集計処理 (Amazon ECS) モデル再学習処理 (Amazon ECS) 前処理済みデータ (Amazon S3) 専⽤線 (AWS Direct Connect) 製造ライン センサデータ前処理 (AWS Lambda) ログ/メトリクス基盤 (Amazon CloudWatch) アラート通知 (Amazon SNS) アラートメール配信 (Amazon SES) コンテナリポジトリ (AWS ECR) コードリポジトリ (AWS CodeCommit) ビルドパイプライン (AWS CodeBuild) アドホック分析⽤ Jupyter (Amazon EC2) データ転送 Worker Python 利⽤箇所 このプロジェクトでは多くの場所で Python を採⽤した 以降のスライドでそれぞれどのように技術選定していったかを説明する 再掲

なぜ Python で統⼀したか 最近のプログラミング⾔語は どれを選んでも だいたいなんでもできる 作るシステムに対して 強みが活かせる⾔語を選ぶ システム全体で⾔語を 統⼀することにメリット • 各コンポーネントで同じモジュールを使い回せる • その⾔語さえ使えればシステム全体を触れる 機械学習に強みのある Python がいい システム全体を Python で作ろう︕

Python は遅い︖ • Python (CPython) は遅いか︖ • 本当に遅いのかどうかはよく知らない • C で書かれたモジュールは遅くないとかなんとか︖ (知らない) • 仮に Python が遅いとしたときのリスク • API サーバのレスポンスが遅れる • 今回は「5秒以内に返せればいい」程度の要件だったため無問題だった • バッチ処理に時間がかかる・コストがかさむ • コスト試算してみたが無問題だった • 所感 • 計算リソースは柔軟にスケールできる時代なので、⾔語としての速度を気にしすぎるよりも ⾔語としての強みや開発スピードなどの他のメリットに⽬を向けたほうがいいのではないか 少なくとも今回のプロジェクトでは問題にならなかった

AWS でデータ処理を⾏う際の選択肢 (1/2) 何らかのデータ処理を⾏うシステムを作りたい場合、無数の選択肢がある ⽣データ (Amazon S3) 加⼯済みデータ (Amazon S3) 何らかの データ処理 観点︖ • 何を起点に処理するか • 処理性能 • 柔軟性・表現⼒ • エラー処理・リトライ • コスト • 信頼性 要件1 (⽣データの前処理) • すべての S3 オブジェクトに対して 変換処理したい • 数分に1回オブジェクトが作成される • 1回あたりの処理は数秒 • Python + Pandas で処理を記述したい 要件2 (⽇次の集計処理) • 1⽇に1回、1⽇分データを処理したい • 1回あたりの処理は数分〜数⼗分 • Python + Pandas で処理を記述したい

AWS でデータ処理を⾏う際の選択肢 (2/2) • AWS Lambda • 最も⼿軽、可能な限り Lambda でやりたい • タイムアウトが最⼤でも900秒 (15分) という制約 • AWS Batch • ETL というよりジョブキュー • スケジューリングはできないと思っていたが、いつの間にか対応していた • AWS Glue Jobs (Python Shell) • PySpark を使う場合は有⼒な選択肢になりそうだが今回は Python Shell で検討 • 細かい Python バージョンを選択できない点がデメリット • Amazon ECS Tasks (EC2 + AutoScale) • Docker イメージを使えるので⾮常に柔軟 • 最⼩インスタンス数を 0 にできない (︖) ので実⾏していないときも料⾦が発⽣してしまう • Amazon ECS Tasks (Fargate) • 実⾏されている間だけ課⾦される、便利︕ 今回は AWS Lambda と Amazon ECS Tasks (Fargate) を採⽤

EC2 は︖ • 「サーバ管理」は気にしなければならないことが多く多⼤なコストがかかるため ⾃分たちでサーバ管理するコンポーネントは少ないに越したことはない • サーバ管理したくないシステムたち • データが消えないように細⼼の注意を払う系 • オブジェクトストレージ / データベース / ログ基盤 / メールサーバ / DNS サーバ / Git リポジトリ • 柔軟にスケールできないとすぐリソースが詰まる系 • ジョブキュー / バッチ処理 / パイプライン • 特殊な事情がない限りはマネージドサービスをフル活⽤するのが現代のシステム設計における ベストプラクティスではないか 少⼈数で AWS にシステム構築するプロジェクトにおいては 「EC2 は使ったら負け」くらいの⼼構えを持つのがよい

オンプレサーバをどう考えるか (1/3) いくら AWS マネージドサービスを活⽤したところで、サーバ管理から 逃れられない領域がある AWS ロギング・監視・通知 CI / CD ⼯場 制御システム センサー システム Linux サーバ機 推論 API (HTTP サーバ) ⽣データ (Amazon S3) データベース (Amazon Aurora) ⽇次の集計処理 (Amazon ECS) モデル再学習処理 (Amazon ECS) 前処理済みデータ (Amazon S3) 専⽤線 (AWS Direct Connect) 製造ライン センサデータ前処理 (AWS Lambda) ログ/メトリクス基盤 (Amazon CloudWatch) アラート通知 (Amazon SNS) アラートメール配信 (Amazon SES) コンテナリポジトリ (AWS ECR) コードリポジトリ (AWS CodeCommit) ビルドパイプライン (AWS CodeBuild) アドホック分析⽤ Jupyter (Amazon EC2) データ転送 Worker

オンプレサーバをどう考えるか (2/3) • 背景 • 「⽣産に関わるシステムは⼯場内で完結すること」という要件のため 推論は⼯場内でやる必要があった → オンプレサーバが必須 • オンプレサーバは⼤変 • 可⽤性を⾼めたい (システムが⽌まらないようにしたい) → 冗⻑構成 (物理サーバを複数台⽤意) → 設計が複雑化 & 運⽤オペレーションが複雑化 • 耐久性を⾼めたい (データが消えないようにしたい) → バックアップの仕組みとバックアップ先を⽤意 → ⾯倒⾒るコンポーネントが増える オンプレサーバは⼤変

オンプレサーバをどう考えるか (3/3) • ⽅針 • 可⽤性を割り切る • 「障害の際は AI を切り離して⼈間に替わればいい」という割り切り • RAID 1 は組む • 耐久性を不要にする • 「データ保持」はログも含めてすべてクラウドに寄せる、オンプレサーバに保持しない (ステートレス) • データを保持しないのでバックアップは考えない • 新しい物理サーバを⽤意すればすぐに同じものが作れるようにしておく • 結果 • サーバ1台で動かすように割り切れた → 構築と運⽤の⼯数を⼤幅に削減 「最悪、壊れたときはなんとかする」という⽅針に倒した

オンプレサーバのサービス管理 AWS ロギング・監視・通知 CI / CD ⼯場 制御システム センサー システム Linux サーバ機 推論 API (HTTP サーバ) ⽣データ (Amazon S3) データベース (Amazon Aurora) ⽇次の集計処理 (Amazon ECS) モデル再学習処理 (Amazon ECS) 前処理済みデータ (Amazon S3) 専⽤線 (AWS Direct Connect) 製造ライン センサデータ前処理 (AWS Lambda) ログ/メトリクス基盤 (Amazon CloudWatch) アラート通知 (Amazon SNS) アラートメール配信 (Amazon SES) コンテナリポジトリ (AWS ECR) コードリポジトリ (AWS CodeCommit) ビルドパイプライン (AWS CodeBuild) アドホック分析⽤ Jupyter (Amazon EC2) データ転送 Worker (簡単のために記載していないが) 実際は6個くらいサービスが動いている → どうやって管理する︖ (ログ収集/死活管理など)

Docker ! AWS 側では既に Docker を使っている (ECS) ので、オンプレのサービスも Docker で合わせるとデプロイフローが簡潔になって良い AWS ロギング・監視・通知 CI / CD ⼯場 制御システム センサー システム Linux サーバ機 推論 API (HTTP サーバ) ⽣データ (Amazon S3) データベース (Amazon Aurora) ⽇次の集計処理 (Amazon ECS) モデル再学習処理 (Amazon ECS) 前処理済みデータ (Amazon S3) 専⽤線 (AWS Direct Connect) 製造ライン センサデータ前処理 (AWS Lambda) ログ/メトリクス基盤 (Amazon CloudWatch) アラート通知 (Amazon SNS) アラートメール配信 (Amazon SES) コンテナリポジトリ (AWS ECR) コードリポジトリ (AWS CodeCommit) ビルドパイプライン (AWS CodeBuild) アドホック分析⽤ Jupyter (Amazon EC2) データ転送 Worker

Docker Compose によるコンテナ運⽤ • ⽅針 • ログは「logging: driver: awslogs」で CloudWatch Logs に送る • 死活監視は各コンテナが running かどうかを Amazon CloudWatch Metrics に送る • 「restart: unless-stopped」を設定すれば、サーバ再起動時にも勝⼿に起動してくる • Docker Compose のメリット • 設定ファイルを書くのも運⽤するのもとにかく楽 • 開発環境と設定ファイルを共有しやすい Kubernetes を使う理由を考えて、特になければ Docker Compose でも良いかもしれない (場合によっては) Docker Compose でも本番システムの運⽤はできる オンプレサーバは1台と割り切ったため、Kubernetes を使うまでもなく Docker Compose でコンテナ運⽤をすることにした

まとめ

まとめ • プログラミングが必要な箇所は Python で統⼀した • Python はなんでもできる (データ処理 / HTTP サーバ / 独⾃プロトコル) • 何らかの⾔語に統⼀することにメリットがあり、今回は機械学習に強みのある Python にした • AWS 側はマネージドサービスをフル活⽤する設計にした • データ処理だけでも様々な選択肢があるので、要件に合わせて検討した • オンプレサーバは可⽤性と耐久性を割り切ることで構築と運⽤のコストを削減した ⼯場に AI 導⼊とデータ分析基盤構築をした事例を紹介した