Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a ML system design_pattern
Semelhante a ML system design_pattern (20)
Mais de yusuke shibui
Mais de yusuke shibui (20)
ML system design_pattern
- 2. 自己紹介 shibui yusuke ● 自動運転スタートアップのティアフォー所属 ● 前職メルカリでAIとかKubernetesとか ● 文学部の大学院卒（イギリス史） ● もともとクラウド基盤の開発、運用。 ● ここ5年くらいMLOpsで仕事。 ● Github: @shibuiwilliam ● Qiita: @cvusk ● FB: yusuke.shibui ● 最近やってること: UnityとFlutterとIstio cat : 0.55 dog: 0.45 human : 0.70 gorilla : 0.30 物体検知
- 3. 今日話すこと 1. 少年時代からの夢が叶った！ 2. 『機械学習システムデザインパターン』が生まれた背景 3. 課題、プロセス、運用
- 6. 機械学習システムデザインパターン ● 2020年5月に機械学習システムの作り方をパターン化して公開。 「デザインパターン」と呼ぶには偉大な先人に畏れ多い。。。 ○ https://github.com/mercari/ml-system-design-pattern ● その内容をメルカリ卒業直前の 2020年8月のPyConJP 2020で公演。 ○ https://pycon.jp/2020/timetable/?id=203111 ● 翔泳社様にお声がけいただいて本を執筆。ついでに独自実装を公開。 ○ https://github.com/shibuiwilliam/ml-system-in-actions
- 7. 本を出版しました！ ● AIエンジニアのための 機械学習システムデザインパターン ● 2021年5月17日発売 ● https://www.amazon.co.jp/dp/4798169447/ ● 機械学習と銘打ってるのに KubernetesとIstioに 詳しくなれる一冊です！
- 9. みんなありがとう！ ● 翔泳社編集の宮腰さん、高橋さん、村上さん ● レビュアーのメルカリ上野さんと木村さん、ティアフォー関谷さん ● いろいろな機械学習プロジェクトでご一緒した皆様 ● ウィリアム（真ん中）、マルグレーテ（右）
- 11. 機械学習の実用化の課題 ● 機械学習チームのソフトウェア開発の理解不足 ● ソフトウェア開発チームの機械学習の理解不足 ● 機械学習を0->1だけで終わらせているプロジェクトを散見 → 機械学習を実用化し運用する方法をパターン化して共通理解を作る
- 12. 最近の機械学習界隈の状況 ● 研究から利用へ データ 機械学習 デプロイ 利用 課題 ユーザ システム 解決 開発
- 14. 0->1の次を目指す ● 解決策を洗練させる データ 機械学習 課題 ユーザ システム 0->1 機械学習で課題を解決する データから課題解決を評価する データで理解する 1->10 プロダクトの成長を実現する
- 15. 機械学習でビジネスをレベルアップする ● 開発と運用のサイクルを作る データ 機械学習 課題 ユーザ システム 機械学習で課題を解決する 機械学習を含めたUI/UXに反応する データ、機械学習、システムでユーザ体験をレベルアップする データを使う
- 16. ユーザ価値を改善することでチームを育成する ● 技術利用から課題解決へ データ 機械学習 課題 ユーザ システム 機械学習で課題を解決する 機械学習を含めたUI/UXに反応する データ、機械学習、システムでユーザ体験をレベルアップする データを使う サイクルを繰り返しスケールすることで課題解決の速度と質を向上させる 主体的な開発と運用を繰り返すことでチームのレベルアップを実現する → DevOps、MLOps データ ML SWE SRE PdM LevelUP !!
- 21. 課題、プロセス、運用
- 22. WFH with Catパターン ● ネコとともに在宅勤務するパターン。 ● 仕事中、食事中、睡眠中、あらゆる状況で 障害が発生する。 ● 作業を中断してネコが満足するまで撫でる 必要がある。 ● 撫でずに無視すると以下の障害を招く。 ○ キーボード歩き。 ○ 椅子爪研ぎ。 ○ ゴミ箱倒し。 ● 多頭飼いでは他ネコも平等に撫でないと 上記の障害を招く。 →安定稼働しているシステムでも不意に アラートが発生する。 →ひとつ対策を立ててもまた別の課題が生じる。
- 23. 課題
- 24. Good ● プロダクトの課題からはじめる ● リリースからはじめる ● ユーザへの価値からはじめる Bad ● 機械学習からはじめる ● 汎用基盤からはじめる ● 技術的な課題からはじめる Issueからはじめる
- 25. プロダクトを考える ネコ ネコ イヌ ・・・ ネコ 個数 位置 明るさ 場所 容易さ 便利さ 画像をアップロード 用途次第 カテゴリを選択 テキスト検索 フリーテキスト入力 自然言語処理 フリーテキストと属性 画像分類＋物体検知＋ 自然言語処理 画像から類似画像を検索 特徴量抽出＋ANN 3 暗 外 上
- 26. プロダクトを設計する ● 課題： 被写体が検索可能になるまでの時間が 長すぎる ● 条件： ○ 被写体を検索できる必要がある ○ コンテンツは違反検知を通して 問題ないと判定されている必要が ある ● 成功の定義： コンテンツが登録され検索可能になる までの時間をxx分以内に短縮する 写真を撮る タイトル入力 説明入力 登録する ねこ XX分
- 27. モデル開発
- 28. 学習の課題 ● 実用可能なモデルを開発するために実験しながら 各プロセスを行き来する ● 各プロセスのアウトプットの管理 ● 機械学習だけでなくモデルのシステム面での パフォーマンスや可用性（重すぎない、壊れない） ● 学習を運用するためのコードのリファクタリングと 学習の障害対応 データ分析、取得 前処理 学習 評価 ビルド モデル選定 パラメータ整理 システム評価
- 29. アンチパターン：Only meパターン ● コード、データ、モデルが管理されず、 開発者の環境でしか再現できない。 （開発者の環境でも再現できないこともある） ● DVCやML Metadataでステップごとに アウトプットを記録することを推奨。 ● Data validation：推論のサンプルデータと インターフェイス（入力データの型と shape、出力 データの型とshape、意味）を定義する。 import load local data evaluate retrain define ml train save model git no training data 99.99% ???
- 30. 学習のシステムと運用 データ取得 前処理 学習 評価 ビルド ● データパイプラインやMLパイプラインは 有向非巡回グラフとして定義。 ● 取得したデータを各フローで処理し、 結果をモデルレポジトリに記録。 ● ビルドのアウトプットは実行環境含めてDocker イメージとしてビルドすることも あれば、モデルのみをビルドし、実行環境は メタデータとして定義することもある。 ● メタデータにはモデルの学習、評価に 使った再現可能なデータ、パラメータ、 評価値を登録。 DWH ストレージ テスト データセット メタデータ モデルレポジトリ Image builder Docker registry Docker registry モデル選定 パラメータ整理 システム評価
- 31. モデルリリース
- 32. モデルリリースの課題 インフラ、OS ライブラリ モデル 入力 前処理 推論 出力 データ取得 前処理 学習 評価 ビルド インフラ、OS ライブラリ 学習環境のみ - Jupyter Notebook - バッチ学習用のライブラリ （例：PyTorch、TensorFlow、Keras） - バッチ学習用のインフラ（ GPUとか） - データ・モデルバージョニングツール - モデルビルダー 両環境に共通 - モデルファイル - 前処理で使うライブラリ （例：Sklearn、PIL、Mecab） - 入出力のデータ型と形 推論環境のみ - 推論用のライブラリ （例：ONNX Runtime, TF Serving） - ランタイムと外部インターフェイス - ロガーとモニタリングツール
- 33. サーバサイドにモデルをリリースする 1. モデルインイメージパターン 推論器のイメージにモデルを含めてビルドするパターン。 Dockerイメージサイズは大きくなるため、 Docker pullに時間を要する。 ベースイメージを共通化することで pull時間を短縮することが可能。 2. モデルロードパターン モデルファイルと推論器イメージを別に管理するパターン。 Dockerイメージを共通かつ軽量に保つことが可能。 学習時と推論イメージでソフトウェアのバージョン不一致が発生する可能性が残る。 学習環境と推論イメージでバージョニングする必要がある。
- 35. 推論システム
- 36. 課題 推論のタイミング ユーザの行動に対する推論のタイミング ● リアルタイム：行動とほぼ同時に推論 用途例：自動運転、AR、ゲーム ● 同期：行動ごとに推論を返す 用途例：検索、Web、手続き的な業務 ● 非同期：行動と切り離して推論 用途例：画面遷移等タイムラグのある用途 ● バッチ：データを溜めて推論 用途例：需要予測等、一括処理の用途 リアルタイム 同期 非同期 バッチ 返さない
- 37. 課題2 推論器のインターフェイス Docker image Runtime Model 入力 前処理 推論 出力 一度は経験する間違い： float32で学習した モデルをfloat16で推論して結果がおかしい。 REST API + Json ● Webではポピュラーな実装。 ● サーバ側でJsonを定義するが、 型が曖昧になるため、 入力値の検査が必要。 GRPC + Protocol Buffers ● TF ServingやONNX Runtime Serverで 標準提供。 （両者ともREST API + Jsonも標準提供） ● .protoファイルで入出力の型含めて 定義可能。クライアント、サーバで 共通化できるが、Webに弱い。 値の範囲や形式 ● 正常に推論可能なデータの範囲。 ● 自然言語の言語。 ● 画像のフォーマット、 RGB、その他。 {input_data: []} ((1,3,224,224)) float32 {prediction: []} (1000,) float32 Node pool Node LB
- 38. Edge AIパターン クラウドで学習 Python クライアントで推論 Kotlin/Swift/C++ 後処理 前処理 学習 前処理 推論 モデル モデル 変 換
- 39. 同期推論パターン ロードバランサー REST API Docker Python image Gunicorn Uvicorns FastAPI Model ● 最もシンプルな構成の推論器。 ● すぐリリースしたいときに有効。 ● GunicornやUvicornをベースに FlaskやFastAPIで稼働。 Gunicorn(WSGI) Uvicorn (ASGI) Uvicorn (ASGI) Gunicorn(WSGI) Flask Flask
- 40. 非同期推論パターン メッセージ 推論器 ● 推論結果を同期的に得る必要がない場合に 有効なパターン。 ● クライアントと推論器の中間にKafkaやRedisを 配置することで実現。 ● 非同期の方式はリクエスト非同期型、 Publish/Subscribe型、Notification型等がある。 ワークフローに応じて選択。 ● ただしディープラーニングでは、ユーザを 待たせないために非同期とし、許容時間内のみ ポーリングすることも可能。 Docker Python image multiprocessing Model Runtime Client クライアント
- 41. 時間差推論パターン ● 複数の推論器でレイテンシーに差がある場合、 速い推論器は同期的に返し、遅い推論器の レスポンスを非同期にする。 ● クライアントと推論器の中間にProxyを置き、Proxyで 各推論器へのリクエストを制御する 構成。 ● 推論器は同期、非同期両方のエンドポイントを 公開しておくことで、より柔軟な対応が可能。 この構成の場合、メッセージングではなく CeleryやBackgroundTasksで実装。 Client LB Sklearn SyncA Deep learning AsyncB Proxy キャッシュ Environment Variable - SVC_A: SyncA - SVC_B: AsyncB - SVC_A_EP: predict - SVC_B_EP: async
- 42. バッチ推論パターン ● データを収集して定期的に一括処理する ● 周辺システムのデータ処理によって推論に 使えるデータに差異が生まれる ● 学習の段階で推論時に使えるタイミングの データを想定して開発する必要がある ● スケジューリングが肝 DB バッチ処理 Docker Batch Model 木 金 木 水 火 月 土 日 月 火 水 木 金 土 金 この1週間の需要を予測する デッドライン バッチ推論完了 失敗時はリトライ 需要予測 バッチ起動 水 火 月 土 日 土 日 テストデータ 学習 データ 日
- 43. 機械学習の品質と運用
- 44. アンチパターン：Nobody knowsパターン ● 稼働中の推論器がなぜ動いているのか 誰も知らないパターン。 歴史的にシステムが複雑になっていくと 頻繁に発生する。 ● MLプロジェクトの初期にプロトタイプで 作ったモデルや、緊急対応で稼働させた 推論器を残しておくと「Nobody knows」に なる。 ● 学習データが残っていない状態は珍しくない。 学習コードもJupyter Notebookのみという 場合、モデルの評価や再現が困難。 LB API API API ML? API ML? このモデルを作った のは誰だあっ!! ぴえん(T_T)
- 45. アンチパターン ● 推論器が遅すぎてユーザを待たせてる。 ● 性能劣化した推論器でも継続して すべてのリクエストに推論を返す。 test data accuracy: 99.99% 5秒/req 2015年の accuracy: 99.99% ネコ！ イヌ！ 2015年 2020年 5秒で離脱
- 46. 機械学習システムの品質 機械学習システムの品質には 3カテゴリある。 1. 機械学習の推論モデル a. 推論モデルのパフォーマンス b. 本番データの変化による劣化とエラー c. 問題定義とソリューション 2. 推論モデルを稼働させるシステム a. 入出力のデータやデータ型 b. 推論スピードと可用性 c. 例外処理 3. 運用と体制 a. モデルの再現および再学習 b. 推論器の再現およびロールバック c. 維持可能な運用体制 Client LB LB int float test data accuracy: 99.99% 何のML だっけ？ 1sec/req モデル作った VM消したよ dockerimg:latest 上書き error率 0.01% アサイン 変わった me too 転 職 商品カテゴリ 追加削除 そして誰も いなくなった
- 47. 機械学習の推論スピード ● 推論器のボトルネックは推論。 Deep learningの場合、9割Deep learningなこともある ● 学習コストの高いDeep learningは学習後に測定するのではなく、学習前に測っておく 入力 前処理 推論 後処理 出力 通信 前処理 推論 後処理 出力 通信 入力 所要時間 通信
- 48. 可用性 ● サーキットブレーカー ○ 急激な負荷増で処理能力やスケールアウトが 間に合わない場合、一部のリクエストを 遮断して全断を防ぐ。 ○ NginxやEnvoy proxyで標準装備。 ● 推論のバックアッププランと例外処理 ○ デフォルトの推論結果や挙動を決めておいて、 エラー発生時はデフォルトの挙動を発動。 ○ 障害発生時や遅延時に有効。 ○ 本番データの傾向が変わって推論器が性能劣化 している場合も環境変数でデフォルトの推論を 返すようにすることもできる。 Client LB Nginx 推論器 circuit break over 300rps Client LB LB <= 300rps: 推論 > 300rps: default 0
- 50. 機械学習システムの監視 Client LB LB 時間 RAM CPU group A CTR group B 時間 req/sec レイテンシー（ms） 時間 nodes 時間 error rate ● ユーザ価値は機械学習だけではない →各コンポーネントの稼働がユーザ価値を支える。 時間
- 52. 本に書きたかったけど書ききれなかったこと ● 各パターンを組み合わせたシステム ● 機械学習の実務的評価とデータドリフトやコンセプトドリフトの対処 ● Edge AIにおけるモデル評価と配布。あと MediaPipeやUnity Barracuda ● Data Validationと機械学習システムに特化したコーディング規約とユニットテスト ● あと本書の英語版と中国語版を出版したいです。
- 53. ご清聴 ありがとうございました。