CyberAgent AI事業本部MLOps研修基礎編

©2023 CyberAgent Inc. Distribution prohibited
Dynalyst 干飯啓太
MLOps基礎編

View Slide

Today’s Schedule
10: 00 - 12: 30: Container編
13: 45 - 14: 45: MLOps基礎編
15: 00 - 18: 30: MLOps応用編

View Slide

本講義のゴール
3
持続可能なMLシステム

View Slide

自己紹介
干飯啓太(ほしいけいた)
略歴: 22卒 ML Engineer/Data Scientist
所属: Dynalyst
タスク: DSPのロジック改善・MLOpsなど
興味のある技術領域
MLOps、ソフトウェアエンジニアリング
4
@hosimesi11_ @hosimesi

View Slide

アジェンダ
5
1. MLOpsとは
2. なぜMLOpsが必要なのか
3. MLOpsレベル別紹介
4. 推論システム紹介
5. 学習ワークフロー紹介
6. アンチパターン
7. システムの品質担保
8. 最後に

View Slide

アナウンス
6
本講義はMLOps基礎編で、実際に手を動かしてもらうのは応用編からに
なります
実践編でもMLOpsの要件が入ってきますので、理解を深めておくとスムーズ
かと思います

View Slide

01
MLOpsとは
7

View Slide

01
MLOpsとは
の前にDevOpsとは
8

View Slide

DevOpsとは
9
Googleによると
ソフトウェアデリバリーの速度とサービスの信頼性の向上、ソフトウェア
の関係者間で共有するオーナー権限の構築を目的とする、組織的で文化的な
仕組み
● デプロイの高速化
● ソフトウェアの安定性の向上
https://cloud.google.com/devops?hl=ja

View Slide

MLOpsとは
10
Googleによると
MLOpsは、MLシステム開発（Dev）とシステムオペレーション（Ops）の
統合を目的とする ML エンジニアリングの文化と手法
MLOpsは、統合、テスト、リリース、デプロイ、インフラストラクチャ管理
など、ML システム構築のすべてのステップで自動化とモニタリングを推進
する
https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning?hl=ja

View Slide

MLOpsとは
11
Googleによると
MLOpsは、MLシステム開発（Dev）とシステムオペレーション（Ops）の
統合を目的とする ML エンジニアリングの文化と手法
MLOpsは、統合、テスト、リリース、デプロイ、インフラストラクチャ管理
など、ML システム構築のすべてのステップで自動化とモニタリングを推進
する
実際何すればいいの？

View Slide

MLOpsを構成する要素
12
https://proceedings.neurips.cc/paper_ﬁles/paper/2015/ﬁle/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf
おおげさに書きすぎている部分もあるが、、、
モデル作成はサービスの一部分であり、システム全体まで責務を持つ

View Slide

MLOpsのタスク
13
機械学習サービスを継続的に稼働させるために、他職種と協力して様々な基盤
を構築する
● データ基盤
● ログ基盤
● 学習基盤
● 推論基盤
● モニタリング基盤
守備範囲が広すぎるように見えるが、1人ですべてできる必要はない

View Slide

一般的に、機械学習サービスと呼ばれるものに対して思い浮かぶもの
一般的な機械学習サービス
14

View Slide

実際の機械学習システム
15

View Slide

MLOpsとは
16
つまり、MLOpsは
● 継続的なテスト(CI)
● 継続的なデプロイ(CD)
● 継続的な学習(CT)
● 継続的なモニタリング(CM)
これらに+αでバージョン管理(コード、モデル)やインフラ管理もして、
持続可能なMLシステムをつくること

View Slide

02
なぜMLOpsが必要なのか
17

View Slide

機械学習の価値
18
機械学習は推論して初めて価値を発揮
● 推論した値そのもの
○ CTR予測を使った入札
● 推論した値を使った意思決定
○ レコメンド
オフライン検証での精度改善だけでは不十分で、実際にシステムに載せ、
意図通りの推論をして初めてビジネス的な価値が生まれる

View Slide

散乱する機械学習
19
このような経験はありませんか
● 散乱したノートブック
○ EDA的な部分も多くコードも複雑になりやすい
● どのハイパラを使ったか分からない
● どのモデルがどんな特徴量の処理を使ったか分からない
● かろうじてコードはgitで管理

View Slide

MLシステム問題
20
この状態でシステムに載せた場合、様々な問題が起きる
● モデルのバージョンが分からず、障害が起きた時に切り戻せない
● 特徴量の変換が意図通り行われているか判断できない
● 各個人のノートブックベースのコードになるので、コードの品質が担保
できない
その他にも
● モデル精度の劣化に対応できない
○ 時系列などで精度が劣化するため継続的に学習する必要性
● テストの欠如

View Slide

21
これらを全て手動ですると疲弊するかつ、実験サイクルのスピード低下
➡ MLOpsを導入することで品質を担保しつつ、自動化してスケールさせる
● 継続的なテスト(CI)
● 継続的なデプロイ(CD)
● 継続的な学習(CT)
● 継続的なモニタリング(CM)

View Slide

構成する要素と役割
22
CI/CD
● 自動テスト・linterによるコード品質の担保、開発者体験の向上
● 自動デプロイにより開発とデプロイのサイクルを高速化
Continuous Training(CT)
● 自動的なモデルの再学習
● モデル精度の担保、評価
Continuous Monitoring(CM)
● 共変量シフトや意図しない入力による予測値の変化に対応する
● レイテンシやリソースの異常に対応する

View Slide

構成する要素(ML特有)
23
● ログ収集基盤・A/Bテスト基盤
○ ログを貯めることで再学習に回す
○ A/Bテストの結果を通じて意思決定する
● バージョン管理
○ 実験やモデルの再現性を担保
○ システム・モデルを容易に元のバージョンに戻せる

View Slide

24
いきなり全部はじめる必要はない
モデルの更新頻度が多くないプロダクトの場合、ワークフローの優先度は
そこまで高くない
● モデルのバージョン管理等の方が優先度高い
自分たちのプロダクトにあったものを優先度つけて取り入れることが重要

View Slide

03
レベル別MLOps
25

View Slide

レベル別MLOps
26
Googleによると大きくMLOpsには大きく3つのフェーズ
レベル0: 手動プロセス
レベル1: MLパイプラインの自動化
レベル2: CI/CDパイプラインの自動化

View Slide

レベル0: 手動フェーズ
27

View Slide

レベル0: 手動フェーズ
28
全てのプロセスを手動実行
● データ準備・分析
● モデル学習・モデルデプロイ
ノートブック等でモデルを学習し、学習済みモデルを手動でデプロイ
モニタリングやバージョン管理は未導入
DS/ML
データ収集・分析モデル学習・評価デプロイ
DS/ML
DS/ML

View Slide

29

View Slide

30
自動化が進む
● データ準備・分析: 自動化
● モデル学習・モデルデプロイ: 自動化
一方でパイプラインのテストやビルド・デプロイは手動のまま
自動自動自動
DS/ML
コードの
ビルド・デプロイ

View Slide

31

View Slide

32
CI/CDが導入され、コードのテスト・ビルド・デプロイが自動化
ワークフロー内での新モデルの検証やハイパーパラメータの
チューニングなども自動化
自動自動自動
コードの
ビルド・デプロイ
自動

View Slide

実際に導入した後
33
MLシステムを作ったあと、MLシステムを定量的に評価したい
オンラインで継続的に学習・推論を行う教師ありの機械学習システム
の場合
ML Test Score
Googleが提唱しているMLシステムを評価する仕組み
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/aad9f93b86b7addfea4c419b9100c6cdd26cacea.pdf

View Slide

ML Test Score
34
以下の4つのカテゴリーでそれぞれ7項目あり、それらを点数づけ
● 特徴量とデータについて
● モデル開発について
● MLのインフラについて
● MLのモニタリングについて
MLシステムを定量化することで、伸ばすべき部分を明確化
興味のある方は以下のリンクを参考
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/aad9f93b86b7addfea4c419b9100c6cdd26cacea.pdf

View Slide

レベル別MLOps
35
紹介したMLOpsレベルはあくまで参考であり、これだけが正ではない
Big Techを模倣するとオーバースペックになりがちなので、実際の
プロダクトのニーズに優先度をつけて小さく取り組むことが大事

View Slide

MLOpsのコンポーネント
36
MLOpsを構成するもののうち、重要なコンポーネントについてもう少し詳し
く紹介する
1. 推論パターン
2. 学習ワークフロー
3. A/Bテストパターン

View Slide

04
推論パターン紹介
37

View Slide

推論パターン
ひとくちに推論といっても用途によって様々
● 推論アーキテクチャも複数存在
● モデルのデプロイ方法も複数存在
機械学習システムデザインパターンを例に、一般的なWebアプリケーションや
実践編で作るDSPを例に紹介
コードをいくつか例示しますが、クレデンシャルや特徴量の前処理の部分は省略しています
https://mercari.github.io/ml-system-design-pattern/README_ja.html

View Slide

紹介するパターン
推論アーキテクチャ
● リアルタイム推論
● バッチ推論
● 非同期推論
モデルデプロイ方法
● モデルビルドイン
● モデルロード
A/Bテスト基盤
● アプリケーションレベル
● ネットワークレベル

View Slide

リアルタイム推論
用途：
インタラクティブに処理する必要がある場合や、推論結果を使用した処理が
走る場合に使われる方法
例
● RTBにおけるCTR・CVR予測
● リアルタイムでの異常検知
https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Synchronous-pattern/design_ja.html

View Slide

シンプルな推論アーキテクチャ
特徴量変換・推論をパイプライン的にリアルタイムに行う
https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Synchronous-pattern/design_ja.html

View Slide

モデルを複数使いたい場合は前段に振り分けるためのProxyサーバを置いて、
コンテナレベルで分けたり、同じアプリケーションで振り分けてもOK

View Slide

バッチ推論
用途：
リアルタイムに推論する必要がなく、毎時やデータ追加などイベントを
トリガーに定期的に溜まったデータを推論した時に用いられる方法
例
● 広告文をデータが溜まったタイミングで一括で自動生成する
● 推薦システムで一括でベクトルを更新する
ツール
● DWH(Snowflake、Redshift)・Workflow Tool(Airflow、Prefect)
https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Batch-pattern/design_ja.html

View Slide

DWH等の推論対象を含むデータストアからデータを抽出し、特徴量変換・
推論をして、DB等に格納する
推論処理自体はリアルタイム推論と同じ
https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Batch-pattern/design_ja.html
バッチ推論

View Slide

非同期推論
用途：
計算量が多く、推論してからレスポンスを返すとブラウザのタイムアウトに
間に合わない場合などに非同期で処理する方法
リクエストと推論器の間にMQやキャッシュを入れる
例
● ユーザからの設定や入力によって、MLモデルを学習させるWebサービス
ツール
● キュー(RabbitMQ、Kafka)・キャッシュ(Redis)
https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Asynchronous-pattern/design_ja.html

View Slide

非同期推論
非同期で処理するため、キューにメッセージを送信し、クライアントには
リアルタイムでレスポンスを返す
別サーバで推論を行い、クライアントとはDBやキューを介して結果を共有
https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Asynchronous-pattern/design_ja.html

View Slide

それぞれのメリット
● リアルタイム推論
○ リアルタイムで処理する必要があるものは一択
● バッチ推論
○ サーバの常時稼働が必要ないことによるコスト削減
○ 失敗した場合のリトライ
○ 並列実行
● 非同期推論
○ 推論基盤を切り離せ、MLとその他で疎結合なシステム
■ 依存関係
■ サーバのリソース

View Slide

デプロイ方法
1. モデルビルドイン
a. Dockerのビルド時にモデル保存先のフォルダごとコピーし、
イメージの中にモデルごと入れ込む方法
2. モデルロード
a. Dockerのビルド時にはモデルを入れ込まず、エントリーポイントの
実行時などに外部ストレージから取得

View Slide

モデルビルドパターン
ﬁles直下の学習済みモデルをビルド時に入れる
起動させる時に、ローカルフォルダに置いているモデルを展開する
FROM python:3.9.16-slim
WORKDIR /app
COPY requirements requirements
RUN pip install --upgrade pip \
&& pip install -r requirements/requirements.bid.txt
COPY ../src /app/src
COPY ../logs /var/log
COPY ../files /app/files
ENV AWS_DEFAULT_REGION ap-northeast-1
app = FastAPI()
MODEL_FILE_DIR = "files"
def load_model(model_file_name: str) -> object:
with open(os.path.join(MODEL_FILE_DIR, model_file_name), "rb") as f:
model = pickle.load(f)
return model
model = load_model(model_file_name="model.pkl")
@app.get("/")
def health_check():
return {"Hello": "World"}

View Slide

モデルビルドイン
メリット
● サーバとモデルを一つのイメージで管理可能なため、イメージの
バージョン管理のみに集約可能
デメリット
● イメージ分のサイズがモデル分大きくなるのでビルドに時間がかかる
○ 複数モデルは載せにくい
○ 一般的にイメージは軽量の方が良いので、この方法だとあまり
スケールしない

View Slide

モデルロード
モデルは外部ストレージ(S3など)においておき、起動時にダウンロードして
展開
FROM python:3.9.16-slim
WORKDIR /app
COPY requirements requirements
RUN pip install --upgrade pip \
&& pip install -r requirements/requirements.bid.txt
COPY ../src /app/src
COPY ../logs /var/log
RUN mkdir /app/files
ENV AWS_DEFAULT_REGION ap-northeast-1
app = FastAPI()
S3_BUCKET = "s3_bucket"
def fetch_model(s3_bucket: str, s3_key: str) -> Any:
s3 = boto3.resource("s3")
bucket = s3.Bucket(s3_bucket)
byte_obj = bucket.Object(s3_key).get()["Body"].read()
return pickle.loads(byte_obj)
model = fecth_model(s3_bucket=S3_BUCKET, s3_key="path/to/model")
@app.get("/")
def health_check():
return {"Hello": "World"}

View Slide

モデルロード
メリット
● サーバとモデルを分離して管理可能なため、柔軟なイメージ管理が可能
● サーバイメージの軽量化
デメリット
● サーバイメージとモデルのバージョン管理が必要になり、依存関係も
注意する必要あり

View Slide

A/Bテスト基盤
何かの施策の効果検証の際、A/Bテストがよく使用されるが、A/Bの基盤も
いくつか存在
CTR予測モデルAとBのA/Bテストをしたい時
● トラフィックレベルの振り分け
● アプリケーションレベルの振り分け

View Slide

トラフィック振り分け
モデルごとにエンドポイントをわけ、プロキシサーバからのトラフィックを
分割
切り戻しが容易で他のモデルの影響(サーバのリソースなど)を受けにくい

View Slide

アプリケーション振り分け
同一エンドポイントに複数モデルを載せ、アプリケーション内でどのモデルを
使うかを振り分け
スケール戦略やA/Bの設定が楽

View Slide

A/Bテストのログ収集
A/Bテストや推論ログの蓄積のため、推論用のコンテナとログ収集用の
コンテナをサイドカーとして一つのサーバにデプロイするような構成もある

View Slide

05
学習ワークフロー紹介
57

View Slide

学習ワークフロー概略
学習ワークフローを構成するStep
● Extract step
● Validate data step
● Preprocess step
● Train step
● Evaluate step
● Validate model step

View Slide

学習ワークフロー
Extract step
● データをストレージ(DWHなど)から抽出
Validate data step
● データのスキーマが変わっていないか
● 過去とデータの分布が変わっていないか
Preprocess step
● モデルを学習させるための前処理

View Slide

学習ワークフロー
Train step
● モデルの学習
Evaluate step
● 学習済みモデルのテストデータでの予測値を評価
● 現在のモデルと新モデルの比較
○ 優れている場合のみデプロイなど
Validate model step
● インフラとの互換性やAPIとの整合性を担保

View Slide

06
アンチパターン
61

View Slide

アンチパターン１
いきなり大きく作り始める
● 初めから全ての自動化に取り組むのは筋が悪い
● MLOpsの開始時は投資的な意味合いが大きくなる(定量的に改善具合を
示しにくい)のでPoCと同様に小さく作る
● Big Techに寄せなくてよく、自分たちのプロダクトの重要な課題のみに
フォーカスする

View Slide

アンチパターン2
運用を考えた設計になっていない
● 少人数なチームの場合、k8sなどリッチな環境を整えても運用できる人が
いないと意味がない
● 導入後の運用工数まで意識する

View Slide

アンチパターン3
コストを度外視しており、とりあえず機械学習を入れようとする
● 機械学習は負債になりやすいので、導入すべきかはよく検討する
○ 機械学習導入による削減コストと人的コストの場合のみ導入する
■ 機械学習導入による削減コスト > 人的コスト
● 一般的に大規模モデルほど精度が向上するがコスト↑
○ 精度向上による利益 > コスト(インフラ代)の場合のみ導入する
■ 単純な線形モデル等も検討に入れる

View Slide

07
システムの品質を担保する
65

View Slide

モニタリング
システムが正常に動作しているかモニタリングし、適切にアラートをあげる
学習
● データ数・分布
● オフライン評価
推論
● 予測値
● インフラのメトリクス
● レスポンスタイム・QPS
● オンライン評価

View Slide

負荷試験
いざ推論サーバを立てた時に性能が足りず頓挫しないように事前に必要要件を
定義し、負荷試験をする
実際の想定より厳しめに負荷試験をすることで、サービスの品質を担保する
問題があった際、ボトルネックの切り分けを行う
重要なことは、ボトルネックの特定のみならず、原因特定のための必要なメト
リクスが取れていることも意識する
→ 実運用時の早急な障害対応の観点

View Slide

ボトルネックの解消
アプリケーション側がボトルネックの場合、該当箇所を特定する
1. Proﬁler(※)を使ってボトルネックを特定する
2. ボトルネックを解消する
a. コンピュートリソースを増強する
b. アルゴリズムを変更する
c. キャッシュを入れる
d. コードレベルで最適化する(C++、Cython)
※ Appendixに記載

View Slide

08
最後に
69

View Slide

最後に
70
○ MLを本当に使うべきかを考える
○ ゴールはビジネス課題の解決であって、MLサービスを作ることではない
○ MLを導入した時のコストと解決できるコストを評価する
○ 小さく作り始める
○ いきなり完成系を目指すのではなく、小さく作り始める
■ デプロイは手動・簡単な線形モデルから
○ コミュニケーションを忘れない
○ 守備範囲が広く1人ではできないからこそ、チームメンバー(Biz、SWE、DS)と
適切にコミュニケーションを取り、すり合わせる

View Slide

09
参考
71

View Slide

参考図書
72
機械学習システムデザインパターン
● 本スライドの元にしている本
● MLOpsのモチベーションからシステム
まで実装多めに網羅している
Clean Architecture
● システム設計で気を付けるべきことを
記述している
興味があれば手に取ってみてください

View Slide

参考リンク
73
● GoogleによるMLシステムの全体像
● Google MLOps
● Azure MLOps
● AWS MLOps
● メルカリ機械学習デザインパターン

View Slide

10
Appendix
74

View Slide

プロファイラ
PythonではプロファイラとしてcProﬁle
が提供されている
各部分の呼び出し回数や実行時間の
統計情報を記録
(statsファイルとして吐き出せる)
https://docs.python.org/ja/3/library/profile.html
import cProfile
def sum_func(a: int, b: int) -> int:
return a + b
def main():
profiler = cProfile.Profile()
n = profiler.runcall(sum_func, 1, 2)
profiler.dump_stats("./sum_func.stats")
if __name__ == "__main__":
main()

View Slide

プロファイラ
statsをgprof2dotでpngに変換すると、ボトルネック箇所を特定可能
$ gprof2dot -f pstats {stats_file_name}.stats | dot -Tpng -o output.png

View Slide


View Slide

CyberAgent AI事業本部MLOps研修基礎編

CyberAgent AI事業本部MLOps研修基礎編

Keita Hoshii

Other Decks in Technology

Featured

Transcript