Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Machine learning system design pattern

Machine learning system design pattern

Machine learning system design pattern

shibuiwilliam

March 17, 2022
Tweet

More Decks by shibuiwilliam

Other Decks in Technology

Transcript

  1. 自己紹介 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 物体検知
  2. 私の半生(反省) 文学部 イギリス史 文学部大学院 イギリス史 SIer クラウド作る メルカリ MLOpsとか ティアフォー

    データ? いろいろ 少年時代 本ばかり読む ~2003年 ~2007年 ~2009年 ~2015年 2017年頃 2018年 2020年 本を書くのが夢 挫折 クラウドデザイン パターンに出会う 機械学習を 始める 本を書く 本の元ネタ
  3. 0->1の次を目指す • 解決策を洗練させる データ 機械学習 課題 ユーザ システム 0->1 機械学習で課題を解決する

    データから課題解決を評価する データで理解する 1->10 プロダクトの成長を実現する
  4. ユーザ価値を改善することでチームを育成する • 技術利用から課題解決へ データ 機械学習 課題 ユーザ システム 機械学習で課題を解決する 機械学習を含めたUI/UXに反応する

    データ、機械学習、システムでユーザ体験をレベルアップする データを使う サイクルを繰り返しスケールすることで課題解決の速度と質を向上させる 主体的な開発と運用を繰り返すことでチームのレベルアップを実現する → DevOps、MLOps データ ML SWE SRE PdM LevelUP !!
  5. 機械学習を使ったプロダクト例 画像処理 写真を撮る タイトル入力 説明入力 登録する 自然言語処理 違反検知 登録情報から違反を フィルタリング

    入力情報から 入力補助 超解像による 画質改善 ねこ 検索 協調フィルタリングや ランク学習による 並べ替え あるコンテンツ登録アプリ 画像分類と 検索
  6. 機械学習を使ったプロダクトの課題例 画像処理 写真を撮る タイトル入力 説明入力 登録する 自然言語処理 違反検知 登録情報から違反を フィルタリング

    入力情報から 入力補助 超解像による 画質改善 ねこ 検索 協調フィルタリングや ランク学習による 並べ替え あるコンテンツ登録アプリ 画像分類と 検索タグ どう学習する? →定期的 →不定期 →評価が悪くなったとき いつ推論する? →検索時 →データ登録時 →1時間ごとにまとめて どう評価する? →Accuracy, Confusion Matrix →検索数、CTR、いいね数
  7. 機械学習を使ったプロダクトのシステム例 写真を撮る タイトル入力 説明入力 登録する ねこ あるコンテンツ登録アプリ ログ DB Storage

    監視 学習 モデル proxy 画像 API 推論 API batch BI デプ ロイ 認証 認可 ID 検索 API Item API 推薦 API Text API
  8. WFH with Catパターン • ネコとともに在宅勤務するパターン。 • 仕事中、食事中、睡眠中、あらゆる状況で 障害が発生する。 • 作業を中断してネコが満足するまで撫でる

    必要がある。 • 撫でずに無視すると以下の障害を招く。 ◦ キーボード歩き。 ◦ 椅子爪研ぎ。 ◦ ゴミ箱倒し。 • 多頭飼いでは他ネコも平等に撫でないと 上記の障害を招く。 →安定稼働しているシステムでも不意に  アラートが発生する。 →ひとつ対策を立ててもまた別の課題が生じる。
  9. プロダクトを考える ネコ ネコ イヌ ・・・ ネコ 個数 位置 明るさ 場所

    容易さ 便利さ 画像をアップロード 用途次第 カテゴリを選択 テキスト検索 フリーテキスト入力 自然言語処理 フリーテキストと属性 画像分類+物体検知+ 自然言語処理 画像から類似画像を検索 特徴量抽出+ANN 3 暗 外 上
  10. プロダクトを設計する • 課題: 被写体が検索可能になるまでの時間が 長すぎる • 条件: ◦ 被写体を検索できる必要がある ◦

    コンテンツは違反検知を通して 問題ないと判定されている必要が ある • 成功の定義: コンテンツが登録され検索可能になる までの時間をxx分以内に短縮する 写真を撮る タイトル入力 説明入力 登録する ねこ XX分
  11. 学習の課題 • 実用可能なモデルを開発するために実験しながら 各プロセスを行き来する • 各プロセスのアウトプットの管理 • 機械学習だけでなくモデルのシステム面での パフォーマンスや可用性(重すぎない、壊れない) •

    学習を運用するためのコードのリファクタリングと 学習の障害対応 データ分析、取得 前処理 学習 評価 ビルド モデル選定 パラメータ整理 システム評価
  12. アンチパターン: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% ???
  13. 学習のシステムと運用 データ取得 前処理 学習 評価 ビルド • データパイプラインやMLパイプラインは 有向非巡回グラフとして定義。 •

    取得したデータを各フローで処理し、 結果をモデルレポジトリに記録。 • ビルドのアウトプットは実行環境含めてDocker イメージとしてビルドすることも あれば、モデルのみをビルドし、実行環境は メタデータとして定義することもある。 • メタデータにはモデルの学習、評価に 使った再現可能なデータ、パラメータ、 評価値を登録。 DWH ストレージ テスト データセット メタデータ モデルレポジトリ Image builder Docker registry Docker registry モデル選定 パラメータ整理 システム評価
  14. モデルリリースの課題 インフラ、OS ライブラリ モデル 入力 前処理 推論 出力 データ取得 前処理

    学習 評価 ビルド インフラ、OS ライブラリ 学習環境のみ - Jupyter Notebook - バッチ学習用のライブラリ  (例:PyTorch、TensorFlow、Keras) - バッチ学習用のインフラ( GPUとか) - データ・モデルバージョニングツール - モデルビルダー 両環境に共通 - モデルファイル - 前処理で使うライブラリ  (例:Sklearn、PIL、Mecab) - 入出力のデータ型と形 推論環境のみ - 推論用のライブラリ  (例:ONNX Runtime, TF Serving) - ランタイムと外部インターフェイス - ロガーとモニタリングツール
  15. サーバサイドにモデルをリリースする 1. モデルインイメージパターン 推論器のイメージにモデルを含めてビルドするパターン。 Dockerイメージサイズは大きくなるため、 Docker pullに時間を要する。 ベースイメージを共通化することで pull時間を短縮することが可能。 2.

    モデルロードパターン モデルファイルと推論器イメージを別に管理するパターン。 Dockerイメージを共通かつ軽量に保つことが可能。 学習時と推論イメージでソフトウェアのバージョン不一致が発生する可能性が残る。 学習環境と推論イメージでバージョニングする必要がある。
  16. サーバサイドのモデルリリース 推論用 Dockerイメージ ランタイム モデル 学習 Docker イメージビルダー モデル管理 推論器

    推論器 推論用Docker ベースイメージ ランタイム Dockerレジストリ 保存 モデルファイル モデルを含めて Dockerビルド モデルインイメージパターン モデル管理 保存 モデルファイル 推論用Docker ベースイメージ ランタイム デプロイ モデルロードパターン デプロイ時に モデルをロード
  17. 課題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
  18. 同期推論パターン ロードバランサー REST API Docker Python image Gunicorn Uvicorns FastAPI

    Model • 最もシンプルな構成の推論器。 • すぐリリースしたいときに有効。 • GunicornやUvicornをベースに FlaskやFastAPIで稼働。 Gunicorn(WSGI) Uvicorn (ASGI) Uvicorn (ASGI) Gunicorn(WSGI) Flask Flask
  19. 非同期推論パターン メッセージ 推論器 • 推論結果を同期的に得る必要がない場合に 有効なパターン。 • クライアントと推論器の中間にKafkaやRedisを 配置することで実現。 •

    非同期の方式はリクエスト非同期型、 Publish/Subscribe型、Notification型等がある。 ワークフローに応じて選択。 • ただしディープラーニングでは、ユーザを 待たせないために非同期とし、許容時間内のみ ポーリングすることも可能。 Docker Python image multiprocessing Model Runtime Client クライアント
  20. 時間差推論パターン • 複数の推論器でレイテンシーに差がある場合、 速い推論器は同期的に返し、遅い推論器の レスポンスを非同期にする。 • クライアントと推論器の中間に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
  21. バッチ推論パターン • データを収集して定期的に一括処理する • 周辺システムのデータ処理によって推論に 使えるデータに差異が生まれる • 学習の段階で推論時に使えるタイミングの データを想定して開発する必要がある •

    スケジューリングが肝 DB バッチ処理 Docker Batch Model 木 金 木 水 火 月 土 日 月 火 水 木 金 土 金 この1週間の需要を予測する デッドライン バッチ推論完了 失敗時はリトライ 需要予測 バッチ起動 水 火 月 土 日 土 日 テストデータ 学習 データ 日
  22. アンチパターン:Nobody knowsパターン • 稼働中の推論器がなぜ動いているのか 誰も知らないパターン。 歴史的にシステムが複雑になっていくと 頻繁に発生する。 • MLプロジェクトの初期にプロトタイプで 作ったモデルや、緊急対応で稼働させた

    推論器を残しておくと「Nobody knows」に なる。 • 学習データが残っていない状態は珍しくない。 学習コードもJupyter Notebookのみという 場合、モデルの評価や再現が困難。 LB API API API ML? API ML? このモデルを作った のは誰だあっ!! ぴえん(T_T)
  23. 機械学習システムの品質 機械学習システムの品質には 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 転 職 商品カテゴリ 追加削除 そして誰も いなくなった
  24. 可用性 • サーキットブレーカー ◦ 急激な負荷増で処理能力やスケールアウトが 間に合わない場合、一部のリクエストを 遮断して全断を防ぐ。 ◦ NginxやEnvoy proxyで標準装備。

    • 推論のバックアッププランと例外処理 ◦ デフォルトの推論結果や挙動を決めておいて、 エラー発生時はデフォルトの挙動を発動。 ◦ 障害発生時や遅延時に有効。 ◦ 本番データの傾向が変わって推論器が性能劣化 している場合も環境変数でデフォルトの推論を 返すようにすることもできる。 Client LB Nginx 推論器 circuit break over 300rps Client LB LB <= 300rps: 推論 > 300rps: default 0
  25. 機械学習システムの監視 Client LB LB 時間 RAM CPU group A CTR

    group B 時間 req/sec レイテンシー(ms) 時間 nodes 時間 error rate • ユーザ価値は機械学習だけではない →各コンポーネントの稼働がユーザ価値を支える。 時間